Re: recommended use of request_any_context_irq()

[Leo Li]

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