Re: Pass transfer_buffer to gadget drivers

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, 28 Jun 2019, Andrey Konovalov wrote:

> On Fri, Jun 28, 2019 at 6:44 PM Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> > On Tue, Jun 18, 2019 at 3:53 PM Alan Stern <stern@rowland.harvard.edu> wrote:

...

> > > > > 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).

Yes, except that wLength should never be 0 for an IN transfer.  If it 
is, it's a bug in the host.

> > 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?

Correct.

There has been some discussion (and a few patches posted) about
modifying this approach.  But for now, this is the way to do it.

Alan Stern