From bede543d2f8a045030ea6ed49307719673342613 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 5 Dec 2024 12:24:35 +0100 Subject: [PATCH 1/5] ACPI: OSL: Use usleep_range() in acpi_os_sleep() As stated by Len in [1], the extra delay added by msleep() to the sleep time value passed to it can be significant, roughly between 1.5 ns on systems with HZ = 1000 and as much as 15 ms on systems with HZ = 100, which is hardly acceptable, at least for small sleep time values. msleep(5) on the default HZ = 250 in Ubuntu on a modern PC takes about 12 ms. This results in over 800 ms of spurious system resume delay on systems such as the Dell XPS-13-9300, which use ASL Sleep(5ms) in a tight loop. Address this by using usleep_range() in acpi_os_sleep() instead of msleep(). For short sleep times this is a no brainer, but even for long sleeps usleep_range() should be preferred because timer wheel timers are optimized for cancelation before they expire and this particular timer is not going to be canceled. Add at least 50 us on top of the requested sleep time in case the timer can be subject to coalescing, which is consistent with what's done in user space in this context [2], but for sleeps longer than 5 ms use 1% of the requested sleep time for this purpose. The rationale here is that longer sleeps don't need that much of a timer precision as a rule and making the timer a more likely candidate for coalescing in these cases is generally desirable. It starts at 5 ms so that the delta between the requested sleep time and the effective deadline is a contiuous function of the former. Link: https://lore.kernel.org/linux-pm/c7db7e804c453629c116d508558eaf46477a2d73.1731708405.git.len.brown@intel.com/ [1] Link: https://lore.kernel.org/linux-pm/CAJvTdK=Q1kwWA6Wxn8Zcf0OicDEk6cHYFAvQVizgA47mXu63+g@mail.gmail.com/ [2] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216263 Reported-by: Len Brown Reviewed-by: Hans de Goede Reviewed-by: Mario Limonciello Tested-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5857066.DvuYhMxLoT@rjwysocki.net --- drivers/acpi/osl.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index fed446aace42..5ff343096ece 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -607,7 +607,27 @@ acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler) void acpi_os_sleep(u64 ms) { - msleep(ms); + u64 usec = ms * USEC_PER_MSEC, delta_us = 50; + + /* + * Use a hrtimer because the timer wheel timers are optimized for + * cancelation before they expire and this timer is not going to be + * canceled. + * + * Set the delta between the requested sleep time and the effective + * deadline to at least 50 us in case there is an opportunity for timer + * coalescing. + * + * Moreover, longer sleeps can be assumed to need somewhat less timer + * precision, so sacrifice some of it for making the timer a more likely + * candidate for coalescing by setting the delta to 1% of the sleep time + * if it is above 5 ms (this value is chosen so that the delta is a + * continuous function of the sleep time). + */ + if (ms > 5) + delta_us = (USEC_PER_MSEC / 100) * ms; + + usleep_range(usec, usec + delta_us); } void acpi_os_stall(u32 us) From 17159601d2ec40b849d3f12713eb6f92093b6748 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Thu, 19 Dec 2024 17:21:48 +0200 Subject: [PATCH 2/5] ACPI: property: Consider data nodes as being available New functions making use of the data node availability information, like fwnode_for_each_available_child_node(), have been added years after fwnode_device_is_available() was introduced. To enumerate the data nodes in various ways specific to those functions, the node availability test needs to pass. On ACPI, there is no explicit data node availbility information in the first place and the original fwnode_device_is_available() implementation simply returns false. This causes new functions that only enumerate available nodes to never return any nodes on ACPI for leaf devices that have child data nodes. However, on the DT side, fwnode_device_is_available() returns true for all nodes without the "status" property which are analogous to the ACPI data nodes, so there is a difference in behavior between DT and ACPI in that respect. Thus from now on, return true from fwnode_device_is_available() on all ACPI data nodes. Signed-off-by: Sakari Ailus Link: https://patch.msgid.link/20241219152148.975622-1-sakari.ailus@linux.intel.com Signed-off-by: Rafael J. Wysocki --- drivers/acpi/property.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c index 80a52a4e66dd..1ee81e771ae6 100644 --- a/drivers/acpi/property.c +++ b/drivers/acpi/property.c @@ -1492,7 +1492,7 @@ acpi_graph_get_remote_endpoint(const struct fwnode_handle *__fwnode) static bool acpi_fwnode_device_is_available(const struct fwnode_handle *fwnode) { if (!is_acpi_device_node(fwnode)) - return false; + return true; return acpi_device_is_present(to_acpi_device_node(fwnode)); } From bff7165da9c1961e44b2fd6c8f80c8704184ae11 Mon Sep 17 00:00:00 2001 From: Sunil V L Date: Fri, 3 Jan 2025 09:21:22 +0530 Subject: [PATCH 3/5] ACPI: tables: Use string choice helpers Use str_enabled_disabled string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202501010947.0e3GVHNa-lkp@intel.com/ Reported-by: Julia Lawall Closes: https://lore.kernel.org/r/202501010947.0e3GVHNa-lkp@intel.com/ Signed-off-by: Sunil V L Link: https://patch.msgid.link/20250103035122.50315-1-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki --- drivers/acpi/tables.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 9e1b01c35070..2295abbecd14 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -56,7 +56,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) (struct acpi_madt_local_apic *)header; pr_debug("LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] %s)\n", p->processor_id, p->id, - (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->lapic_flags & ACPI_MADT_ENABLED)); } break; @@ -66,7 +66,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) (struct acpi_madt_local_x2apic *)header; pr_debug("X2APIC (apic_id[0x%02x] uid[0x%02x] %s)\n", p->local_apic_id, p->uid, - (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->lapic_flags & ACPI_MADT_ENABLED)); } break; @@ -160,7 +160,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) (struct acpi_madt_local_sapic *)header; pr_debug("LSAPIC (acpi_id[0x%02x] lsapic_id[0x%02x] lsapic_eid[0x%02x] %s)\n", p->processor_id, p->id, p->eid, - (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->lapic_flags & ACPI_MADT_ENABLED)); } break; @@ -183,7 +183,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) pr_debug("GICC (acpi_id[0x%04x] address[%llx] MPIDR[0x%llx] %s)\n", p->uid, p->base_address, p->arm_mpidr, - (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->flags & ACPI_MADT_ENABLED)); } break; @@ -218,7 +218,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) pr_debug("CORE PIC (processor_id[0x%02x] core_id[0x%02x] %s)\n", p->processor_id, p->core_id, - (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->flags & ACPI_MADT_ENABLED)); } break; @@ -228,7 +228,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) pr_debug("RISC-V INTC (acpi_uid[0x%04x] hart_id[0x%llx] %s)\n", p->uid, p->hart_id, - (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled"); + str_enabled_disabled(p->flags & ACPI_MADT_ENABLED)); } break; From f4757d84abf523ea831dba0c136db4050d55c99f Mon Sep 17 00:00:00 2001 From: Robert Richter Date: Tue, 7 Jan 2025 17:19:22 +0100 Subject: [PATCH 4/5] ACPI: PRM: Fix missing guid_t declaration in linux/prmt.h MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Seen the following build error: ./include/linux/prmt.h:5:27: error: unknown type name ‘guid_t’ 5 | int acpi_call_prm_handler(guid_t handler_guid, void *param_buffer); | ^~~~~~ The include file uses guid_t but it is not declared. Include linux/uuid.h to fix this. Signed-off-by: Robert Richter Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20250107161923.3387552-1-rrichter@amd.com Signed-off-by: Rafael J. Wysocki --- include/linux/prmt.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/prmt.h b/include/linux/prmt.h index 9c094294403f..c53ab287e932 100644 --- a/include/linux/prmt.h +++ b/include/linux/prmt.h @@ -1,5 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include + #ifdef CONFIG_ACPI_PRMT void init_prmt(void); int acpi_call_prm_handler(guid_t handler_guid, void *param_buffer); From 5c0e00a391dd0099fe95991bb2f962848d851916 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Mon, 13 Jan 2025 13:52:24 +0100 Subject: [PATCH 5/5] APEI: GHES: Have GHES honor the panic= setting The GHES driver overrides the panic= setting by force-rebooting the system after a fatal hw error has been reported. The intent being that such an error would be reported earlier. However, this is not optimal when a hard-to-debug issue requires long time to reproduce and when that happens, the box will get rebooted after 30 seconds and thus destroy the whole hw context of when the error happened. So rip out the default GHES panic timeout and honor the global one. In the panic disabled (panic=0) case, the error will still be logged to dmesg for later inspection and if panic after a hw error is really required, then that can be controlled the usual way - use panic= on the cmdline or set it in the kernel .config's CONFIG_PANIC_TIMEOUT. Reported-by: Feng Tang Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Feng Tang Reviewed-by: Ira Weiny Link: https://patch.msgid.link/20250113125224.GFZ4UMiNtWIJvgpveU@fat_crate.local Signed-off-by: Rafael J. Wysocki --- drivers/acpi/apei/ghes.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 07789f0b59bc..b72772494655 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -173,8 +173,6 @@ static struct gen_pool *ghes_estatus_pool; static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE]; static atomic_t ghes_estatus_cache_alloced; -static int ghes_panic_timeout __read_mostly = 30; - static void __iomem *ghes_map(u64 pfn, enum fixed_addresses fixmap_idx) { phys_addr_t paddr; @@ -983,14 +981,16 @@ static void __ghes_panic(struct ghes *ghes, struct acpi_hest_generic_status *estatus, u64 buf_paddr, enum fixed_addresses fixmap_idx) { + const char *msg = GHES_PFX "Fatal hardware error"; + __ghes_print_estatus(KERN_EMERG, ghes->generic, estatus); ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx); - /* reboot to log the error! */ if (!panic_timeout) - panic_timeout = ghes_panic_timeout; - panic("Fatal hardware error!"); + pr_emerg("%s but panic disabled\n", msg); + + panic(msg); } static int ghes_proc(struct ghes *ghes)