* Re: [Bug 209137] USB is not working since update from 5.0 to 5.3.0-26. And with 5.4 still not working.
2020-10-08 14:35 ` [Bug 209137] USB is not working since update from 5.0 to 5.3.0-26. And with 5.4 still not working Alan Stern
@ 2020-10-09 8:31 ` Benjamin Tissoires
0 siblings, 0 replies; 2+ messages in thread
From: Benjamin Tissoires @ 2020-10-09 8:31 UTC (permalink / raw)
To: Alan Stern; +Cc: Jiri Kosina, Linux USB Mailing List, open list:HID CORE LAYER
Hi Alan,
On Thu, Oct 8, 2020 at 4:42 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Jiri and Benjamin:
>
> Please look at Bugzilla # 209137:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=209137
>
> Somewhere between 5.0 and 5.4, the logitech-djreceiver driver stopped
> binding to the user's Logitech wireless device. Here are relevant parts
> of the kernel logs. From 5.0 (working):
>
> [ 2.857770] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-4/input2
> [ 2.985339] input: Logitech Unifying Device. Wireless PID:1024 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:046D:C52B.0003/0003:046D:1024.0004/input/input13
> [ 2.985410] hid-generic 0003:046D:1024.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1024] on usb-0000:00:14.0-4:1
> [ 2.995266] input: Logitech K520 as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:046D:C52B.0003/0003:046D:2011.0005/input/input17
> [ 3.026985] logitech-hidpp-device 0003:046D:2011.0005: input,hidraw1: USB HID v1.11 Keyboard [Logitech K520] on usb-0000:00:14.0-4:2
> [ 3.033173] input: Logitech M310 as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:046D:C52B.0003/0003:046D:1024.0004/input/input18
> [ 3.033358] logitech-hidpp-device 0003:046D:1024.0004: input,hidraw2: USB HID v1.11 Mouse [Logitech M310] on usb-0000:00:14.0-4:1
>
> From 5.4 (non-working):
>
> [ 2.908901] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-4/input0
> [ 2.909003] hid-generic 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.909016] hid-generic 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.909019] hid-generic 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.909023] hid-generic 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.909030] hid-generic 0003:046D:C52B.0002: unexpected long global item
> [ 2.909038] hid-generic: probe of 0003:046D:C52B.0002 failed with error -22
> [ 2.909196] hid-generic 0003:046D:C52B.0003: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-4/input2
> [ 2.910586] logitech-djreceiver 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.910601] logitech-djreceiver 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.910605] logitech-djreceiver 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.910609] logitech-djreceiver 0003:046D:C52B.0002: unknown main item tag 0x0
> [ 2.910616] logitech-djreceiver 0003:046D:C52B.0002: unexpected long global item
> [ 2.910620] logitech-djreceiver 0003:046D:C52B.0002: logi_dj_probe: parse failed
> [ 2.910623] logitech-djreceiver: probe of 0003:046D:C52B.0002 failed with error -22
>
> FYI, intf 0 is a boot-interface keyboard, intf 1 is a boot-interface
> mouse, and intf 2 is the wireless HID interface.
That is weird. I also have (several) C52B devices here, and I don't
see the problem (though arguably there are several firmware versions
out in the open).
The first part of failures show that even hid-generic can not parse
the report descriptor. This means that the provided report descriptor
is incorrect, which is weird because the one I just tested works fine.
The second part (with logitech-dj) is showing the same errors, so
that's expected given the previous problem.
To actually get the report descriptors, `lsub -v` works fine if the
HID subsystem is not bounded. So there we need to ask the reporter to
run the command with the HID subsystem not handling the device, or
simply in the working case use hid-recorder from
https://gitlab.freedesktop.org/libevdev/hid-tools/.
Another solution if the report descriptor is identical to what I have
here (in the working case), would be to write a BPF kprobe to dump
what hid_parse sees. It should be straightforward to write one, I got
everything in place for i2c-hid at
https://gitlab.freedesktop.org/bentiss/hid-bpf (though for using the
CO-RE BPF program, I am not sure 5.4 is recent enough).
>
> It's not immediately obvious to me where the problem lies.
Not obvious to me either...
Cheers,
Benjamin
>
> Thanks,
>
> Alan Stern
>
^ permalink raw reply [flat|nested] 2+ messages in thread