On Wed, 14 Oct 2015, Felipe Balbi wrote: > Hi, > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > On Wed, 14 Oct 2015, Jassi Brar wrote: > > > >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some > >> setup request that has USB_DIR_IN not set? > > > > Yes. If USB_DIR_IN is not set then the control transfer is OUT, so the > > gadget needs to queue a request to receive some data from the host. > > That request will obviously need to be a non-ZLP. In fact, it's hard > > to think of a situation where a gadget would ever want to submit a > > zero-length OUT request. Isn't the UDC driver supposed to handle the > > status stage of a control-IN transfer automatically? > > yes and no. :-) If USB_GADGET_DELAYED_STATUS is returned, we need to > wait for the gadget driver to queue a request. USB_GADGET_DELAYED_STATUS is used with control-OUT transfers that don't have a data stage. I was speaking of control-IN, because the status stage for a control-IN transfer is a zero-length OUT transaction. But speaking of DELAYED_STATUS, there is a long-standing weakness in the Gadget API. When a gadget receives data from the host in a control-OUT transfer, the API doesn't provide any way for the gadget to delay the status stage until its processing is complete. USB_GADGET_DELAYED_STATUS only works as a return value from the setup routine; once the data stage has started there's no way to delay the status stage. It's an unfortunate oversight in the original design. 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
