On Thu, Oct 15, 2015 at 7:59 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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, > I have been referring to this "0-length IN transaction" when I said "need to send a zlp". > 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). > OK, so that is a known 'feature', not a bug in gadget drivers as I have been calling it. I was trying to make the f_acm.c send that "0-length IN transaction" by making 'value=0' Thanks -- 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
