On Thu, 15 Oct 2015, Jassi Brar wrote:
> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern <[email protected]>
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
