On Tue, 7 Feb 2012, Paul Zimmerman wrote: > If you do need to do this in software, it should be pretty easy. Only > one control transfer can be active at a time, so any request from the > gadget driver is for the last setup that the UDC passed to it. If the > UDC receives another setup packet in the meantime, then it knows the > one in progress should be canceled. It can hold onto the second setup > packet until the gadget completes all phases of the previous one (and > the UDC just throws away those commands instead of acting on them) > before sending the second setup packet to the gadget. That works. In fact, it's probably the only way to insure that a response received from the gadget driver while the setup callback is running is really a response to the current SETUP, rather than the previous one. > The only problem would be a control write with a data stage. Then you > would have the problem of what data to send to the gadget for the data > stage. All zeroes maybe? But I don't think any 3-stage control write > transfers exist in any of the current protocols, so it may not be an > issue. They do exist; that's how SCSI commands are sent in the mass storage CB[I] transports. And it's how lots of devices receive firmware updates. The answer is simple enough: The UDC driver knows that the current transfer is already out of date. Therefore it should either not accept the request to read data from the host in the first place, or it should complete the request with an error (and presumably 0 bytes of data received). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
