From 7718629432676b5ebd9a32940782fe297a0abf8d Mon Sep 17 00:00:00 2001 From: Liguang Zhang Date: Tue, 29 Jun 2021 19:27:48 +0800 Subject: ACPI: AMBA: Fix resource name in /proc/iomem In function amba_handler_attach(), dev->res.name is initialized by amba_device_alloc. But when address_found is false, dev->res.name is assigned to null value, which leads to wrong resource name display in /proc/iomem, "" is seen for those resources. Signed-off-by: Liguang Zhang Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_amba.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c index 49b781a9cd97..ab8a4e0191b1 100644 --- a/drivers/acpi/acpi_amba.c +++ b/drivers/acpi/acpi_amba.c @@ -76,6 +76,7 @@ static int amba_handler_attach(struct acpi_device *adev, case IORESOURCE_MEM: if (!address_found) { dev->res = *rentry->res; + dev->res.name = dev_name(&dev->dev); address_found = true; } break; -- cgit v1.2.3 From 9249c32ec9197e8d34fe5179c9e31668a205db04 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Wed, 30 Jun 2021 17:23:16 +0200 Subject: ACPI: video: Add quirk for the Dell Vostro 3350 The Dell Vostro 3350 ACPI video-bus device reports spurious ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE events being reported to userspace (and causing trouble there). Add a quirk setting the report_key_events mask to REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE events will be ignored, while still reporting brightness up/down hotkey-presses to userspace normally. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1911763 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_video.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index ffb4afc5aad9..42ede059728c 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -540,6 +540,15 @@ static const struct dmi_system_id video_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"), }, }, + { + .callback = video_set_report_key_events, + .driver_data = (void *)((uintptr_t)REPORT_BRIGHTNESS_KEY_EVENTS), + .ident = "Dell Vostro 3350", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3350"), + }, + }, /* * Some machines change the brightness themselves when a brightness * hotkey gets pressed, despite us telling them not to. In this case -- cgit v1.2.3 From 7b167c4cb48ee3912f0068b9ea5ea4eacc1a5e36 Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Wed, 30 Jun 2021 14:46:06 -0500 Subject: ACPI: PM: Only mark EC GPE for wakeup on Intel systems When using s2idle on a variety of AMD notebook systems, they are experiencing spurious events that the EC or SMU are in the wrong state leading to a hard time waking up or higher than expected power consumption. These events only occur when the EC GPE is inadvertently set as a wakeup source. Originally the EC GPE was only set as a wakeup source when using the intel-vbtn or intel-hid drivers in commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") but during testing a reporter discovered that this was not enough for their ASUS Zenbook UX430UNR/i7-8550U to wakeup by lid event or keypress. Marking the EC GPE for wakeup universally resolved this for that reporter in commit b90ff3554aa3 ("ACPI: PM: s2idle: Always set up EC GPE for system wakeup"). However this behavior has lead to a number of problems: * On both Lenovo T14 and P14s the keyboard wakeup doesn't work, and sometimes the power button event doesn't work. * On HP 635 G7 detaching or attaching AC during suspend will cause the system not to wakeup * On Asus vivobook to prevent detaching AC causing resume problems * On Lenovo 14ARE05 to prevent detaching AC causing resume problems * On HP ENVY x360 to prevent detaching AC causing resume problems As there may be other Intel systems besides ASUS Zenbook UX430UNR/i7-8550U that don't use intel-vbtn or intel-hid, avoid these problems by only universally marking the EC GPE wakesource on non-AMD systems. Link: https://patchwork.kernel.org/project/linux-pm/cover/5997740.FPbUVk04hV@kreacher/#22825489 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1230 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1629 Signed-off-by: Mario Limonciello Acked-by: Alex Deucher Signed-off-by: Rafael J. Wysocki --- drivers/acpi/x86/s2idle.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c index 816bf2c34b7a..1c507804fb10 100644 --- a/drivers/acpi/x86/s2idle.c +++ b/drivers/acpi/x86/s2idle.c @@ -417,11 +417,15 @@ static int lps0_device_attach(struct acpi_device *adev, mem_sleep_current = PM_SUSPEND_TO_IDLE; /* - * Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require the - * EC GPE to be enabled while suspended for certain wakeup devices to - * work, so mark it as wakeup-capable. + * Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U don't + * use intel-hid or intel-vbtn but require the EC GPE to be enabled while + * suspended for certain wakeup devices to work, so mark it as wakeup-capable. + * + * Only enable on !AMD as enabling this universally causes problems for a number + * of AMD based systems. */ - acpi_ec_mark_gpe_for_wake(); + if (!acpi_s2idle_vendor_amd()) + acpi_ec_mark_gpe_for_wake(); return 0; } -- cgit v1.2.3 From 9b52363b9283376c868679bdcd6e19405a4aca5a Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 1 Jul 2021 18:34:52 +0200 Subject: ACPI: Kconfig: Provide help text for the ACPI_PRMT option Add missing help text for CONFIG_ACPI_PRMT. Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") Reported-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki --- drivers/acpi/Kconfig | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 3972de7b7565..3fec02522a6a 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -548,3 +548,13 @@ config ACPI_PRMT bool "Platform Runtime Mechanism Support" depends on EFI && X86_64 default y + help + Platform Runtime Mechanism (PRM) is a firmware interface exposing a + set of binary executables that can be called from the AML interpreter + or directly from device drivers. + + Say Y to enable the AML interpreter to execute the PRM code. + + While this feature is optional in principle, leaving it out may + substantially increase computational overhead related to the + initialization of some server systems. -- cgit v1.2.3 From bd7a94c0fa41dfbea8564556c7a28b05e353c5da Mon Sep 17 00:00:00 2001 From: Aubrey Li Date: Fri, 2 Jul 2021 15:03:49 +0800 Subject: ACPI: Correct \_SB._OSC bit definition for PRM According to Platform Runtime Mechanism Specification v1.0 [1], Page 42, \_SB._OSC bit 21 is used to indicate OS support for PRM. Update the definition of the PRM support bit in the code to match the specification. Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1] Fixes: 60faa8f1ac6e ("ACPI: Add \_SB._OSC bit for PRM") Signed-off-by: Aubrey Li [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki --- include/linux/acpi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index a618ba698a5c..81786864566c 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -551,8 +551,8 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context); #define OSC_SB_OSLPI_SUPPORT 0x00000100 #define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000 #define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000 -#define OSC_SB_PRM_SUPPORT 0x00020000 #define OSC_SB_NATIVE_USB4_SUPPORT 0x00040000 +#define OSC_SB_PRM_SUPPORT 0x00200000 extern bool osc_sb_apei_support_acked; extern bool osc_pc_lpi_support_confirmed; -- cgit v1.2.3 From 392ed6a789803fbfd49994e95fe99cd07b07eb87 Mon Sep 17 00:00:00 2001 From: Aubrey Li Date: Fri, 2 Jul 2021 15:03:50 +0800 Subject: ACPI: Do not singal PRM support if not enabled If the OS confirms PRM (Platform Runtime Mechanism) support through the \_SB._OSC PRM bit, the BIOS may start relying on the presence of PRM support in the OS, so prevent the PRM bit from being set in the \_SB._OSC capabilities bitmask when PRM support is not built in so as to avoid confusing the BIOS in that case. Fixes: 60faa8f1ac6e ("ACPI: Add \_SB._OSC bit for PRM") Signed-off-by: Aubrey Li [ rjw: Rewrite subject and changelog, replace #ifdef with if (IS_ENABLED()) ] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/bus.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index e8119a9eca28..cba00f079eb4 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -305,7 +305,8 @@ static void acpi_bus_osc_negotiate_platform_control(void) capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_OST_SUPPORT; capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT; - capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PRM_SUPPORT; + if (IS_ENABLED(CONFIG_ACPI_PRMT)) + capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PRM_SUPPORT; #ifdef CONFIG_ARM64 capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_GENERIC_INITIATOR_SUPPORT; -- cgit v1.2.3