On Thu, 15 Nov 2012, Thomas Gleixner wrote: > > I see. The USB code does do a reasonably large amount of work in > > interrupt context. It doesn't have to be that way; it could be in > > process context -- but the design of the USB subsystem requires that > > much of the work be carried out with interrupts disabled. (The API > > states that all the driver callbacks occur with disabled interrupts.) > > Well, the reason why the API says that is because you are doing lots > of work in interrupt context and you probably not only disable > interrupts for that, you also hold the proper locks to protect against > the eventually incoming interrupt on the other cpu.
Certainly. > So sure, this needs some thought whether it's worth the trouble, but > last I looked a few years ago (when I just had a stab on it), it > definitely looked worthwhile to simplify a lot of things by simply > serializing them naturaly. Don't misunderstand me. You still will need > locks :) Right, because we can't accept requests while the handler thread is modifying the driver's internal state. Those requests could be submitted by timer routines in other drivers, which means the handler thread would have to do almost all of its work inside a spin_lock_irq region. That private spinlock already serializes most of what the driver does. I don't see how using a threaded interrupt handler would give any significant improvement in this respect. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
