On Thu, 15 Oct 2015, Jassi Brar wrote: > On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > > > By 'reply' I meant after reading out and parsing the > setup(control-out) request. I am sure we need to send a ZLP. You're wrong. Consider what happens when the host wants to send 7 bytes of data to the gadget using a control-OUT transfer: The gadget receives a SETUP packet. The USB_DIR_IN bit is clear because this is an OUT transfer, and wLength is set to 7. Which is what you got, right? Next, the host will send the 7-byte data packet. The gadget has to prepare to receive it, and it does so by submitting a 7-byte OUT request to ep0. This happens within the setup handler. The data packet is sent and the gadget receives it. The status stage for this transfer consists of a 0-length IN transaction, which the UDC driver automatically queues as soon as the completion routine for the data packet returns. The gadget driver isn't involved in the status stage (unfortunately). > > Could this cause the problem you're seeing? The host tries to send > > more data than the gadget is ready to receive? (Although then the > > error code on the gadget side should be -75, not -71.) > > > Thanks, but as you said my problem is not that (I get protocol error > -71). My problem is my udc driver actually tries to send a 7 byte > response to a control-out command. It shouldn't try to _send_ a 7-byte response; it should try to _receive_ a 7-byte data packet. This is, after all, an OUT transfer: host -> gadget. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html