kernel/git/stable/linux.git/drivers/acpi, branch linux-6.7.y

ACPI: scan: Fix device check notification handling

2024-03-26T22:18:21+00:00

[ Upstream commit 793551c965116d9dfaf0550dacae1396a20efa69 ] It is generally invalid to fail a Device Check notification if the scan handler has not been attached to the given device after a bus rescan, because there may be valid reasons for the scan handler to refuse attaching to the device (for example, the device is not ready). For this reason, modify acpi_scan_device_check() to return 0 in that case without printing a warning. While at it, reduce the log level of the "already enumerated" message in the same function, because it is only interesting when debugging notification handling Fixes: 443fc8202272 ("ACPI / hotplug: Rework generic code to handle suprise removals") Signed-off-by: Rafael J. Wysocki Reviewed-by: Jonathan Cameron Signed-off-by: Sasha Levin

ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override

2024-03-26T22:18:21+00:00

[ Upstream commit 021a67d096154893cd1d883c7be0097e2ee327fd ] A known issue on some Zen laptops, keyboard stopped working due to commit 9946e39fe8d0 fael@kernel.org("ACPI: resource: skip IRQ override on AMD Zen platforms") on kernel 5.19.10. The ACPI IRQ override is required for this board due to buggy DSDT, thus adding the board vendor and name to irq1_edge_low_force_override fixes the issue. Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217394 Link: https://lore.kernel.org/linux-acpi/20231006123304.32686-1-hdegoede@redhat.com/ Tested-by: Maxim Trofimov Signed-off-by: Maxim Kudinov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: resource: Do IRQ override on Lunnen Ground laptops

2024-03-26T22:18:20+00:00

[ Upstream commit e23ad54fef186aa66007895be1382c88f1ee2bf7 ] The Lunnen Ground 15 and 16 needs IRQ overriding for the keyboard to work. Adding an entries for these laptops to the override_table makes the internal keyboard functional. Signed-off-by: Alexey I. Froloff Signed-off-by: Rafael J. Wysocki Stable-dep-of: 021a67d09615 ("ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override") Signed-off-by: Sasha Levin

ACPI: resource: Add Infinity laptops to irq1_edge_low_force_override

2024-03-26T22:18:20+00:00

[ Upstream commit e2605d4039a42a03000856b3229932455717b48b ] A user reported a keyboard problem similar to ones reported with other Zen laptops, on an Infinity E15-5A165-BM. Add board name matches for this model and one (untested) close relative to irq1_edge_low_force_override. Link: https://lemmy.ml/post/9864736 Link: https://www.infinitygaming.com.au/bios/ Link: https://lore.kernel.org/linux-acpi/20231006123304.32686-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 021a67d09615 ("ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override") Signed-off-by: Sasha Levin

ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()

2024-03-26T22:18:14+00:00

[ Upstream commit e18afcb7b2a12b635ac10081f943fcf84ddacc51 ] After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CGA

2024-02-05T20:17:03+00:00

[ Upstream commit e315e8692f7922cd1b2a26bd7a1741cc8ce77085 ] Like the ASUS ExpertBook B1502CBA and various ASUS laptops, the ASUS ExpertBook B1502CGA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to Edge_High. $ sudo dmesg | grep DMI [ 0.000000] DMI: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B1502CGA_B1502CGA/B1502CGA, BIOS B1502CGA.303 06/05/2023 $ grep -A 40 PS2K dsdt.dsl | grep IRQ -A 1 IRQ (Level, ActiveLow, Exclusive, ) {1} This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Signed-off-by: Michael Maltsev [ rjw: rebase, replace .ident field with a comment ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: resource: Add DMI quirks for ASUS Vivobook E1504GA and E1504GAB

2024-02-05T20:17:03+00:00

[ Upstream commit d2aaf19965045f70bb2ece514399cdc6fcce2e73 ] Asus Vivobook E1504GA and E1504GAB notebooks are affected by bug #216158 (DSDT specifies the kbd IRQ as level active-low and using the override changes this to rising edge, stopping the keyboard from working). Users of these notebooks do not have a working keyboard unless they add their DMI information to the struct irq1_level_low_skip_override array and compile a custom kernel. Add support for these computers to the Linux kernel without requiring the end-user to recompile the kernel. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158 Signed-off-by: Ben Mayo [ rjw: Link tag, subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events

2024-02-05T20:16:46+00:00

[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ] There are two major types of uncorrected recoverable (UCR) errors : - Synchronous error: The error is detected and raised at the point of the consumption in the execution flow, e.g. when a CPU tries to access a poisoned cache line. The CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64 and Machine Check Exception (MCE) on X86. OS requires to take action (for example, offline failure page/kill failure thread) to recover this uncorrectable error. - Asynchronous error: The error is detected out of processor execution context, e.g. when an error is detected by a background scrubber. Some data in the memory are corrupted. But the data have not been consumed. OS is optional to take action to recover this uncorrectable error. When APEI firmware first is enabled, a platform may describe one error source for the handling of synchronous errors (e.g. MCE or SEA notification ), or for handling asynchronous errors (e.g. SCI or External Interrupt notification). In other words, we can distinguish synchronous errors by APEI notification. For synchronous errors, kernel will kill the current process which accessing the poisoned page by sending SIGBUS with BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in early kill mode. However, the GHES driver always sets mf_flags to 0 so that all synchronous errors are handled as asynchronous errors in memory failure. To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous events. Signed-off-by: Shuai Xue Tested-by: Ma Wupeng Reviewed-by: Kefeng Wang Reviewed-by: Xiaofei Tan Reviewed-by: Baolin Wang Reviewed-by: James Morse Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: NUMA: Fix the logic of getting the fake_pxm value

2024-02-05T20:16:46+00:00

[ Upstream commit e3f577830ce216b0ca21d4750cbbd64cfc21efff ] The for loop does not iterate over the last element of the node_to_pxm_map array. This could lead to a conflict between the final fake_pxm value and the existing pxm values. That is, the final fake_pxm value can not be guaranteed to be an unused pxm value. While at it, fix up white space in slit_valid(). Signed-off-by: Yuntao Wang [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: extlog: fix NULL pointer dereference check

2024-02-05T20:16:45+00:00

[ Upstream commit 72d9b9747e78979510e9aafdd32eb99c7aa30dd1 ] The gcc plugin -fanalyzer [1] tries to detect various patterns of incorrect behaviour. The tool reports: drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: drivers/acpi/acpi_extlog.c:307:12: warning: check of ‘extlog_l1_addr’ for NULL after already dereferencing it [-Wanalyzer-deref-before-check] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) pointer ‘extlog_l1_addr’ is dereferenced here | 307 | if (extlog_l1_addr) | | ~ | | | | | (2) pointer ‘extlog_l1_addr’ is checked for NULL here but it was already dereferenced at (1) | Fix the NULL pointer dereference check in extlog_exit(). Link: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html # [1] Signed-off-by: Prarit Bhargava Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin