Re: [REGRESSION] usbhid -110 timeouts and reset loop for Keychron M5 (3434:d068) at boot since v7.3

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 10/26/26 13:38, Michal Pecio wrote:
> On Mon, 26 Oct 2026 10:51:39 +0100, Michal Pecio wrote:
>> On Mon, 26 Oct 2026 11:18:34 +0200, Mathias Nyman wrote:
>>> So even if we give back all pending URBs and clear the
>>> EP_DROP_PENDING flag we continue using the stale ring. We should
>>> either either move dequeue pointer, set TRBs to no-op, or clear and
>>> reinitialize whole ep0 ring at device reset.
>>
>> This may need to be fixed regardless, because EP_DROP_PENDING on EP0
>> can result from xHCI "Error" aka USB3 "Inactive" state, which (AFAIU)
>> may be cleared with warm reset, without reallocating the udev. That's
>> the "existed since forever" issue I was thinking about.
> 
> 4.6.11 isn't 100% explicit what happens if EP 0 is halted at Reset
> Device, but generally it should "terminate any USB activity, abort
> any pending events and transition to the Running state".
> 
> So just a Set TR Dequeue to current enqueue will probably work, but
> I think this has never been tried before.
> 
> I see that xhci_discover_or_reset_device() clears EP_DROP_PENDING
> even in case of Reset Device failure, which looks a little odd. We
> probably wouldn't want to issue Set TR Deq in such case and don't
> want to clear this flag without fixing the endpoint.
> 
> What was the reason for placing this loop after and not before
> the command_cleanup label?


USB core may reset a device several times without reaching 'addresses'
or 'configured' state in between resets.

The reset device command in xhci fails with a "context state error" if
the slot isn't in a addressed or configured state. Make sure we clear
the flag in those cases.

-Mathias