aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/core
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2005-04-18 17:39:30 -0700
committerGreg K-H <gregkh@suse.de>2005-04-18 17:39:30 -0700
commit8835f6657316162a8937d3f26ccd8f5886ba3845 (patch)
tree7f6f1860d05a4d6afa4284c385ecb0a402b32f48 /drivers/usb/core
parent0e4987639a774d08b69c1c58774f3430f6083d4f (diff)
[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 <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/usb/core')
-rw-r--r--drivers/usb/core/urb.c16
1 files changed, 10 insertions, 6 deletions
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index dc838f81742..16972159a57 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -420,12 +420,16 @@ int usb_submit_urb(struct urb *urb, int mem_flags)
*
* 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