On Wed, Jun 06, 2012 at 11:03:54AM -0400, Alan Stern wrote: > On Wed, 6 Jun 2012, Sarah Sharp wrote: > > > There are two ways to deal with sglists: > > > > 1. Set urb->sg and everything else in the URB, and call > > usb_submit_urb(). This is what the UAS driver does, and the URB call > > back will be asychronous. > > > > 2. Call usb_sg_init() with a sglist. This will set up urb->sg. Then > > call usb_sg_wait() to wait on all the URBs to be completed. This is > > the path the usb-storage driver uses, and this path is synchronous. > > > > The only reason the usb-storage driver uses usb_sg_wait() is because it > > is designed to submit each part of the SCSI command and wait on each of > > the two to three URBs that make up that command. > > No. The reason usb-storage uses usb_sg_wait() is because it has to > work with _all_ host controller drivers, not just those that support > SG. The same should be true of usbfs. Ah, right. I think I've only ever used uas devices under xHCI, so that would explain it. However, UAS really shouldn't be using the synchronous usb_sg_wait(). That would defeat the purpose of multiple SCSI command queuing. :) Should we add an asynchronous scatter-gather interface to the USB core that falls back to submitting multiple URBs if the host controller doesn't have a native scatter gather interface? What would it mean to have an asynchronous callback for potentially multiple URBs? The USB core could submit each URB one at a time, with the Nth URB being submitted from a USB core completion callback. Then the driver's completion function could be called when all the URBs complete (or one URB fails with an error status, and the other URBs aren't submitted). 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
