[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230121134812.16637-1-mario.limonciello@amd.com>
Date: Sat, 21 Jan 2023 07:48:09 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Raul E Rangel <rrangel@...omium.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"Wolfram Sang" <wsa@...nel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"Mika Westerberg" <mika.westerberg@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
<linux-gpio@...r.kernel.org>, <linux-acpi@...r.kernel.org>
CC: Mario Limonciello <mario.limonciello@....com>,
<linux-kernel@...r.kernel.org>
Subject: [PATCH 0/2] Fix some more fallout from GPIOs from _CRS
Raul's series that let GPIOs be enabled based on ACPI tables
caused some fallout on systems that don't support s2idle.
When systems were suspended they either immediately woke up
or never (appeared) to enter suspend.
This affected at least 2 System76 systems (pang10/pang11) as
well as two Lenovo laptops (X13 G2a/T14 G2a).
Initially the solution was developed as a quirk for these
4 systems, but then it was discovered the systems are ONLY
affected when set to S3 instead of s2idle in BIOS setup.
To fix the regression, don't set wake capable for those GPIOs
unless the system claims to support low power idle in the FADT.
This effectively restores the behavior from before
commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
but only when utilized with S3.
Mario Limonciello (2):
pinctrl: amd: Fix debug output for debounce time
gpiolib-acpi: Don't set GPIOs for wakeup in S3 mode
drivers/gpio/gpiolib-acpi.c | 3 ++-
drivers/pinctrl/pinctrl-amd.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.34.1
Powered by blists - more mailing lists