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

Alan Stern
2026-04-22T02:11:46Z

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?

I've been thinking about how to implement all this, and some issues have
to be solved. In particular, suppose we have sent a Clear-Halt request
for an endpoint that has gotten an error, and either the request times
out or the device replies with a stall. What can we do then?

My feeling is that either of these events would mean that the device is
so far out of whack that the only thing to do is try resetting it. Any
proposals for something a little less drastic?

Also, it seems reasonable to devote only a single thread to endpoint
error recovery. Another possibility would be to have one thread for
each device having problems, but I think the likelihood of this
happening to multiple devices at once is pretty small unless the problem
affects a hub upstream from all of them -- in which case having multiple
threads wouldn't really help much. Other opinions?

Alan Stern