Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 -- balbi
Attachment:
signature.asc
Description: PGP signature
