> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Zimmerman > Sent: Thursday, May 08, 2014 11:42 AM > > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern > > Sent: Thursday, May 08, 2014 10:40 AM > > > > On Thu, 8 May 2014, Felipe Balbi wrote: > > > > > > The dwc3 driver should always prepare a buffer for the next ep0 SETUP > > > > packet as soon as it retrieves the information for the current SETUP > > > > packet from the buffer. > > > > > > > > Otherwise, as you described it, if the gadget driver never sends its > > > > delayed status response then the UDC will never respond to any more > > > > control transfers. > > > > > > we _do_ prepare transfers for setup packet everytime a Status phase is > > > completed (we also restart ep0 in case of stalls): > > > > I said that dwc3 should prepare a buffer for a SETUP packet every time > > a _SETUP_ stage is completed -- not every time a _STATUS_ stage is > > completed. > > > > In principle the host can send a SETUP packet at any time, even in the > > middle of an ongoing transfer. (Consider the case where a driver on > > the host unlinks a control transfer before it has completed and then > > submits a new one.) > > Just FYI, the DWC3 core is designed to always respond to SETUP packets. > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up > properly according to the databook. If the buffer fills up, then > further SETUP packets will get lost, but they will still be ACKed. I forgot to say, this means that it is not necessary to prepare a buffer for the next SETUP immediately after the previous SETUP stage ends, since the next SETUP will be cached in the controller. There is a flowchart in the databook that describes the programming flow for Control transfers. I think the DWC3 driver follows this pretty closely, although it has been a while since I last reviewed it. -- Paul -- 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
