linux-kernel - Re: [RFC PATCH v1 3/4] dt-bindings: interrupt-controller: realtek,rtl-intc: replace irq mapping

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]

Date:   Thu, 23 Dec 2021 20:29:23 +0100
From:   Sander Vanheule <sander@...nheule.net>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>, devicetree@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Birger Koblitz <mail@...ger-koblitz.de>,
        Bert Vermeulen <bert@...t.com>,
        John Crispin <john@...ozen.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 3/4] dt-bindings: interrupt-controller:
 realtek,rtl-intc: replace irq mapping

On Thu, 2021-12-23 at 18:00 +0000, Marc Zyngier wrote:
> On Thu, 23 Dec 2021 12:08:33 +0000,
> Sander Vanheule <sander@...nheule.net> wrote:
> > 
> > The binding incorrectly specified the "interrupt-map" property should be
> > used, although the use is non-standard. A quirk had to be introduced in
> > commit de4adddcbcc2 ("of/irq: Add a quirk for controllers with their own
> > definition of interrupt-map") to allow the driver to function again.
> 
> That's too late. We have released a kernel with this binding, and it
> will live on forever until we totally remove the platform from the
> tree.
> 
> DT is an ABI, and only time travel can fix this blunder.

Taking into account your comments on the previous patch, this change wouldn't even be
required if I correct the mappings for my devices. But that wouldn't get rid of the
assumed mapping between output lines and parent interrupts.

To what extent can the binding be updated to get rid of this assumption? Or would that
require a completely new binding?


Best,
Sander