On Wed, 8 Jul 2015, Rui Miguel Silva wrote:
> >> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> >> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> >> @@ -1367,8 +1367,10 @@ top:
> >> /* many requests terminate without a short packet */
> >> } else {
> >> if (req->req.length == req->req.actual
> >> - && !req->req.zero)
> >> + && !req->req.zero) {
> >> req->req.status = 0;
> >> + *status = 0;
> >> + }
> >> if (urb->transfer_buffer_length == urb->actual_length
> >> && !(urb->transfer_flags
> >> & URB_ZERO_PACKET))
> >
> >This patch is wrong. *status should indeed remain -EINPROGRESS and the
> >transfer should remain incomplete.
> >
> >Here's an example to illustrate what I mean. Let's say the endpoint's
> >maxpacket value is 512, and suppose the host queues a 1024-byte IN URB.
> >In response, suppose the gadget queues two 512-byte requests, each with
> >req->req.zero clear. Consider what happens when the first request is
> >processed.
> >
> >len, req->req.length and req->req.actual are all equal to 512, and
> >is_short is false. req therefore completes with req->req.status set to
> >0. But the URB is still in progress! It still has 512 bytes left to
> >transfer, and it won't complete until the second request finishes.
> >Therefore *status (which is the URB's status) should remain set to
> >-EINPROGRESS.
>
> Yes, in this case the patch breaks the flow and remove the URB status
> of -EINPROGRESS to soon. But what about, and taken your example above,
> the gadget queues only one 512-byte request? is_short is false, and
> urb->transfer_buffer_length != urb->actual_length and so the URB
> status is never changed.
Yes, the status never changes. And in fact, that is exactly what would
happen if you used a real UDC and a separate host computer instead of
dummy-hcd -- the URB would not complete. (In practice the URB would
eventually time out or be unlinked for some other reason.)
Since we want dummy-hcd to behave as much as possible like a real UDC,
we should keep the current code.
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
