Re: Pass transfer_buffer to gadget drivers

[Felipe Balbi <felipe.balbi@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]


Hi,

Andrey Konovalov <andreyknvl@google.com> writes:
>> >> 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.
>>
>> A control request is *always* 8 bytes. That's mandated by the USB
>> specification.
>>
>> > And therefore it can't access the data that is
>> > attached to a control request.
>>
>> There is no data attached to a control request. A Control Transfer is
>> composed of 2 or 3 stages:
>>
>> - SETUP stage
>>         an 8 byte transfer descriptor type thing
>>
>> - (optional) Data stage
>>         if wLength of control request contains a value > 0, then this
>>         stage fires up to transfer the amount of data communicated in
>>         wLength (during previous stage).
>>
>> - Status Stage
>>         A zero length transfer to communicate successful end of transfer
>>         (in case it completes fine) or an error (in case of STALL
>>         condition).
>
> Hm, then why does the usb_control_msg() function accepts a data and
> size arguments? Which are described in the comment as "pointer to the
> data to send" and "length in bytes of the data to send" accordingly?
> Or is this the buffer for the response?

That's for the data stage :-)

usb_control_msg() is an upper lever API to encode and entire Control
Transfer (all stages of it).

What is the problem you see, then?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]