On Fri, Jun 28, 2019 at 6:44 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > On Tue, Jun 18, 2019 at 3:53 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > 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.) > > And another one to clarify :) > > So if we got a setup() callback, which denotes: > 1. an IN transfer, we need to submit an URB with response (even if > wLength == 0). When it completes, the transaction is over, and we will > get the next setup() callback (if there's going to be any). > 2. an OUT transfer, we need to submit an URB to fetch the data (even > if wLength == 0). Or more like: to fetch the data when wLength != 0 and to acknowledge the request when wLength == 0. > When it completes, the transaction is over, and we > will get the next setup() callback (if there's going to be any). > > Is the above correct? > > > > > > 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 > >
