Re: How are halted endpoints supposed to be handled in Linux?

["Michał Pecio" <michal.pecio@gmail.com>]

On Thu, 21 Nov 2024 10:06:50 -0500, Alan Stern wrote:=
> > One way I see with existing APIs is to wait until the driver
> > submits a new URB, but are drivers prepared for this? Is EHCI doing
> > the same?  
> 
> Yes; see above.

That's comforting to hear.
But still seems to have races, see Mathias and my reply to him.

I suppose alternative solutions include: bypassing the BH on unlink and
error paths, or making it call the HCD back when it's done. The latter
may not be so trivial, as it would ideally be per-endpoint.

> What about automatic unlinking?

Maybe it could make things go faster and smoother.

Networking can tolerate dropped packets, but considering that their MTU
is larger than USB MTU, I suppose they have to split payloads across
multiple USB packets and may get out of sync if only part of a payload
is dropped. But I don't know, they could use packet headers to resync.

> Note that some class drivers treat -EPROTO as a fatal error.  That
> is, they don't retry and their completion-resubmission loop breaks
> down.

Well, that's on EHCI. xHCI gives them a chance to continue with the
remaining URBs. Hopefuly nobody relies on that...

> However, this seems impractical if the class driver wants to retain
> the existing URBs already on the endpoint's queue.  (I don't know of
> any drivers that do this, but still...)  Perhaps we should adopt the
> policy that -EPROTO, -EILSEQ, and -ETIME cause all outstanding URBs
> to fail and enforce this policy in usbcore by automatic unlinking so
> that HC drivers don't have to do it.

I wouldn't exclude the possibility of sloppy drivers leaving URBs
simply because they don't care. Hard to tell what's right for them.