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

Alan Stern
2026-04-17T17:38:51Z

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
>
> I also support adding usb_purge_endpoint_queue(), but it doesn't have to
> be done at the same time as the EPROTO changes.

I've started working on an implementation of this, and there are a few
edge cases. Can anyone answer these questions?

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?

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?

When the error recovery mechanism is in place and working, should
usb_bulk_msg() and friends automatically retry when a transaction error
occurs? If they do, how many times?

Alan Stern