Den 02.06.2020 20.38, skrev Peter Stuge: > Alan Stern wrote: >>>> 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? >> >> In the way described just above: The gadget driver's SETUP handler tells >> the UDC to stall the data packet. >> >>> Is it related to f->setup() returning < 0 ? >> >> Yes; the composite core interprets such a value as meaning to STALL >> endpoint 0. > > Thanks a lot for confirming this. > > >>> The spec also allows NAK, but the gadget code seems to not (need to?) >>> explicitly support that. Can you comment on this as well? >> >> If the gadget driver doesn't submit a usb_request then the UDC will >> reply with NAK. > > And thanks for this as well. > > >>> a status request so I can know the result of the operation the device has >>> performed. > .. >> There are two reasonable approaches you could use. One is to have a >> vendor-specific control request to get the result of the preceding >> operation. > .. >> The other approach is to send the status data over a bulk-IN endpoint. > > I've tried to explain a third approach, which I think fits well because the > status is only a "Ready" flag - ie. a memory barrier or flow control, > to make the host not send data OUT. > > I'm proposing that the gadget should NAK on data OUT when it isn't Ready, and > that the host driver shouldn't query status but simply send data when it has. > > Per Alans description the NAK happens automatically if the gadget driver has > no usb_request pending while it is processing previously received data. > > On the host that NAK makes the host controller retry automatically until > transfer success, timeout or fatal error. > > >> It would have to be formatted in such a way that the host could >> recognize it as a status packet and not some other sort of data packet. > > For host notification of status changes other than Ready I really like > such an IN endpoint, but preferably an interrupt endpoint. > > To avoid the formatting problem each data packet could be one full status > message. That way the host would always receive a known data structure. > Interrupt packets can be max 64 byte. Noralf, do you think that's enough > for everyone in the first version? > I'm going through some treatment that turned out to be worse than expected, so sadly I have to put this project on hold until my body recovers. Noralf.
