On Fri, 31 Aug 2018, Andrey Konovalov wrote: > 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. If all you want to do is wait, STALL is not the appropriate strategy. Instead the device should send NAK packets to the host. STALL means "I can't process that request, because it is erroneous or I don't understand it". NAK means "I'm not yet ready to reply; try again later". > > 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 Sure. Just don't submit any response. With no data in its FIFO, the UDC will respond with NAK packets. Some gadget drivers use the special USB_GADGET_DELAYED_STATUS return code for this purpose in their ->setup() routine. > >> 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 The Linux stack will send the Get-Device-Qualifier request three times before giving up and moving on. See the usb_get_descriptor() routine in drivers/usb/core/message.c. > Do you know of any particular hosts that fail right away when they > receive a protocol STALL? Like I said before, it depends on the particular code. For example, Linux's usb-storage driver will give up after only one attempt at sending a Bulk-only Get-Max-LUN request. Alan Stern
