linux/include/acpi, branch v6.17

mailbox/pcc: support mailbox management of the shared buffer

2025-08-08T04:49:56Z

Define a new, optional, callback that allows the driver to specify how the return data buffer is allocated. If that callback is set, mailbox/pcc.c is now responsible for reading from and writing to the PCC shared buffer. This also allows for proper checks of the Commnand complete flag between the PCC sender and receiver. For Type 4 channels, initialize the command complete flag prior to accepting messages. Since the mailbox does not know what memory allocation scheme to use for response messages, the client now has an optional callback that allows it to allocate the buffer for a response message. When an outbound message is written to the buffer, the mailbox checks for the flag indicating the client wants an tx complete notification via IRQ. Upon receipt of the interrupt It will pair it with the outgoing message. The expected use is to free the kernel memory buffer for the previous outgoing message. Signed-off-by: Adam Young Signed-off-by: Jassi Brar

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

2025-07-29T03:44:42Z

Pull ACPI updates from Rafael Wysocki: "These update APEI (new EINJv2 error injection, assorted fixes), fix the ACPI processor driver, update the legacy ACPI /proc interface (multiple assorted fixes of minor issues) and several assorted ACPI drivers (minor fixes and cleanups): - Printing the address in acpi_ex_trace_point() is either incorrect during early kernel boot or not really useful later when pathnames resolve properly, so stop doing it (Mario Limonciello) - Address several minor issues in the legacy ACPI proc interface (Andy Shevchenko) - Fix acpi_object union initialization in the ACPI processor driver to avoid using memory that contains leftover data (Sebastian Ott) - Make the ACPI processor perflib driver take the initial _PPC limit into account as appropriate (Jiayi Li) - Fix message formatting in the ACPI processor throttling driver and in the ACPI PCI link driver (Colin Ian King) - Clean up general ACPI PM domain handling (Rafael Wysocki) - Fix iomem-related sparse warnings in the APEI EINJ driver (Zaid Alali, Tony Luck) - Add EINJv2 error injection support to the APEI EINJ driver (Zaid Alali) - Fix memory corruption in error_type_set() in the APEI EINJ driver (Dan Carpenter) - Fix less than zero comparison on a size_t variable in the APEI EINJ driver (Colin Ian King) - Fix check and iounmap of an uninitialized pointer in the APEI EINJ driver (Colin Ian King) - Add TAINT_MACHINE_CHECK to the GHES panic path in APEI to improve diagnostics and post-mortem analysis (Breno Leitao) - Update APEI reviewer records and other ACPI-related information in MAINTAINERS as well as the contact information in the ACPI ABI documentation (Rafael Wysocki) - Fix the handling of synchronous uncorrected memory errors in APEI (Shuai Xue) - Remove an AudioDSP-related ID from the ACPI LPSS driver (Andy Shevchenko) - Replace sprintf()/scnprintf() with sysfs_emit() in the ACPI fan driver and update a debug message in fan_get_state_acpi4() (Eslam Khafagy, Abdelrahman Fekry, Sumeet Pawnikar) - Add Intel Wildcat Lake support to the ACPI DPTF driver (Srinivas Pandruvada) - Add more debug information regarding failing firmware updates to the ACPI pfr_update driver (Chen Yu) - Reduce the verbosity of the ACPI PRM (platform runtime mechanism) driver to avoid user confusion (Zhu Qiyu) - Replace sprintf() with sysfs_emit() in the ACPI TAD (time and alarm device) driver (Sukrut Heroorkar) - Enable CONFIG_ACPI_DEBUG by default to make it easier to get ACPI debug messages from OEM platforms (Mario Limonciello) - Fix parent device references in ASL examples in the ACPI documentation and fix spelling and style in the gpio-properties documentation in firmware-guide (Andy Shevchenko) - Fix typos in ACPI documentation and comments (Bjorn Helgaas)" * tag 'acpi-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (39 commits) ACPI: Fix typos ACPI/PCI: Remove space before newline ACPI: processor: throttling: Remove space before newline ACPI: processor: perflib: Fix initial _PPC limit application ACPI/PNP: Use my kernel.org address in MAINTAINERS and ABI docs ACPI: TAD: Replace sprintf() with sysfs_emit() ACPI: APEI: handle synchronous exceptions in task work ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered ACPI: APEI: MAINTAINERS: Update reviewers for APEI Documentation: ACPI: Fix parent device references ACPI: fan: Update debug message in fan_get_state_acpi4() ACPI: PRM: Reduce unnecessary printing to avoid user confusion ACPI: fan: Replace sprintf() with sysfs_emit() ACPI: APEI: EINJ: Fix trigger actions ACPI: processor: fix acpi_object initialization ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path ACPI: LPSS: Remove AudioDSP related ID Documentation: firmware-guide: gpio-properties: Spelling and style fixes ACPI: fan: Replace sprintf()/scnprintf() with sysfs_emit() in show() functions ACPI: PM: Set .detach in acpi_general_pm_domain definition ...

ACPI: APEI: handle synchronous exceptions in task work

2025-07-16T19:08:04Z

The memory uncorrected error could be signaled by asynchronous interrupt (specifically, SPI in arm64 platform), e.g. when an error is detected by a background scrubber, or signaled by synchronous exception (specifically, data abort exception in arm64 platform), e.g. when a CPU tries to access a poisoned cache line. Currently, both synchronous and asynchronous errors use memory_failure_queue() to schedule memory_failure() to exectute in a kworker context. As a result, when a user-space process is accessing a poisoned data, a data abort is taken and the memory_failure() is executed in the kworker context, which: - will send wrong si_code by SIGBUS signal in early_kill mode, and - can not kill the user-space in some cases resulting a synchronous error infinite loop Issue 1: send wrong si_code in early_kill mode Since commit a70297d22132 ("ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events")', the flag MF_ACTION_REQUIRED could be used to determine whether a synchronous exception occurs on ARM64 platform. When a synchronous exception is detected, the kernel is expected to terminate the current process which has accessed a poisoned page. This is done by sending a SIGBUS signal with error code BUS_MCEERR_AR, indicating an action-required machine check error on read. However, when kill_proc() is called to terminate the processes who has the poisoned page mapped, it sends the incorrect SIGBUS error code BUS_MCEERR_AO because the context in which it operates is not the one where the error was triggered. To reproduce this problem: #sysctl -w vm.memory_failure_early_kill=1 vm.memory_failure_early_kill = 1 # STEP2: inject an UCE error and consume it to trigger a synchronous error #einj_mem_uc single 0: single vaddr = 0xffffb0d75400 paddr = 4092d55b400 injecting ... triggering ... signal 7 code 5 addr 0xffffb0d75000 page not present Test passed The si_code (code 5) from einj_mem_uc indicates that it is BUS_MCEERR_AO error and it is not factually correct. After this change: # STEP1: enable early kill mode #sysctl -w vm.memory_failure_early_kill=1 vm.memory_failure_early_kill = 1 # STEP2: inject an UCE error and consume it to trigger a synchronous error #einj_mem_uc single 0: single vaddr = 0xffffb0d75400 paddr = 4092d55b400 injecting ... triggering ... signal 7 code 4 addr 0xffffb0d75000 page not present Test passed The si_code (code 4) from einj_mem_uc indicates that it is a BUS_MCEERR_AR error as expected. Issue 2: a synchronous error infinite loop If a user-space process, e.g. devmem, accesses a poisoned page for which the HWPoison flag is set, kill_accessing_process() is called to send SIGBUS to current processs with error info. Since the memory_failure() is executed in the kworker context, it will just do nothing but return EFAULT. So, devmem will access the posioned page and trigger an exception again, resulting in a synchronous error infinite loop. Such exception loop may cause platform firmware to exceed some threshold and reboot when Linux could have recovered from this error. To reproduce this problem: # STEP 1: inject an UCE error, and kernel will set HWPosion flag for related page #einj_mem_uc single 0: single vaddr = 0xffffb0d75400 paddr = 4092d55b400 injecting ... triggering ... signal 7 code 4 addr 0xffffb0d75000 page not present Test passed # STEP 2: access the same page and it will trigger a synchronous error infinite loop devmem 0x4092d55b400 To fix above two issues, queue memory_failure() as a task_work so that it runs in the context of the process that is actually consuming the poisoned data. Signed-off-by: Shuai Xue Tested-by: Ma Wupeng Reviewed-by: Kefeng Wang Reviewed-by: Xiaofei Tan Reviewed-by: Baolin Wang Reviewed-by: Jarkko Sakkinen Reviewed-by: Jonathan Cameron Reviewed-by: Jane Chu Reviewed-by: Yazen Ghannam Reviewed-by: Hanjun Guo Link: https://patch.msgid.link/20250714114212.31660-3-xueshuai@linux.alibaba.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki

cpufreq: CPPC: Remove cpu_data_list

2025-06-18T19:03:52Z

After commit a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list"), cpu_data can be got from policy->driver_data, so cpu_data_list is not actually needed and can be removed. Signed-off-by: Lifeng Zheng Link: https://patch.msgid.link/20250526113057.3086513-2-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-processor' and 'acpi-cppc'

2025-05-26T16:37:38Z

Merge ACPI processor driver updates and ACPI CPPC library updates for 6.16-rc1: - Clean up the initialization of CPU data structures in the ACPI processor driver (Zhang Rui). - Remove an obsolete comment regarding the C-states handling in the ACPI processor driver (Giovanni Gherdovich). - Simplify PCC shared memory region handling (Sudeep Holla). - Rework and extend functions for reading CPPC register values and for updating CPPC registers (Lifeng Zheng). - Add three functions related to autonomous CPU performance state selection to the CPPC library (Lifeng Zheng). * acpi-processor: ACPI: processor: idle: Remove redundant pr->power.count assignment ACPI: processor: idle: Set pr->flags.power unconditionally ACPI: processor: idle: Remove obsolete comment * acpi-cppc: ACPI: CPPC: Add three functions related to autonomous selection ACPI: CPPC: Modify cppc_get_auto_sel_caps() to cppc_get_auto_sel() ACPI: CPPC: Refactor register value get and set ABIs ACPI: CPPC: Add cppc_set_reg_val() ACPI: CPPC: Extract cppc_get_reg_val_in_pcc() ACPI: CPPC: Rename cppc_get_perf() to cppc_get_reg_val() ACPI: CPPC: Optimize cppc_get_perf() ACPI: CPPC: Add IS_OPTIONAL_CPC_REG macro to judge if a cpc_reg is optional ACPI: CPPC: Simplify PCC shared memory region handling ACPI: PCC: Simplify PCC shared memory region handling

ACPICA: Update copyright year

2025-05-12T13:38:43Z

ACPICA commit 45253be18b3f37d46cd0072aa3f8a0a21a70e0a4 Changes needed by acpisrc to update copyright year when building for release. Link: https://github.com/acpica/acpica/commit/45253be1 Signed-off-by: Saket Dumbre Signed-off-by: Rafael J. Wysocki

ACPICA: Logfile: Changes for version 20250404

2025-05-12T13:38:43Z

ACPICA commit 52de9040740c562a35244de19d21c0313964c874 Link: https://github.com/acpica/acpica/commit/52de9040 Signed-off-by: Saket Dumbre Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2251077.Icojqenx9y@rjwysocki.net

ACPICA: Replace strncpy() with memcpy()

2025-05-12T13:38:42Z

ACPICA commit 83019b471e1902151e67c588014ba2d09fa099a3 strncpy() is deprecated for NUL-terminated destination buffers[1]. Use memcpy() for length-bounded destinations. Link: https://github.com/KSPP/linux/issues/90 [1] Link: https://github.com/acpica/acpica/commit/83019b47 Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1910878.atdPhlSkOF@rjwysocki.net

ACPICA: Apply ACPI_NONSTRING in more places

2025-05-12T13:38:42Z

ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b Add ACPI_NONSTRING for destination char arrays without a terminating NUL character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply ACPI_NONSTRING") where not all instances received the same treatment, in preparation for replacing strncpy() calls with memcpy() Link: https://github.com/acpica/acpica/commit/1035a3d4 Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3833065.MHq7AAxBmi@rjwysocki.net

ACPICA: Avoid sequence overread in call to strncmp()

2025-05-12T13:38:42Z

ACPICA commit 8b83a8d88dfec59ea147fad35fc6deea8859c58c ap_get_table_length() checks if tables are valid by calling ap_is_valid_header(). The latter then calls ACPI_VALIDATE_RSDP_SIG(Table->Signature). ap_is_valid_header() accepts struct acpi_table_header as an argument, so the signature size is always fixed to 4 bytes. The problem is when the string comparison is between ACPI-defined table signature and ACPI_SIG_RSDP. Common ACPI table header specifies the Signature field to be 4 bytes long[1], with the exception of the RSDP structure whose signature is 8 bytes long "RSD PTR " (including the trailing blank character)[2]. Calling strncmp(sig, rsdp_sig, 8) would then result in a sequence overread[3] as sig would be smaller (4 bytes) than the specified bound (8 bytes). As a workaround, pass the bound conditionally based on the size of the signature being passed. Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#system-description-table-header [1] Link: https://uefi.org/specs/ACPI/6.5_A/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp-structure [2] Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overread [3] Link: https://github.com/acpica/acpica/commit/8b83a8d8 Signed-off-by: Ahmed Salem Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2248233.Mh6RI2rZIc@rjwysocki.net