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

[Marc Zyngier <maz@kernel.org>]

On 2020-09-11 10:14, Huacai Chen wrote:
> 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

Tell me something I don't know...

> middle nodes (not leaf nodes and not root node), midde nodes is not
> directed by devices, but they consumes irq numbers.

Then name the #define something that represents its use. "middle" 
doesn't
describe anything. Call it "chained", or "cascade", or something at 
actually
reflects the topology of these systems.

> 
>> 
>> >>
>> >> 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.

It really is the same topic. You keep bumping this NR_IRQS up in 
arbitrary ways,
which would be avoided if you brought MIPS into the 21st century.

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