Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov <andreyknvl@google.com>]

On Fri, Jun 7, 2019 at 2:02 PM Felipe Balbi
<felipe.balbi@linux.intel.com> wrote:
>
>
> Hi,
>
> Andrey Konovalov <andreyknvl@google.com> writes:
> > I've noticed that when the host performs a control request,
> > urb->transfer_buffer/transfer_buffer_length are not passed to the
> > gadget drivers via the setup() call, the only thing that is passed is
> > the usb_ctrlrequest struct. Is there a way to get the transfer_buffer
> > from within a gadget driver? If not, what approach would the best to
> > implement this?
>
> I think you need to further explain what you mean here.
>
> What do you mean by gadget driver in this case?
>
> If you mean the drivers under drivers/usb/gadget/{function,legacy}
> directories then there's no way that they can have access to anything
> from the host.
>
> Remember that gadget and host are two completely distinct units. The
> only thing they share is a USB cable. When it comes to Control
> Transfers, if a data stage is necessary, that must be encoded in the
> wLength field of the control structure.
>
> Also, host side does *not* pass its usb_ctrlrequest struct to the
> gadget, it passes a series of 8 bytes which are oblivious to where in
> memory they were from the host point of view.
>
> If if you have the same machine acting as both host and device, each
> side has no knowledge of that fact.

Hi Felipe,

What I meant is that any module (gadget driver) that implements
usb_gadget_driver struct callbacks and registers it, will only get
usb_ctrlrequest through the setup() callback, but not the
transfer_buffer/length. And therefore it can't access the data that is
attached to a control request.

I've faced this with a custom implementation of a gadget driver module
while using the dummy_hcd module, but I AFAIU it's not relevant to
those two, but rather to the whole gadget subsystem.

Thanks!

>
> --
> balbi