linux-kernel - Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1

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] [day] [month] [year] [list]

Message-ID: <874k847a3w.wl-maz@kernel.org>
Date:   Mon, 22 Nov 2021 10:33:55 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     John Crispin <john@...ozen.org>
Cc:     Sander Vanheule <sander@...nheule.net>,
        Rob Herring <robh+dt@...nel.org>,
        Birger Koblitz <mail@...ger-koblitz.de>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Bert Vermeulen <bert@...t.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Frank Rowand <frowand.list@...il.com>
Subject: Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1

On Sun, 21 Nov 2021 21:11:15 +0000,
John Crispin <john@...ozen.org> wrote:
> 
> 
> 
> On 21.11.21 21:33, Sander Vanheule wrote:
> > Alternatively, a second compatible could perhaps be introduced and the current
> > one would be deprecated, using (2) to prevent breaking 5.16+ kernels. I don't
> > think that's really worth the effort though.
> > 
> > Best,
> 
> Hey,
> 
> I think that what Marc proposed as (1) is the clean solution. We want
> to describe the HW as it exists. Yes we have zero docs, and the RLT
> 2.6 sdk kernel is a pain to extract info from, yet we should move fwd
> with a clean implementation.
> 
> breaking pseudo owrt dts ABI is imho acceptable. owrt users are well
> able to reflash their units from uboot, they are at the end flying
> without wings on bleeding edge. asking for some backward compat for a
> de-facto broken dts mapping of the HW is imho a no-go.

I'm afraid this ship has sailed a long time ago. As I found out, there
are a number of drivers having perpetuated the same horror:

+       "CBEA,platform-spider-pic",
+       "sti,platform-spider-pic",
+       "realtek,rtl-intc",
+       "fsl,ls1021a-extirq",
+       "fsl,ls1043a-extirq",
+       "fsl,ls1088a-extirq",
+       "renesas,rza1-irqc",

We can't just change the bindings for those. For the first two, the DT
is provided by the FW. For the others, there are numerous systems in
the wild, and we can't break them (DT and kernel must be upgradable
independently).

I've posted a quirk patch[1], and I'd appreciate any feedback on
whether it fixes your problem.

Thanks,

	M.

[1] https://lore.kernel.org/r/20211122103032.517923-1-maz@kernel.org

-- 
Without deviation from the norm, progress is not possible.