Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov <andreyknvl@google.com>]

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?

>
> >
> > Alan Stern
> >