Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 09 Jun 2022 13:01:49 +0100
Message-ID: <87a6am3v0y.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc:     Huacai Chen <chenhuacai@loongson.cn>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org, Xuefeng Li <lixuefeng@loongson.cn>,
        Huacai Chen <chenhuacai@gmail.com>,
        Jianmin Lv <lvjianmin@loongson.cn>
Subject: Re: [PATCH V11 00/10] irqchip: Add LoongArch-related irqchip drivers
In-Reply-To: <f9bafd6c-0819-9046-e0dd-11e2dd98da38@flygoat.com>
References: <20220430085344.3127346-1-chenhuacai@loongson.cn>
        <87v8uk6kfa.wl-maz@kernel.org>
        <f9bafd6c-0819-9046-e0dd-11e2dd98da38@flygoat.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

+ Jianmin Lv

On Fri, 20 May 2022 16:04:28 +0100,
Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>=20
>=20
>=20
> =E5=9C=A8 2022/5/5 16:58, Marc Zyngier =E5=86=99=E9=81=93:
> >> LoongArch use ACPI, but ACPI tables cannot describe the hierarchy of
> >> irqchips, so we initilize the irqchip subsystem in this way (from arch
> >> code):
> >>=20
> >>    cpu_domain =3D loongarch_cpu_irq_init();
> >>    liointc_domain =3D liointc_acpi_init(cpu_domain, acpi_liointc);
> >>    eiointc_domain =3D eiointc_acpi_init(cpu_domain, acpi_eiointc);
> >>    pch_pic_domain =3D pch_pic_acpi_init(eiointc_domain, acpi_pchpic);
> >>    pch_msi_domain =3D 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.
>=20
> Those drivers have such a topology just because this was my design to
> handle irqchip differences between RS780E and LS7A for MIPS-era Loongson.
>=20
> TBH, for LoongArch-era Loongson, they should be handled by the same drive=
r,
> cuz the topology behind them just looks like GIC PPI SPI and MSI for
> Arm GIC.
>=20
> 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.

That was my impression too, but I keep getting pushback on that. I
wouldn't mind leaving the existing drivers for MIPS only and get new
ones for Loongson if that made things clearer.

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

OK. So how do we move forward? You seem to have a good grasp on how
this should be structured, so can you work with Jianmin Lv to make
some progress on this?

Thanks,

	M.

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