Hi,
Alan Stern stern@rowland.harvard.edu writes:
Alan Stern stern@rowland.harvard.edu writes:
So I am not sure how the Gadget driver can figure out that it needs to usb_ep_queue() another request for status stage when handling the no-data control?
Gadget drivers already queue status-stage requests for no-data control-OUT requests. The difficulty comes when you want to handle an IN request or an OUT request with a data stage.
I don't see a difficulty there. Gadget driver will see wLength and notice it needs both data and status stages, then it does:
usb_ep_queue(ep0, data_req, GFP_KERNEL); usb_ep_queue(ep0, status_req, GFP_KERNEL);
The main difficulty is that all the gadget/function drivers will have to be audited to add the status requests.
yeah, that's a given and was also mentioned in this thread somewhere.
Just needs to prepare both requests and queue them both ahead of time. UDC drivers should hold both requests in their own private list and process one at a time.
Or the gadget driver should queue the status request after the data stage has been fully processed, in the case of an OUT transfer.
right, we could use ->complete() for that.
There is still a possible race. The host might send another SETUP packet before the status request has been queued, or after it has been
we should also have code for this race since it would happen with USB_GADGET_DELAYED_STATUS.
queued but before the UDC driver has completed it. (Of course, that's already true now for the data request...)
right