On Sat, 22 Jun 2013, Ming Lei wrote: > On Sat, Jun 22, 2013 at 12:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 21 Jun 2013, Ming Lei wrote: > >> But the patch violates USB spec, doesn't it? > > > > No, the client driver violates the kernel's requirements by submitting > > an SG transfer that can't be carried out. Although it probably isn't > > documented anywhere, the USB stack requires that the size of each SG > > element except the last one must be a multiple of the endpoint's > > maxpacket value. > > Look there is the description: > > 5.3.2 Pipes of USB 1.1 spec: > > An IRP may require multiple data payloads to move the client data over the bus. > The data payloads for such a multiple data payload IRP are expected to be of > the maximum packet size until the last data payload that contains the remainder > of the overall IRP. Yes, I know. So what? The spec doesn't say anything about the requirements of Linux's USB stack. > > (The wireless USB stack may have a weaker requirement here. I'm > > talking about wired USB only.) > > > > We could fail the transfer request if the SG element length violates > > this requirement. That would be acceptable. But then ehci-hcd and > > xhci-hcd should be updated to do the same thing. > > > >> Also it sets the later packet size of TD as the small one, is it correct? > > > > I don't understand the question. TDs don't have a "later" or an > > "earlier" packet size. Are you referring to the ActLen and MaxLen > > fields in the TD? And what do you mean by "the small one"? > > I mean MaxLen, the patch changes 'pktsze' as 'this_sg_len' if 'this_sg_len' > is less than 'pktsze', then the maxlen of all following TDs will use the > value smaller than maxp. No, they won't. pktsze gets reinitialized each time through the loop. 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
