Bug 208935

I can confirm this with a Logitech Ergo MX trackball and unified receiver. With kernel 5.9-rc1 I get:

[  144.210951] logitech-djreceiver 0003:046D:C52B.0003: device of type eQUAD step 4 DJ (0x04) connected on slot 4
[  144.211174] hid-generic 0003:046D:406F.0005: item fetching failed at offset 0/0
[  144.211189] hid-generic: probe of 0003:046D:406F.0005 failed with error -22
[  144.217224] logitech-hidpp-device 0003:046D:406F.0005: item fetching failed at offset 0/0
[  144.217236] logitech-hidpp-device 0003:046D:406F.0005: hidpp_probe:parse failed
[  144.217243] logitech-hidpp-device: probe of 0003:046D:406F.0005 failed with error -22


Reverting "d31327922 HID: usbhid: do not sleep when opening device" makes the device work again:

[  157.133316] logitech-djreceiver 0003:046D:C52B.0009: hiddev96,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.4-1/input2
[  157.252639] input: Logitech MX Ergo as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-1/3-1:1.2/0003:046D:C52B.0009/0003:046D:406F.000A/input/input35
[  157.252915] logitech-hidpp-device 0003:046D:406F.000A: input,hidraw2: USB HID v1.11 Keyboard [Logitech MX Ergo] on usb-0000:04:00.4-1/input2:3
[  157.262429] input: Logitech MX Ergo as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-1/3-1:1.2/0003:046D:C52B.0009/0003:046D:406F.000B/input/input36
[  157.262702] logitech-hidpp-device 0003:046D:406F.000B: input,hidraw3: USB HID v1.11 Keyboard [Logitech MX Ergo] on usb-0000:04:00.4-1/input2:4
[  159.899985] logitech-hidpp-device 0003:046D:406F.000B: HID++ 4.5 device connected.

(In reply to Johannes Hirte from comment #1)
> I can confirm this with a Logitech Ergo MX trackball and unified receiver.
> Reverting "d31327922 HID: usbhid: do not sleep when opening device" makes
> the device work again:

Thanks for the confirmation.

You have a Logitech trackball with the unified wireless receiver; I have a Logitech trackpad with the unified receiver; and bug #809923 says Logitech mouse m220, which googling (on the privacy respecting duckduckgo) suggests also uses a unified receiver or something looking like it, tho the revert-fix isn't confirmed on that one yet.

Meanwhile, it's worth mentioning again that my Logitech k350 wireless keyboard, connected as well thru the same unified receiver connecting the trackpad, continues to work even while the trackpad fails.

So it seems to affect Logitech unifying receiver connected pointing devices, but /not/ Logitech keyboards similarly connected.  And it's bisected.  Adjusting the title accordingly (and marking regression, which I missed with the original filing).

changing the line

usbhid->input_start_time = ktime_add_ms(ktime_get_coarse(), 50);

to become

usbhid->input_start_time = ktime_add_ms(ktime_get_coarse(), 0);

also results in working mouse input again.

Is hid_start_in() being called recursively such that input_start_time gets incremented forever and the check conditions can never be successful?

FYI I mailed the maintainers and Jiri replies "I have revert already queued in hid.git#for-5.9/upstream-fixes."

(In reply to Eric Shattow from comment #4)
> FYI I mailed the maintainers and Jiri replies "I have revert already queued
> in hid.git#for-5.9/upstream-fixes."

Looks like that's in now, as commit 5b0545dc1, merged in commit b9aa527ae on August 25, Tuesday.  So for those doing the rcs only it should be in 5.9-rc3.  Quoting the git log:

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

     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

That's a link to this bug, of course. =:^)

Also note the "revert ... now, and fix this properly ... for next merge window" bit.  So be particularly on the lookout for 5.10-rcs as well, but I expect they'll be pre-commit testing against hardware that failed this time and won't fail on it for the second go-round in 5.10.

I'll leave the bug open until rc3 is released with the revert, then will close the bug if no objections as it was introduced pre-rc1 this cycle and never hit full release.

Fixed in 5.9-rc3. =:^)