kernel/linux.git/drivers/acpi, branch v7.1-rc6

ACPI: button: Add missing device class clearing on probe failures

2026-05-25T07:52:34+00:00

Commit e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") modified acpi_button_remove() to clear the device class field in struct acpi_device on driver removal, but it should also have updated the rollback path in acpi_button_probe(), which it didn't do, so do it now. Fixes: e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/6167713.MhkbZ0Pkbq@rafael.j.wysocki

ACPI: button: Enable wakeup GPEs for ACPI buttons at probe time

2026-05-25T07:52:34+00:00

Prior to commit 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons"), ACPI button wakeup GPEs having handler methods remained enabled after acpi_wakeup_gpe_init(), but currently they are not enabled because acpi_setup_gpe_for_wake() disables them. That causes function keys to stop working on some systems [1] and there may be other related issues elsewhere. To address that, make the ACPI button driver enable wakeup GPEs for ACPI buttons so long as they have handler methods. While this does not restore the old behavior exactly (the ACPI button driver needs to be bound to the button devices for the GPEs to be enabled), it should be sufficient to restore the missing functionality. For this purpose, introduce acpi_enable_gpe_cond() that enables a GPE if its dispatch type matches the supplied one and modify acpi_button_probe() to use that function for enabling the GPEs in question. Fixes: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons") Reported-by: Nick Closes: https://lore.kernel.org/linux-acpi/E2OXET.4X5GTP37VTNC3@kousu.ca/ [1] Signed-off-by: Rafael J. Wysocki Tested-by: Nick Cc: 7.0+ # 7.0+ Link: https://patch.msgid.link/9629117.CDJkKcVGEf@rafael.j.wysocki

ACPI: button: Fix ACPI GPE handler leak during removal

2026-05-25T07:52:33+00:00

Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate. Fixes: a7e23ec17fee ("ACPI: button: Install notifier for system events as well") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Cc: 6.15+ # 6.15+ Link: https://patch.msgid.link/7954431.EvYhyI6sBW@rafael.j.wysocki

ACPI: battery: Fix system wakeup on critical battery status

2026-05-19T21:06:09+00:00

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

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

2026-05-11T16:50:06+00:00

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+

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