From: Andrey Konovalov <andreyknvl@google.com>
To: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
USB list <linux-usb@vger.kernel.org>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Pass transfer_buffer to gadget drivers
Date: Fri, 7 Jun 2019 14:45:40 +0200 [thread overview]
Message-ID: <CAAeHK+y8Aj1r1XyNHwXe2dF_yxoQSe2_u4-aDOPkYk9Q9tRGzA@mail.gmail.com> (raw)
In-Reply-To: <871s05d0rg.fsf@linux.intel.com>
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
next prev parent reply other threads:[~2019-06-07 12:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 11:44 Pass transfer_buffer to gadget drivers Andrey Konovalov
2019-06-07 12:02 ` Felipe Balbi
2019-06-07 12:14 ` Andrey Konovalov
2019-06-07 12:25 ` Felipe Balbi
2019-06-07 12:32 ` Andrey Konovalov
2019-06-07 12:43 ` Felipe Balbi
2019-06-07 12:45 ` Andrey Konovalov [this message]
2019-06-07 14:04 ` Alan Stern
2019-06-07 14:38 ` Andrey Konovalov
2019-06-07 15:02 ` Alan Stern
2019-06-07 15:05 ` Andrey Konovalov
2019-06-18 13:31 ` Andrey Konovalov
2019-06-18 13:34 ` Andrey Konovalov
2019-06-18 13:53 ` Alan Stern
2019-06-19 6:36 ` Felipe Balbi
2019-06-28 16:44 ` Andrey Konovalov
2019-06-28 17:29 ` Andrey Konovalov
2019-06-28 18:07 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAeHK+y8Aj1r1XyNHwXe2dF_yxoQSe2_u4-aDOPkYk9Q9tRGzA@mail.gmail.com \
--to=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=felipe.balbi@linux.intel.com \
--cc=glider@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).