From: Andrew Jones <ajones@ventanamicro.com>
To: Sunil V L <sunilvl@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
Anup Patel <apatel@ventanamicro.com>,
Atish Patra <atishp@rivosinc.com>,
'Conor Dooley ' <conor.dooley@microchip.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH V3 11/20] RISC-V: ACPI: Cache and retrieve the RINTC structure
Date: Fri, 3 Mar 2023 19:04:52 +0100 [thread overview]
Message-ID: <20230303180452.qzzjdwpgvqqxdqz5@orel> (raw)
In-Reply-To: <ZAI1PbEfo1Gyco1n@sunil-laptop>
On Fri, Mar 03, 2023 at 11:28:21PM +0530, Sunil V L wrote:
> On Fri, Mar 03, 2023 at 05:05:56PM +0100, Andrew Jones wrote:
> > On Fri, Mar 03, 2023 at 07:06:38PM +0530, Sunil V L wrote:
> > > RINTC structures in the MADT provide mapping between the hartid
> > > and the CPU. This is required many times even at run time like
> > > cpuinfo. So, instead of parsing the ACPI table every time, cache
> > > the RINTC structures and provide a function to get the correct
> > > RINTC structure for a given cpu.
> > >
> > > Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
> > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > ---
> > > arch/riscv/include/asm/acpi.h | 9 ++++++
> > > arch/riscv/kernel/acpi.c | 56 +++++++++++++++++++++++++++++++++++
> > > 2 files changed, 65 insertions(+)
> > >
> > > diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h
> > > index 111a8ed10af1..8be16c1ef7da 100644
> > > --- a/arch/riscv/include/asm/acpi.h
> > > +++ b/arch/riscv/include/asm/acpi.h
> > > @@ -61,6 +61,10 @@ static inline void arch_fix_phys_package_id(int num, u32 slot) { }
> > >
> > > int acpi_get_riscv_isa(struct acpi_table_header *table,
> > > unsigned int cpu, const char **isa);
> > > +
> > > +struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu);
> > > +
> > > +u32 get_acpi_id_for_cpu(int cpu);
> > > #else
> > > static inline int acpi_get_riscv_isa(struct acpi_table_header *table,
> > > unsigned int cpu, const char **isa)
> > > @@ -68,6 +72,11 @@ static inline int acpi_get_riscv_isa(struct acpi_table_header *table,
> > > return -EINVAL;
> > > }
> > >
> > > +static inline u32 get_acpi_id_for_cpu(int cpu)
> > > +{
> > > + return -1;
> > > +}
> >
> > Why do we need this stub? I wouldn't expect non-ACPI code to need an ACPI
> > ID.
> >
> > > +
> > > #endif /* CONFIG_ACPI */
> > >
> > > #endif /*_ASM_ACPI_H*/
> > > diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c
> > > index 81d448c41714..8b3d68d8225f 100644
> > > --- a/arch/riscv/kernel/acpi.c
> > > +++ b/arch/riscv/kernel/acpi.c
> > > @@ -24,6 +24,62 @@ EXPORT_SYMBOL(acpi_disabled);
> > > int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
> > > EXPORT_SYMBOL(acpi_pci_disabled);
> > >
> > > +static struct acpi_madt_rintc cpu_madt_rintc[NR_CPUS];
> > > +
> > > +static int acpi_parse_madt_rintc(union acpi_subtable_headers *header, const unsigned long end)
> > > +{
> > > + struct acpi_madt_rintc *rintc = (struct acpi_madt_rintc *)header;
> > > + int cpuid;
> > > +
> > > + if (!(rintc->flags & ACPI_MADT_ENABLED))
> > > + return 0;
> >
> > Why not cache the data even when its disabled? We also cache the flags so
> > we can always check later too.
> >
> Okay, doesn't harm.
>
> > > +
> > > + cpuid = riscv_hartid_to_cpuid(rintc->hart_id);
> > > + if (cpuid >= 0 && cpuid < NR_CPUS)
> >
> > What does it mean for the above check to fail? Bad ACPI tables?
> >
> This can happen when SMP is disabled but platform has more CPUs.
Ah yes, NR_CPUS can be too small for the platform. Maybe a comment
explaining that we ignore all additional cpus in the ACPI tables that
we can't manage with the kernel's limits would be helpful here.
Thanks,
drew
next prev parent reply other threads:[~2023-03-03 18:04 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 13:36 [PATCH V3 00/20] Add basic ACPI support for RISC-V Sunil V L
2023-03-03 13:36 ` [PATCH V3 01/20] riscv: move sbi_init() earlier before jump_label_init() Sunil V L
2023-03-03 13:36 ` [PATCH V3 02/20] ACPICA: MADT: Add RISC-V INTC interrupt controller Sunil V L
2023-03-03 13:36 ` [PATCH V3 03/20] ACPICA: Add structure definitions for RISC-V RHCT Sunil V L
2023-03-03 13:36 ` [PATCH V3 04/20] ACPI: tables: Print RINTC information when MADT is parsed Sunil V L
2023-03-03 14:58 ` Andrew Jones
2023-03-03 13:36 ` [PATCH V3 05/20] ACPI: OSL: Make should_use_kmap() 0 for RISC-V Sunil V L
2023-03-03 13:36 ` [PATCH V3 06/20] RISC-V: Add support to build the ACPI core Sunil V L
2023-03-03 15:36 ` Andrew Jones
2023-03-04 14:38 ` Andrew Jones
2023-03-06 20:00 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 07/20] ACPI: processor_core: RISC-V: Enable mapping processor to the hartid Sunil V L
2023-03-03 13:36 ` [PATCH V3 08/20] drivers/acpi: RISC-V: Add RHCT related code Sunil V L
2023-03-03 13:36 ` [PATCH V3 09/20] RISC-V: smpboot: Create wrapper smp_setup() Sunil V L
2023-03-03 13:36 ` [PATCH V3 10/20] RISC-V: smpboot: Add ACPI support in smp_setup() Sunil V L
2023-03-03 15:49 ` Andrew Jones
2023-03-03 17:54 ` Sunil V L
2023-03-03 13:36 ` [PATCH V3 11/20] RISC-V: ACPI: Cache and retrieve the RINTC structure Sunil V L
2023-03-03 16:05 ` Andrew Jones
2023-03-03 16:58 ` Conor Dooley
2023-03-03 17:21 ` Andrew Jones
2023-03-03 17:49 ` Sunil V L
2023-03-03 17:58 ` Sunil V L
2023-03-03 18:04 ` Andrew Jones [this message]
2023-03-03 18:17 ` Sunil V L
2023-03-03 13:36 ` [PATCH V3 12/20] RISC-V: cpufeature: Add ACPI support in riscv_fill_hwcap() Sunil V L
2023-03-03 16:16 ` Andrew Jones
2023-03-03 17:55 ` Sunil V L
2023-03-06 20:26 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 13/20] RISC-V: cpu: Enable cpuinfo for ACPI systems Sunil V L
2023-03-03 16:18 ` Andrew Jones
2023-03-06 20:39 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 14/20] irqchip/riscv-intc: Add ACPI support Sunil V L
2023-03-06 20:53 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 15/20] clocksource/timer-riscv: Refactor riscv_timer_init_dt() Sunil V L
2023-03-06 21:01 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 16/20] clocksource/timer-riscv: Add ACPI support Sunil V L
2023-03-06 21:06 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 17/20] RISC-V: time.c: Add ACPI support for time_init() Sunil V L
2023-03-06 21:09 ` Conor Dooley
2023-03-08 9:43 ` Sunil V L
2023-03-03 13:36 ` [PATCH V3 18/20] RISC-V: Add ACPI initialization in setup_arch() Sunil V L
2023-03-06 21:17 ` Conor Dooley
2023-03-08 9:42 ` Sunil V L
2023-03-08 10:21 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 19/20] RISC-V: Enable ACPI in defconfig Sunil V L
2023-03-03 16:23 ` Andrew Jones
2023-03-06 21:18 ` Conor Dooley
2023-03-03 13:36 ` [PATCH V3 20/20] MAINTAINERS: Add entry for drivers/acpi/riscv Sunil V L
2023-03-06 21:51 ` [PATCH V3 00/20] Add basic ACPI support for RISC-V Conor Dooley
2023-03-07 5:06 ` Sunil V L
2023-03-07 6:13 ` Conor Dooley
2023-03-07 18:44 ` Conor Dooley
2023-03-08 1:01 ` Sunil V L
2023-04-04 6:35 ` Ley Foon Tan
2023-04-04 6:54 ` Sunil V L
2023-04-06 2:45 ` Atish Kumar Patra
2023-04-19 8:07 ` Ley Foon Tan
2023-04-19 23:34 ` Atish Patra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230303180452.qzzjdwpgvqqxdqz5@orel \
--to=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=daniel.lezcano@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=palmer@dabbelt.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=sunilvl@ventanamicro.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).