Re: Testing endpoint halt support for raw-gadget

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 28, 2020 at 2:50 AM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
>
> On Mon, Apr 27, 2020 at 10:47 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
> >
> > On Mon, Apr 27, 2020 at 9:51 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
> > >
> > > On Fri, Apr 24, 2020 at 9:36 PM Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 2:29 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Thu, 9 Apr 2020, Andrey Konovalov wrote:
> > > > >
> > > > > > Hi Alan and Greg,
> > > > > >
> > > > > > I've been thinking about what kind of features raw-gadget might be
> > > > > > missing, that would allow more flexibility in emulating USB devices.
> > > > > > One of the things that is currently missing is halting endpoints.
> > > > > > Adding this functionality seems to be fairly easy, but it's unclear to
> > > > > > me how to test it. Any suggestions?
> > > > >
> > > > > You should use the usbtest driver along with the testusb program in
> > > > > tools/usb.  Of course, to do it you will need a userspace driver for
> > > > > raw-gadget.  usbtest works best with gadget-zero, but it can be used
> > > > > (in degraded form) with any USB device.
> > > >
> > > > Hi Alan,
> > > >
> > > > I've started working on a test suite for raw-gadget based on the
> > > > usbtest module as you suggested and have a few questions:
> > >
> > > Another question, which actually seems to be a major problem.
> > >
> > > It looks like automatic endpoint selection based on required features
> > > doesn't work in raw-gadget. The way it tries to do that is iterating
> > > over the list of available endpoints and finding one that has the
> > > right direction and transfer type. But it seems that the right way to
> > > do that (like it's done in usb_ep_autoconfig()) is to also patch the
> > > bEndpointAddress field of the endpoint descriptor.
> > >
> > > Currently with raw-gadget the endpoints are supposed to be enabled
> > > after a set_configuration/set_interface request from the host, so it's
> > > too late to patch the endpoint descriptor (the one that was sent to
> > > the host during enumeration). I'm guessing that sending one endpoint
> > > descriptor during enumeration and then using a different one (with
> > > patched bEndpointAddress) to set ep->desc before doing usb_ep_enable()
> > > won't work (as there's going to be mismatch in endpoint addresses
> > > between the host and the UDC), right?
> > >
> > > I wonder what we can do about that. It seems that we actually need to
> > > parse the descriptors and figure out the right endpoints before the
> > > enumeration starts.
> >
> > Or maybe somehow expose all endpoints and their features (like
> > GadgetFS) and let userspace put proper addresses into endpoint
> > descriptors before enumeration starts.
>
> I think this is the way to go, giving the userspace maximum control
> over what's going on. Seems not too hard to implement too. The only
> part that is not clear to me is how to figure out the endpoint address
> that a particular UDC endpoint expects to have.
>
> Most of the time endpoints are named as something like "ep1in" or
> "ep2out", and AFAIU the number in the endpoint name is the address.
> However net2280 seems to have weird endpoint names "ep-a", "ep-b",
> etc. Looking at usb_ep_autoconfig_ss(), those endpoints supposedly
> have sequential addresses starting from 1 (for each in/out type). But
> then in the GadgetFS example [1] e.g. "ep-a" corresponds to address 7,
> which I don't understand. My guess is that this is done to handle both
> dummy_udc and net2280 in a single if case, but I'm not sure.
>
> [1] http://www.linux-usb.org/gadget/usb.c

Oh, there's actually a comment that explains this [1] in dummy_hcd.c
(exactly the place where one would look for it :). So "ep-a" and
others are fully configurable and accept any endpoint address. OK, I
think I've figured out what to do here, will send a patch.

[1] https://elixir.bootlin.com/linux/v5.7-rc3/source/drivers/usb/gadget/udc/dummy_hcd.c#L113



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux