linux/drivers/acpi/processor_core.c, branch v6.7

arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper

2023-10-24T14:12:09Z

ACPI, irqchip and the architecture code all inspect the MADT enabled bit for a GICC entry in the MADT. The addition of an 'online capable' bit means all these sites need updating. Move the current checks behind a helper to make future updates easier. Signed-off-by: James Morse Reviewed-by: Jonathan Cameron Reviewed-by: Gavin Shan Signed-off-by: "Russell King (Oracle)" Acked-by: "Rafael J. Wysocki" Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/E1quv5D-00AeNJ-U8@rmk-PC.armlinux.org.uk Signed-off-by: Catalin Marinas

ACPI: processor: LoongArch: Get physical ID from MADT

2023-08-17T16:39:28Z

With ACPI Spec 6.5 chapter 5.2.12.20, each processor in LoongArch systems has a Core Programmable Interrupt Controller in MADT. The value of its type is 0x11 in the spec and defined as enum variable ACPI_MADT_TYPE_CORE_PIC in the Linux kernel. Physical IDs can be retrieved from MADT for LoongArch systems during initialization and they can be retrieved from the _MAT output for hotplug CPUs. Add physical CPU ID enumeration for LoongArch systems. Signed-off-by: Bibo Mao [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor_core: RISC-V: Enable mapping processor to the hartid

2023-06-01T15:45:02Z

processor_core needs arch-specific functions to map the ACPI ID to the physical ID. In RISC-V platforms, hartid is the physical id and RINTC structure in MADT provides this mapping. Add arch-specific function to get this mapping from RINTC. Signed-off-by: Sunil V L Acked-by: Rafael J. Wysocki Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20230515054928.2079268-8-sunilvl@ventanamicro.com Signed-off-by: Palmer Dabbelt

ACPI: processor: Remove dead ACPICA debug code

2020-09-25T16:25:51Z

The ACPICA debug code is not used anywhere in processor_core.c and processor_thermal.c, remove it. Signed-off-by: Hanjun Guo [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45Z

Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

xen/ACPI: don't upload Px/Cx data for disabled processors

2018-08-20T18:46:18Z

This is unnecessary and triggers a warning in the hypervisor. Often systems have more processor entries in their ACPI tables than are actually installed/active. The ACPI_STA_DEVICE_PRESENT bit cannot be reliably used, but the ACPI_MADT_ENABLED bit can. In order to not introduce new functions in the main ACPI processor driver code, simply use acpi_get_phys_id(), which does more than we need, but which checks the MADT enabled bit in the process. Any CPU for which we can't determine the APIC ID is unlikely to work properly anyway, so the extra checks done by acpi_get_phys_id() should do no harm. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Acked-by: Rafael J. Wysocki Signed-off-by: Boris Ostrovsky

Revert"x86/acpi: Enable MADT APIs to return disabled apicids"

2017-03-11T13:41:18Z

Revert: 8ad893faf2ea ("x86/acpi: Enable MADT APIs to return disabled apicids") Remove the leftovers of the boot time 'cpuid <-> nodeid' mapping approach. Signed-off-by: Dou Liyang Tested-by: Xiaolong Ye Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: guzheng1@huawei.com Cc: izumi.taku@jp.fujitsu.com Cc: lenb@kernel.org Link: http://lkml.kernel.org/r/1488528147-2279-3-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Thomas Gleixner

Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"

2017-03-11T13:41:18Z

Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting") The mapping of "cpuid <-> nodeid" is established at boot time via ACPI tables to keep associations of workqueues and other node related items consistent across cpu hotplug. But, ACPI tables are unreliable and failures with that boot time mapping have been reported on machines where the ACPI table and the physical information which is retrieved at actual hotplug is inconsistent. Revert the mapping implementation so it can be replaced with a less error prone approach. Signed-off-by: Dou Liyang Tested-by: Xiaolong Ye Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: guzheng1@huawei.com Cc: izumi.taku@jp.fujitsu.com Cc: lenb@kernel.org Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fujitsu.com Signed-off-by: Thomas Gleixner

ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users

2016-12-21T01:36:38Z

This patch removes the users of the deprectated APIs: acpi_get_table_with_size() early_acpi_os_unmap_memory() The following APIs should be used instead of: acpi_get_table() acpi_put_table() The deprecated APIs are invented to be a replacement of acpi_get_table() during the early stage so that the early mapped pointer will not be stored in ACPICA core and thus the late stage acpi_get_table() won't return a wrong pointer. The mapping size is returned just because it is required by early_acpi_os_unmap_memory() to unmap the pointer during early stage. But as the mapping size equals to the acpi_table_header.length (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when such a convenient result is returned, driver code will start to use it instead of accessing acpi_table_header to obtain the length. Thus this patch cleans up the drivers by replacing returned table size with acpi_table_header.length, and should be a no-op. Reported-by: Dan Williams Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

acpi: Fix broken error check in map_processor()

2016-09-23T16:04:56Z

map_processor() checks the cpuid value returned by acpi_map_cpuid() for -1 but acpi_map_cpuid() returns -EINVAL in case of error. As a consequence the error is ignored and the following access into percpu data with that negative cpuid results in a boot crash. This happens always when NR_CPUS/nr_cpu_ids is smaller than the number of processors listed in the ACPI tables. Use a proper error check for id < 0 so the function returns instead of trying to map CPU#(-EINVAL). Reported-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Dou Liyang Cc: Gu Zheng Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Tang Chen Cc: Zhu Guihua Cc: akpm@linux-foundation.org Cc: chen.tang@easystack.cn Cc: cl@linux.com Cc: gongzhaogang@inspur.com Cc: isimatu.yasuaki@jp.fujitsu.com Cc: izumi.taku@jp.fujitsu.com Cc: kamezawa.hiroyu@jp.fujitsu.com Cc: len.brown@intel.com Cc: lenb@kernel.org Cc: linux-acpi@vger.kernel.org Cc: linux-mm@kvack.org Cc: mika.j.penttila@gmail.com Cc: rafael@kernel.org Cc: rjw@rjwysocki.net Cc: tj@kernel.org Cc: yasu.isimatu@gmail.com Fixes: dc6db24d2476 ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting") Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1609231705570.5640@nanos Signed-off-by: Ingo Molnar