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

Thinh Nguyen
2026-04-04T22:28:47Z

On Sat, Apr 04, 2026, Thinh Nguyen wrote:
> On Sat, Apr 04, 2026, Alan Stern wrote:
> > On Sat, Apr 04, 2026 at 08:41:36PM +0000, Thinh Nguyen wrote:
> > > On Fri, Apr 03, 2026, stern@rowland.harvard.edu wrote:
> > > > Summarizing:
> > > >
> > > > If the class driver wants to unlink queued URBs when a transaction error
> > > > occurs, it has to do so itself in the failed URB's completion handler.
> > > > We can make this easier by adding a usb_flush_endpoint_queue() routine
> > > > to the core. In the meantime, the HCD ensures that the queue is stopped
> > > > before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
> > > > -EREMOTEIO aren't considered to be transaction errors.)
> > > >
> > > > When the completion handler returns, the core will automatically call
> > > > usb_clear_halt(), which will also reset the endpoint on the host side
> > > > and will restart the queue. This also happens after SetConfiguration
> > > > and SetInterface, either explicitly or implicitly.
> > >
> > > I like that the core will handle this automatically. But one concern:
> > > How will the class driver know when the clear-halt complete so it can
> > > perform the recovery? (ie. it shouldn't perform recovery immediately
> > > after seeing -EPROTO)
> >
> > It doesn't know, and it doesn't need to know. Any recovery URBs the
> > class driver wants to send can be submitted as usual, and they will be
> > added onto the queue. When the core resets the endpoint, the queue will
> > start going again and the URBs will run.
> >
> > If the class driver wants to take some other action (like submitting
> > URBs to a different endpoint) before using the endpoint that stopped,
> > it's free to do so. It only has to make sure that it doesn't submit any
> > URBs to the stopped endpoint until after the other action is finished --
> > which is what it would do anyway. (And maybe it has to unlink any URBs
> > that are already queued, which can be done with a simple function call.)
> >
>
> Then the xhci must make sure that it should not ring the doorbell to
> restart the endpoint when giving back the canceled URBs. It should only
> do so on newly submitted URBs.

Ignore this comment, it's not restarting the endpoint in the case of
unlinking.

>
> We can add a requirement such that if the class driver submitted the
> recovery URBs prior to completing the usb_reset_endpoint (which should
> be done after clear-halt), then the HCD may keep those URBs on a queue
> and only process those URBs and restart the endpoint afterward.
>

Actually, adding this new requirement would be tricky because we don't
know whether it's recovery URBs or not.

BR,
Thinh