baldrick at free.fr
Fri May 6 04:59:32 EDT 2005
> > 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
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.
More information about the Usbatm