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

[Michal Pecio <michal.pecio@gmail.com>]

On Fri, 17 Apr 2026 13:38:46 -0400, Alan Stern wrote:
> The behavior for control endpoints isn't clear.  When a transaction 
> error occurs in a control transfer, does xHCI stop the endpoint
> queue? Presumably usb_clear_halt() isn't needed, but what about 
> usb_reset_endpoint()?
> 
> I will assume that all stalls for control endpoints are protocol
> stalls and therefore do not need to be cleared (the device will
> automatically clear the halt condition when it receives the next
> SETUP packet for the endpoint).  But does xhci-hcd still require a
> usb_reset_endpoint() after a control stall?

Nope.

The host endpoint halts on every STALL handshake or non-isoc protocol
error, but the driver immediately resets every halted endpoint because
it's a precondition to even remove the failed URB from the HW queue
before giving it back, which looks like a prudent thing to do.

Currently, by the time the URB is given back, its endpoint is already
in a "stopped but runnable" state and its sequence state is zeroed.
And it may have already been restarted if there are more pending URBs.

This seems to need no change for control endpoints?

For bulk/interrupt it also means that if we delay the restart until
endpoint_reset() then endpoint_reset() has nothing to do besides
restarting the endpoint, which is a good thing because this method
under normal conditions requires no URBs to be present.

> Recovery from a transaction error on a bulk or interrupt endpoint 
> involves sending a Clear-Halt request to the device.  But if the
> error was caused by some sort of transient interference that hasn't
> ended yet, the Clear-Halt might itself fail with the same error. To
> handle this, we should retry the Clear-Halt at increasing time
> intervals.  At what point should the core give up?

Good question, I don't know. One thing I noticed is that Windows does
tend to lose patience with completely unresponsive devices and kicks
them out, but I don't know the exact criteria.

And if core is to clear halt autonomously, things may get interesting
if a driver tries to do the same, or something else like removing the
endpoint with usb_set_interface().

A related issue is clearing TT buffers. AFAIK this has no retries, it
fails silently and leaves the endpoint potentially broken, and it is
waited for to complete in case of usb_set_interface().

Regards,
Michal