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. > > (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. Thanks, -- Ming Lei -- 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
