Hi Alan, Alan Stern wrote: > > The way I read composite_setup() after try_fun_setup: it calls f->setup() > > when available, and that can return < 0 to stall. > > > > I expect that composite_setup() and thus f->setup() run when the > > SETUP packet has arrived, thus before the data packet arrives, and if > > composite_setup() stalls then the device/function should never see the > > data packet. > > > > For an OUT transaction I think the host controller might still send > > the DATA packet, but the device controllers that I know don't make it > > visible to the application in that case. > > ... > > Are you guys interested in comments from other people who know more > about the kernel and how it works with USB? I am, especially when it comes to the gadget code. > The USB protocol forbids a device from sending a STALL response to a > SETUP packet. The only valid response is ACK. Thus, there is no way > to prevent the host from sending its DATA packet for a control-OUT > transfer. Right; a STALL handshake only after a DATA packet, but a udc could silently drop the first DATA packet if instructed to STALL during SETUP processing. I don't know how common that is for the udc:s supported by gadget, but some MCU:s behave like that. > A gadget driver can STALL in response to a control-OUT data packet, > but only before it has seen the packet. How can it do that for OUT, and IN if possible there too? Is it related to f->setup() returning < 0 ? The spec also allows NAK, but the gadget code seems to not (need to?) explicitly support that. Can you comment on this as well? > Once the driver knows what the data packet contains, the gadget API > doesn't provide any way to STALL the status stage. Thanks. I think this particular gadget driver doesn't need to decide late. Ideally the control transfers can even be avoided. Thanks and kind regards //Peter
