Hi, On Mon, Jan 09, 2012 at 04:57:05PM +0100, Sebastian Andrzej Siewior wrote: > >>usb_sg_init() provides a workaround for them. So if the HCD supports sg > >>it ends up with one URB. If it does not the function allocates a bunch > >>of URBs and sets urb->transfer_buffer = sg_virt(sg) for each sg entry > >>which should work. It will fail if the hcd supports DMA transfers (no > >>bounce buffer from the scsi host because it can handle high mem) and > >>does not support sg (for the HIGHMEM page the transfer_buffer will be > >>set to NULL). > >>So that could be one problem we have. > >>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? > > All this controllers are 2.0 or less. According to the protocol we > learn in the URB's completion that we have enqueue a new URB. So > blocking here means a context switch into an UAS-thread/workqueue. > This is no good. > So I propose (start of this thread) to change usb_sg_wait() so it does > not wait. that would be better of as a new API, something like usb_sg_submit(). Changing the sematics of usb_sg_wait() might cause a giant amount of regressions with other drivers and we're can't allow that. Specially when we don't have how to test every device the kernel supports ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
