On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyng...@arm.com> wrote: > Leo, > > On 21/09/16 22:14, Leo Li wrote: >> Hi Marc and Thomas, >> >> With the introduction of request_any_context_irq() routine, driver can >> deal with interrupt controllers using either threaded irq or normal >> irq. But I don't see many drivers that have been changed to use this >> function to request interrupt. For on-board devices, the driver >> normally don't know which kind of interrupt controller they are >> connected to. Why don't we make the request_any_context_irq() >> mandatory or recommended for all drivers? Is there any drawback for >> changing all the request_irq() to the request_any_context_irq()? > > In 99.99% of the cases, a device is integrated in one particular way, > always. For the 0.01% that is left, we have the above API. And if a > particular device moves from the first category to the second, whoever > designed the system will change the driver to use this API, and that > driver only.
I'm not sure if these are such rare cases. Devices which are not integrated in the SoC and not on a bus with interrupt handling such as PCI/PCIE could easily fall into this category. For example, I2C devices and SPI devices are very likely to be in this category. I did a quick search: git grep -l 'i2c_driver\|spi_driver' drivers/ |xargs grep -l request_irq |wc -l The result is 109. > > 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. Right now, it might take quite some time for a developer unfamiliar with the threaded interrupt to figure out the problem. Regards, Leo
