tree 7f6f1860d05a4d6afa4284c385ecb0a402b32f48
parent 0e4987639a774d08b69c1c58774f3430f6083d4f
author Alan Stern <[EMAIL PROTECTED]> Tue, 19 Apr 2005 07:39:30 -0700
committer Greg K-H <[EMAIL PROTECTED]> Tue, 19 Apr 2005 07:39:30 -0700

[PATCH] USB: USB API documentation modification

In response to complaints about excessive latency in the uhci-hcd driver
I'm planning to convert it to a top-half/bottom-half design.  It turns out
that to do this, the USB API has to be modified slightly since the driver
will not be able to meet one of the guarantees in the current API.  This
patch changes some kerneldoc, specifying the weaker guarantee.

Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


 usb/core/urb.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

Index: drivers/usb/core/urb.c
===================================================================
--- d9d9eb475b11c05b069c715df50f9e6d89c32ecf/drivers/usb/core/urb.c  
(mode:100644 sha1:dc838f81742cb1c848ea084e07266d1cd7477c52)
+++ 7f6f1860d05a4d6afa4284c385ecb0a402b32f48/drivers/usb/core/urb.c  
(mode:100644 sha1:16972159a57ad855485f61e1e1a9421e88a95b0f)
@@ -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 any
- * fault (such as an error, or being unlinked) 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.
+ * 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; 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.
  *
  * This means that USB device drivers can safely build deep queues for
  * large or complex transfers, and clean them up reliably after any sort
-
To unsubscribe from this list: send the line "unsubscribe bk-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to