On Mon, Jan 09, 2012 at 11:10:46AM -0500, Alan Stern wrote: > 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. MUSB can go up to highspeed and it won't support SGs easily. At least not with the internal Inventra DMA Engine. -- balbi
Attachment:
signature.asc
Description: Digital signature
