On Tue, Jun 05, 2012 at 08:56:12AM -0700, Sarah Sharp wrote:
> On Tue, Jun 05, 2012 at 01:09:17PM +0200, Hans de Goede wrote:
> > But an important user of the flag is usb_sg_init and friends, which gets used in:
> > ./drivers/usb/storage/transport.c
> > ./drivers/usb/misc/usbtest.c
> > ./drivers/usb/core/message.c
> > ./drivers/staging/rts5139/rts51x_transport.c
> > ./drivers/staging/usbip/vhci_hcd.c
> > ./drivers/staging/keucr/transport.c
>
> Should these staging drivers really be using usb_sg_init()? Also, are
> they really submitting sglists with multiple vectors, or just one
> vector?
>
> > ./drivers/mmc/host/vub300.c
>
> Why is a *host* driver using usb_sg_init()?
>
> > Which also means that the issues of XHCI ep rings not
> > stopping on a short transfer is bigger then we thought, as
> > under the right circumstances it can impact the linux
> > usb-storage driver too .. :|
>
> But short transfers should happen all the time with the usb-storage
> driver, so I don't understand why it wouldn't be effected by this bug.
Oh, I know why. usb_sg_init() does use the native xHCI scatter
gather interface:
if (use_sg) {
/* There is no single transfer buffer */
urb->transfer_buffer = NULL;
urb->num_sgs = nents;
/* A length of zero means transfer the whole sg list */
len = length;
if (len == 0) {
struct scatterlist *sg2;
int j;
for_each_sg(sg, sg2, nents, j)
len += sg2->length;
}
}
So instead of submitting multiple URBs to the xHCI driver, it submits one URB
with the sglist entry.
So usbfs just needs to call usb_sg_init(), which will automatically use the
xHCI native scatter gather interface.
Sarah Sharp
--
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
