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