On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
> 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.