On Thu, Sep 22, 2016 at 3:47 PM, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 22 Sep 2016, Leo Li wrote: >> On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyng...@arm.com> wrote: >> > There is strictly no reason to perform a blanket change of all the >> > drivers. What would be the reason to change them other than to cater for >> > a contrived use case that may never happen? >> >> Maybe we could do blanket change to drivers that meet certain >> criteria? At least we should improve the messaging when a driver >> cannot request interrupt due to nested threading. > > Nested threading is a result of requesting an any context interrupt not > something which is there already. > >> Right now, it might take quite some time for a developer unfamiliar with >> the threaded interrupt to figure out the problem. > > Did you have issues with a driver which was not able to request an > interrupt? If yes, please explain in detail what the failure was and why > you think that this should be changed. If not, please explain which problem > you are trying to solve.
My problem was with sc16is7xx, an SPI-to-UART device(drivers/tty/serial/sc16is7xx.c), the interrupt of it is connected together with interrupts from other on-board devices to a GPIO expander (drivers/gpio/gpio-pca953x.c). The interrupt handler of pca953x interrupt controller is threaded, but the sc16is7xx driver is currently requesting plain interrupt. So the sc16is7xx just fails when requesting irq. The problem can be fixed by changing the sc16is7xx driver to use the request_any_context_irq(). But it is not easy to see this is because of requesting plain interrupt on a threaded interrupt controller without some debugging effort into the core code. And my concerns is that there are other drivers can hit the same problem if connected to the threaded interrupt controller. What can we do prevent similar problem in the future? Regards, Leo
