ROG Ally: device hangs completely on suspend, never wakes, requires hard power-off

Summary

Putting the device to sleep (via power button tap or Steam power menu) results in a full hang: the kernel logs suspend entry into s2idle and then nothing further is ever logged — no resume, no error. The device does not respond to the power button (short or long press) afterward and requires holding the power button to force a hard shutdown. This is a full suspend/resume failure, not a slow wake or a post-wake input issue (distinct from #2119 and #2124).

System info

• Device: ASUS ROG Ally (RC71L), BIOS RC71L.342 (2025-02-11)
• SteamOS: 3.8.16, build 20260716.1
• Kernel: 6.16.12-valve24.5-1-neptune-616-gb2f7cfe85e45
• Firmware checked via fwupdmgr get-updates: no updates available (already latest known to LVFS)

Steps to reproduce

1. On stable SteamOS 3.8.16, from Gaming Mode, put the device to sleep (single power-button press).
2. Wait 15-30 seconds.
3. Attempt to wake with a power-button press (tried both short and long/~1s press).
4. Device does not wake; screen stays off, no response to any input.
5. Only recovery is a forced hard shutdown (holding power button).

Expected behavior

Device resumes from sleep on power-button press.

Actual behavior

Device hangs indefinitely in suspend and must be hard-power-cycled.

Relevant journal log (previous boot, ends abruptly)

Aug 13 22:17:13 steamdeck PluginLoader[7099]: {'info': 'mobX suspend triggered with true'}
Aug 13 22:17:13 steamdeck PluginLoader[7099]: main#on_suspend started
Aug 13 22:17:13 steamdeck PluginLoader[7099]: main#on_suspend complete
Aug 13 22:17:15 steamdeck systemd-logind[1630]: The system will suspend now!
Aug 13 22:17:15 steamdeck NetworkManager[2262]: manager: sleep: sleep requested (sleeping: no enabled: yes)
Aug 13 22:17:15 steamdeck NetworkManager[2262]: manager: NetworkManager state is now ASLEEP
Aug 13 22:17:15 steamdeck kwin_wayland[4227]: kwin_core: Failed to delay sleep: Sender is not authorized to send message
Aug 13 22:17:15 steamdeck systemd[1]: Reached target Sleep.
Aug 13 22:17:15 steamdeck systemd[1]: Starting System Suspend...
Aug 13 22:17:15 steamdeck systemd-sleep[7645]: Successfully froze unit 'user.slice'.
Aug 13 22:17:15 steamdeck systemd-sleep[7645]: Performing sleep operation 'suspend'...
Aug 13 22:17:15 steamdeck kernel: PM: suspend entry (s2idle)
--- (nothing further logged this boot; device had to be hard power-cycled) ---

Earlier in the same boot, at suspend-path init time:
Aug 13 22:03:52 steamdeck kernel: Low-power S0 idle used by default for system suspend
Aug 13 22:03:54 steamdeck kernel: asus_rog_ally 0003:0B05:1ABE.0005: Disabled wakeup capability on 1-3

journalctl --list-boots confirms the boot simply ends at the suspend-entry timestamp with no resume-side entries, and the next boot (3 minutes later) is a cold boot, not a resume:
-1 04133f0e77d14350a146aae1f0994f05 Thu 2026-08-13 22:03:52 MDT Thu 2026-08-13 22:17:15 MDT
0 72b8f95e0c794257b90c0e162fbeaaed Thu 2026-08-13 22:20:28 MDT ...

Additional notes

• Reproduced with Decky Loader + SimpleDeckyTDP + Ally Center + SteamGridDB plugins installed, but the on_suspend hooks for these completed successfully before the hang, and the hang occurs at the kernel/firmware suspend-entry boundary (PM: suspend entry (s2idle)), past the point where userspace/plugins have any involvement — I don't believe this is plugin-related, but flagging for completeness.
• Possibly related to known ROG Ally s2idle/USB0-hub suspend quirks (asus-wmi: disable USB0 hub before suspend); the mitigation for that appears present in this kernel (Disabled wakeup capability on 1-3 above) but does not prevent this hang.
• Happy to provide a full journalctl -b -1 export or test further reproduction steps if useful.

Start by reproducing the failure on the ASUS ROG Ally with journalctl and inspect the suspend path around the kernel's “PM: suspend entry (s2idle)” message. Compare the asus_rog_ally and asus-wmi USB0-hub wakeup handling noted in the report; done means the device resumes from a power-button suspend instead of requiring a hard shutdown.