All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: John Stultz <john.stultz@linaro.org>,
	USB list <linux-usb@vger.kernel.org>
Subject: USB: gadget: Improve kerneldoc for usb_ep_dequeue()
Date: Tue, 5 Feb 2019 14:33:02 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1902051431160.1472-100000@iolanthe.rowland.org> (raw)

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


[as1883]


 drivers/usb/gadget/udc/core.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: usb-4.x/drivers/usb/gadget/udc/core.c
===================================================================
--- usb-4.x.orig/drivers/usb/gadget/udc/core.c
+++ usb-4.x/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

                 reply	other threads:[~2019-02-05 19:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1902051431160.1472-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=felipe.balbi@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.