[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>

diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index dc838f81742cb1c848ea084e07266d1cd7477c52..16972159a57ad855485f61e1e1a9421e88a95b0f 100644 (file)
--- 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