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
