linux-stable.git/include/acpi, branch v6.18.40

ACPI: bus: Introduce devm_acpi_install_notify_handler()

2026-07-24T14:17:20+00:00

[ Upstream commit ca70ce555a1eb8edf5fb1d5575f1fe19c9ae17f4 ]

Introduce devm_acpi_install_notify_handler() for installing an ACPI
notify handler managed by devres that will be removed automatically on
driver detach.

It installs the notify handler on the device object in the ACPI
namespace that corresponds to the owner device's ACPI companion, if
present (an error is returned if the owner device doesn't have an ACPI
companion).

Currently, there is no way to manually remove the notify handler
installed by it because none of its users brought on subsequently
will need to do that.

Signed-off-by: Rafael J. Wysocki 
[ rjw: Kerneldoc comment refinement ]
Link: https://patch.msgid.link/2268031.irdbgypaU6@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki 
Stable-dep-of: 18a00ed0e718 ("ACPI: NFIT: core: Fix possible deadlock and missing notifications")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Provide #defines for EINJV2 error types

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

[ Upstream commit 1f6008538384453eb4c13a3d7ff9e37ee8aee6b9 ]

EINJV2 defined new error types by moving the severity (correctable,
uncorrectable non-fatal, uncorrectable fatal) out of the "type".

ACPI 6.5 introduced EINJV2 and defined a vendor defined error type
using bit 31. This was dropped in ACPI 6.6.

Link: https://github.com/acpica/acpica/commit/e82d2d2fd145
Signed-off-by: Tony Luck 
Link: https://patch.msgid.link/20260421150216.11666-2-tony.luck@intel.com
Signed-off-by: Rafael J. Wysocki 
Stable-dep-of: 0c00cfbcfcff ("ACPI: APEI: EINJ: Fix EINJV2 memory error injection")
Signed-off-by: Sasha Levin

APEI/GHES: ensure that won't go past CPER allocated record

2026-03-04T12:19:35+00:00

[ Upstream commit fa2408a24f8f0db14d9cfc613ef162dc267d7ad4 ]

The logic at ghes_new() prevents allocating too large records, by
checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB).
Yet, the allocation is done with the actual number of pages from the
CPER bios table location, which can be smaller.

Yet, a bad firmware could send data with a different size, which might
be bigger than the allocated memory, causing an OOPS:

    Unable to handle kernel paging request at virtual address fff00000f9b40000
    Mem abort info:
      ESR = 0x0000000096000007
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x07: level 3 translation fault
    Data abort info:
      ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000
    [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000
    Internal error: Oops: 0000000096000007 [#1]  SMP
    Modules linked in:
    CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT
    Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
    Workqueue: kacpi_notify acpi_os_execute_deferred
    pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    pc : hex_dump_to_buffer+0x30c/0x4a0
    lr : hex_dump_to_buffer+0x328/0x4a0
    sp : ffff800080e13880
    x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083
    x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004
    x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083
    x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010
    x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020
    x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008
    x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000
    x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020
    x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000
    x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008
    Call trace:
     hex_dump_to_buffer+0x30c/0x4a0 (P)
     print_hex_dump+0xac/0x170
     cper_estatus_print_section+0x90c/0x968
     cper_estatus_print+0xf0/0x158
     __ghes_print_estatus+0xa0/0x148
     ghes_proc+0x1bc/0x220
     ghes_notify_hed+0x5c/0xb8
     notifier_call_chain+0x78/0x148
     blocking_notifier_call_chain+0x4c/0x80
     acpi_hed_notify+0x28/0x40
     acpi_ev_notify_dispatch+0x50/0x80
     acpi_os_execute_deferred+0x24/0x48
     process_one_work+0x15c/0x3b0
     worker_thread+0x2d0/0x400
     kthread+0x148/0x228
     ret_from_fork+0x10/0x20
    Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44)
    ---[ end trace 0000000000000000 ]---

Prevent that by taking the actual allocated are into account when
checking for CPER length.

Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Jonathan Cameron 
Acked-by: Ard Biesheuvel 
Reviewed-by: Hanjun Guo 
[ rjw: Subject tweaks ]
Link: https://patch.msgid.link/4e70310a816577fabf37d94ed36cde4ad62b1e0a.1767871950.git.mchehab+huawei@kernel.org
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

Revert "mailbox/pcc: support mailbox management of the shared buffer"

2026-02-26T22:59:28+00:00

[ Upstream commit f82c3e62b6b8c31d8c56415bf38658f306fda4cb ]

This reverts commit 5378bdf6a611a32500fccf13d14156f219bb0c85.

Commit 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer")
attempted to introduce generic helpers for managing the PCC shared memory,
but it largely duplicates functionality already provided by the mailbox
core and leaves gaps:

1. TX preparation: The mailbox framework already supports this via
  ->tx_prepare callback for mailbox clients. The patch adds
  pcc_write_to_buffer() and expects clients to toggle pchan->chan.manage_writes,
  but no drivers set manage_writes, so pcc_write_to_buffer() has no users.

2. RX handling: Data reception is already delivered through
   mbox_chan_received_data() and client ->rx_callback. The patch adds an
   optional pchan->chan.rx_alloc, which again has no users and duplicates
   the existing path.

3. Completion handling: While adding last_tx_done is directionally useful,
   the implementation only covers Type 3/4 and fails to handle the absence
   of a command_complete register, so it is incomplete for other types.

Given the duplication and incomplete coverage, revert this change. Any new
requirements should be addressed in focused follow-ups rather than bundling
multiple behavioral changes together.

Fixes: 5378bdf6a611 ("mailbox/pcc: support mailbox management of the shared buffer")
Signed-off-by: Sudeep Holla 
Signed-off-by: Jassi Brar 
Signed-off-by: Sasha Levin

Revert "ACPI: processor: idle: Optimize ACPI idle driver registration"

2025-11-25T15:08:06+00:00

Revert commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle
driver registration") because it is reported to introduce a cpuidle
regression leading to a kernel crash on a platform using the ACPI idle
driver.

Signed-off-by: Rafael J. Wysocki 
Reported-by: Borislav Petkov 
Tested-by: Borislav Petkov (AMD) 
Closes: https://lore.kernel.org/lkml/20251124200019.GIaSS5U9HhsWBotrQZ@fat_crate.local/

Revert "ACPI: processor: Remove unused empty stubs of some functions"

2025-11-25T14:05:01+00:00

Revert commit 5020d05b3476 ("ACPI: processor: Remove unused empty stubs
of some functions") because it depends on a problematic one.

Signed-off-by: Rafael J. Wysocki

Revert "ACPI: processor: idle: Rearrange declarations in header file"

2025-11-25T14:03:24+00:00

Revert commit bdf780fbcef5 ("ACPI: processor: idle: Rearrange declarations
in header file") because it depends on a problematic one.

Signed-off-by: Rafael J. Wysocki

Revert "ACPI: processor: idle: Redefine two functions as void"

2025-11-25T13:53:33+00:00

Revert commit fbd401e95e56 ("ACPI: processor: idle: Redefine two
functions as void") because it depends on a problematic one.

Signed-off-by: Rafael J. Wysocki

Revert "ACPI: processor: Do not expose global variable acpi_idle_driver"

2025-11-25T13:50:25+00:00

Revert commit 559f2eacc8a2 ACPI: processor: Do not expose global variable
acpi_idle_driver" because it depends on a problematic one.

Signed-off-by: Rafael J. Wysocki

Merge tag 'pm-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2025-10-07T16:39:51+00:00

Pull more power management updates from Rafael Wysocki:
 "These are cpufreq fixes and cleanups on top of the material merged
  previously, a power management core code fix and updates of the
  runtime PM framework including unit tests, documentation updates and
  introduction of auto-cleanup macros for runtime PM "resume and get"
  and "get without resuming" operations.

  Specifics:

   - Make cpufreq drivers setting the default CPU transition latency to
     CPUFREQ_ETERNAL specify a proper default transition latency value
     instead which addresses a regression introduced during the 6.6
     cycle that broke CPUFREQ_ETERNAL handling (Rafael Wysocki)

   - Make the cpufreq CPPC driver use a proper transition delay value
     when CPUFREQ_ETERNAL is returned by cppc_get_transition_latency()
     to indicate an error condition (Rafael Wysocki)

   - Make cppc_get_transition_latency() return a negative error code to
     indicate error conditions instead of using CPUFREQ_ETERNAL for this
     purpose and drop CPUFREQ_ETERNAL that has no other users (Rafael
     Wysocki, Gopi Krishna Menon)

   - Fix device leak in the mediatek cpufreq driver (Johan Hovold)

   - Set target frequency on all CPUs sharing a policy during frequency
     updates in the tegra186 cpufreq driver and make it initialize all
     cores to max frequencies (Aaron Kling)

   - Rust cpufreq helper cleanup (Thorsten Blum)

   - Make pm_runtime_put*() family of functions return 1 when the given
     device is already suspended which is consistent with the
     documentation (Brian Norris)

   - Add basic kunit tests for runtime PM API contracts and update
     return values in kerneldoc comments for the runtime PM API (Brian
     Norris, Dan Carpenter)

   - Add auto-cleanup macros for runtime PM "resume and get" and "get
     without resume" operations, use one of them in the PCI core and
     drop the existing "free" macro introduced for similar purpose, but
     somewhat cumbersome to use (Rafael Wysocki)

   - Make the core power management code avoid waiting on device links
     marked as SYNC_STATE_ONLY which is consistent with the handling of
     those device links elsewhere (Pin-yen Lin)"

* tag 'pm-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  docs/zh_CN: Fix malformed table
  docs/zh_TW: Fix malformed table
  PM: runtime: Fix error checking for kunit_device_register()
  PM: runtime: Introduce one more usage counter guard
  cpufreq: Drop unused symbol CPUFREQ_ETERNAL
  ACPI: CPPC: Do not use CPUFREQ_ETERNAL as an error value
  cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay
  cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency
  PM: runtime: Drop DEFINE_FREE() for pm_runtime_put()
  PCI/sysfs: Use runtime PM guard macro for auto-cleanup
  PM: runtime: Add auto-cleanup macros for "resume and get" operations
  cpufreq: tegra186: Initialize all cores to max frequencies
  cpufreq: tegra186: Set target frequency for all cpus in policy
  rust: cpufreq: streamline find_supply_names
  cpufreq: mediatek: fix device leak on probe failure
  PM: sleep: Do not wait on SYNC_STATE_ONLY device links
  PM: runtime: Update kerneldoc return codes
  PM: runtime: Make put{,_sync}() return 1 when already suspended
  PM: runtime: Add basic kunit tests for API contracts