Hi Marc,

On Monday, 27 December 2021, Marc Zyngier wrote:

On Thu, 23 Dec 2021 19:29:23 +0000,
Sander Vanheule [off-list ref] wrote:

quoted

On Thu, 2021-12-23 at 18:00 +0000, Marc Zyngier wrote:

quoted

On Thu, 23 Dec 2021 12:08:33 +0000,
Sander Vanheule [off-list ref] wrote:

quoted

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.

A driver can always ignore some information from the DT and do its own
thing. No sure if that addresses your problem though.

quoted

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

You can only extend a binding in a two-way fashion: old kernel works
with new DT, new kernel works old DT. Which means that in practice,
you can only *add* information to the DT, and have reasonable defaults
in the driver when you don't find it.

Thanks for clarifying. In that case I don't think it is possible to get rid of the output-to-parent assumption entirely, since the driver would always need to accommodate for the original binding, where there is no output mapping specified in the binding. There are no SoC-specific compatibles (where a mapping could be assumed), and I don't know on how many MIPS platforms Realtek has used this interrupt router/controller.

I don't have much time anymore today, but I'll break my head over it again tomorrow.

Best,
Sander