Re: [PATCH V11 00/10] irqchip: Add LoongArch-related irqchip drivers

[Jiaxun Yang <jiaxun.yang@flygoat.com>]

在 2022/5/5 16:58, Marc Zyngier 写道:
>> LoongArch use ACPI, but ACPI tables cannot describe the hierarchy of
>> irqchips, so we initilize the irqchip subsystem in this way (from arch
>> code):
>>
>>    cpu_domain = loongarch_cpu_irq_init();
>>    liointc_domain = liointc_acpi_init(cpu_domain, acpi_liointc);
>>    eiointc_domain = eiointc_acpi_init(cpu_domain, acpi_eiointc);
>>    pch_pic_domain = pch_pic_acpi_init(eiointc_domain, acpi_pchpic);
>>    pch_msi_domain = pch_msi_acpi_init(eiointc_domain, acpi_pchmsi);
> I said no to this in the past, and I'm going to reiterate: this is
> *not* acceptable. This obviously doesn't scale and isn't manageable in
> the long run. Hardcoding the topology and the probing order in the
> kernel code has repeatedly proved to be a disaster, and yet you refuse
> to take any input from past experience. This is pretty worrying.
Just my two cents here.

Those drivers have such a topology just because this was my design to
handle irqchip differences between RS780E and LS7A for MIPS-era Loongson.

TBH, for LoongArch-era Loongson, they should be handled by the same driver,
cuz the topology behind them just looks like GIC PPI SPI and MSI for Arm 
GIC.

PCH PIC and eiointc in combination relays interrupts from peripherals 
just like SPI.
liointc is doing the PPI job. They are not separated modules in 
hardware, they are
interlocked.

The system should be treated as a whole, pretty much like how we see 
Arm's GIC. The
topology will last forever for every ACPI enabled LoongArch PC.

I see no reason they should be described separately. Adding complicities to
ACPI bindings brings no benefit. Changing ACPI binding which is already in
final draft stage can only leave us with chaos.

Disclaimer: I don't have any connections with Loongson currently. I'm 
standing
at contributor's approach to make statement above.

Thanks.
- Jiaxun