On Tue, 18 Jun 2019, Andrey Konovalov wrote: > On Tue, Jun 18, 2019 at 3:31 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > > > On Fri, Jun 7, 2019 at 5:05 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > > > > > On Fri, Jun 7, 2019 at 5:02 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Fri, 7 Jun 2019, Andrey Konovalov wrote: > > > > > > > > > > > The problem is that I want to receive that data (from the data stage) > > > > > > > from within my gadget driver module. But it's not passed to the > > > > > > > setup() callback. And the question is: how do I do that then? > > > > > > > > > > > > I just caught up on this thread... > > > > > > > > > > > > The answer is simple: The gadget driver's setup() callback routine > > > > > > submits a request for endpoint 0. The Data Stage data is sent or > > > > > > received (depending on the direction encoded in the Setup information) > > > > > > by this request. > > > > > > > > > > Ah, OK, got it, thanks! > > > > > > > > > > Although while looking at the dummy_hcd implementation, I saw that it > > > > > accesses usb->transfer_buffer in case USB_REQ_GET_STATUS in > > > > > handle_control_request(), which is called right before the setup() > > > > > callback is called. So the data already available there without any > > > > > additional requests. Is this an implementation detail that is specific > > > > > to dummy_hcd? > > > > > > > > Yes, it is. dummy-hcd is unusual in that it combines both a USB host > > > > controller and a USB device controller in a single driver. > > > > > > > > Normal UDC drivers do handle USB_REQ_GET_STATUS on their own without > > > > requiring the use of an explicit usb_request, because they handle the > > > > entire transfer internally and don't involve the gadget driver. > > > > However, they don't have access to any transfer_buffer; all they can do > > > > is exchange packets with the host. > > > > > > OK, I see. Thanks a lot! > > > > Another question: do I understand correctly, that we only proceed with > > submitting an URB to get the data for the control OUT request > > (ctrl->bRequestType doesn't have the USB_DIR_IN bit set) if > > ctrl->wLength != 0? That's right. If a control-OUT transfer has wLength == 0, it means there is no data stage. (And control-IN transfers are not allowed to have wLength == 0.) > Also, does the gadget subsystem guarantee, that we get the complete() > callback for the DATA stage of the OUT control request before we get a > setup() callback for the next control request if there's any? As I recall, this isn't mentioned in the documentation. But the UDC drivers I know of do behave that way, and it's reasonable to assume they all do. After all, a data-stage transfer can't complete _after_ the next Setup packet arrives. Reception of a new Setup packet invalidates all ongoing control transfers. Alan Stern
