summaryrefslogtreecommitdiffstats
path: root/drivers/usb/gadget/udc/core.c
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2019-02-05 14:33:02 -0500
committerFelipe Balbi <felipe.balbi@linux.intel.com>2019-02-06 08:37:16 +0200
commit1e19a520a9258f3c7286826e7172e56bf6da86dc (patch)
tree2973ceb45f1934a5c4cf9f44df955085b9d7acf0 /drivers/usb/gadget/udc/core.c
parent1381a5113caf764f090b912b478663275e7b999e (diff)
downloadlinux-1e19a520a9258f3c7286826e7172e56bf6da86dc.tar.bz2
USB: gadget: Improve kerneldoc for usb_ep_dequeue()
Commit bf594c1070f5 ("USB: gadget: Document that certain ep operations can be called in interrupt context") documented that usb_ep_dequeue() may be called in a non-process context. It follows that the routine must not sleep or wait for events. However, the routine's existing kerneldoc seems to imply that it will wait until the request being cancelled has fully completed. This is not so, and thus the comment needs to be improved. Misunderstanding this point may very well have been responsible for a bug recently uncovered in the f_fs function. The updated comment explicitly says that the routine may return before the request's completion handler is called. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: John Stultz <john.stultz@linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Diffstat (limited to 'drivers/usb/gadget/udc/core.c')
-rw-r--r--drivers/usb/gadget/udc/core.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 87d6b12779f2..7cf34beb50df 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -281,10 +281,10 @@ EXPORT_SYMBOL_GPL(usb_ep_queue);
* @ep:the endpoint associated with the request
* @req:the request being canceled
*
- * If the request is still active on the endpoint, it is dequeued and its
- * completion routine is called (with status -ECONNRESET); else a negative
- * error code is returned. This is guaranteed to happen before the call to
- * usb_ep_dequeue() returns.
+ * If the request is still active on the endpoint, it is dequeued and
+ * eventually its completion routine is called (with status -ECONNRESET);
+ * else a negative error code is returned. This routine is asynchronous,
+ * that is, it may return before the completion routine runs.
*
* Note that some hardware can't clear out write fifos (to unlink the request
* at the head of the queue) except as part of disconnecting from usb. Such