Another thing I forgot to mention: If a control transfer terminates with an error, the final status stage acknowledgment will most likely not take place. If it stops early because of a short packet but URB_SHORT_NOT_OK _isn't_ set, then it's not an error and the status stage does occur.
Those sorts of things can stand more attention; I think there are some corner cases in control traffic where Linux may not be strictly correct.
There's a difference between what the device driver wants to view as an error, and what USB does. SHORT_NOT_OK is purely part of the device driver's reality-filter, so far as I know.
If an URB is unlinked, its queue is stopped until the URB's completion handler returns. Is this true even if the URB wasn't at the head of its queue?
Right. Think of unlink/cancel as a special driver-initiated error; it's covered by the general rule above. Anyway, how could you know that the URB didn't get to the front of the hardware's queue unless you first stopped that queue from advancing? :)
You couldn't know that. But if the queue is stopped, you could restart it _before_ invoking the completion handler. That's what I was really checking.
Things are a lot simpler if restarting the queue only happens after the HCD has no more cleanup work to do ...
I'm not entirely sure that unlinking in arbitrary order would work reasonably with all HCDs today, for example. It should, of course...
The UHCI driver currently does not follow these rules exactly.
I'd be most concerned with the bulk queues stopping.
FYI: EHCI currently implements ISO's "completes soon" requirement of unlinking by just letting those requests complete normally ... "soon" for ISO thus being just a few msec longer than if it did tried something complex (and error-prone).
Doesn't that depend on how much data has been queued?
Yes, but there's a ceiling on that: 1024 frames at most, or for most controllers 256 frames.
Incidentally, the changes in store for the UHCI driver will make it possible to queue iso transfers way into the future (just as a side effect, but the capability will be there). I don't know if anyone cares about this.
OHCI can do that too; each ISO TD in the queue is marked with a start frame, it's disgustingly easy to do that!
For EHCI I'll avoid such things for now. If driver writers do get interested in that behavior, it could be added.
- Dvae
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
