On Mon, Nov 13, 2023 at 10:29:39AM +1000, Gavin Shan wrote:
> On 11/7/23 20:29, Russell King (Oracle) wrote:
> > From: James Morse <james.morse@xxxxxxx>
> >
> > Neither arm64 nor riscv support physical hotadd of CPUs that were not
> > present at boot. For arm64 much of the platform description is in static
> > tables which do not have update methods. arm64 does support HOTPLUG_CPU,
> > which is backed by a firmware interface to turn CPUs on and off.
> >
> > acpi_processor_hotadd_init() and acpi_processor_remove() are for adding
> > and removing CPUs that were not present at boot. arm64 systems that do this
> > are not supported as there is currently insufficient information in the
> > platform description. (e.g. did the GICR get removed too?)
> >
> > arm64 currently relies on the MADT enabled flag check in map_gicc_mpidr()
> > to prevent CPUs that were not described as present at boot from being
> > added to the system. Similarly, riscv relies on the same check in
> > map_rintc_hartid(). Both architectures also rely on the weak 'always fails'
> > definitions of acpi_map_cpu() and arch_register_cpu().
> >
> > Subsequent changes will redefine ACPI_HOTPLUG_CPU as making possible
> > CPUs present. Neither arm64 nor riscv support this.
> >
> > Disable ACPI_HOTPLUG_CPU for arm64 and riscv by removing 'default y' and
> > selecting it on the other three ACPI architectures. This allows the weak
> > definitions of some symbols to be removed.
> >
> > Signed-off-by: James Morse <james.morse@xxxxxxx>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@xxxxxxxxxxxxxxx>
> > ---
> > Changes since RFC:
> > * Expanded conditions to avoid ACPI_HOTPLUG_CPU being enabled when
> > HOTPLUG_CPU isn't.
> > Changes since RFC v3:
> > * Dropped ia64 changes
> > ---
> > arch/loongarch/Kconfig | 1 +
> > arch/x86/Kconfig | 1 +
> > drivers/acpi/Kconfig | 1 -
> > drivers/acpi/acpi_processor.c | 18 ------------------
> > 4 files changed, 2 insertions(+), 19 deletions(-)
> >
>
> With the following nits addressed:
>
> Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
>
> > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> > index d889a0b97bc1..64620e90c12c 100644
> > --- a/arch/loongarch/Kconfig
> > +++ b/arch/loongarch/Kconfig
> > @@ -5,6 +5,7 @@ config LOONGARCH
> > select ACPI
> > select ACPI_GENERIC_GSI if ACPI
> > select ACPI_MCFG if ACPI
> > + select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
> > select ACPI_PPTT if ACPI
> > select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
> > select ARCH_BINFMT_ELF_STATE
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 3762f41bb092..dbdcfc708369 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -59,6 +59,7 @@ config X86
> > #
> > select ACPI_LEGACY_TABLES_LOOKUP if ACPI
> > select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
> > + select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
> > select ARCH_32BIT_OFF_T if X86_32
> > select ARCH_CLOCKSOURCE_INIT
> > select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index f819e760ff19..a3acfc750fce 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -310,7 +310,6 @@ config ACPI_HOTPLUG_CPU
> > bool
> > depends on ACPI_PROCESSOR && HOTPLUG_CPU
> > select ACPI_CONTAINER
> > - default y
> > config ACPI_PROCESSOR_AGGREGATOR
> > tristate "Processor Aggregator"
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 0f5218e361df..4fe2ef54088c 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -184,24 +184,6 @@ static void __init acpi_pcc_cpufreq_init(void) {}
> > /* Initialization */
> > #ifdef CONFIG_ACPI_HOTPLUG_CPU
> > -int __weak acpi_map_cpu(acpi_handle handle,
> > - phys_cpuid_t physid, u32 acpi_id, int *pcpu)
> > -{
> > - return -ENODEV;
> > -}
> > -
> > -int __weak acpi_unmap_cpu(int cpu)
> > -{
> > - return -ENODEV;
> > -}
> > -
> > -int __weak arch_register_cpu(int cpu)
> > -{
> > - return -ENODEV;
> > -}
> > -
> > -void __weak arch_unregister_cpu(int cpu) {}
> > -
>
> Since we're here, EXPORT_SYMBOL() can be dropped for these functions on
> x86 and loongarch because they're not called from a module?
I'm confused, and don't understand your comment. You've r-b the
previous two patches that remove the EXPORT_SYMBOL()s for
arch_register_cpu() and arch_unregister_cpu() from x86 and loongarch.
So it seems your comment is already addressed, and thus makes no
sense.
Please clarify.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
|