Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map

[Marc Zyngier <maz@kernel.org>]

On Wed, 24 Nov 2021 07:54:48 +0000,
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> Hi Marc,
> 
> On Tue, Nov 23, 2021 at 10:11 AM Marc Zyngier <maz@kernel.org> wrote:
> > On Tue, 23 Nov 2021 08:44:19 +0000,
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Nov 23, 2021 at 9:33 AM Marc Zyngier <maz@kernel.org> wrote:
> > > > On Tue, 23 Nov 2021 07:57:48 +0000,
> > > > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > Summarized:
> > > > >   - Before the bad commit, and after your fix, irqc-rza1 is invoked,
> > > > >     and the number of interrupts seen is correct, but input events
> > > > >     are doubled.
> > > > >   - After the bad commit, irqc-rza1 is not invoked, and there is an
> > > > >     interrupt storm, but input events are OK.
> > > >
> > > > OK, that's reassuring, even if the "twice the events" stuff isn't what
> > > > you'd expect. We at least know this is a separate issue, and that this
> > > > patch on top of -rc1 brings you back to the 5.15 behaviour.
> > > >
> > > > I'd expect it to be the case for the other platforms as well.
> > >
> > > OK.
> > >
> > > BTW, what would have been the correct way to do this for irqc-rza1?
> > > I think we're about to make the same mistake with RZ/G2L IRQC
> > > support[1]?
> >
> > Indeed, and I was about to look into it.
> >
> > There are multiple ways to skin this cat, including renaming
> > 'interrupt-map' to 'my-own-private-interrupt-map'. Or use something
> > akin the new 'msi-range' (which we could call interrupt-range), and
> > replace:
> 
> "interrupt-ranges" (with trailing "S"), cfr. "msi-ranges"?

Yes, absolutely. I keep thinking of it in the singular form, but it
absolutely needs to be plural.

> >   interrupt-map = <0 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> >                   <1 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> >                   <2 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> >                   <3 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> >                   <4 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> >                   <5 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
> >                   <6 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> >                   <7 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> >
> > with:
> >
> >   interrupt-range = <&gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0 8>;
> >
> > which reads as "base interrupt spec", "start pin", "count".  This
> > gives you almost the same level of information, and doesn't interfere
> > with the rest of the DT properties. Parsing it is also much simpler.
> 
> And in the non-consecutive case, you need multiple ranges, right?

That's the idea. The nice part about this is that you can grab each
range with of_parse_phandle_with_args() + two read_u32_index. The bad
part is that you have to know what part of the intspec needs to be
hacked to provide the range, but you already have this built-in in any
hierarchical interrupt controller driver.

> > But that's up to you, really.
> 
> Chris: do you think we can still do this for RZ/A, or do we have too
> many users in the wild using the upstream code?

Honestly, I don't think it is worth it. There are a number of other
irqchips in the same boat, and nobody will ever update them (the fsl
stuff, for example). I'd rather you focus on the new stuff to make it
right.

Thanks,

	M.

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