linux.git/drivers/acpi, branch master

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2026-05-01T23:32:42+00:00

Pull arm64 fixes from Catalin Marinas:

 - Avoid writing an uninitialised stack variable to POR_EL0 on sigreturn
   if the poe_context record is absent

 - Reserve one more page for the early 4K-page kernel mapping to cover
   the extra [_text, _stext) split introduced by the non-executable
   read-only mapping

 - Force the arch_local_irq_*() wrappers to be __always_inline so that
   noinstr entry and idle paths cannot call out-of-line, instrumentable
   copies

 - Fix potential sign extension in the arm64 SCS unwinder's DWARF
   advance_loc4 decoding

 - Tolerate arm64 ACPI platforms with only WFI and no deeper PSCI idle
   states, restoring cpuidle registration on such systems

 - Include the UAPI  header in the arm64 GCS libc test
   rather than carrying a duplicate struct user_gcs definition (the
   original #ifdef NT_ARM_GCS was wrong to cover the structure
   definition as it would be masked out if the toolchain defined it)

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: signal: Preserve POR_EL0 if poe_context is missing
  arm64: Reserve an extra page for early kernel mapping
  kselftest/arm64: Include  for user_gcs definition
  ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
  arm64/irqflags: __always_inline the arch_local_irq_*() helpers
  arm64/scs: Fix potential sign extension issue of advance_loc4

Merge branches 'acpi-apei', 'acpi-bus', 'acpi-cppc' and 'acpi-video'

2026-04-30T19:07:06+00:00

Merge assorted ACPI support fixes for 7.1-rc2:

 - Fix EINJV2 memory error injection in APEI (Tony Luck)

 - Add missing notifier_block structure forward declaration to
   acpi_bus.h (Bartosz Golaszewski)

 - Fix related_cpus inconsistency during CPU hotplug in the ACPI CPPC
   library (Jinjie Ruan)

 - Add a quirk to force native backlight on HP OMEN 16 (8A44) in the
   ACPI video bus driver (Shivam Kalra)

* acpi-apei:
  ACPI: APEI: EINJ: Fix EINJV2 memory error injection
  ACPICA: Provide #defines for EINJV2 error types

* acpi-bus:
  ACPI: bus: add missing forward declaration to acpi_bus.h

* acpi-cppc:
  ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug

* acpi-video:
  ACPI: video: force native backlight on HP OMEN 16 (8A44)

ACPI: video: force native backlight on HP OMEN 16 (8A44)

2026-04-27T20:00:00+00:00

The HP OMEN 16 Gaming Laptop (board name 8A44) has a mux-less hybrid
GPU configuration with AMD Rembrandt (Radeon 680M) and NVIDIA GA104
(RTX 3070 Ti). The internal eDP panel is wired to the AMD iGPU.

When Nouveau loads without GSP firmware, the ACPI video backlight
device (acpi_video0) gets registered alongside the native AMD
backlight (amdgpu_bl2). In this state, writes to amdgpu_bl2 update
the software brightness value but fail to change the physical panel
brightness.

Force native backlight to prevent acpi_video0 from registering.
Confirmed that booting with acpi_backlight=native resolves the
issue.

Cc: All applicable 
Signed-off-by: Shivam Kalra 
Link: https://patch.msgid.link/20260426-omen-16-backlight-fix-v1-1-62364f268ea6@zohomail.in
Signed-off-by: Rafael J. Wysocki

ACPI: TAD: Fix up a comment in acpi_tad_probe()

2026-04-27T19:57:09+00:00

Fix grammar in the comment preceding the pm_runtime_set_active() call in
acpi_tad_probe().

Signed-off-by: Rafael J. Wysocki 
Link: https://patch.msgid.link/8678306.T7Z3S40VBb@rafael.j.wysocki

ACPI: TAD: RTC: Refine timer value computations and checks

2026-04-27T19:57:09+00:00

Since rtc_tm_to_ktime() may overflow for large RTC time values and
full second granularity is sufficient in timer value computations
in acpi_tad_rtc_set_alarm() and acpi_tad_rtc_read_alarm(), use
rtc_tm_to_time64() instead of that function, which also allows the
computations to be simplified.

Moreover, U32_MAX is a special "timer disabled" value, so make
acpi_tad_rtc_set_alarm() reject it when attempting to program the
alarm timers.

Fixes: 7572dcabe38d ("ACPI: TAD: Add alarm support to the RTC class device interface")
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Alexandre Belloni 
Link: https://patch.msgid.link/3414608.aeNJFYEL58@rafael.j.wysocki

ACPI: TAD: Use devres for all driver cleanup

2026-04-27T19:57:09+00:00

The code in acpi_tad_remove() needs to run after the unregistration of
the devres-managed RTC class device so that it doesn't race with the
class callbacks of the latter.

To make that happen, pass it to devm_add_action_or_reset() before
registering the RTC class device.

Fixes: 7572dcabe38d ("ACPI: TAD: Add alarm support to the RTC class device interface")
Fixes: 8a1e7f4b1764 ("ACPI: TAD: Add RTC class device interface")
Signed-off-by: Rafael J. Wysocki 
Link: https://patch.msgid.link/14001754.uLZWGnKmhe@rafael.j.wysocki

ACPI: TAD: Use __ATTRIBUTE_GROUPS() macro

2026-04-27T19:56:44+00:00

Recent commit 93afe8ba9b01 ("ACPI: TAD: Use dev_groups in struct
device_driver") switched over the ACPI TAD driver to using device
attribute groups instead of creating and removing the device sysfs
attributes directly, but it might go one step farther and use the
__ATTRIBUTE_GROUPS() macro which would reduce the code size slightly.

Do it now.

Signed-off-by: Rafael J. Wysocki 
[ rjw: Fixed typo in the changelog ]
Link: https://patch.msgid.link/1961102.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug

2026-04-27T19:50:26+00:00

When concurrently bringing up and down two SMT threads of a physical
core, many warning call traces occur as below:

The issue timeline is as follows:

 1. When the system starts,
    cpufreq: CPU: 220, policy->related_cpus: 220-221, policy->cpus: 220-221

 2. Offline CPU 220 and CPU 221.

 3. Online CPU 220
    - CPU 221 is now offline, as acpi_get_psd_map() use
      for_each_online_cpu(), so the cpu_data->shared_cpu_map,
      policy->cpus, and related_cpus has only CPU 220.

    cpufreq: CPU: 220, policy->related_cpus: 220, policy->cpus: 220

 4. Offline CPU 220

 5. Online CPU 221, the below call trace occurs:
    - Since CPU 220 and CPU 221 share one policy, and
      policy->related_cpus = 220 after step 3, so CPU 221
      is not in policy->related_cpus but
      per_cpu(cpufreq_cpu_data, cpu221) is not NULL.

After reverting commit 56eb0c0ed345 ("ACPI: CPPC: Fix remaining
for_each_possible_cpu() to use online CPUs"), the issue disappeared.

The _PSD (P-State Dependency) defines the hardware-level dependency of
frequency control across CPU cores. Since this relationship is a physical
attribute of the hardware topology, it remains constant regardless of the
online or offline status of the CPUs.

Using for_each_online_cpu() in acpi_get_psd_map() is problematic. If a
CPU is offline, it will be excluded from the shared_cpu_map.
Consequently, if that CPU is brought online later, the kernel will fail
to recognize it as part of any shared frequency domain.

Switch back to for_each_possible_cpu() to ensure that all cores defined
in the ACPI tables are correctly mapped into their respective performance
domains from the start. This aligns with the logic of policy->related_cpus,
which must encompass all potentially available cores in the domain to
prevent logic gaps during CPU hotplug operations.

To resolve the original issue regarding the "nosmt" or "nosmt=force"
boot parameter, as send_pcc_cmd() function already does if (!desc)
continue, so reverting that loop back to for_each_possible_cpu() is ok,
only need to change the match_cpc_ptr NULL case in acpi_get_psd_map() to
continue as Sean suggested.

How to reproduce, on arm64 machine with SMT support which use acpi cppc
cpufreq driver:

	bash test.sh 220 & bash test.sh 221 &

	The test.sh is as below:
		while true
			do
			echo 0 > /sys/devices/system/cpu/cpu${1}/online
			sleep 0.5
			cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus
			echo 1 >  /sys/devices/system/cpu/cpu${1}/online
			cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus
		done

	CPU: 221 PID: 1119 Comm: cpuhp/221 Kdump: loaded Not tainted 6.6.0debug+ #5
	Hardware name: To be filled by O.E.M. S920X20/BC83AMDA01-7270Z, BIOS 20.39 09/04/2024
	pstate: a1400009 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
	pc : cpufreq_online+0x8ac/0xa90
	lr : cpuhp_cpufreq_online+0x18/0x30
	sp : ffff80008739bce0
	x29: ffff80008739bce0 x28: 0000000000000000 x27: ffff28400ca32200
	x26: 0000000000000000 x25: 0000000000000003 x24: ffffd483503ff000
	x23: ffffd483504051a0 x22: ffffd48350024a00 x21: 00000000000000dd
	x20: 000000000000001d x19: ffff28400ca32000 x18: 0000000000000000
	x17: 0000000000000020 x16: ffffd4834e6a3fc8 x15: 0000000000000020
	x14: 0000000000000008 x13: 0000000000000001 x12: 00000000ffffffff
	x11: 0000000000000040 x10: ffffd48350430728 x9 : ffffd4834f087c78
	x8 : 0000000000000001 x7 : ffff2840092bdf00 x6 : ffffd483504264f0
	x5 : ffffd48350405000 x4 : ffff283f7f95cc60 x3 : 0000000000000000
	x2 : ffff53bc2f94b000 x1 : 00000000000000dd x0 : 0000000000000000
	Call trace:
	 cpufreq_online+0x8ac/0xa90
	 cpuhp_cpufreq_online+0x18/0x30
	 cpuhp_invoke_callback+0x128/0x580
	 cpuhp_thread_fun+0x110/0x1b0
	 smpboot_thread_fn+0x140/0x190
	 kthread+0xec/0x100
	 ret_from_fork+0x10/0x20
	---[ end trace 0000000000000000 ]---

Cc: All applicable 
Fixes: 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs")
Co-developed-by: Sean Kelley 
Signed-off-by: Sean Kelley 
Signed-off-by: Jinjie Ruan 
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20260417040112.3727756-1-ruanjinjie@huawei.com
Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Fix EINJV2 memory error injection

2026-04-27T19:42:31+00:00

Error types in EINJV2 use different bit positions for each flavor of
injection from legacy EINJ.

Two issues:

 1) The address sanity checks in einj_error_inject() were skipped for
    EINJV2 injections. Noted by sashiko[1]
 2) __einj_error_trigger() failed to drop the entry of the target
    physical address from the list of resources that need to be
    requested.

Add a helper function that checks if an injection is to memory and use it
to solve each of these issues.

Note that the old test in __einj_error_trigger() checked that param2 was
not zero. This isn't needed because the sanity checks in einj_error_inject()
reject memory injections with param2 == 0.

Fixes: b47610296d17 ("ACPI: APEI: EINJ: Enable EINJv2 error injections")
Reported-by: sashiko 
Reported-by: Herman Li 
Signed-off-by: Tony Luck 
Tested-by: "Lai, Yi1" 
Link: https://sashiko.dev/#/patchset/20260415163620.12957-1-tony.luck%40intel.com # [1]
Reviewed-by: Jiaqi Yan 
Reviewed-by: Zaid Alali 
Link: https://patch.msgid.link/20260421150216.11666-3-tony.luck@intel.com
Signed-off-by: Rafael J. Wysocki

ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states

2026-04-27T12:39:32+00:00

Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
call from acpi_processor_setup_cpuidle_dev(), where its return value was
ignored, to acpi_processor_get_power_info(), where it is now treated as
a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
busy-poll when idle.

On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
(only WFI, no deep PSCI states beyond it), so the previous
"count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.

The lpi_states count is already validated in acpi_processor_get_lpi_info(),
so the check here is redundant. Simplify the loop to iterate over
lpi_states[1..power.count). When only WFI is present, the loop body
simply does not execute and the function returns 0, which is the correct
outcome: there is nothing to validate for FFH and no error to report.

Suggested-by: Huisong Li 
Cc: stable@vger.kernel.org
Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
Signed-off-by: Breno Leitao 
Reviewed-by: Sudeep Holla 
Signed-off-by: Catalin Marinas