1
0
Fork 0

USB Gadget: documentation update

This patch (as1102) clarifies two points in the USB Gadget kerneldoc:

	Request completion callbacks are always made with interrupts
	disabled;

	Device controllers may not support STALLing the status stage
	of a control transfer after the data stage is over.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hifive-unleashed-5.1
Alan Stern 2008-06-02 16:26:48 -04:00 committed by Greg Kroah-Hartman
parent e0d795e4f3
commit f579c2b46f
1 changed files with 6 additions and 2 deletions

View File

@ -33,7 +33,8 @@ struct usb_ep;
* @short_not_ok: When reading data, makes short packets be
* treated as errors (queue stops advancing till cleanup).
* @complete: Function called when request completes, so this request and
* its buffer may be re-used.
* its buffer may be re-used. The function will always be called with
* interrupts disabled, and it must not sleep.
* Reads terminate with a short packet, or when the buffer fills,
* whichever comes first. When writes terminate, some data bytes
* will usually still be in flight (often in a hardware fifo).
@ -271,7 +272,10 @@ static inline void usb_ep_free_request(struct usb_ep *ep,
* (Note that some USB device controllers disallow protocol stall responses
* in some cases.) When control responses are deferred (the response is
* written after the setup callback returns), then usb_ep_set_halt() may be
* used on ep0 to trigger protocol stalls.
* used on ep0 to trigger protocol stalls. Depending on the controller,
* it may not be possible to trigger a status-stage protocol stall when the
* data stage is over, that is, from within the response's completion
* routine.
*
* For periodic endpoints, like interrupt or isochronous ones, the usb host
* arranges to poll once per interval, and the gadget driver usually will