linux-kernel - Re: [PATCH v6 10/17] ACPI: RISC-V: Implement function to reorder irqchip probe entries

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] [day] [month] [year] [list]

Message-ID: <Zo6S6T3HXW1IY1lP@sunil-laptop>
Date: Wed, 10 Jul 2024 19:25:53 +0530
From: Sunil V L <sunilvl@...tanamicro.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-acpi@...r.kernel.org,
	linux-pci@...r.kernel.org, acpica-devel@...ts.linux.dev,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Anup Patel <anup@...infault.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Samuel Holland <samuel.holland@...ive.com>,
	Robert Moore <robert.moore@...el.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	Andrew Jones <ajones@...tanamicro.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Marc Zyngier <maz@...nel.org>,
	Atish Kumar Patra <atishp@...osinc.com>,
	Haibo1 Xu <haibo1.xu@...el.com>,
	Björn Töpel <bjorn@...nel.org>
Subject: Re: [PATCH v6 10/17] ACPI: RISC-V: Implement function to reorder
 irqchip probe entries

Hi Bjorn,

On Thu, Jun 06, 2024 at 05:07:43PM -0500, Bjorn Helgaas wrote:
> On Sat, Jun 01, 2024 at 08:34:04PM +0530, Sunil V L wrote:
> > ACPI MADT entries for interrupt controllers don't have a way to describe
> > the hierarchy. However, the hierarchy is known to the architecture and
> > on RISC-V platforms, the MADT sub table types are ordered in the
> > incremental order from the root controller which is RINTC. So, add
> > architecture function for RISC-V to reorder the interrupt controller
> > probing as per the hierarchy as below.
> 
> Is this ordering requirement documented anywhere?  I don't see it in
> the RISC-V ECRs to the ACPI r6.5 spec.
> 

Thanks. We have added this clarity in a new mantis request.

> I guess the implication is that you need to process MADT structures in
> order of ascending acpi_madt_type:
> 
>   ACPI_MADT_TYPE_RINTC = 24,
>   ACPI_MADT_TYPE_IMSIC = 25,
>   ACPI_MADT_TYPE_APLIC = 26,
>   ACPI_MADT_TYPE_PLIC = 27,
> 
> regardless of the order they appear in the MADT?  I.e., process all
> the RINTC structures (in order of appearance in MADT), followed by all
> the IMSIC structures, then all the APLIC structures, etc?
> 
Correct!

> > Signed-off-by: Sunil V L <sunilvl@...tanamicro.com>
> > ---
> >  drivers/acpi/riscv/Makefile |  2 +-
> >  drivers/acpi/riscv/irq.c    | 32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 33 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/acpi/riscv/irq.c
> > 
> > diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
> > index 877de00d1b50..a96fdf1e2cb8 100644
> > --- a/drivers/acpi/riscv/Makefile
> > +++ b/drivers/acpi/riscv/Makefile
> > @@ -1,4 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > -obj-y					+= rhct.o init.o
> > +obj-y					+= rhct.o init.o irq.o
> >  obj-$(CONFIG_ACPI_PROCESSOR_IDLE)	+= cpuidle.o
> >  obj-$(CONFIG_ACPI_CPPC_LIB)		+= cppc.o
> > diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> > new file mode 100644
> > index 000000000000..f56e103a501f
> > --- /dev/null
> > +++ b/drivers/acpi/riscv/irq.c
> > @@ -0,0 +1,32 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023-2024, Ventana Micro Systems Inc
> > + *	Author: Sunil V L <sunilvl@...tanamicro.com>
> > + *
> 
> Spurious blank line.
> 
Okay.

> > + */
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/sort.h>
> > +
> > +static int irqchip_cmp_func(const void *in0, const void *in1)
> > +{
> > +	struct acpi_probe_entry *elem0 = (struct acpi_probe_entry *)in0;
> > +	struct acpi_probe_entry *elem1 = (struct acpi_probe_entry *)in1;
> > +
> > +	return (elem0->type > elem1->type) - (elem0->type < elem1->type);
> > +}
> > +
> > +/*
> > + * RISC-V irqchips in MADT of ACPI spec are defined in the same order how
> > + * they should be probed. Since IRQCHIP_ACPI_DECLARE doesn't define any
> > + * order, this arch function will reorder the probe functions as per the
> > + * required order for the architecture.
> 
> But this comment seems to contradict the commit log.  This comment
> says you should process MADT structures in the order they appear in
> the MADT.  But if that were the case, you wouldn't need to sort
> anything.
> 
> Maybe "defined in the order they should be probed" means "in order of
> increasing Interrupt Controller structure type value"?
>
Agree. Let me update.

Thanks!
Sunil