On Tue, Jun 5, 2018 at 10:06 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 5 Jun 2018, Andrey Konovalov wrote: [...] > What do you need that's different from what gadgetfs provides? 1. It does some sanity checks on the provided USB descriptors, which we don't really want, since providing improper descriptors is a way to find bugs. 2. Replies to some USB requests without asking the user. Same thing, giving the user (== syzkaller) to reply something improper can trigger some bugs. 3. File based interface is somewhat inconvenient for integration with syzkaller. (4. Doesn't support SuperSpeed and doesn't support multiple UDC devices. This can be fixed of course. ) Basically what (I think) I want is an ioctl-based GadgetFS-like interface, that doesn't implement any USB protocol logic, but simply passes all received requests to the user and asks for replies. [...] >> Could you elaborate on this? AFAIU the dummy device contains both a >> virtual UDC and a virtual HCD that are connected to each other and >> allow to plug a gadget device into usb core within the kernel. How do >> you test a driver for an actual host controller? Is there a way to >> connect a dummy UDC with an actual HCD? > > You can't connect a dummy UDC to an actual HCD. But you can connect an > actual UDC to an actual HCD -- people do it all the time. > > Normally the UDC and the HCD reside on separate computers. For > example, mobile devices typically have UDCs, and you can connect them > to PCs. But there is also UDC hardware available for Linux on Intel > systems, so you can have the UDC and the HCD in the same computer if > that's what you want. Or two separate PCs, both running Linux. Or > even a Linux PC gadget connected to a Windows or OS X host! I see, but that all requires real hardware, right? You can't just run it in a VM (that's what I'm planning to do with dummy_hcd)? [...] > Right. For example, usb-storage uses a work-queue routine for SCSI > scanning when a new device is probed. And in that routine, the SCSI > layer often delegates some of the scanning work to async helper > threads, depending on the how the system is configured. Could you point me to the code that does that? I mean SCSI scanning. [...] >> 2. All the virtual UDCs get the same name "dummy_udc". And since the >> process of UDC lookup to bind a gadget driver is based on the UDC name >> (see usb_gadget_probe_driver()), we can't bind different gadget >> drivers to different UDCs (and therefore connect to different hubs). > > That can be changed pretty easily. For virtual UDCs beyond the first, > we could append "-2", "-3", and so on to the "dummy_udc" name, for > example. I wrote a patch to implement this and then realized that it's actually not needed. Even though all UDC devices have the same name "dummy_udc", it seems they are actually renamed by someone and end up getting names "dummy_udc.0", "dummy_udc.1" and so on (that'w what I see when I add printk to usb_gadget_probe_driver()). What initially confused me was that gadgetfs always binds to the same UDC, but that's because it doesn't set the udc_name field of the usb_gadget_driver struct (and also because it always expects the UDC name to be the one returned by usb_get_gadget_udc_name(), but that part I patched when I was trying to bind it to some other UDC). Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
