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

[Marc Zyngier <maz@kernel.org>]

On Sun, 21 Nov 2021 21:11:15 +0000,
John Crispin <john@phrozen.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.