forked from Minki/linux
usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS
Some UDC drivers (like the DWC3) expect that the response to a setup() request is queued from within the setup function itself so that it is available as soon as setup() has completed. Upon receiving a setup request the function fs driver creates an event that is made available to userspace. And only once userspace has acknowledged that event the response to the setup request is queued. So it violates the requirement of those UDC drivers and random failures can be observed. This is basically a race condition and if userspace is able to read the event and queue the response fast enough all is good. But if it is not, for example because other processes are currently scheduled to run, the USB host that sent the setup request will observe an error. To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS return code. If a setup() callback returns this value the UDC driver is aware that response is not yet available and can uses the appropriate methods to handle this case. Since in the case of function fs the response will never be available when the setup() function returns make sure that this status code is used. This fixed random occasional failures that were previously observed on a DWC3 based system under high system load. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This commit is contained in:
parent
4058ebf33c
commit
946ef68ad4
@ -3243,7 +3243,7 @@ static int ffs_func_setup(struct usb_function *f,
|
||||
__ffs_event_add(ffs, FUNCTIONFS_SETUP);
|
||||
spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags);
|
||||
|
||||
return 0;
|
||||
return USB_GADGET_DELAYED_STATUS;
|
||||
}
|
||||
|
||||
static bool ffs_func_req_match(struct usb_function *f,
|
||||
|
Loading…
Reference in New Issue
Block a user