On Thu, 30 Aug 2018, Andrey Konovalov wrote: > Hi Alan, > > I have a few questions about gadgetfs. > > According to documentation usb_gadget_driver->setup "queues a response > to ep0, or returns negative to stall". > > Do I understand correctly, that "stall" in this case means "retry the > same request later" and it's unrelated to the STALL USB packet? No; it _is_ related to USB STALL packets. In fact, it means "send a STALL packet back to the host". > Is it OK to stall the initial control requests (the one that requests > the device descriptor for example)? Well, the USB spec allows a device to do this. However, a device that always returns STALL for a Get-Device-Descriptor request will not be usable for anything, since the host will not be able to enumerate it. The Linux USB stack will try such requests up to three times. And there are retry loops at higher layers in the code too, so it can take quite a while before the stack finally gives up. > What exactly happens when we stall between the gadget and the host? > Does the UDC driver/hardware see that we don't have a response yet and > waits? Or does it somehow communicate that stall to the host? It sends a STALL packet to the host. > Does it make any difference whether we stall or reply right away from > the host point of view? It depends on how the host-side code is written. Some code will retry STALLed requests a few times, and some code will fail right away. > The questions arose when I started implementing a gadgetfs like > interface, that allows to respond to every USB packet (including the > initial control requests) from a userspace app. > > Thanks! You're welcome. Alan Stern
