Re: [PATCH 1/3] MIPS: Loongson64: Increase NR_IRQS to 320

From: Huacai Chen <chenhc@lemote.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	Fuxin Zhang <zhangfx@lemote.com>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCH 1/3] MIPS: Loongson64: Increase NR_IRQS to 320
Date: Fri, 11 Sep 2020 17:14:40 +0800	[thread overview]
Message-ID: <CAAhV-H5ZF6=xj9=mP5r6FudFjy9N-TjzZaoVhkuevVKE50LE1A@mail.gmail.com> (raw)
In-Reply-To: <88b8ce9eaf6c866d47685d8608fe5a49@kernel.org>

Hi, Marc,

On Fri, Sep 11, 2020 at 5:03 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On 2020-09-11 09:43, Huacai Chen wrote:
> > Hi, Marc,
> >
> > On Fri, Sep 11, 2020 at 3:45 PM Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> On 2020-09-11 04:24, Huacai Chen wrote:
> >> > Hi, Marc,
> >> >
> >> > On Thu, Sep 10, 2020 at 6:10 PM Marc Zyngier <maz@kernel.org> wrote:
> >> >>
> >> >> On 2020-09-09 05:09, Huacai Chen wrote:
> >> >> > Modernized Loongson64 uses a hierarchical organization for interrupt
> >> >> > controllers (INTCs), all INTC nodes (not only leaf nodes) need some IRQ
> >> >> > numbers. This means 280 (i.e., NR_IRQS_LEGACY + NR_MIPS_CPU_IRQS + 256)
> >> >> > is not enough to represent all interrupts, so let's increase NR_IRQS to
> >> >> > 320.
> >> >> >
> >> >> > Cc: stable@vger.kernel.org
> >> >> > Signed-off-by: Huacai Chen <chenhc@lemote.com>
> >> >> > ---
> >> >> >  arch/mips/include/asm/mach-loongson64/irq.h | 2 +-
> >> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> > diff --git a/arch/mips/include/asm/mach-loongson64/irq.h
> >> >> > b/arch/mips/include/asm/mach-loongson64/irq.h
> >> >> > index f5e362f7..0da3017 100644
> >> >> > --- a/arch/mips/include/asm/mach-loongson64/irq.h
> >> >> > +++ b/arch/mips/include/asm/mach-loongson64/irq.h
> >> >> > @@ -7,7 +7,7 @@
> >> >> >  /* cpu core interrupt numbers */
> >> >> >  #define NR_IRQS_LEGACY               16
> >> >> >  #define NR_MIPS_CPU_IRQS     8
> >> >> > -#define NR_IRQS                      (NR_IRQS_LEGACY + NR_MIPS_CPU_IRQS + 256)
> >> >> > +#define NR_IRQS                      320
> >> >> >
> >> >> >  #define MIPS_CPU_IRQ_BASE    NR_IRQS_LEGACY
> >> >>
> >> >> Why are you hardcoding a random value instead of bumping the constant
> >> >> in NR_IRQS?
> >> > Because INTCs can organized in many kinds of hierarchy, we cannot use
> >> > constants to define a accurate value, but 320 is big enough.
> >>
> >> You're not answering my question. You have a parameterized NR_IRQS,
> >> and
> >> you're turning it into an absolute constant. Why? I.e:
> >>
> >> #define NR_IRQS        (NR_IRQS_LEGACY + NR_MIPS_CPU_IRQS + 296)
> >>
> >> And why 320? Why not 512? or 2^15?
> > OK, I know, I will define a NR_MAX_MIDDLE_IRQS and then define NR_IRQS
> > as  (NR_IRQS_LEGACY + NR_MIPS_CPU_IRQS + NR_MAX_MIDDLE_IRQS + 256)
>
> What does MIDDLE_IRQS mean? Please name it to something that actually
> relates to its usage...
INTCs are organized as a tree, MIDDLE_IRQS means those IRQS used by
middle nodes (not leaf nodes and not root node), midde nodes is not
directed by devices, but they consumes irq numbers.

>
> >>
> >> As for a "modernized" setup, the fact that you are not using
> >> SPARSE_IRQ
> >> is pretty backward.
> > I have discussed this with Jiaxun, and he said that there are some
> > difficulties to use SPARSE_IRQ.
>
> It'd be worth considering putting some efforts there...
Yes, but that is another topic.

Huacai
>
>          M.
> --
> Jazz is not dead. It just smells funny...