kernel/linux.git/drivers/acpi, branch v7.0.11

ACPI: driver: Check ACPI_COMPANION() against NULL during probe

2026-06-01T15:54:24+00:00

[ Upstream commit e4865a56d013e86e46ea6acea15bb6eae01898ff ] Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks against NULL to 13 platform drivers handling core ACPI devices. Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/4516068.ejJDZkT8p0@rafael.j.wysocki Cc: 7.0+ # 7.0+ [ reordered variable declaration to add NULL check before pre-existing stable-only code that dereferences the pointer ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: battery: Fix system wakeup on critical battery status

2026-06-01T15:54:21+00:00

commit c35cb4fc7231702d1e9952aec1a442f3e27df6f5 upstream. Commit 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") changed the parent of the battery wakeup source to the platform device used for driver binding, but it forgot to update the acpi_pm_wakeup_event() call in acpi_battery_update() accordingly. Do it now to unbreak waking up the system on critical battery status during suspend-to-idle and during transitions to ACPI S3/S4. Fixes: 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Cc: 7.0+ # 7.0+ Link: https://patch.msgid.link/12898712.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: APEI: EINJ: Fix EINJV2 memory error injection

2026-05-23T11:09:28+00:00

[ Upstream commit 0c00cfbcfcffa7085e4f0c7fd7a4caada4e7a90f ] 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 Signed-off-by: Sasha Levin

ACPI: AGDI: fix missing newline in error message

2026-05-23T11:08:37+00:00

[ Upstream commit b178330b67abb7293b6de28b2a49d49c83962db5 ] Add the missing trailing newline to the dev_err() message printed when SDEI event registration fails. This keeps the error output as a properly terminated log line. Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen Signed-off-by: Haoyu Lu Reviewed-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver

2026-05-23T11:08:27+00:00

[ Upstream commit 6cee29ad9d7e400d39ae0b1a54447fedcb62eecd ] If a CMOS RTC (PNP0B00/PNP0B01/PNP0B02) device coexists with an ACPI TAD (timer and event alarm device, ACPI000E), the ACPI TAD driver will attempt to install the CMOS RTC address space hanlder that has been installed already and the TAD probing will fail. Avoid that by changing acpi_install_cmos_rtc_space_handler() to return zero and acpi_remove_cmos_rtc_space_handler() to do nothing if the CMOS RTC address space handler has been installed already. Fixes: 596ca52a56da ("ACPI: TAD: Install SystemCMOS address space handler for ACPI000E") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2415111.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Sasha Levin

ACPI: x86: cmos_rtc: Clean up address space handler driver

2026-05-23T11:08:27+00:00

[ Upstream commit ba0b236736dde4059bdcb8e99beaa50d6e5b6e7e ] Make multiple changes that do not alter functionality to the CMOS RTC ACPI address space handler driver, including the following: - Drop the unused .detach() callback from cmos_rtc_handler. - Rename acpi_cmos_rtc_attach_handler() to acpi_cmos_rtc_attach(). - Rearrange acpi_cmos_rtc_space_handler() to reduce the number of redundant checks and make white space follow the coding style. - Adjust an error message in acpi_install_cmos_rtc_space_handler() and make the white space follow the coding style. - Rearrange acpi_remove_cmos_rtc_space_handler() and adjust an error message in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5094429.31r3eYUQgx@rafael.j.wysocki Stable-dep-of: 6cee29ad9d7e ("ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver") Signed-off-by: Sasha Levin

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

2026-05-14T13:31:02+00:00

commit 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 upstream. 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 Signed-off-by: Greg Kroah-Hartman

ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug

2026-05-14T13:31:02+00:00

commit 75141a770f4f8225d316f6c7e146723a32e9720e upstream. 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 Signed-off-by: Greg Kroah-Hartman

ACPI: video: Add backlight=native quirk for Dell OptiPlex 7770 AIO

2026-05-14T13:31:02+00:00

commit ad7997f5a01af6f711fe6b6a2df578b964109d49 upstream. The Dell OptiPlex 7770 AIO needs the same quirk as the 7760 AIO. The backlight can be controlled with the native controller, intel_backlight, but not with dell_uart_backlight. I dumped the DSDT using acpidump, acpixtract and iasl, and confirmed that it contains the DELL0501 device. When loading the dell_uart_backlight driver with `rmmod dell_uart_backlight`, `modprobe dell_uart_backlight dyndbg`, it reports "Firmware version: GL_Re_V18". Fixes: cd8e468efb4f ("ACPI: video: Add Dell UART backlight controller detection") Cc: All applicable Signed-off-by: Jan Schär Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260411092606.47925-1-jan@jschaer.ch Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: scan: Use acpi_dev_put() in object add error paths

2026-05-14T13:31:02+00:00

commit 9c0acc169ac71535477caedea8315f7041c5f07c upstream. After acpi_init_device_object(), the lifetime of struct acpi_device is managed by the driver core through reference counting. Both acpi_add_power_resource() and acpi_add_single_object() call acpi_init_device_object() and then invoke acpi_device_add(). If that fails, their error paths call the release callback directly instead of dropping the device reference through acpi_dev_put(). This bypasses the normal device lifetime rules and frees the object without releasing the reference acquired by device_initialize(), which may lead to a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix both error paths by using acpi_dev_put() and let the release callback handle the final cleanup. Fixes: 781d737c7466 ("ACPI: Drop power resources driver") Fixes: 718fb0de8ff88 ("ACPI: fix NULL bug for HID/UID string") Cc: All applicable Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman