[REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[Olzhas]

Hi Mario,

I am experiencing a regression on my laptop where attempting to power
off the machine results in an immediate reboot instead of a shutdown.

The last known good kernel is v7.1.7, while v7.1.8 is the first known
bad release.

I bisected the regression across 9 kernel builds and identified the
following commit as the first bad commit:

a7c855969b1a ("pinctrl-amd: Don't clear S4 wake bits at probe")

With this commit present, running:

    systemctl poweroff

causes the laptop to power off and then immediately power back on.

I reverted this specific commit on top of v7.3.0-rc3 and the issue is
completely resolved. The laptop now powers off correctly and remains
off.

Hardware:
- Laptop: Chuwi CoreBook Plus 16
- DMI board vendor: Default string
- DMI board name: Default string
- DMI BIOS version: AB8139_S_2C_V00.01_007
- DMI BIOS date: 2025-08-05
- CPU reported by the system: AMD Ryzen 5 7430U with Radeon Graphics
- The CPU/hardware appears to correspond to Ryzen 5 5500U / Lucienne
  silicon, although I am not certain whether this is relevant.

Software:
- Distribution: Arch Linux
- Last known good: v7.1.7
- First known bad: v7.1.8
- Current test kernel: v7.3.0-rc3 with a7c855969b1a reverted

I have verified the fix by booting the reverted kernel and testing
poweroff successfully.

Since the DMI board strings are generic ("Default string"), I would be
happy to provide an ACPI dump, dmesg output, kernel configuration,
bisect log, or perform additional testing if needed.

I suspect this may be related to an S4 wake source left enabled by the
firmware, but I have not identified the exact wake source yet.

Best regards,
Olzhas Marat

#regzbot introduced: a7c855969b1a

Re: [REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[Mario Limonciello]

On 9/20/26 12:00 PM, Olzhas wrote:
> Hi Mario,
> 
> I am experiencing a regression on my laptop where attempting to power
> off the machine results in an immediate reboot instead of a shutdown.
> 
> The last known good kernel is v7.1.7, while v7.1.8 is the first known
> bad release.
> 
> I bisected the regression across 9 kernel builds and identified the
> following commit as the first bad commit:
> 
> a7c855969b1a ("pinctrl-amd: Don't clear S4 wake bits at probe")
> 
> With this commit present, running:
> 
>      systemctl poweroff
> 
> causes the laptop to power off and then immediately power back on.
> 
> I reverted this specific commit on top of v7.3.0-rc3 and the issue is
> completely resolved. The laptop now powers off correctly and remains
> off.
> 
> Hardware:
> - Laptop: Chuwi CoreBook Plus 16
> - DMI board vendor: Default string
> - DMI board name: Default string
> - DMI BIOS version: AB8139_S_2C_V00.01_007
> - DMI BIOS date: 2025-08-05
> - CPU reported by the system: AMD Ryzen 5 7430U with Radeon Graphics
> - The CPU/hardware appears to correspond to Ryzen 5 5500U / Lucienne
>    silicon, although I am not certain whether this is relevant.
> 
> Software:
> - Distribution: Arch Linux
> - Last known good: v7.1.7
> - First known bad: v7.1.8
> - Current test kernel: v7.3.0-rc3 with a7c855969b1a reverted
> 
> I have verified the fix by booting the reverted kernel and testing
> poweroff successfully.
> 
> Since the DMI board strings are generic ("Default string"), I would be
> happy to provide an ACPI dump, dmesg output, kernel configuration,
> bisect log, or perform additional testing if needed.
> 
> I suspect this may be related to an S4 wake source left enabled by the
> firmware, but I have not identified the exact wake source yet.
> 
> Best regards,
> Olzhas Marat
> 
> #regzbot introduced: a7c855969b1a
> 

This is most likely a BIOS bug, but we need to dig into the details to 
understand more and decide what to do.  It could also be a driver bug, 
most likely in a WLAN driver.

Can you please open a kernel bugzilla with the following information:

1) /sys/kernel/debug/gpio without the commit
2) /sys/kernel/debug/gpio with the commit
3) acpidump (just once)
4) amd-s2idle report (this will capture and associate some information 
that will make this easier to triage)

Please CC me into the bug report.

Thanks