kernel/linux.git/drivers/acpi/processor_pdc.c, branch v7.0-rc7

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

ACPI: processor: Fix uninitialized access of buf in acpi_set_pdc_bits()

2023-09-18T10:16:16+00:00

A bug was introduced during unification of setting CAP_SMP_T_SWCOORD for the _PDC and _OSC methods. The third u32 in the buffer is never cleared before setting bits on it. The memory is not guaranteed to be zero as it was allocated by kmalloc() instead of kzalloc(). Fix this by initializing the third u32 in the buffer to 0. Fixes: b9e8d0168a7a ("ACPI: processor: Set CAP_SMP_T_SWCOORD in arch_acpi_set_proc_cap_bits()") Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Set CAP_SMP_T_SWCOORD in arch_acpi_set_proc_cap_bits()

2023-07-14T15:59:40+00:00

Currently, ACPI_PROC_CAP_SMP_T_SWCOORD is set in acpi_set_pdc_bits(), but it is not _PDC-specific. It should be set along with the other processor capability bits. Move the setting of ACPI_PROC_CAP_SMP_T_SWCOORD to arch_acpi_set_proc_cap_bits(). Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Clear C_C2C3_FFH and C_C1_FFH in arch_acpi_set_proc_cap_bits()

2023-07-14T15:59:40+00:00

Currently arch_acpi_set_proc_cap_bits() clears ACPI_PDC_C_C2C3_FFH bit in case MWAIT instruction is not supported. It should also clear ACPI_PDC_C_C1_FFH, as when MWAIT is not supported, C1 is entered by executing the HLT instruction. Quote from the C_C1_FFH description: "If set, OSPM is capable of performing native C State instructions (beyond halt) for the C1 handler in multi-processor configurations". As without MWAIT there is no native C-state instructions beyond HALT, this bit should be toggled off." Clear ACPI_PDC_C_C1_FFH and ACPI_PDC_C_C2C3_FFH in arch_acpi_set_proc_cap_bits() in case MWAIT is not supported or overridden. Remove setting those bits from the processor_pdc.c code. Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Rename ACPI_PDC symbols

2023-07-14T15:59:40+00:00

The prefix in the names of the ACPI_PDC symbols suggests that they are only relevant for _PDC, but in fact they can also be used in the _OSC. Change that prefix to a more generic ACPI_PROC_CAP that will better reflect the purpose of those symbols as they represent bits in a general processor capabilities buffer. Rename pdc_intel.h to proc_cap_intel.h to follow the change of the symbol name prefix. No intentional functional impact. Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Refactor arch_acpi_set_pdc_bits()

2023-07-14T15:59:40+00:00

The capabilities buffer modified by the arch_acpi_set_pdc_bits() is not _PDC-specific, as it can be used by _OSC too. Change the name of that function to better reflect its independence from _PDC and make it take the capabilities buffer address as the argument directly, without any offset, as _OSC and _PDC use different capabilities buffer offsets. No intentional functional impact. Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski Reviewed-by: Andy Shevchenko [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Move processor_physically_present() to acpi_processor.c

2023-07-14T15:59:40+00:00

Since _PDC method is deprecated and a preferred method of communicating OSPM processor power management capabilities is _OSC, there is a need to move function checking whether processor is present as this logic is not _PDC specific. Move processor_physically_present() to acpi_processor.c. No intentional functional impact. Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Move MWAIT quirk out of acpi_processor.c

2023-07-14T15:59:40+00:00

Commit 2a2a64714d9c ("ACPI: Disable MWAIT via DMI on broken Compal board") introduced a workaround for MWAIT for a specific x86 system. Move the code outside of acpi_processor.c to acpi/x86/ directory for consistency and rename the functions associated with it, so their names start with "acpi_proc_quirk_" to make the goal obvious. No intentional functional impact. Suggested-by: Rafael J. Wysocki Signed-off-by: Michal Wilczynski [ rjw: Subject and changelog edits, two function names changed ] Signed-off-by: Rafael J. Wysocki

ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

2023-03-22T18:36:31+00:00

In ACPI systems, the OS can direct power management, as opposed to the firmware. This OS-directed Power Management is called OSPM. Part of telling the firmware that the OS going to direct power management is making ACPI "_PDC" (Processor Driver Capabilities) calls. These _PDC methods must be evaluated for every processor object. If these _PDC calls are not completed for every processor it can lead to inconsistency and later failures in things like the CPU frequency driver. In a Xen system, the dom0 kernel is responsible for system-wide power management. The dom0 kernel is in charge of OSPM. However, the number of CPUs available to dom0 can be different than the number of CPUs physically present on the system. This leads to a problem: the dom0 kernel needs to evaluate _PDC for all the processors, but it can't always see them. In dom0 kernels, ignore the existing ACPI method for determining if a processor is physically present because it might not be accurate. Instead, ask the hypervisor for this information. Fix this by introducing a custom function to use when running as Xen dom0 in order to check whether a processor object matches a CPU that's online. Such checking is done using the existing information fetched by the Xen pCPU subsystem, extending it to also store the ACPI ID. This ensures that _PDC method gets evaluated for all physically online CPUs, regardless of the number of CPUs made available to dom0. Fixes: 5d554a7bb064 ("ACPI: processor: add internal processor_physically_present()") Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Rafael J. Wysocki