On Sun, 21 Nov 2021 21:11:15 +0000, John Crispin <john@xxxxxxxxxxx> 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@xxxxxxxxxx -- Without deviation from the norm, progress is not possible.
