On Mon, 6 Feb 2012, Sebastian Andrzej Siewior wrote: > On 02/04/2012 05:14 PM, Alan Stern wrote: > > On Sat, 4 Feb 2012, Sebastian Andrzej Siewior wrote: > > > >>> What happens if host sends another setup packet while one of the above > >>> request is pending? Most of the controller drivers are nuking the > >>> endpoint and start processing the new packet. But the composite driver's > >>> processing is not canceled. I guess this can happen with the current > >>> "DELAYED_STATUS" implementation also. > >> > >> You should not continue processing setup packets after you received a > >> DELAYED_STATUS return code. > > > > No, that's wrong. The gadget _must_ process SETUP packets, always. > > But if break the HW or don't ACK the setup packet or just disable the Well, obviously broken hardware can do anything, but that doesn't make it right. And the hardware _must_ ACK every valid SETUP packet (see 8.5.3 in the USB-2.0 spec); it is not allowed to reply with NAK. > IRQs you never receive a second one packet untill the first SETUP > packet is done. The gadget will process the packet but at a later point > in time. After all you could hold a spinlock with irqs for a long time > and notice the second setup packet before the gadget was done with the > first one. Doesn't matter. If the hardware is designed properly, it will flush the ep0 FIFO whenever a new SETUP packet arrives. The UDC driver must be written so that it doesn't queue a response to an old SETUP packet. > > What should happen is that the response to the first SETUP (the one > > that was delayed) should not be sent after another SETUP is received. > > If the workqueue routine hasn't started running yet, cancelling it > > would be a good idea. > > That isn't actually that easy. Canceling means waiting until it is > done. Not necessarily. If a workqueue routine hasn't started yet, you can cancel it right away. But if it has already started then you're right; it can't be cancelled. Nevertheless, the UDC driver must not accept transfer requests for ep0 from an old setup() callback after a new SETUP packet has arrived. > What is wrong processing one setup packet after the other? Suppose the host sends a Set-Interface request, and you delay handling it. If the delay is too long, the host will time out and cancel the request. Then the host sends some completely different request, such as Set-Feature. If your delayed response goes back now, the host will think you accepted the Set-Feature request and not realize that you really carried out the Set-Interface. In addition, the response to the Set-Feature request will remain sitting in the ep0 FIFO and never get sent, because the host won't ask for it. 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
