Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error

Mathias Nyman
2026-04-01T22:35:02Z

On 4/2/26 01:08, Thinh Nguyen wrote:
> On Mon, Mar 30, 2026, Mathias Nyman wrote:
>>
>>>
>>> On a separate note, will you plan to implement the clear-halt for EPROTO
>>> in xhci?
>>
>> I don't think this should be part of xhci driver. Decision to send control requests
>> to the device should be done by core or class drivers.
>>
>
> This not like STALL where it's standardized for the core or class driver
> to know how to handle. The programming sequence for the errors that
> resulted in EPROTO from xhci is specific to xhci. That is, the xhci
> reset endpoint command will reset the bulk sequence, it's specific to
> xhci. The xhci spec recommends to send a clear-halt for this scenario,
> not the USB spec or any other class specific spec. So we should not
> delegate this to the core or class driver to handle.
>
USB 2 Specification does mention handling halt conditions due to transmission
erros _OR_ STALL handshake with clearing halt and resetting both host and device
endpoint toggle.

See USB 2

5.7.5 Interrupt Transfer Data Sequences

"If a halt condition is detected on an interrupt pipe due to transmission errors or
a STALL handshake being returned from the endpoint, all pending IRPs are retired.
Removal of the halt condition is achieved via software intervention through a
separate control pipe. This recovery will reset the data toggle bit to DATA0 for
the endpoint on both the host and the device"

5.8.5 Bulk Transfer Data Sequences

"If a halt condition is detected on a bulk pipe due to transmission errors or a
STALL handshake being returned from the endpoint, all pending IRPs are retired.
Removal of the halt condition is achieved via software intervention through a
separate control pipe. This recovery will reset the data toggle bit to DATA0
for the endpoint on both the host and the device"

Thanks
Mathias