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'.
For USB3 the xhci controller (at least some versions) needs special
code that isn't present in the linux driver it order to always correctly
setup transfers that have sg boundaries that are not at multiples
of 1k from the start of the transfer.
The actual boundary mentioned in the specification is actually a 16k
boundary (because it can send 16 packet bursts, and it is the burst
boundary that matters). But the effect of failing to meet the restriction
is almost certainly that the USB transfer it split. This isn't detectable
at the target provided the data is 1k aligned.
Unfortunately the simple fixes to the driver end up limiting the number
of SG entries - and various parts of the storage system send arbitrarily
long SG lists.
This isn't helped by the fact that the driver has to split SG buffers on
64k address boundaries.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
