[PATCH v5 0/4] amd_pmc: Delay s2idle suspend for some devices

[PATCH v5 0/4] amd_pmc: Delay s2idle suspend for some devices

[Daniel Gibson]

On some AMD Zen3 and Zen3+-based Lenovo IdeaPad laptops the keyboard and
the lid switch stop working after the first suspend, until rebooted.

More specifically, they stop sending events when pressing a key or
closing the lid - it's still possible to toggle the capslock- and
numlock-LEDs with an external keyboard or read the lid state at
/proc/acpi/button/lid/LID/state.

See also https://bugzilla.kernel.org/show_bug.cgi?id=221383

It appears that suspending and/or resuming gets the EC into a broken
state. This problem doesn't happen on Windows and Mario Limonciello
mentioned that the Windows kernel gives hardware and software some time
before actually suspending (before activating HW DRIPS), while Linux
(or the amd_pmc module) does that immediately, so it may be worth trying
if calling msleep() in amd_pmc_s2idle_check() helps.

It turned out that sleeping for 2.5 seconds at that point indeed makes
the problems mostly disappear. Sleeping for 1.5 seconds wasn't enough.

"Mostly" because it turned out that they still occur (on some but not
all devices needing this patch) when using a wakeup timer (wakealarm).

I could build on an existing quirk[1] that also sleeps for 2.5 seconds
under other circumstances; my first commit refactors that a bit so I
can integrate my further changes in a cleaner way.

I found several reports of these or similar issues on the web, for
different devices, so in a second commit I added a parameter to the
kernel module that allows enabling or disabling this, which will make
it easy for people whose devices aren't matched yet to test this quirk.

Thanks to Mario Limonciello for his support and to Sindre Henriksen for
testing my patch and to Ilpo Järvinen and Hans de Goede for reviewing!

[1] https://lore.kernel.org/platform-driver-x86/20250414162446.3853194-1-superm1@kernel.org/

Changes in v5:
- Re-add missing first commit ("Check for intermediate wakeup in function")
  (sorry!)
- Add Reviewed-By tags for Hans de Goede's review

Changes in v4 ():
- Don't log during intermediate wakes, which happen a lot when charging
  those IdeaPads while they're suspended, so dmesg isn't spammed
- Removed the documentation commits to make merging this less painful
  (one of them referred to commits added here, so the IDs would have to
   be fixed up while merging). I'll submit them separately.

Changes in v3 (https://lore.kernel.org/platform-driver-x86/20260512202645.1549111-1-daniel@gibson.sh/T/#u
    and https://lore.kernel.org/platform-driver-x86/20260603031110.345815-1-daniel@gibson.sh/T/#u):
- Rewrote commit messages of patch 1, 4 and 5 as requested in the review
- Adjusted formatting of the other commit messages
- Added another confirmed device (83MM) to the quirks list and mention
  it in the commit message

Changes in v2 (https://lore.kernel.org/platform-driver-x86/20260509013105.816339-1-daniel@gibson.sh/t/#u):
- Documented this in Documentation/arch/x86/amd-debugging.rst
- Added example for reset register kernel message in same file
- In amd_pmc_quirk_need_suspend_delay(), avoid dereferencing a NULL
  pointer of devices not detected for any quirk - oops!
- Mention that timed resumes may still cause those keyboard/lid issues
- Various code changes requested or suggested in reviews of v1:
  - Some formatting changes (commas behind non-terminating entries)
  - Moved check for existing quirk (that OVP thing) into its own function
    amd_pmc_intermediate_wakeup_need_delay() in pmc.c, so the checks of
    the different quirks are separated more clearly.
  - Added function amd_pmc_want_suspend_delay() in pmc.c handling
    amd_pmc_quirk_need_suspend_delay() together with disable_workarounds
    and delay_suspend and also logging about the reason for the delay,
    also for cleaner separation.
  - If delay_suspend=1 is used to force-enable the fix on hardware that
    is not automatically detected as needing this fix, log message
    encouraging the user to report their device, including the most
    relevant DMI values that could be used for matching

v1: https://lore.kernel.org/platform-driver-x86/20260501032655.283789-1-daniel@gibson.sh/t/#u

Daniel Gibson (4):
  platform/x86/amd/pmc: Check for intermediate wakeup in function
  platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops
  platform/x86/amd/pmc: Add delay_suspend module parameter
  platform/x86/amd/pmc: Don't log during intermediate wakeups

 drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++
 drivers/platform/x86/amd/pmc/pmc.c        | 83 ++++++++++++++++++++++-
 drivers/platform/x86/amd/pmc/pmc.h        |  2 +
 3 files changed, 121 insertions(+), 3 deletions(-)

-- 
2.48.1

[PATCH v5 1/4] platform/x86/amd/pmc: Check for intermediate wakeup in function

[Daniel Gibson]

Refactor code introduced by commit 9f5595d5f03f ("pmc: Require at
least 2.5 seconds between HW sleep cycles") to allow adding different
conditions for that delay in an upcoming change.

Signed-off-by: Daniel Gibson <daniel@gibson.sh>
Cc: stable@vger.kernel.org
---
 drivers/platform/x86/amd/pmc/pmc.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index cae3fcafd4d7..2b9e5730170a 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -598,6 +598,19 @@ static int amd_pmc_verify_czn_rtc(struct amd_pmc_dev *pdev, u32 *arg)
 	return rc;
 }
 
+static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
+{
+	/*
+	 * Starting a new HW sleep cycle right after waking from one
+	 * can cause electrical problems triggering the over voltage protection.
+	 * That is avoided by delaying the next suspend a bit, see also
+	 * https://lore.kernel.org/all/20250414162446.3853194-1-superm1@kernel.org/
+	 */
+	struct smu_metrics table;
+
+	return get_metrics_table(pdev, &table) == 0 && table.s0i3_last_entry_status;
+}
+
 static void amd_pmc_s2idle_prepare(void)
 {
 	struct amd_pmc_dev *pdev = &pmc;
@@ -632,11 +645,9 @@ static void amd_pmc_s2idle_prepare(void)
 static void amd_pmc_s2idle_check(void)
 {
 	struct amd_pmc_dev *pdev = &pmc;
-	struct smu_metrics table;
 	int rc;
 
-	/* Avoid triggering OVP */
-	if (!get_metrics_table(pdev, &table) && table.s0i3_last_entry_status)
+	if (amd_pmc_intermediate_wakeup_need_delay(pdev))
 		msleep(2500);
 
 	/* Dump the IdleMask before we add to the STB */
-- 
2.48.1

[PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Daniel Gibson]

Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
nonfunctional keyboard and lid switch after s2idle.

It helps to delay suspend by 2.5 seconds so the EC has some time
to do whatever it needs to get done before suspend - unfortunately
at least on my 16ABR8 waking it with a timer (wakealarm) still
triggers the issue, but at least normal resume via keypress or
lid works fine. On the 14ARP10 wakealarm has been reported to also
work fine with this patch.

This issue has been reported for many different devices, this patch
has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
15ARP10 (83MM).

Reported-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Tested-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
Suggested-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Daniel Gibson <daniel@gibson.sh>
Cc: stable@vger.kernel.org
---
 drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++++++
 drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
 drivers/platform/x86/amd/pmc/pmc.h        |  1 +
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
index 24506e342943..74ddf1d8289a 100644
--- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
+++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
@@ -18,6 +18,7 @@
 struct quirk_entry {
 	u32 s2idle_bug_mmio;
 	bool spurious_8042;
+	bool need_suspend_delay;
 };
 
 static struct quirk_entry quirk_s2idle_bug = {
@@ -33,6 +34,10 @@ static struct quirk_entry quirk_s2idle_spurious_8042 = {
 	.spurious_8042 = true,
 };
 
+static struct quirk_entry quirk_s2idle_need_suspend_delay = {
+	.need_suspend_delay = true,
+};
+
 static const struct dmi_system_id fwbug_list[] = {
 	{
 		.ident = "L14 Gen2 AMD",
@@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
 		}
 	},
+	/* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
+	{
+		.ident = "Zen3-based IdeaPad Slim and similar",
+		.driver_data = &quirk_s2idle_need_suspend_delay,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			/*
+			 * Note: there are also some Zen2-based 82X* devices that
+			 * need different quirks, they're already handled above
+			 */
+			DMI_MATCH(DMI_PRODUCT_NAME, "82X"),
+		}
+	},
+	{
+		.ident = "Zen3+-based IdeaPad Slim and similar",
+		.driver_data = &quirk_s2idle_need_suspend_delay,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83K"),
+		}
+	},
+	{
+		.ident = "IdeaPad Slim 3 15ARP10 (83MM)",
+		.driver_data = &quirk_s2idle_need_suspend_delay,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83MM"),
+		}
+	},
 	/* https://bugzilla.kernel.org/show_bug.cgi?id=221273 */
 	{
 		.ident = "Thinkpad L14 Gen3",
@@ -356,6 +390,11 @@ void amd_pmc_process_restore_quirks(struct amd_pmc_dev *dev)
 		amd_pmc_skip_nvme_smi_handler(dev->quirks->s2idle_bug_mmio);
 }
 
+bool amd_pmc_quirk_need_suspend_delay(struct amd_pmc_dev *dev)
+{
+	return dev->quirks && dev->quirks->need_suspend_delay;
+}
+
 void amd_pmc_quirks_init(struct amd_pmc_dev *dev)
 {
 	const struct dmi_system_id *dmi_id;
diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index 2b9e5730170a..6bafd8661d68 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -611,6 +611,27 @@ static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
 	return get_metrics_table(pdev, &table) == 0 && table.s0i3_last_entry_status;
 }
 
+static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
+{
+	/*
+	 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
+	 * me-time before sleeping or they get uncooperative after waking
+	 * up and don't send events for keyboard and lid switch anymore.
+	 *
+	 * Unfortunately this doesn't entirely fix the problem: It can still
+	 * happen when resuming with a timer (wakealarm), but at least the
+	 * more common usecases (wakeup by opening lid or pressing a key)
+	 * work fine with this workaround.
+	 *
+	 * See https://bugzilla.kernel.org/show_bug.cgi?id=221383
+	 */
+	if (!disable_workarounds && amd_pmc_quirk_need_suspend_delay(pdev)) {
+		dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
+		return true;
+	}
+	return false;
+}
+
 static void amd_pmc_s2idle_prepare(void)
 {
 	struct amd_pmc_dev *pdev = &pmc;
@@ -647,7 +668,8 @@ static void amd_pmc_s2idle_check(void)
 	struct amd_pmc_dev *pdev = &pmc;
 	int rc;
 
-	if (amd_pmc_intermediate_wakeup_need_delay(pdev))
+	if (amd_pmc_intermediate_wakeup_need_delay(pdev) ||
+	    amd_pmc_want_suspend_delay(pdev))
 		msleep(2500);
 
 	/* Dump the IdleMask before we add to the STB */
diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
index fe3f53eb5955..f5257e47b8c4 100644
--- a/drivers/platform/x86/amd/pmc/pmc.h
+++ b/drivers/platform/x86/amd/pmc/pmc.h
@@ -147,6 +147,7 @@ enum amd_pmc_def {
 };
 
 void amd_pmc_process_restore_quirks(struct amd_pmc_dev *dev);
+bool amd_pmc_quirk_need_suspend_delay(struct amd_pmc_dev *dev);
 void amd_pmc_quirks_init(struct amd_pmc_dev *dev);
 void amd_mp2_stb_init(struct amd_pmc_dev *dev);
 void amd_mp2_stb_deinit(struct amd_pmc_dev *dev);
-- 
2.48.1

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 6402 bytes --]

On Tue, 9 Jun 2026, Daniel Gibson wrote:

> Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
> nonfunctional keyboard and lid switch after s2idle.
> 
> It helps to delay suspend by 2.5 seconds so the EC has some time
> to do whatever it needs to get done before suspend - unfortunately
> at least on my 16ABR8 waking it with a timer (wakealarm) still
> triggers the issue, but at least normal resume via keypress or
> lid works fine. On the 14ARP10 wakealarm has been reported to also
> work fine with this patch.
> 
> This issue has been reported for many different devices, this patch
> has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
> and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
> 15ARP10 (83MM).
> 
> Reported-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
> Tested-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
> Suggested-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
> Cc: stable@vger.kernel.org
> ---
>  drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++++++
>  drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
>  drivers/platform/x86/amd/pmc/pmc.h        |  1 +
>  3 files changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
> index 24506e342943..74ddf1d8289a 100644
> --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
> +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
> @@ -18,6 +18,7 @@
>  struct quirk_entry {
>  	u32 s2idle_bug_mmio;
>  	bool spurious_8042;
> +	bool need_suspend_delay;
>  };
>  
>  static struct quirk_entry quirk_s2idle_bug = {
> @@ -33,6 +34,10 @@ static struct quirk_entry quirk_s2idle_spurious_8042 = {
>  	.spurious_8042 = true,
>  };
>  
> +static struct quirk_entry quirk_s2idle_need_suspend_delay = {
> +	.need_suspend_delay = true,
> +};
> +
>  static const struct dmi_system_id fwbug_list[] = {
>  	{
>  		.ident = "L14 Gen2 AMD",
> @@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
>  			DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
>  		}
>  	},
> +	/* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
> +	{
> +		.ident = "Zen3-based IdeaPad Slim and similar",
> +		.driver_data = &quirk_s2idle_need_suspend_delay,

Hi,

One more question.

Sashiko noted, that amd_pmc_quirks_init() can overwrite 
disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data 
provides quirks. Is it okay in this case to not have .spurious_8042?

-- 
 i.

> +		.matches = {
> +			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> +			/*
> +			 * Note: there are also some Zen2-based 82X* devices that
> +			 * need different quirks, they're already handled above
> +			 */
> +			DMI_MATCH(DMI_PRODUCT_NAME, "82X"),
> +		}
> +	},
> +	{
> +		.ident = "Zen3+-based IdeaPad Slim and similar",
> +		.driver_data = &quirk_s2idle_need_suspend_delay,
> +		.matches = {
> +			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "83K"),
> +		}
> +	},
> +	{
> +		.ident = "IdeaPad Slim 3 15ARP10 (83MM)",
> +		.driver_data = &quirk_s2idle_need_suspend_delay,
> +		.matches = {
> +			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "83MM"),
> +		}
> +	},
>  	/* https://bugzilla.kernel.org/show_bug.cgi?id=221273 */
>  	{
>  		.ident = "Thinkpad L14 Gen3",
> @@ -356,6 +390,11 @@ void amd_pmc_process_restore_quirks(struct amd_pmc_dev *dev)
>  		amd_pmc_skip_nvme_smi_handler(dev->quirks->s2idle_bug_mmio);
>  }
>  
> +bool amd_pmc_quirk_need_suspend_delay(struct amd_pmc_dev *dev)
> +{
> +	return dev->quirks && dev->quirks->need_suspend_delay;
> +}
> +
>  void amd_pmc_quirks_init(struct amd_pmc_dev *dev)
>  {
>  	const struct dmi_system_id *dmi_id;
> diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
> index 2b9e5730170a..6bafd8661d68 100644
> --- a/drivers/platform/x86/amd/pmc/pmc.c
> +++ b/drivers/platform/x86/amd/pmc/pmc.c
> @@ -611,6 +611,27 @@ static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
>  	return get_metrics_table(pdev, &table) == 0 && table.s0i3_last_entry_status;
>  }
>  
> +static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
> +{
> +	/*
> +	 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
> +	 * me-time before sleeping or they get uncooperative after waking
> +	 * up and don't send events for keyboard and lid switch anymore.
> +	 *
> +	 * Unfortunately this doesn't entirely fix the problem: It can still
> +	 * happen when resuming with a timer (wakealarm), but at least the
> +	 * more common usecases (wakeup by opening lid or pressing a key)
> +	 * work fine with this workaround.
> +	 *
> +	 * See https://bugzilla.kernel.org/show_bug.cgi?id=221383
> +	 */
> +	if (!disable_workarounds && amd_pmc_quirk_need_suspend_delay(pdev)) {
> +		dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
> +		return true;
> +	}
> +	return false;
> +}
> +
>  static void amd_pmc_s2idle_prepare(void)
>  {
>  	struct amd_pmc_dev *pdev = &pmc;
> @@ -647,7 +668,8 @@ static void amd_pmc_s2idle_check(void)
>  	struct amd_pmc_dev *pdev = &pmc;
>  	int rc;
>  
> -	if (amd_pmc_intermediate_wakeup_need_delay(pdev))
> +	if (amd_pmc_intermediate_wakeup_need_delay(pdev) ||
> +	    amd_pmc_want_suspend_delay(pdev))
>  		msleep(2500);
>  
>  	/* Dump the IdleMask before we add to the STB */
> diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
> index fe3f53eb5955..f5257e47b8c4 100644
> --- a/drivers/platform/x86/amd/pmc/pmc.h
> +++ b/drivers/platform/x86/amd/pmc/pmc.h
> @@ -147,6 +147,7 @@ enum amd_pmc_def {
>  };
>  
>  void amd_pmc_process_restore_quirks(struct amd_pmc_dev *dev);
> +bool amd_pmc_quirk_need_suspend_delay(struct amd_pmc_dev *dev);
>  void amd_pmc_quirks_init(struct amd_pmc_dev *dev);
>  void amd_mp2_stb_init(struct amd_pmc_dev *dev);
>  void amd_mp2_stb_deinit(struct amd_pmc_dev *dev);
> 

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Daniel Gibson]

On 09.06.26 13:46, Ilpo Järvinen wrote:
> On Tue, 9 Jun 2026, Daniel Gibson wrote:
> 
>> Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
>> nonfunctional keyboard and lid switch after s2idle.
>>
>> It helps to delay suspend by 2.5 seconds so the EC has some time
>> to do whatever it needs to get done before suspend - unfortunately
>> at least on my 16ABR8 waking it with a timer (wakealarm) still
>> triggers the issue, but at least normal resume via keypress or
>> lid works fine. On the 14ARP10 wakealarm has been reported to also
>> work fine with this patch.
>>
>> This issue has been reported for many different devices, this patch
>> has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
>> and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
>> 15ARP10 (83MM).
>>
>> Reported-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
>> Tested-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>> Suggested-by: Mario Limonciello (AMD) <superm1@kernel.org>
>> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
>> Cc: stable@vger.kernel.org
>> ---
>>  drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++++++
>>  drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
>>  drivers/platform/x86/amd/pmc/pmc.h        |  1 +
>>  3 files changed, 63 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>> index 24506e342943..74ddf1d8289a 100644
>> --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
>> +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>> @@ -18,6 +18,7 @@
>>  struct quirk_entry {
>>  	u32 s2idle_bug_mmio;
>>  	bool spurious_8042;
>> +	bool need_suspend_delay;
>>  };
>>  
>>  static struct quirk_entry quirk_s2idle_bug = {
>> @@ -33,6 +34,10 @@ static struct quirk_entry quirk_s2idle_spurious_8042 = {
>>  	.spurious_8042 = true,
>>  };
>>  
>> +static struct quirk_entry quirk_s2idle_need_suspend_delay = {
>> +	.need_suspend_delay = true,
>> +};
>> +
>>  static const struct dmi_system_id fwbug_list[] = {
>>  	{
>>  		.ident = "L14 Gen2 AMD",
>> @@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
>>  			DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
>>  		}
>>  	},
>> +	/* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>> +	{
>> +		.ident = "Zen3-based IdeaPad Slim and similar",
>> +		.driver_data = &quirk_s2idle_need_suspend_delay,
> 
> Hi,
> 
> One more question.
> 
> Sashiko noted, that amd_pmc_quirks_init() can overwrite 
> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data 
> provides quirks. Is it okay in this case to not have .spurious_8042?
> 

Good question.
So far I haven't had complaints that sounded like they'd be related to
this quirk not being active.

(The only report about things not working as expected on detected
devices was something about "ACPI event storms" after resume:
https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
else with similar devices could reproduce that, so no idea what's going
on there, and it doesn't sound like that IRQ1 issue)

I can test if explicitly enabling .spurious_8042 in
quirk_s2idle_need_suspend_delay breaks anything on my device, if you
think that enabling it by default makes more sense?

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Mario Limonciello]

On 6/9/26 07:07, Daniel Gibson wrote:
> On 09.06.26 13:46, Ilpo Järvinen wrote:
>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>
>>> Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
>>> nonfunctional keyboard and lid switch after s2idle.
>>>
>>> It helps to delay suspend by 2.5 seconds so the EC has some time
>>> to do whatever it needs to get done before suspend - unfortunately
>>> at least on my 16ABR8 waking it with a timer (wakealarm) still
>>> triggers the issue, but at least normal resume via keypress or
>>> lid works fine. On the 14ARP10 wakealarm has been reported to also
>>> work fine with this patch.
>>>
>>> This issue has been reported for many different devices, this patch
>>> has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
>>> and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
>>> 15ARP10 (83MM).
>>>
>>> Reported-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
>>> Tested-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>>> Suggested-by: Mario Limonciello (AMD) <superm1@kernel.org>
>>> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
>>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>>> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
>>> Cc: stable@vger.kernel.org
>>> ---
>>>   drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++++++
>>>   drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
>>>   drivers/platform/x86/amd/pmc/pmc.h        |  1 +
>>>   3 files changed, 63 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>> index 24506e342943..74ddf1d8289a 100644
>>> --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>> +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>> @@ -18,6 +18,7 @@
>>>   struct quirk_entry {
>>>   	u32 s2idle_bug_mmio;
>>>   	bool spurious_8042;
>>> +	bool need_suspend_delay;
>>>   };
>>>   
>>>   static struct quirk_entry quirk_s2idle_bug = {
>>> @@ -33,6 +34,10 @@ static struct quirk_entry quirk_s2idle_spurious_8042 = {
>>>   	.spurious_8042 = true,
>>>   };
>>>   
>>> +static struct quirk_entry quirk_s2idle_need_suspend_delay = {
>>> +	.need_suspend_delay = true,
>>> +};
>>> +
>>>   static const struct dmi_system_id fwbug_list[] = {
>>>   	{
>>>   		.ident = "L14 Gen2 AMD",
>>> @@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
>>>   			DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
>>>   		}
>>>   	},
>>> +	/* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>> +	{
>>> +		.ident = "Zen3-based IdeaPad Slim and similar",
>>> +		.driver_data = &quirk_s2idle_need_suspend_delay,
>>
>> Hi,
>>
>> One more question.
>>
>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>
> 
> Good question.
> So far I haven't had complaints that sounded like they'd be related to
> this quirk not being active.
> 
> (The only report about things not working as expected on detected
> devices was something about "ACPI event storms" after resume:
> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
> else with similar devices could reproduce that, so no idea what's going
> on there, and it doesn't sound like that IRQ1 issue)
> 
> I can test if explicitly enabling .spurious_8042 in
> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
> think that enabling it by default makes more sense?

Famous last words - but we haven't had a need for spurious 8042 on 
recent hardware so I think this is unlikely to be a big problem.

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Daniel Gibson]

On 09.06.26 16:40, Mario Limonciello wrote:
> On 6/9/26 07:07, Daniel Gibson wrote:
>> On 09.06.26 13:46, Ilpo Järvinen wrote:
>>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>>
>>>> Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
>>>> nonfunctional keyboard and lid switch after s2idle.
>>>>
>>>> It helps to delay suspend by 2.5 seconds so the EC has some time
>>>> to do whatever it needs to get done before suspend - unfortunately
>>>> at least on my 16ABR8 waking it with a timer (wakealarm) still
>>>> triggers the issue, but at least normal resume via keypress or
>>>> lid works fine. On the 14ARP10 wakealarm has been reported to also
>>>> work fine with this patch.
>>>>
>>>> This issue has been reported for many different devices, this patch
>>>> has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
>>>> and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
>>>> 15ARP10 (83MM).
>>>>
>>>> Reported-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
>>>> Tested-by: Sindre Henriksen <sindrehenriksen93@gmail.com>
>>>> Suggested-by: Mario Limonciello (AMD) <superm1@kernel.org>
>>>> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
>>>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>>> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>>>> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
>>>> Cc: stable@vger.kernel.org
>>>> ---
>>>>   drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++
>>>> ++++
>>>>   drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
>>>>   drivers/platform/x86/amd/pmc/pmc.h        |  1 +
>>>>   3 files changed, 63 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/
>>>> platform/x86/amd/pmc/pmc-quirks.c
>>>> index 24506e342943..74ddf1d8289a 100644
>>>> --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>>> +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>>> @@ -18,6 +18,7 @@
>>>>   struct quirk_entry {
>>>>       u32 s2idle_bug_mmio;
>>>>       bool spurious_8042;
>>>> +    bool need_suspend_delay;
>>>>   };
>>>>     static struct quirk_entry quirk_s2idle_bug = {
>>>> @@ -33,6 +34,10 @@ static struct quirk_entry
>>>> quirk_s2idle_spurious_8042 = {
>>>>       .spurious_8042 = true,
>>>>   };
>>>>   +static struct quirk_entry quirk_s2idle_need_suspend_delay = {
>>>> +    .need_suspend_delay = true,
>>>> +};
>>>> +
>>>>   static const struct dmi_system_id fwbug_list[] = {
>>>>       {
>>>>           .ident = "L14 Gen2 AMD",
>>>> @@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
>>>>               DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
>>>>           }
>>>>       },
>>>> +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>>> +    {
>>>> +        .ident = "Zen3-based IdeaPad Slim and similar",
>>>> +        .driver_data = &quirk_s2idle_need_suspend_delay,
>>>
>>> Hi,
>>>
>>> One more question.
>>>
>>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>>
>>
>> Good question.
>> So far I haven't had complaints that sounded like they'd be related to
>> this quirk not being active.
>>
>> (The only report about things not working as expected on detected
>> devices was something about "ACPI event storms" after resume:
>> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
>> else with similar devices could reproduce that, so no idea what's going
>> on there, and it doesn't sound like that IRQ1 issue)
>>
>> I can test if explicitly enabling .spurious_8042 in
>> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
>> think that enabling it by default makes more sense?
> 
> Famous last words - but we haven't had a need for spurious 8042 on
> recent hardware so I think this is unlikely to be a big problem.

FWIW enabling .spurious_8042 didn't break anything on my machine, but
didn't improve anything either - only visible difference is that when
resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
reported as having triggered the resume, and with the quirk only IRQ7 is
reported. But it didn't seem like IRQ1 triggers a resume when it shouldn't.

OTOH I have a the latest BIOS (from this year), so it's likely fixed
there - maybe people with older BIOS versions still need the
.spurious_8042 quirk?

As these devices are relatively recent and still sold I hope that
everyone affected can get a new BIOS (which they should do either way).

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Daniel Gibson]

On 09.06.26 17:06, Daniel Gibson wrote:
> On 09.06.26 16:40, Mario Limonciello wrote:
>> On 6/9/26 07:07, Daniel Gibson wrote:
>>> On 09.06.26 13:46, Ilpo Järvinen wrote:
>>>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>>>>       },
>>>>> +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>>>> +    {
>>>>> +        .ident = "Zen3-based IdeaPad Slim and similar",
>>>>> +        .driver_data = &quirk_s2idle_need_suspend_delay,
>>>>
>>>> Hi,
>>>>
>>>> One more question.
>>>>
>>>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>>>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>>>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>>>
>>>
>>> Good question.
>>> So far I haven't had complaints that sounded like they'd be related to
>>> this quirk not being active.
>>>
>>> (The only report about things not working as expected on detected
>>> devices was something about "ACPI event storms" after resume:
>>> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
>>> else with similar devices could reproduce that, so no idea what's going
>>> on there, and it doesn't sound like that IRQ1 issue)
>>>
>>> I can test if explicitly enabling .spurious_8042 in
>>> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
>>> think that enabling it by default makes more sense?
>>
>> Famous last words - but we haven't had a need for spurious 8042 on
>> recent hardware so I think this is unlikely to be a big problem.
> 
> FWIW enabling .spurious_8042 didn't break anything on my machine, but
> didn't improve anything either - only visible difference is that when
> resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
> reported as having triggered the resume, and with the quirk only IRQ7 is
> reported. But it didn't seem like IRQ1 triggers a resume when it shouldn't.
> 
> OTOH I have a the latest BIOS (from this year), so it's likely fixed
> there - maybe people with older BIOS versions still need the
> .spurious_8042 quirk?
> 
> As these devices are relatively recent and still sold I hope that
> everyone affected can get a new BIOS (which they should do either way).

Anyway, overall I'd say that the patches can be merged as they are - the
affected devices are known to have serious (-ly annoying) suspend
issues, so it's unlikely that a currently matched devices has working
suspend that breaks with them, so things at least shouldn't get any
worse for their users?

The patches have gotten some testing already on different devices (from
my out-of-tree patched amd_pmc module on Github) and so far it looks
like the spurious_8042 quirk isn't needed.
If reports of needing both quirks turn up after all, that can still be
easily added in a few lines of code (maybe even just one).

Cheers,
Daniel

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Mario Limonciello]

On 6/9/26 10:36, Daniel Gibson wrote:
> On 09.06.26 17:06, Daniel Gibson wrote:
>> On 09.06.26 16:40, Mario Limonciello wrote:
>>> On 6/9/26 07:07, Daniel Gibson wrote:
>>>> On 09.06.26 13:46, Ilpo Järvinen wrote:
>>>>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>>>>>        },
>>>>>> +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>>>>> +    {
>>>>>> +        .ident = "Zen3-based IdeaPad Slim and similar",
>>>>>> +        .driver_data = &quirk_s2idle_need_suspend_delay,
>>>>>
>>>>> Hi,
>>>>>
>>>>> One more question.
>>>>>
>>>>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>>>>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>>>>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>>>>
>>>>
>>>> Good question.
>>>> So far I haven't had complaints that sounded like they'd be related to
>>>> this quirk not being active.
>>>>
>>>> (The only report about things not working as expected on detected
>>>> devices was something about "ACPI event storms" after resume:
>>>> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
>>>> else with similar devices could reproduce that, so no idea what's going
>>>> on there, and it doesn't sound like that IRQ1 issue)
>>>>
>>>> I can test if explicitly enabling .spurious_8042 in
>>>> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
>>>> think that enabling it by default makes more sense?
>>>
>>> Famous last words - but we haven't had a need for spurious 8042 on
>>> recent hardware so I think this is unlikely to be a big problem.
>>
>> FWIW enabling .spurious_8042 didn't break anything on my machine, but
>> didn't improve anything either - only visible difference is that when
>> resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
>> reported as having triggered the resume, and with the quirk only IRQ7 is
>> reported. But it didn't seem like IRQ1 triggers a resume when it shouldn't.
>>
>> OTOH I have a the latest BIOS (from this year), so it's likely fixed
>> there - maybe people with older BIOS versions still need the
>> .spurious_8042 quirk?
>>
>> As these devices are relatively recent and still sold I hope that
>> everyone affected can get a new BIOS (which they should do either way).
> 
> Anyway, overall I'd say that the patches can be merged as they are - the
> affected devices are known to have serious (-ly annoying) suspend
> issues, so it's unlikely that a currently matched devices has working
> suspend that breaks with them, so things at least shouldn't get any
> worse for their users?
> 
> The patches have gotten some testing already on different devices (from
> my out-of-tree patched amd_pmc module on Github) and so far it looks
> like the spurious_8042 quirk isn't needed.
> If reports of needing both quirks turn up after all, that can still be
> easily added in a few lines of code (maybe even just one).
> 
> Cheers,
> Daniel

Even with all that testing; it's only on hardware with problems.
We don't want to have issues exposed by these patches for people that 
didn't need the patches.

So my 2c:
* It's "too risky" to pick up for 7.1 final
* It's a "bit late" in the cycle for 7.2-rc1 (usually new content stops 
being added around rc6).
* This isn't "risky enough" to wait until 7.3 (basically after 7.2-rc1 
merge window is done)

But this has been on the list for a while now, so I would say this makes 
sense to put in for 7.2-rc1 and we should all make sure we test well 
once the RCs are posted.

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 5025 bytes --]

On Tue, 9 Jun 2026, Mario Limonciello wrote:
> On 6/9/26 10:36, Daniel Gibson wrote:
> > On 09.06.26 17:06, Daniel Gibson wrote:
> > > On 09.06.26 16:40, Mario Limonciello wrote:
> > > > On 6/9/26 07:07, Daniel Gibson wrote:
> > > > > On 09.06.26 13:46, Ilpo Järvinen wrote:
> > > > > > On Tue, 9 Jun 2026, Daniel Gibson wrote:
> > > > > > >        },
> > > > > > > +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
> > > > > > > +    {
> > > > > > > +        .ident = "Zen3-based IdeaPad Slim and similar",
> > > > > > > +        .driver_data = &quirk_s2idle_need_suspend_delay,
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > One more question.
> > > > > > 
> > > > > > Sashiko noted, that amd_pmc_quirks_init() can overwrite
> > > > > > disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
> > > > > > provides quirks. Is it okay in this case to not have .spurious_8042?
> > > > > > 
> > > > > 
> > > > > Good question.
> > > > > So far I haven't had complaints that sounded like they'd be related to
> > > > > this quirk not being active.
> > > > > 
> > > > > (The only report about things not working as expected on detected
> > > > > devices was something about "ACPI event storms" after resume:
> > > > > https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
> > > > > else with similar devices could reproduce that, so no idea what's
> > > > > going
> > > > > on there, and it doesn't sound like that IRQ1 issue)
> > > > > 
> > > > > I can test if explicitly enabling .spurious_8042 in
> > > > > quirk_s2idle_need_suspend_delay breaks anything on my device, if you
> > > > > think that enabling it by default makes more sense?
> > > > 
> > > > Famous last words - but we haven't had a need for spurious 8042 on
> > > > recent hardware so I think this is unlikely to be a big problem.
> > > 
> > > FWIW enabling .spurious_8042 didn't break anything on my machine, but
> > > didn't improve anything either - only visible difference is that when
> > > resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
> > > reported as having triggered the resume, and with the quirk only IRQ7 is
> > > reported. But it didn't seem like IRQ1 triggers a resume when it
> > > shouldn't.
> > > 
> > > OTOH I have a the latest BIOS (from this year), so it's likely fixed
> > > there - maybe people with older BIOS versions still need the
> > > .spurious_8042 quirk?
> > > 
> > > As these devices are relatively recent and still sold I hope that
> > > everyone affected can get a new BIOS (which they should do either way).
> > 
> > Anyway, overall I'd say that the patches can be merged as they are - the
> > affected devices are known to have serious (-ly annoying) suspend
> > issues, so it's unlikely that a currently matched devices has working
> > suspend that breaks with them, so things at least shouldn't get any
> > worse for their users?
> > 
> > The patches have gotten some testing already on different devices (from
> > my out-of-tree patched amd_pmc module on Github) and so far it looks
> > like the spurious_8042 quirk isn't needed.
> > If reports of needing both quirks turn up after all, that can still be
> > easily added in a few lines of code (maybe even just one).
> > 
> > Cheers,
> > Daniel
> 
> Even with all that testing; it's only on hardware with problems.
> We don't want to have issues exposed by these patches for people that didn't
> need the patches.
> 
> So my 2c:
> * It's "too risky" to pick up for 7.1 final

Definitely it won't be happening.

Also, Linus effectively only allows regression fixes during -rc phase 
anymore (he stated his policy change around -rc5 timeframe). I therefore 
moved even some of queued new HW support patches from the pdx86 fixes 
branch into for-next.

> * It's a "bit late" in the cycle for 7.2-rc1 (usually new content stops being
> added around rc6).

I usually only stop accepting large series around that time, with some
exceptions. (We've one such exception ATM because I was a week away and 
couldn't process patches, it would feel unfair to penalize other devs 
because of that so for the series which have been around for awhile, I 
still try to process them during this week, this one included).

> * This isn't "risky enough" to wait until 7.3 (basically after 7.2-rc1 merge
> window is done)
> 
> But this has been on the list for a while now, so I would say this makes sense
> to put in for 7.2-rc1 and we should all make sure we test well once the RCs
> are posted.

My plan is to take this into for-next during this cycle.

We can always take a timeout and revert it during -rc phase if problems 
appear because of it (and even after 7.2 release, if situation requires 
it).

I'm not convinced testing pre rc1 really covers much when it comes to 
platform drivers, those few people testing linux-next, as valuable as they 
are, cannot really cover that much HW diversity.

-- 
 i.

Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Mario Limonciello]

On 6/10/26 03:21, Ilpo Järvinen wrote:
> On Tue, 9 Jun 2026, Mario Limonciello wrote:
>> On 6/9/26 10:36, Daniel Gibson wrote:
>>> On 09.06.26 17:06, Daniel Gibson wrote:
>>>> On 09.06.26 16:40, Mario Limonciello wrote:
>>>>> On 6/9/26 07:07, Daniel Gibson wrote:
>>>>>> On 09.06.26 13:46, Ilpo Järvinen wrote:
>>>>>>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>>>>>>>         },
>>>>>>>> +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>>>>>>> +    {
>>>>>>>> +        .ident = "Zen3-based IdeaPad Slim and similar",
>>>>>>>> +        .driver_data = &quirk_s2idle_need_suspend_delay,
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> One more question.
>>>>>>>
>>>>>>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>>>>>>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>>>>>>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>>>>>>
>>>>>>
>>>>>> Good question.
>>>>>> So far I haven't had complaints that sounded like they'd be related to
>>>>>> this quirk not being active.
>>>>>>
>>>>>> (The only report about things not working as expected on detected
>>>>>> devices was something about "ACPI event storms" after resume:
>>>>>> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
>>>>>> else with similar devices could reproduce that, so no idea what's
>>>>>> going
>>>>>> on there, and it doesn't sound like that IRQ1 issue)
>>>>>>
>>>>>> I can test if explicitly enabling .spurious_8042 in
>>>>>> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
>>>>>> think that enabling it by default makes more sense?
>>>>>
>>>>> Famous last words - but we haven't had a need for spurious 8042 on
>>>>> recent hardware so I think this is unlikely to be a big problem.
>>>>
>>>> FWIW enabling .spurious_8042 didn't break anything on my machine, but
>>>> didn't improve anything either - only visible difference is that when
>>>> resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
>>>> reported as having triggered the resume, and with the quirk only IRQ7 is
>>>> reported. But it didn't seem like IRQ1 triggers a resume when it
>>>> shouldn't.
>>>>
>>>> OTOH I have a the latest BIOS (from this year), so it's likely fixed
>>>> there - maybe people with older BIOS versions still need the
>>>> .spurious_8042 quirk?
>>>>
>>>> As these devices are relatively recent and still sold I hope that
>>>> everyone affected can get a new BIOS (which they should do either way).
>>>
>>> Anyway, overall I'd say that the patches can be merged as they are - the
>>> affected devices are known to have serious (-ly annoying) suspend
>>> issues, so it's unlikely that a currently matched devices has working
>>> suspend that breaks with them, so things at least shouldn't get any
>>> worse for their users?
>>>
>>> The patches have gotten some testing already on different devices (from
>>> my out-of-tree patched amd_pmc module on Github) and so far it looks
>>> like the spurious_8042 quirk isn't needed.
>>> If reports of needing both quirks turn up after all, that can still be
>>> easily added in a few lines of code (maybe even just one).
>>>
>>> Cheers,
>>> Daniel
>>
>> Even with all that testing; it's only on hardware with problems.
>> We don't want to have issues exposed by these patches for people that didn't
>> need the patches.
>>
>> So my 2c:
>> * It's "too risky" to pick up for 7.1 final
> 
> Definitely it won't be happening.
> 
> Also, Linus effectively only allows regression fixes during -rc phase
> anymore (he stated his policy change around -rc5 timeframe). I therefore
> moved even some of queued new HW support patches from the pdx86 fixes
> branch into for-next.
> 
>> * It's a "bit late" in the cycle for 7.2-rc1 (usually new content stops being
>> added around rc6).
> 
> I usually only stop accepting large series around that time, with some
> exceptions. (We've one such exception ATM because I was a week away and
> couldn't process patches, it would feel unfair to penalize other devs
> because of that so for the series which have been around for awhile, I
> still try to process them during this week, this one included).
> 
>> * This isn't "risky enough" to wait until 7.3 (basically after 7.2-rc1 merge
>> window is done)
>>
>> But this has been on the list for a while now, so I would say this makes sense
>> to put in for 7.2-rc1 and we should all make sure we test well once the RCs
>> are posted.
> 
> My plan is to take this into for-next during this cycle.
> 
> We can always take a timeout and revert it during -rc phase if problems
> appear because of it (and even after 7.2 release, if situation requires
> it).

Sounds good to me, thanks.

[PATCH v5 3/4] platform/x86/amd/pmc: Add delay_suspend module parameter

[Daniel Gibson]

Enabling the new delay_suspend module parameter delays suspend for
2.5 seconds which is known to help for some AMD-based Lenovo Laptops
that otherwise failed to send/receive events for key presses or the
lid switch after s2idle. Apparently the EC needs to do some things
in the background before suspend or it gets into a bad state.

There are many reports of AMD-based laptops (mostly but not exclusively
IdeaPads) about similar issues on the web; this parameter gives
affected users an easy way to try out if their issues have the same
root cause and to work around them until their specific device is added
to the quirks list.

The parameter description has a note encouraging users to report
their device so it can be added to the quirks list, inspired by a
similar request in parameter descriptions of the ideapad-laptop module.

The module parameter can be set to "1" to explicitly enable it,
"0" to disable it even on devices that are assumed to be affected,
or -1 (the default) to enable it if the device is assumed to be affected
(according to fwbug_list[])

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Daniel Gibson <daniel@gibson.sh>
Cc: stable@vger.kernel.org
---
 drivers/platform/x86/amd/pmc/pmc.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index 6bafd8661d68..2d3d180c15d2 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -16,6 +16,7 @@
 #include <linux/bits.h>
 #include <linux/debugfs.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/limits.h>
@@ -89,6 +90,11 @@ static bool disable_workarounds;
 module_param(disable_workarounds, bool, 0644);
 MODULE_PARM_DESC(disable_workarounds, "Disable workarounds for platform bugs");
 
+static int delay_suspend = -1;
+module_param(delay_suspend, int, 0644);
+MODULE_PARM_DESC(delay_suspend,
+		 "Delays s2idle by 2.5 seconds to work around buggy ECs, often causing keyboard issues after suspend. 0: don't delay, 1: do delay, -1 (default): let amd_pmc decide. If you need this please report this to: platform-driver-x86@vger.kernel.org");
+
 static struct amd_pmc_dev pmc;
 
 static inline u32 amd_pmc_reg_read(struct amd_pmc_dev *dev, int reg_offset)
@@ -625,8 +631,23 @@ static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
 	 *
 	 * See https://bugzilla.kernel.org/show_bug.cgi?id=221383
 	 */
-	if (!disable_workarounds && amd_pmc_quirk_need_suspend_delay(pdev)) {
-		dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
+	if (amd_pmc_quirk_need_suspend_delay(pdev)) {
+		/*
+		 * delay_suspend=1 force-enables this, otherwise it can be
+		 * disabled with disable_workarounds or delay_suspend=0
+		 */
+		if (delay_suspend == 1 || (delay_suspend == -1 && !disable_workarounds)) {
+			dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
+			return true;
+		}
+		dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
+	} else if (delay_suspend == 1) {
+		dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
+			 dmi_get_system_info(DMI_SYS_VENDOR),
+			 dmi_get_system_info(DMI_PRODUCT_NAME),
+			 dmi_get_system_info(DMI_PRODUCT_FAMILY),
+			 dmi_get_system_info(DMI_BOARD_VENDOR),
+			 dmi_get_system_info(DMI_BOARD_NAME));
 		return true;
 	}
 	return false;
-- 
2.48.1

[PATCH v5 4/4] platform/x86/amd/pmc: Don't log during intermediate wakeups

[Daniel Gibson]

The ECs in the IdeaPads that need the delay_suspend quirk send lots
of messages when charging, which not only causes intermediate wakeups
when suspended, but also prevents the device from reaching the deepest
suspend state.

Because of this amd_pmc_intermediate_wakeup_need_delay() returns false
during intermediate wakeups and amd_pmc_want_suspend_delay() is called.
So far it always logged its "Delaying suspend by 2.5s ..." messages
then, which spams dmesg. This commit makes sure that those messages are
only logged once per suspend.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Daniel Gibson <daniel@gibson.sh>
Cc: stable@vger.kernel.org
---
 drivers/platform/x86/amd/pmc/pmc.c | 39 ++++++++++++++++++++++++------
 drivers/platform/x86/amd/pmc/pmc.h |  1 +
 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index 2d3d180c15d2..7d772ccd17a6 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -619,6 +619,20 @@ static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
 
 static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
 {
+	/*
+	 * intermediate_wakeup implies that the machine didn't get to deepest sleep
+	 * state before - otherwise this function isn't called in amd_pmc_s2idle_check()
+	 * because amd_pmc_intermediate_wakeup_need_delay() returns true first.
+	 * On some IdeaPads that happens when charging, because the EC seems
+	 * to send lots of messages then that wake the machine.
+	 *
+	 * But even in that case, the sleep here is necessary (on those IdeaPads),
+	 * otherwise they wake up completely (resume) after a few seconds.
+	 * So this variable is only used to avoid spamming dmesg on each
+	 * intermediate wakeup.
+	 */
+	bool intermediate_wakeup = !pdev->is_first_check_after_suspend;
+
 	/*
 	 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
 	 * me-time before sleeping or they get uncooperative after waking
@@ -637,17 +651,20 @@ static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
 		 * disabled with disable_workarounds or delay_suspend=0
 		 */
 		if (delay_suspend == 1 || (delay_suspend == -1 && !disable_workarounds)) {
-			dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
+			if (!intermediate_wakeup)
+				dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
 			return true;
 		}
-		dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
+		if (!intermediate_wakeup)
+			dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
 	} else if (delay_suspend == 1) {
-		dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
-			 dmi_get_system_info(DMI_SYS_VENDOR),
-			 dmi_get_system_info(DMI_PRODUCT_NAME),
-			 dmi_get_system_info(DMI_PRODUCT_FAMILY),
-			 dmi_get_system_info(DMI_BOARD_VENDOR),
-			 dmi_get_system_info(DMI_BOARD_NAME));
+		if (!intermediate_wakeup)
+			dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
+				 dmi_get_system_info(DMI_SYS_VENDOR),
+				 dmi_get_system_info(DMI_PRODUCT_NAME),
+				 dmi_get_system_info(DMI_PRODUCT_FAMILY),
+				 dmi_get_system_info(DMI_BOARD_VENDOR),
+				 dmi_get_system_info(DMI_BOARD_NAME));
 		return true;
 	}
 	return false;
@@ -660,6 +677,9 @@ static void amd_pmc_s2idle_prepare(void)
 	u8 msg;
 	u32 arg = 1;
 
+	/* Reset this variable because this is a fresh suspend */
+	pdev->is_first_check_after_suspend = true;
+
 	/* Reset and Start SMU logging - to monitor the s0i3 stats */
 	amd_pmc_setup_smu_logging(pdev);
 
@@ -699,6 +719,9 @@ static void amd_pmc_s2idle_check(void)
 	rc = amd_stb_write(pdev, AMD_PMC_STB_S2IDLE_CHECK);
 	if (rc)
 		dev_err(pdev->dev, "error writing to STB: %d\n", rc);
+
+	/* remember that first check after suspend is done (until next prepare) */
+	pdev->is_first_check_after_suspend = false;
 }
 
 static int amd_pmc_dump_data(struct amd_pmc_dev *pdev)
diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
index f5257e47b8c4..8aa7073ed09f 100644
--- a/drivers/platform/x86/amd/pmc/pmc.h
+++ b/drivers/platform/x86/amd/pmc/pmc.h
@@ -114,6 +114,7 @@ struct amd_pmc_dev {
 	struct dentry *dbgfs_dir;
 	struct quirk_entry *quirks;
 	bool disable_8042_wakeup;
+	bool is_first_check_after_suspend;
 	struct amd_mp2_dev *mp2;
 	struct stb_arg stb_arg;
 };
-- 
2.48.1

Re: [PATCH v5 4/4] platform/x86/amd/pmc: Don't log during intermediate wakeups

[Ilpo Järvinen]

On Tue, 9 Jun 2026, Daniel Gibson wrote:

> The ECs in the IdeaPads that need the delay_suspend quirk send lots
> of messages when charging, which not only causes intermediate wakeups
> when suspended, but also prevents the device from reaching the deepest
> suspend state.
> 
> Because of this amd_pmc_intermediate_wakeup_need_delay() returns false
> during intermediate wakeups and amd_pmc_want_suspend_delay() is called.
> So far it always logged its "Delaying suspend by 2.5s ..." messages
> then, which spams dmesg. This commit makes sure that those messages are
> only logged once per suspend.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
> Cc: stable@vger.kernel.org
> ---
>  drivers/platform/x86/amd/pmc/pmc.c | 39 ++++++++++++++++++++++++------
>  drivers/platform/x86/amd/pmc/pmc.h |  1 +
>  2 files changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
> index 2d3d180c15d2..7d772ccd17a6 100644
> --- a/drivers/platform/x86/amd/pmc/pmc.c
> +++ b/drivers/platform/x86/amd/pmc/pmc.c
> @@ -619,6 +619,20 @@ static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
>  
>  static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
>  {
> +	/*
> +	 * intermediate_wakeup implies that the machine didn't get to deepest sleep
> +	 * state before - otherwise this function isn't called in amd_pmc_s2idle_check()
> +	 * because amd_pmc_intermediate_wakeup_need_delay() returns true first.
> +	 * On some IdeaPads that happens when charging, because the EC seems
> +	 * to send lots of messages then that wake the machine.
> +	 *
> +	 * But even in that case, the sleep here is necessary (on those IdeaPads),
> +	 * otherwise they wake up completely (resume) after a few seconds.
> +	 * So this variable is only used to avoid spamming dmesg on each
> +	 * intermediate wakeup.
> +	 */
> +	bool intermediate_wakeup = !pdev->is_first_check_after_suspend;
> +
>  	/*
>  	 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
>  	 * me-time before sleeping or they get uncooperative after waking
> @@ -637,17 +651,20 @@ static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
>  		 * disabled with disable_workarounds or delay_suspend=0
>  		 */
>  		if (delay_suspend == 1 || (delay_suspend == -1 && !disable_workarounds)) {
> -			dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
> +			if (!intermediate_wakeup)
> +				dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
>  			return true;
>  		}
> -		dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
> +		if (!intermediate_wakeup)
> +			dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
>  	} else if (delay_suspend == 1) {
> -		dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
> -			 dmi_get_system_info(DMI_SYS_VENDOR),
> -			 dmi_get_system_info(DMI_PRODUCT_NAME),
> -			 dmi_get_system_info(DMI_PRODUCT_FAMILY),
> -			 dmi_get_system_info(DMI_BOARD_VENDOR),
> -			 dmi_get_system_info(DMI_BOARD_NAME));
> +		if (!intermediate_wakeup)
> +			dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
> +				 dmi_get_system_info(DMI_SYS_VENDOR),
> +				 dmi_get_system_info(DMI_PRODUCT_NAME),
> +				 dmi_get_system_info(DMI_PRODUCT_FAMILY),
> +				 dmi_get_system_info(DMI_BOARD_VENDOR),
> +				 dmi_get_system_info(DMI_BOARD_NAME));
>  		return true;
>  	}
>  	return false;
> @@ -660,6 +677,9 @@ static void amd_pmc_s2idle_prepare(void)
>  	u8 msg;
>  	u32 arg = 1;
>  
> +	/* Reset this variable because this is a fresh suspend */
> +	pdev->is_first_check_after_suspend = true;
> +
>  	/* Reset and Start SMU logging - to monitor the s0i3 stats */
>  	amd_pmc_setup_smu_logging(pdev);
>  
> @@ -699,6 +719,9 @@ static void amd_pmc_s2idle_check(void)
>  	rc = amd_stb_write(pdev, AMD_PMC_STB_S2IDLE_CHECK);
>  	if (rc)
>  		dev_err(pdev->dev, "error writing to STB: %d\n", rc);
> +
> +	/* remember that first check after suspend is done (until next prepare) */
> +	pdev->is_first_check_after_suspend = false;
>  }
>  
>  static int amd_pmc_dump_data(struct amd_pmc_dev *pdev)
> diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
> index f5257e47b8c4..8aa7073ed09f 100644
> --- a/drivers/platform/x86/amd/pmc/pmc.h
> +++ b/drivers/platform/x86/amd/pmc/pmc.h
> @@ -114,6 +114,7 @@ struct amd_pmc_dev {
>  	struct dentry *dbgfs_dir;
>  	struct quirk_entry *quirks;
>  	bool disable_8042_wakeup;
> +	bool is_first_check_after_suspend;
>  	struct amd_mp2_dev *mp2;
>  	struct stb_arg stb_arg;
>  };
> 

Hi,

This fails to apply to the review-ilpo-next branch and I don't want to 
spend time at this point to figure it out so please send v6 which is 
based on the for-next or review-ilpo-next branch:

Applying: platform/x86/amd/pmc: Check for intermediate wakeup in function
Applying: platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops
Applying: platform/x86/amd/pmc: Add delay_suspend module parameter
Applying: platform/x86/amd/pmc: Don't log during intermediate wakeups
error: patch failed: drivers/platform/x86/amd/pmc/pmc.c:660
error: drivers/platform/x86/amd/pmc/pmc.c: patch does not apply
error: patch failed: drivers/platform/x86/amd/pmc/pmc.h:114
error: drivers/platform/x86/amd/pmc/pmc.h: patch does not apply
Patch failed at 0004 platform/x86/amd/pmc: Don't log during intermediate wakeups


-- 
 i.

Re: [PATCH v5 4/4] platform/x86/amd/pmc: Don't log during intermediate wakeups

[Daniel Gibson]

On 11.06.26 16:02, Ilpo Järvinen wrote:
> On Tue, 9 Jun 2026, Daniel Gibson wrote:
> 
>> The ECs in the IdeaPads that need the delay_suspend quirk send lots
>> of messages when charging, which not only causes intermediate wakeups
>> when suspended, but also prevents the device from reaching the deepest
>> suspend state.
>>
>> Because of this amd_pmc_intermediate_wakeup_need_delay() returns false
>> during intermediate wakeups and amd_pmc_want_suspend_delay() is called.
>> So far it always logged its "Delaying suspend by 2.5s ..." messages
>> then, which spams dmesg. This commit makes sure that those messages are
>> only logged once per suspend.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
>> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>> Signed-off-by: Daniel Gibson <daniel@gibson.sh>
>> Cc: stable@vger.kernel.org
>> ---
>>  drivers/platform/x86/amd/pmc/pmc.c | 39 ++++++++++++++++++++++++------
>>  drivers/platform/x86/amd/pmc/pmc.h |  1 +
>>  2 files changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
>> index 2d3d180c15d2..7d772ccd17a6 100644
>> --- a/drivers/platform/x86/amd/pmc/pmc.c
>> +++ b/drivers/platform/x86/amd/pmc/pmc.c
>> @@ -619,6 +619,20 @@ static bool amd_pmc_intermediate_wakeup_need_delay(struct amd_pmc_dev *pdev)
>>  
>>  static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
>>  {
>> +	/*
>> +	 * intermediate_wakeup implies that the machine didn't get to deepest sleep
>> +	 * state before - otherwise this function isn't called in amd_pmc_s2idle_check()
>> +	 * because amd_pmc_intermediate_wakeup_need_delay() returns true first.
>> +	 * On some IdeaPads that happens when charging, because the EC seems
>> +	 * to send lots of messages then that wake the machine.
>> +	 *
>> +	 * But even in that case, the sleep here is necessary (on those IdeaPads),
>> +	 * otherwise they wake up completely (resume) after a few seconds.
>> +	 * So this variable is only used to avoid spamming dmesg on each
>> +	 * intermediate wakeup.
>> +	 */
>> +	bool intermediate_wakeup = !pdev->is_first_check_after_suspend;
>> +
>>  	/*
>>  	 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
>>  	 * me-time before sleeping or they get uncooperative after waking
>> @@ -637,17 +651,20 @@ static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
>>  		 * disabled with disable_workarounds or delay_suspend=0
>>  		 */
>>  		if (delay_suspend == 1 || (delay_suspend == -1 && !disable_workarounds)) {
>> -			dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
>> +			if (!intermediate_wakeup)
>> +				dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
>>  			return true;
>>  		}
>> -		dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
>> +		if (!intermediate_wakeup)
>> +			dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
>>  	} else if (delay_suspend == 1) {
>> -		dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>> -			 dmi_get_system_info(DMI_SYS_VENDOR),
>> -			 dmi_get_system_info(DMI_PRODUCT_NAME),
>> -			 dmi_get_system_info(DMI_PRODUCT_FAMILY),
>> -			 dmi_get_system_info(DMI_BOARD_VENDOR),
>> -			 dmi_get_system_info(DMI_BOARD_NAME));
>> +		if (!intermediate_wakeup)
>> +			dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@vger.kernel.org so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>> +				 dmi_get_system_info(DMI_SYS_VENDOR),
>> +				 dmi_get_system_info(DMI_PRODUCT_NAME),
>> +				 dmi_get_system_info(DMI_PRODUCT_FAMILY),
>> +				 dmi_get_system_info(DMI_BOARD_VENDOR),
>> +				 dmi_get_system_info(DMI_BOARD_NAME));
>>  		return true;
>>  	}
>>  	return false;
>> @@ -660,6 +677,9 @@ static void amd_pmc_s2idle_prepare(void)
>>  	u8 msg;
>>  	u32 arg = 1;
>>  
>> +	/* Reset this variable because this is a fresh suspend */
>> +	pdev->is_first_check_after_suspend = true;
>> +
>>  	/* Reset and Start SMU logging - to monitor the s0i3 stats */
>>  	amd_pmc_setup_smu_logging(pdev);
>>  
>> @@ -699,6 +719,9 @@ static void amd_pmc_s2idle_check(void)
>>  	rc = amd_stb_write(pdev, AMD_PMC_STB_S2IDLE_CHECK);
>>  	if (rc)
>>  		dev_err(pdev->dev, "error writing to STB: %d\n", rc);
>> +
>> +	/* remember that first check after suspend is done (until next prepare) */
>> +	pdev->is_first_check_after_suspend = false;
>>  }
>>  
>>  static int amd_pmc_dump_data(struct amd_pmc_dev *pdev)
>> diff --git a/drivers/platform/x86/amd/pmc/pmc.h b/drivers/platform/x86/amd/pmc/pmc.h
>> index f5257e47b8c4..8aa7073ed09f 100644
>> --- a/drivers/platform/x86/amd/pmc/pmc.h
>> +++ b/drivers/platform/x86/amd/pmc/pmc.h
>> @@ -114,6 +114,7 @@ struct amd_pmc_dev {
>>  	struct dentry *dbgfs_dir;
>>  	struct quirk_entry *quirks;
>>  	bool disable_8042_wakeup;
>> +	bool is_first_check_after_suspend;
>>  	struct amd_mp2_dev *mp2;
>>  	struct stb_arg stb_arg;
>>  };
>>
> 
> Hi,
> 
> This fails to apply to the review-ilpo-next branch and I don't want to 
> spend time at this point to figure it out so please send v6 which is 
> based on the for-next or review-ilpo-next branch:
> 
> Applying: platform/x86/amd/pmc: Check for intermediate wakeup in function
> Applying: platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops
> Applying: platform/x86/amd/pmc: Add delay_suspend module parameter
> Applying: platform/x86/amd/pmc: Don't log during intermediate wakeups
> error: patch failed: drivers/platform/x86/amd/pmc/pmc.c:660
> error: drivers/platform/x86/amd/pmc/pmc.c: patch does not apply
> error: patch failed: drivers/platform/x86/amd/pmc/pmc.h:114
> error: drivers/platform/x86/amd/pmc/pmc.h: patch does not apply
> Patch failed at 0004 platform/x86/amd/pmc: Don't log during intermediate wakeups
> 
> 

Hi,

is the review-ilpo-next branch on
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/?h=review-ilpo-next
up-to-date?
I checked it out and cherry-picked my patches from my original branch
and all applied without conflicts, so I wonder if I'm missing commits
introducing conflicts.