From 8835f6657316162a8937d3f26ccd8f5886ba3845 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Mon, 18 Apr 2005 17:39:30 -0700 Subject: [PATCH] [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 Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/urb.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index dc838f8..1697215 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 -- 2.7.4