On Tue, Mar 4, 2014 at 10:56 PM, David Laight <David.Laight@xxxxxxxxxx> wrote:
> From: Bjørn Mork
>> > If xHCI won't plan to support arbitrary-length scatter-gather any more, that
>> > is fine to revert the commit forever. Otherwise, it should be better to just
>> > clear no_sg_constraint in xhcd, shouldn't it?
>>
>> No, that's what's currently causing bugs with the storage driver.
>>
>> IIUC, the bug was added by
>>
>> commit 10e232c597ac ("USB: check sg buffer size in usb_submit_urb")
>>
>> which introduced an additional restriction on SG URBs not present
>> before:
>>
>> + for_each_sg(urb->sg, sg, urb->num_sgs - 1, i)
>> + if (sg->length % max)
>> + return -EINVAL;
>>
>>
>> where max is usb_endpoint_maxp(&ep->desc). As has been shown by
>> numerous bug reports lately, the storage driver will submit SG lists
>> with 512 byte elements on superspeed endpoints with max == 1024.
>
> That has never been 'fine'.
So when this SS storage device(maxp isn't 512) comes and block layer
may send scatter-gather list with an non-tail entry that isn't aligned
to the max packet size, looks xHCD has to enable no_sg_constraint
and has to deal with it correctly, and I am wondering if there is other
solutions for the case.
Basically this case is very similar with current usbnet(axis 88179/
178a).
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
