kernel.git/drivers/hid/usbhid, branch linux-5.16.y

Merge branch 'for-5.15/core' into for-linus

2021-09-01T20:00:06Z

- Regression fix for an issue in HID core that got uncovered by recent USB core cleanup leading to issues when transfer_buffer_length is not in line with wLength - Memory leak fix in USB HID core - Improvement of stylus battery reporting

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: Kconfig: Fix spelling mistake "Uninterruptable" -> "Uninterruptible"

2021-07-28T09:41:57Z

There is a spelling mistake in the Kconfig text. Fix it. Signed-off-by: Colin Ian King 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

Merge branch 'for-5.14/multitouch' into for-linus

2021-06-30T07:15:15Z

- patch series that ensures that hid-multitouch driver disables touch and button-press reporting on hid-mt devices during suspend when the device is not configured as a wakeup-source, from Hans de Goede

Merge branch 'for-5.14/core' into for-linus

2021-06-30T07:03:51Z

- device unbinding locking fix from Dmitry Torokhov - support for programmable buttons (mapping to KEY_MACRO# event codes) from Thomas Weißschuh - various other small fixes and code style improvements

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: usbkbd: Avoid GFP_ATOMIC when GFP_KERNEL is possible

2021-06-15T08:50:36Z

usb_kbd_alloc_mem is called in usb_kbd_probe, which is not in atomic context. So constraints can be relaxed here. Use GFP_KERNEL instead of GFP_ATOMIC. Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Jiri Kosina