linux-dev/drivers/hid/usbhid/hid-core.c, branch linus/master

HID: usbhid: remove third argument of usb_maxpacket()

2022-04-23T08:33:53Z

The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Jiri Kosina CC: Benjamin Tissoires Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/r/20220317035514.6378-3-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman

HID: add suspend/resume helpers

2021-12-02T14:42:46Z

There is a lot of duplication of code in the HID low level drivers. Better have everything in one place so we can eventually extend it in a generic way. Signed-off-by: Benjamin Tissoires Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20211202095334.14399-4-benjamin.tissoires@redhat.com

HID: usbhid: Simplify code in hid_submit_ctrl()

2021-09-01T18:52:32Z

This patch makes a small simplification to the code in hid_submit_ctrl(). The test for maxpacket being > 0 is unnecessary, because endpoint 0 always has a maxpacket value which is >= 8. Furthermore, endpoint 0's maxpacket value is always a power of 2, so instead of open-coding the round-to-next-multiple computation we can call the optimized round_up() routine. Signed-off-by: Alan Stern Tested-by: Benjamin Tissoires Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: usbhid: Fix warning caused by 0-length input reports

2021-09-01T18:52:31Z

Syzbot found a warning caused by hid_submit_ctrl() submitting a control request to transfer a 0-length input report: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType a1 (The warning message is a little difficult to understand. It means that the control request claims to be for an IN transfer but this contradicts the USB spec, which requires 0-length control transfers always to be in the OUT direction.) Now, a zero-length report isn't good for anything and there's no reason for a device to have one, but the fuzzer likes to pick out these weird edge cases. In the future, perhaps we will decide to reject 0-length reports at probe time. For now, the simplest approach for avoiding these warnings is to pretend that the report actually has length 1. Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com Tested-by: Oleksandr Natalenko Tested-by: Benjamin Tissoires Acked-by: Benjamin Tissoires Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina

HID: usbhid: Fix flood of "control queue full" messages

2021-09-01T18:52:31Z

[patch description by Alan Stern] Commit 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers") causes control URB submissions to fail if the transfer_buffer_length value disagrees with the setup packet's wLength valuel. Unfortunately, it turns out that the usbhid can trigger this failure mode when it submits a control request for an input report: It pads the transfer buffer size to a multiple of the maxpacket value but does not increase wLength correspondingly. These failures have caused problems for people using an APS UPC, in the form of a flood of log messages resembling: hid-generic 0003:051D:0002.0002: control queue full This patch fixes the problem by setting the wLength value equal to the padded transfer_buffer_length value in hid_submit_ctrl(). As a nice bonus, the code which stores the transfer_buffer_length value is now shared between the two branches of an "if" statement, so it can be de-duplicated. Signed-off-by: Michal Kubecek Signed-off-by: Alan Stern Fixes: 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers") Tested-by: Oleksandr Natalenko Tested-by: Benjamin Tissoires Acked-by: Benjamin Tissoires Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina

HID: usbhid: free raw_report buffers in usbhid_stop

2021-07-28T09:31:40Z

Free the unsent raw_report buffers when the device is removed. Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47 Reported-by: syzbot+47b26cd837ececfc666d@syzkaller.appspotmail.com Tested-by: syzbot+47b26cd837ececfc666d@syzkaller.appspotmail.com Signed-off-by: Anirudh Rayabharam Signed-off-by: Jiri Kosina

HID: usbhid: Implement may_wakeup ll-driver callback

2021-06-25T12:02:58Z

Without a ll-driver callback hid_hw_may_wakeup() will return: device_may_wakeup(hdev->dev.parent), usb_hid_driver instantiated hid devices have their parent set to the usb-interface to which the usb_hid_driver is bound, but the power/wakeup* sysfs attributes are part of the usb-device. Add a may_wakeup ll-driver callback which calls device_may_wakeup() on the usb-device instead. Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: usbhid: fix info leak in hid_submit_ctrl

2021-05-05T13:52:34Z

In hid_submit_ctrl(), the way of calculating the report length doesn't take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes. To fix this, first modify hid_report_len() to account for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from hid_submit_ctrl(). Reported-by: syzbot+7c2bb71996f95a82524c@syzkaller.appspotmail.com Signed-off-by: Anirudh Rayabharam Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: usbhid: Fix fall-through warnings for Clang

2020-11-25T13:01:55Z

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a couple of break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Jiri Kosina

Revert "HID: usbhid: do not sleep when opening device"

2020-08-18T17:54:04Z

This reverts commit d3132792285859253c466354fd8d54d1fe0ba786. This patch causes a regression with quite a few devices, as probing fails because of the race where the first IRQ is dropped on the floor (after hid_device_io_start() happens, but before the 50ms timeout passess), and report descriptor never gets parsed and populated. As this is just a boot time micro-optimization, let's revert the patch for 5.9 now, and fix this properly eventually for next merge window. Link: https://bugzilla.kernel.org/show_bug.cgi?id=208935 Reported-by: Johannes Hirte Reported-by: Marius Zachmann Signed-off-by: Jiri Kosina