On Fri, 21 Jun 2013, Ming Lei wrote:
> On Fri, Jun 21, 2013 at 11:19 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, 21 Jun 2013, Konstantin Filatov wrote:
> >
> >> > --- a/drivers/usb/host/uhci-q.c
> >> > +++ b/drivers/usb/host/uhci-q.c
> >> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_hcd *uhci, struct urb *urb,
> >> > for (;;) { /* Allow zero length packets */
> >> > int pktsze = maxsze;
> >> >
> >> > + if (this_sg_len < pktsze) /* The short packet */
> >> > + pktsze = this_sg_len;
> >> > This will build a short packet transfer descriptor which is not the last
> >> > one, and it isn't correct.
> >> Why do you think so? Could you please refer to the specification of UHCI.
> >
> > It _isn't_ correct. But the fault lies in the driver that submitted
> > the SG transfer in the first place, not in uhci-hcd. This is the right
> > thing to do.
>
> The correct fix should be: not using sg under this situation by
> patching usb_sg_init(),
> shouldn't it?
I'm not sure what you mean. Do you mean that usb_sg_init() should fail
if the SG element length isn't a multiple of the maxpacket size? That
probably will break wireless USB.
Do you mean that usb_sg_init() should break the transfer up into a
bunch of separate URBs in this case (the way it does when the HCD
doesn't have native support for SG)? That won't work because one of
the URBs would have a transfer length that wasn't a multiple of the
maxpacket size.
Furthermore, URBs using SG can be submitted directly, without going
through usb_sg_init() at all. So changing usb_sg_init() won't fix the
problem.
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
