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

[Arnd Bergmann]

On Tue, Feb 16, 2021 at 12:00 PM Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxxxx>
> > Date: Tue, 16 Feb 2021 10:41:11 +0100
> >
> > On Mon, Feb 15, 2021 at 1:17 PM Hector Martin <marcan@xxxxxxxxx> 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