[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221318

--- Comment #19 from Michał Pecio (michal.pecio@gmail.com) ---
The "spurious event" noise is likely from SuperSpeed device 4-1.1.2 whose Bulk
IN URBs may trigger it even on properly working hardware. The driver isn't very
good at telling apart certain valid and invalid events, it just logs them all.

Mouse interrupt endpoint has an URB at 1267010, cycle bit 1 as expected.
 0 0x0000000001267000: Buffer 0000000000000000 length 0 TD size 0 intr 0 type
'No-Op' flags b:i:i:c:s:i:e:C
 0 0x0000000001267010: Buffer 000000000125e700 length 10 TD size 0 intr 0 type
'Normal' flags b:i:I:c:s:I:e:C

Cancellation commands, Set TR Dequeue to 1267010 with cycle 1.
 0 0x0000000001201950: Stop Ring Command: slot 7 sp 0 ep 3 flags C
 0 0x0000000001201960: Set TR Dequeue Pointer Command: deq 0000000001267011
stream 0 slot 7 ep 3 flags C

Their completion events have been overwritten by SuperSpeed device activity,
but no sign of problems was seen in logs.

Endpoint is running so the doorbell has been rung after 1267010 submission.
0x000000000125d060: State running mult 1 max P. Streams 0 interval 1000 us max
ESIT payload 10 CErr 3 Type Int IN burst 0 maxp 10 deq 0000000001267011 avg trb
len 10, virt_state:0x0

I see nothing obviously wrong here, it looks like some weird HW problem.

BTW, I see that the endpoint of interest has 1ms interval too, longer interval
is on the second endpoint of this mouse. IDK if it matters anyway.

If you would like to play with intervals, see drivers/usb/host/xhci-mem.c
function xhci_parse_frame_interval(). Replace ep->desc.bInterval with any
number like 1 or 10, units are milliseconds. Leave *8 unchanged.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.