lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a6am3v0y.wl-maz@kernel.org>
Date:   Thu, 09 Jun 2022 13:01:49 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>
Cc:     Huacai Chen <chenhuacai@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>,
        Huacai Chen <chenhuacai@...il.com>,
        Jianmin Lv <lvjianmin@...ngson.cn>
Subject: Re: [PATCH V11 00/10] irqchip: Add LoongArch-related irqchip drivers

+ Jianmin Lv

On Fri, 20 May 2022 16:04:28 +0100,
Jiaxun Yang <jiaxun.yang@...goat.com> wrote:
> 
> 
> 
> 在 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.

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ