Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov <andreyknvl@google.com>]

On Tue, Jun 18, 2019 at 3:53 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Tue, 18 Jun 2019, Andrey Konovalov wrote:
>
> > On Tue, Jun 18, 2019 at 3:31 PM Andrey Konovalov <andreyknvl@google.com> wrote:
> > >
> > > On Fri, Jun 7, 2019 at 5:05 PM Andrey Konovalov <andreyknvl@google.com> wrote:
> > > >
> > > > On Fri, Jun 7, 2019 at 5:02 PM Alan Stern <stern@rowland.harvard.edu> 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). 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
>