On Thu, 15 Oct 2015, Jassi Brar wrote: > 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". You're thinking of what happens when the host does a 0-length control-OUT transfer. In that case there is no data stage, so after the setup stage you go directly to the status stage -- which consists of a 0-length IN transaction that the gadget driver has to submit. It sounds like you were getting confused over the difference between a 0-length and a more-than-0-length control-OUT transfer. They don't get handled the same way. > > 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 You're welcome. 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
