speedtch usbatm.c,1.26,1.27

[Duncan Sands]

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

If the same error occurs for every urb we send (i.e. submit OK, but
-EAGAIN in the completion handler) then we'll loop tightly.

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

I don't think you can trust error-codes.txt much.  Looking through the
code, I don't see anywhere that returns EAGAIN in the cases that the doc
describes.  I don't see EAGAIN ending up in status anywhere, which is
good.  Also, why don't we support iso 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.

An error code that isn't used by the core today may be used by the
core tomorrow.  I think EAGAIN is a decent choice.

Ciao,

D.