Just for the record -- this doesn't look like a change at all, but
I'm not sure it catches the nuances correctly either.


On Tuesday 05 April 2005 8:55 am, Alan Stern wrote:
> @@ -420,12 +420,16 @@
>   *
>   * Host Controller Drivers (HCDs) place all the URBs for a particular
>   * endpoint in a queue.  Normally the queue advances as the controller
> ...
> + * hardware processes each request.  But when an URB terminates with an
> + * error its queue stops, at least until that URB's completion routine
> + * returns.  It is guaranteed that the queue will not restart until all
> + * its unlinked URBs have been fully retired, with their completion
> + * routines run, even if that's not until some time after the original
> + * completion handler returns.  Normally the same behavior and guarantees
> + * apply when an URB terminates because it was unlinked; 

That "normally" bit restates the guarantee provided above.

The redundancy makes things less clear (IMO) because it's
weakening the guarantee that "when an URB terminates with
an error" (including an unlink or kill status!!) its queue
stops ... that says "always", this says "sometimes maybe".

> + *                                                        however if an 
> + * URB is unlinked before the hardware has started to execute it, then
> + * its queue is not guaranteed to stop until all the preceding URBs have
> + * completed.

Well, that's because no urb before that one will have
completed with any fault code, so there was no need
for the queue to have stopped.  The relevant urb was
not yet terminated.



>   *
>   * This means that USB device drivers can safely build deep queues for
>   * large or complex transfers, and clean them up reliably after any sort
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to