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.
