--- /dev/null
+From 1d66e379731f79ae5039a869c0fde22a4f6a6a91 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 13 Oct 2022 08:47:29 -0500
+Subject: pinctrl: amd: Add dynamic debugging for active GPIOs
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 1d66e379731f79ae5039a869c0fde22a4f6a6a91 upstream.
+
+Some laptops have been reported to wake up from s2idle when plugging
+in the AC adapter or by closing the lid. This is a surprising
+behavior that is further clarified by commit cb3e7d624c3ff ("PM:
+wakeup: Add extra debugging statement for multiple active IRQs").
+
+With that commit in place the following interaction can be seen
+when the lid is closed:
+
+[ 28.946038] PM: suspend-to-idle
+[ 28.946083] ACPI: EC: ACPI EC GPE status set
+[ 28.946101] ACPI: PM: Rearming ACPI SCI for wakeup
+[ 28.950152] Timekeeping suspended for 3.320 seconds
+[ 28.950152] PM: Triggering wakeup from IRQ 9
+[ 28.950152] ACPI: EC: ACPI EC GPE status set
+[ 28.950152] ACPI: EC: ACPI EC GPE dispatched
+[ 28.995057] ACPI: EC: ACPI EC work flushed
+[ 28.995075] ACPI: PM: Rearming ACPI SCI for wakeup
+[ 28.995131] PM: Triggering wakeup from IRQ 9
+[ 28.995271] ACPI: EC: ACPI EC GPE status set
+[ 28.995291] ACPI: EC: ACPI EC GPE dispatched
+[ 29.098556] ACPI: EC: ACPI EC work flushed
+[ 29.207020] ACPI: EC: ACPI EC work flushed
+[ 29.207037] ACPI: PM: Rearming ACPI SCI for wakeup
+[ 29.211095] Timekeeping suspended for 0.739 seconds
+[ 29.211095] PM: Triggering wakeup from IRQ 9
+[ 29.211079] PM: Triggering wakeup from IRQ 7
+[ 29.211095] ACPI: PM: ACPI non-EC GPE wakeup
+[ 29.211095] PM: resume from suspend-to-idle
+
+* IRQ9 on this laptop is used for the ACPI SCI.
+* IRQ7 on this laptop is used for the GPIO controller.
+
+What has occurred is when the lid was closed the EC woke up the
+SoC from it's deepest sleep state and the kernel's s2idle loop
+processed all EC events. When it was finished processing EC events,
+it checked for any other reasons to wake (break the s2idle loop).
+
+The IRQ for the GPIO controller was active so the loop broke, and
+then this IRQ was processed. This is not a kernel bug but it is
+certainly a surprising behavior, and to better debug it we should
+have a dynamic debugging message that we can enact to catch it.
+
+Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
+Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Acked-by: Mark Pearson <markpearson@lenovo.com>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://lore.kernel.org/r/20221013134729.5592-2-mario.limonciello@amd.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/pinctrl-amd.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-amd.c
++++ b/drivers/pinctrl/pinctrl-amd.c
+@@ -627,13 +627,15 @@ static bool do_amd_gpio_irq_handler(int
+ /* Each status bit covers four pins */
+ for (i = 0; i < 4; i++) {
+ regval = readl(regs + i);
+- /* caused wake on resume context for shared IRQ */
+- if (irq < 0 && (regval & BIT(WAKE_STS_OFF))) {
++
++ if (regval & PIN_IRQ_PENDING)
+ dev_dbg(&gpio_dev->pdev->dev,
+- "Waking due to GPIO %d: 0x%x",
++ "GPIO %d is active: 0x%x",
+ irqnr + i, regval);
++
++ /* caused wake on resume context for shared IRQ */
++ if (irq < 0 && (regval & BIT(WAKE_STS_OFF)))
+ return true;
+- }
+
+ if (!(regval & PIN_IRQ_PENDING) ||
+ !(regval & BIT(INTERRUPT_MASK_OFF)))