Re: [PATCH v2 14/25] dt-bindings: interrupt-controller: Add DT bindings for apple-aic

Arnd Bergmann
2021-02-16T11:22:56Z

On Tue, Feb 16, 2021 at 12:00 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: Arnd Bergmann <arnd@kernel.org>
> > Date: Tue, 16 Feb 2021 10:41:11 +0100
> >
> > On Mon, Feb 15, 2021 at 1:17 PM Hector Martin <marcan@marcan.st> wrote:
> > > +
> > > + The 2nd cell contains the interrupt number.
> > > + - HW IRQs: interrupt number
> > > + - FIQs:
> > > + - 0: physical HV timer
> > > + - 1: virtual HV timer
> > > + - 2: physical guest timer
> > > + - 3: virtual guest timer
> >
> > I wonder if you could just model the FIQ as a single shared level interrupt
> > (which is essentially what it is), and have every driver that uses it do a
> > request_irq() on the same IRQ number.
> >
> > This would avoid having to come up with a fake binding for it, and simplify
> > the implementation that then no longer has to peek into each interrupt
> > source.
>
> That would tie the binding more closely to the implementation as it
> would remove the option of peeking at the interrupt source.

I don't think having the binding match the implementation is a bad thing ;-)

If a future SoC variant handles it differently, it will need a binding update
anyway.

> And wouldn't it mean that the arch_timer driver would need to know whether
> the interrupt is shared or not?

Indeed, it does require each driver to pass IRQF_SHARED, and be
prepared to be called when no irq is pending (returning IRQ_NONE
otherwise), so a downside would be that this requires changing the
bindings for the timer and anything else that ends up using FIQ
later. It may be possible to just always pass IRQF_SHARED when
registering the arch timer handler, not sure if there are any downsides
in case for the normal (non-shared) case.

This is a drawback, but I still find it a little cleaner than having to
encode information about the individual irq sources into the irqchip
driver.

Arnd