On Mon, 9 Jan 2012, Sebastian Andrzej Siewior wrote: > > Ok, and why would you want to run a UAS device on anything other than > > those controllers? > > There is nothing wrong with adding UAS to a device which can do only > USB2.0. On the hand you could attach your USB3.0 UAS device to the ohci > controller because you have an old computer _or_ some other device > which has only musb for instance. But there's very little advantage to using UAS in those circumstances; it will be only slightly faster than BOT. Nobody is going to stop supporting BOT any time soon -- not until UAS support is added to all the old versions of Windows floating around! (Besides, we might as well add SG support to ohci-hcd. Doing so will be fairly easy, and it's already present in uhci-hcd; you must have missed 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. You would also have to allocate a bunch of URBs using GFP_ATOMIC, which is not desirable. 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
