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.
--
balbi
Attachment:
signature.asc
Description: Digital signature
