On Wed, 9 Jan 2019, Paul Elder wrote: > This patch series adds a mechanism to allow asynchronously validating > the data stage of a control OUT request, and for stalling or suceeding > the request accordingly. One thing we haven't mentioned explicitly: What should happen when the time for the status stage rolls around if the gadget driver queues a non-zero length request? This can happen in a few different ways. One obvious possibility is that the gadget driver sets the explicit_status flag and then submits a non-zero length request. Another is that the gadget driver submits _two_ requests during the data stage (the second would be interpreted as the status-stage request). A third is that the gadget driver submits a data-stage request that is too long and the excess portion is used for the status stage. My feeling is that the behavior in these cases should officially be undefined. Almost anything could happen: the status stage could STALL, it could succeed, it could NAK, or it could send a non-zero packet to the host. The request could return with 0 status or an error status, and req->actual could take on any reasonable value. Alternatively, the UDC driver could detect these errors and report them somehow. Maybe STALL the status stage and complete the request with -EPIPE status or some such thing. Any preferences or other ideas? One other thing: Some UDC drivers may assume that the data stage of a control transfer never spans more than a single usb_request. Should this become an official requirement? Alan Stern
