> > > Thus, if I was writing and my bulk out endpoint STALLed, then yes, I want
> > > the string of bulk-out transfers to all fail with -EPIPE. However, if
> > > there is a bulk-in transfer in the chain, why not do it?
> >
> > Because that IN only makes sense if the OUT succeeded!
>
> No, it doesn't. That IN makes sense regardless -- that IN was my request
> for status from the device, while the OUTs were data transfer. The IN is
> totally valid.
Actually in MY example the IN was to read the response to the request,
which was the OUT ... I thought the idea was that such queue traversal
shouldn't be specific to usb-storage! :) IN requires successful OUT.
> Because it's faster to just send the CLEAR_HALT than to actually stop and
> look at the status -- other driver vendors have realized this, resulting in
> some odd-looking but totally legal bus transactions which run very quickly.
I can't buy this. The instructions requesting I/O cost more than the ones
testing status, and then there's cost for the I/O cost itself.
> > On error, the little queueing engine could chase "urb->alt_next"
> > instead of "urb->next" ... if completion functions aren't wanted.
>
> One could do this, yes. It seems a bit contrived, but doable. I'd rather
> see the enginge just abort the chain processing, tho. Of course, I'm not
> convinced that the engine needs to look at the status codes at all (see
> above).
FWIW the EHCI hardware "queuing engine" supports such an "alt_next"
field, which is why that model for error handling came to mind.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
