Georg Acher wrote:
>
> On Mon, Mar 18, 2002 at 12:10:31AM +0100, Stephan Feder wrote:
> > To be precise: the failures I am talking about are those that could
> > occur while talking to real devices, not errors like OOM and illegal
> > URBs (e.g. URBs with transfer_buffer=0 and transfer_buffer_length!=0). I
> > do not know in which category URBs with a bad pipe value fall.
>
> I think these failures are already well defined. The cases in which
> submit_urb immediately fails can only be "formal" failures (bad pipes, NULL
> pointers somewhere, wrong length, etc.), ie. everything that can be checked
> before actually transmitting. In these cases the return value is
> !=0 and no USB transfer was sent out on the "wire".
>
> Everything else that happens after the return of submit_urb can only be
> related to the device or the host controller itself. These failures are
> handled by calling the completion with the right urb->status.
>
> There should be absolutely no case in which submit_urb returns with !=0 and a
> completions to that URB comes later on.
I completely agree but it is still not documented anywhere. Furthermore,
the completion handler can be (and was until recently in uhci) called
_before_ returning from submit_urb; whether the completion handler is
called before or after return from submit_urb is undefined in the
general case.
But that is beside the point: The question was how to handle
"non-formal" failures in the root hub. Right now they are handled
differently from failures in non-root hubs where the failure is reported
in the completion handler.
Regards
Stephan
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
