Hi, Lars-Peter Clausen <lars@xxxxxxxxxx> 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? -- balbi
Attachment:
signature.asc
Description: PGP signature
