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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2pOUWqZjuk3PcBSsy9b3qv1D_1LiBH62bmTr7Uusp90A@mail.gmail.com>
Date:   Tue, 16 Feb 2021 12:21:05 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Mark Kettenis <mark.kettenis@...all.nl>
Cc:     Hector Martin <marcan@...can.st>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Marc Zyngier <maz@...nel.org>, Rob Herring <robh@...nel.org>,
        Olof Johansson <olof@...om.net>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Mohamed Mediouni <mohamed.mediouni@...amail.com>,
        Stan Skowronek <stan@...ellium.com>,
        Alexander Graf <graf@...zon.com>,
        Will Deacon <will@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 14/25] dt-bindings: interrupt-controller: Add DT
 bindings for apple-aic

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