linux/drivers/hid/hid-magicmouse.c

1126 lines
34 KiB

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed <andfed.net@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-06 19:55:07 +02:00
HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed <andfed.net@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-06 19:55:07 +02:00
HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: if ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, connect_mask & HID_CONNECT_HIDINPUT_FORCE)) hdev->claimed |= HID_CLAIMED_INPUT; and the "device has no listeners" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the "input not registered" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well. Fixes: f1a9a149abc8 ("HID: magicmouse: fix race between input_register() and probe()") Link: https://lore.kernel.org/linux-input/20260728185542.65F091F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: Jose Villaseñor Montfort <pepemontfort@gmail.com> Reviewed-by: Alec Hall <signshop.alec@gmail.com> Tested-by: Alec Hall <signshop.alec@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-28 22:15:57 -06:00
HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad USB-C The Apple Magic Trackpad 2 (USB-C) reports a wildly wrong battery capacity over Bluetooth, for example a constant 4% for a pack that is actually at 74%. The device's battery input report (0x90) is laid out as [report-id][status][charge]. hid-input's synchronous capacity query, hidinput_query_battery_capacity(), assumes the common [report-id][capacity] layout and returns buf[1], which for this device is the status byte rather than the charge (buf[2]). magicmouse_fetch_battery(), which requests the battery report through hid_hw_request() so the reply is decoded via the report descriptor at the correct field offset, is gated to the USB models and never runs over Bluetooth. The device does not push battery reports on its own either, except a single one at connect time, which is delivered while probe holds driver_input_lock and is silently dropped. All userspace reads therefore go through the misparsing query, and the device is stuck reporting its status byte as the capacity. Enabling the fetch for Bluetooth is not sufficient on its own: user space reacts to the power_supply registration immediately, so a query is typically already in flight when the fetch reply is parsed. hidinput_get_battery_property() stores the query result and marks the battery as queried without rechecking whether a report arrived while it was waiting, clobbering the just-reported correct value with the misparsed one. Fix this by adding HID_BATTERY_QUIRK_AVOID_QUERY for the Bluetooth Magic Trackpad USB-C so the misparsing query path is never used, and by fetching the battery at the end of probe for this device. hidp has no asynchronous request() callback, so the fetch is serviced synchronously via __hid_request() while probe still holds driver_input_lock; call hid_device_io_start() first so the reply is processed instead of being discarded. Tested with a Magic Trackpad USB-C (004c:0324) over Bluetooth on 6.18.37: the reported capacity now matches the device (verified against a raw GET_REPORT of report 0x90) and updates on reconnect. Fixes: 87a2f10395c8 ("HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support") Cc: stable@vger.kernel.org Signed-off-by: Andrei Fed <andfed.net@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-07-06 19:55:07 +02:00
HID: add missing MODULE_DESCRIPTION() macros make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-a4tech.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-apple.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-aureal.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-belkin.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-betopff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-bigbenff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-cherry.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-chicony.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-cypress.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-dr.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-emsff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-elecom.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-elo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-evision.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ezkey.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-vivaldi-common.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-google-hammer.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-google-stadiaff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-gyration.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-kbd.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-mouse.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ite.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kensington.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-keytouch.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kye.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lcpower.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lenovo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-logitech.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-magicmouse.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-maltron.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-mf.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-megaworld.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-microsoft.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-monterey.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ntrig.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ortek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-prodikeys.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-pl.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-petalynx.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-primax.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-razer.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-redragon.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-retrode.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-saitek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-samsung.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-semitek.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sjoy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sony.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-speedlink.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-steam.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-steelseries.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-sunplus.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-gaff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-tmff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-tivo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-topseed.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-twinhan.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-uclogic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-xinmo.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-zpff.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-zydacron.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-viewsonic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-waltop.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-winwing.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Note: All HID drivers that had explicit entries in the MAINTAINERS file were fixed individually. This patch fixes all remaining HID drivers that fall under the generic "HID CORE LAYER" entry in the MAINTAINERS file. Almost all descriptions were taken from the header comment in each file. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240604-md-hid-misc-v1-1-4f9560796f3c@quicinc.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-06-04 15:10:23 -07:00