Pass transfer_buffer to gadget drivers

Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

Hi Alan,

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?

Thanks!

Re: Pass transfer_buffer to gadget drivers

[Felipe Balbi]

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


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.

-- 
balbi

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

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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

Re: Pass transfer_buffer to gadget drivers

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2673 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).

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

What is this custom gadget doing? Which kernel version are you using?
What error are you facing? Could it be that you misunderstood how USB
works?

Best regards

-- 
balbi

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

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

On Fri, Jun 7, 2019 at 2:25 PM Felipe Balbi
<felipe.balbi@linux.intel.com> wrote:
>
>
> 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?

>
> > 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.
>
> What is this custom gadget doing? Which kernel version are you using?
> What error are you facing? Could it be that you misunderstood how USB
> works?

The details are here: https://www.spinics.net/lists/linux-usb/msg179158.html

But my question is not related to that custom gadget.

>
> Best regards
>
> --
> balbi

Re: Pass transfer_buffer to gadget drivers

[Felipe Balbi]

[-- 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 --]

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
<felipe.balbi@linux.intel.com> wrote:
>
>
> 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 :-)

Sure =)

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

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?

>
> --
> balbi

Re: Pass transfer_buffer to gadget drivers

[Alan Stern]

On Fri, 7 Jun 2019, Andrey Konovalov wrote:

> On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
> <felipe.balbi@linux.intel.com> wrote:
> >
> >
> > 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 :-)
> 
> Sure =)
> 
> >
> > 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?
> 
> 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.

Alan Stern

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

On Fri, Jun 7, 2019 at 4:04 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 7 Jun 2019, Andrey Konovalov wrote:
>
> > On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
> > <felipe.balbi@linux.intel.com> wrote:
> > >
> > >
> > > 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 :-)
> >
> > Sure =)
> >
> > >
> > > 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?
> >
> > 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?

>
> Alan Stern
>

Re: Pass transfer_buffer to gadget drivers

[Alan Stern]

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.

Alan Stern

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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!

>
> Alan Stern
>

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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?

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?

>
> >
> > >
> > > Alan Stern
> > >

Re: Pass transfer_buffer to gadget drivers

[Alan Stern]

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

> 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

Re: Pass transfer_buffer to gadget drivers

[Felipe Balbi]

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


Hi,

Alan Stern <stern@rowland.harvard.edu> writes:
>> 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.

Considering that the gadget API handles one stage at a time, it would be
impossible for this to not be the case :-)

UDCs start a trasnfer only for the setup phase, then process the
control request to decide what to do next.

-- 
balbi

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

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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
>

Re: Pass transfer_buffer to gadget drivers

[Andrey Konovalov]

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

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

Re: Pass transfer_buffer to gadget drivers

[Alan Stern]

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