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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 22, 2024 at 01:57:33PM +0100, Michał Pecio wrote:
> 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.

Bypassing the BH might not be a good idea, because driver's completion 
handlers expect to be called in order of URB completion.  It probably 
wouldn't make any difference, but it's hard to be sure.

> > 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.

No, it's the behavior of the class driver and is independent of the 
type of host controller.

>  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.

If they don't care then they won't care if the URBs get unlinked.

Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux