On Thu, Aug 30, 2018 at 10:50 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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". OK, understood. I read the part of the USB spec about this (functional and protocol stalls). > >> 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. Yes, I understand this. The idea is to stall/wait until the userspace provides a response. Like gadgetfs, but for every USB request. > > 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. Is there a way to tell the UDC to not send the STALL packet, but to just wait? Assuming the userspace will read the request and provide a response within the timeout (50ms? [1]). Would this approach be supported by more hosts than sending STALLs? [1] https://www.beyondlogic.org/usbnutshell/usb6.shtml > >> 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. So the USB spec doesn't specify how the host should react to these protocol STALL packets, but some USB hosts (e.g. Linux) just resend the request? I assume that other popular hosts (Windows, MacOS, etc.) do that as well, otherwise gadgetfs wouldn't be usable to emulate USB devices for them. Although while searching info about this I found an article [2], which states: "The EFM8 HID device sends a STALL handshake in response to the get DEVICE_QUALIFIER descriptor request because the EFM8 HID device does not support the certain request. After that, the USB host will issue the next SETUP transaction". So the host skips the request and goes to the next one instead of rerequesting. [2] https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2017/06/18/the_role_of_stallha-pQTe Do you know of any particular hosts that fail right away when they receive a protocol STALL? > >> 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 >
