speedtch usbatm.c,1.26,1.27

[Roman Kagan]

On Thu, May 05, 2005 at 09:47:03PM +0200, Duncan Sands wrote:
> On Thu, 2005-05-05 at 21:18 +0200, Duncan Sands wrote:
> > > > But is it OK to resubmit straight away [...] ?
> > > 
> > > But we don't: it's always a "soft failure" path, when we only schedule
> > > the resumption of the processing after our throttling delay.
> > 
> > Yeah, and it's about the hundredth time I've forgotten that.
> 
> Actually I've just remembered what the potential problem is: what if
> the error is only seen in the completion handler, not on submission?
> I can imagine that it's only quite late in the day, after
> usb_submit_urb has succeeded, that the problem is discovered (signaled
> by the host controller perhaps) and the -EAGAIN is generated.  Then
> we could end up submitting the urb again and again in a tight loop.

Hmm, not exactly: the completion routine adds the urb to the tail of the
queue, so if it happens we'll attempt to resend the data out of
sequence...

Well, AFAICS from Documentation/usb/error-codes.txt, the usb core only
returns -EAGAIN from usb_submit_urb() and not in urb->status (and only
for isoc transfers which we don't use for tx).  Anyway, even if we can
receive -EAGAIN in urb->status, there's nothing which forces us to use
it to signal the submission failure.  We can choose any error code which
isn't used by the usb core, and thus distinguish the urb which was
returned to the queue due to failed submission and should be appended
to, from urbs which completed with an error and should be overwritten.

Cheers,
  Roman.