On Mon, 9 Jan 2012, Matthew Wilcox wrote: > On Mon, Jan 09, 2012 at 07:45:46AM -0800, Greg KH wrote: > > > UAS is not using this function. It comes with usb_sg_wait() which > > > queues the URBs _and_ waits until the transfer is complete. For UAS > > > it should be non-blocking because we need to do this from IRQ > > > context. > > > > > > So the question is how to deal with it. > > > > Fix the UAS driver to not do a blocking call from interrupt context? > > It's not in interrupt context. The SCSI layer expects you to queue > the command and return; usg_sg_wait queues the command and waits for it > to finish. UAS can't use that. That's not right. A transfer is queued by calling usb_sg_init(). Then usb_sg_wait() waits for the transfer to complete. However both of these routines do require to be called in process context. The SCSI layer does not make its calls in process context, so that USB SG library can't be used unless you do it from a separate thread or a workqueue. However, keep in mind that not all HCDs need to support UAS. Unless somebody makes a device with UAS and without BOT, we afford to make UAS unavailable on host controllers without SG support -- expecially if those controllers can't go any faster than full speed anyway. Alan Stern -- 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
