usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

[Felipe Balbi <balbi@kernel.org>]

Hi,

Lars-Peter Clausen <lars@metafoo.de> writes:
> Some UDC drivers (like the DWC3) expect that the response to a setup()

not some, but *all*. You can only queue a response later IFF you return
USB_GADGET_DELAYED_STATUS.

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

I need to see tracepoint capture from the failure ;-) Care to send them
to me for analysis?