On Tue, Aug 23, 2011 at 12:32:23AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Aug 22, 2011 at 01:36:58PM -0700, Greg KH wrote:
> > > > diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> > > > index bb10846..bd71500 100644
> > > > --- a/drivers/usb/misc/usbtest.c
> > > > +++ b/drivers/usb/misc/usbtest.c
> > > > @@ -359,8 +359,10 @@ static int simple_io(
> > > > urb->context = &completion;
> > > > while (retval == 0 && iterations-- > 0) {
> > > > init_completion(&completion);
> > > > - if (usb_pipeout(urb->pipe))
> > > > + if (usb_pipeout(urb->pipe)) {
> > > > simple_fill_buf(urb);
> > > > + urb->transfer_flags |= URB_ZERO_PACKET;
> > > > + }
> > > > retval = usb_submit_urb(urb, GFP_KERNEL);
> > > > if (retval != 0)
> > > > break;
> > >
> > > this looks good to me, as of today, the only way to pass testusb is to
> > > cancel requests when we start the next one, rather then having them
> > > completed. Adding a ZLP on the requests, will force the requests to
> > > complete even though they have a size which is aligned to
> > > wMaxPacketSize, which allow us to remove the hackish abort transfer on
> > > all UDCs.
> >
> > But don't you need that to handle this type of thing properly if it were
> > to happen with a "real" device? So you really can't remove that check,
> > so we should leave the usbtest driver alone, right?
>
> From USB in a nutshell we have:
>
> "A bulk transfer is considered complete when it has transferred the
> exact amount of data requested, transferred a packet less than the
> maximum endpoint size, or transferred a zero-length packet."
>
> From USB 3.0 Specification we have (4.4.6.1):
>
> "A bulk transfer is complete when the endpoint does one of the
> following:
>
> . Has transferred exactly the amount of data expected.
> . Transfers a data packet with a payload less than 1024 bytes.
> . Responds with a STALL handshake."
>
> From USB 2.0 Specification we have (5.8.3)
>
> "A bulk transfer is complete when the endpoint does one of the
> following:
>
> . Has transferred exactly the amount of data expected
> . Transfers a packet with a payload size less than wMaxPacketSize or
> transfers a zero-length packet"
>
> In this particular test case, we are falling in a situation where gadget
> driver waits to receive 4096 bytes, but host only sends 2048 bytes.
> Withtout a packet which is less than wMaxPacketSize, we don't know when
> to finish the transfer. Clearly a ZLP is needed here IMHO. Doing an
> Abort transfer on the next EP IRQ sounds very hackish to me and this is
> actually a long standing bug of the Gadget Framework which was added
> just to get g_zero to work rather than fixing the broken usbtest.c
> module.
Ah, ok, thanks, I missed the fact that this was a short-send, the patch
looks correct then.
Can someone resend it without the "RFC" line so that I can apply it?
thanks,
greg k-h
--
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
