linux-kernel - Re: [PATCH V18 00/13] irqchip: Add LoongArch-related irqchip drivers

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r12dy3hq.wl-maz@kernel.org>
Date:   Fri, 22 Jul 2022 09:07:45 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Huacai Chen <chenhuacai@...nel.org>
Cc:     Jianmin Lv <lvjianmin@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, loongarch@...ts.linux.dev,
        Hanjun Guo <guohanjun@...wei.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [PATCH V18 00/13] irqchip: Add LoongArch-related irqchip drivers

Hi Huacai,

On Fri, 22 Jul 2022 03:25:23 +0100,
Huacai Chen <chenhuacai@...nel.org> wrote:
> 
> Hi, Marc,
> 
> On Wed, Jul 20, 2022 at 7:03 PM Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Wed, 20 Jul 2022 11:51:19 +0100,
> > Jianmin Lv <lvjianmin@...ngson.cn> wrote:
> > >
> > > LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V.
> > > LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit
> > > version (LA32S) and a 64-bit version (LA64). LoongArch use ACPI as its
> > > boot protocol LoongArch-specific interrupt controllers (similar to APIC)
> > > are already added in the ACPI Specification 6.5(which may be published in
> > > early June this year and the board is reviewing the draft).
> > >
> > > Currently, LoongArch based processors (e.g. Loongson-3A5000) can only
> > > work together with LS7A chipsets. The irq chips in LoongArch computers
> > > include CPUINTC (CPU Core Interrupt Controller), LIOINTC (Legacy I/O
> > > Interrupt Controller), EIOINTC (Extended I/O Interrupt Controller), PCH-PIC
> > > (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
> > > in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
> >
> > [...]
> >
> > OK, that's 4 versions in quick succession, so I suggest we stop the
> > bikeshedding and focus on getting this actually merged.
> >
> > I'm going to stick this in a branch and throw it at -next. Any change
> > will need to go on top of it, no rebasing. If anything that breaks
> > cannot be fixed easily, I will drop the branch.
> Thank you very much for this series finally get merged.
> But there is a question that has puzzled me for a long time so I want
> to consult with you: Why exporting fwnode_handle in the driver is
> acceptable but exporting irqdomain is not? In my opinion, exporting
> irqdomain is more simple and direct because it can avoid
> irq_find_matching_fwnode() in the consumer side.

The idea is that creating a mapping is normally driven by the code
that parses firmware tables, be it DT or ACPI. That code normally only
has access to something that eventually derives into a fwnode.
irqdomains should only be a concern for the IRQ stack itself, and not
the firmware interface.

Now, your architecture breaks some of the fundamentals of what we have
tried to do over the past 10 years, which is to separate the FW
interface from the IRQ code, because you can't describe the topology
in the firmware tables and are stuck with some in-code flow.

We have two choices:

- Either we let you break the above separation and start exposing
  irqdomains everywhere outside of the IRQ stack,

- Or we turn your arch code into its own firmware interface, and make
  it drive the IRQ code as DT/ACPI would normally do.

I have decided to go for the latter, because I don't think the
LoongArch model is a good one. I'm convinced that eventually you will
have to redesign a FW interface that allows full topology discovery
(probably similar to IORT, should you stick with the ACPI model), and
that the current code will become a historical artefact.

And I really don't want this legacy in the core code.

	M.

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