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

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

On 4/22/26 08:30, Michal Pecio wrote:
> On Tue, 21 Apr 2026 22:11:41 -0400, Alan Stern wrote:
>> On Tue, Apr 07, 2026 at 11:24:01PM +0300, Mathias Nyman wrote:
>>> On 4/7/26 18:23, Alan Stern wrote:
>>>> It's been a while now, and nobody has objected to the proposed
>>>> plan for handling this issue, so I'm going to assume that
>>>> everyone is on board with the idea.
>>>
>>> Yes, I support this
>>>
>>> So basically usb core will call usb_clear_halt() after EPROTO URB
>>> completion handler finishes, and xhci-hcd needs to prevent
>>> bulk/interrupt endpoint from restarting after returning a EPROTO
>>> URB up until usb_reset_endpoint() is called
>>
>> Can you confirm that it's also possible for xhci-hcd to prevent
>> control endpoints from restarting when a transaction error (-EPROTO)
>> occurs?  Up until usb_reset_endpoint() or a new callback?
> 
> Doable. They halt like any other and it's SW's choice how to restart.

Yes, doable.

Would this be used in cases where all hope is lost and we want to reset the
device, canceling all pending control URBs before restarting the ring,
thus avoiding sending any extra URBs to the device just to wait for
them to fail or timeout?

In most cases I can think of it would make sense to keep the control endpoint
running. Just let the hcd move to the SETUP stage of the next control transfer
URB and continue.

For example EMF causing transaction error (-EPROTO) on active IN and OUT bulk
transfers. Two clear-halt requests are queued, one for each endpoint.
If first clear-halt request fails with -EPROTO  we still want to continue with
the next request.
Shouldn't be any toggle/seq-nr issues here on the control endpoint.

Most control transfer STALL (EPIPE) cases are protocol stalls, and we should
just continue running. Exception here might be a STALL response
to a clear-halt request. I assume (didn't check) device must support those.
So in that case we may want to reset the device.

There's also a risk that the control endpoint isn't started when it should.
For example class driver could potentially call usb_clear_halt() on the control
endpoint, synchronously waiting  for the clear-halt request to complete before
calling usb_reset_endpoint(). If endpoint restarts at usb_reset_endpoint() then
the clear-halt control transfer would time out.

Thanks
Mathias