On Thu, 8 May 2014, Zhuang Jin Can wrote: > > A similar problem can occur in the opposite sense: The thread queuing > > the delayed status request might be delayed for so long that another > > SETUP packet arrives from the host first. In that case, the delayed > > status request is a response for a stale transfer, so it must not be > > sent to the host. > > > > Do dwc3 and composite.c handle this case correctly? > > > So the situation you describe is that we get the STATUS XferNotReady > event, but gadget queues a status request when control transfer already > failed. When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request The gadget driver finally submits the delayed request response to the Set-Configuration request. But it is now too late, because the host expects a response to the Get-Descriptor request. > dwc3 can't move to SETUP phase until the status request arrives, > so any SETUP transaction from host will fail. If status request > eventually arrives, it already missed the first control transfer, and > I don't know how the controller will behave. If we still can get a > STATUS XferComplete event without actually transfer anything on the > bus, then we can move back to SETUP PHASE which will remove the stale > delayed status request and start the new SETUP transaction. But I think > in this situation, the host should already lose it patience and start > to reset the bus. My point is that the UDC driver can't handle this. Therefore the gadget driver has to prevent this from happening. That means composite.c has to avoid sending delayed status responses if a new SETUP packet has been received already. > Per my understanding, it's impossible for dwc3 to send a stale STATUS > request for a new SETUP transaction. dwc3 won't know that the status response is stale. It will think the response was meant for the new transfer, not the old one. 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
