[Steam Frame] Wake-on-WLAN cannot wake the headset: the WCN7850 firmware only signals in-band PME#, which sm8650 cannot turn into a wake; root cause located, host patch and repro attached

Start with the linked patch series and journals in the theTechGoose/steam-frame-wowlan repository, especially tests/wake-test.sh and firmware/QUALCOMM.md; the issue names ath12k_wmi_wow_enable() and pcie-qcom as kernel entry points. Compare deep and s2idle behavior and review the firmware and stable-kernel asks. Done means WoW wakes the headset reliably, with acceptance-test results and journals covering the relevant configurations.

Your system information

• Device: Steam Frame
• SteamOS: 0.5.7 beta, kernel 7.2.0-g9a8c8ea46950 (Valve commit 9a8c8ea46950). All hardware evidence below is from this kernel and a patched build of the same commit. The stable 0.4.5 image (BUILD_ID 20261022.6150929, kernel 6.18.0-ge66bc2ca6f8c) has a separate, earlier problem noted in ask 3.
• Wi-Fi: ath12k_pci 17cb:1107, WCN7850, firmware WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 (0x110a0012, 2025-08-20), board_77.bin
• Opted into SteamOS beta: yes

Please describe your issue in as much detail as possible:

Developers who SSH into the headset want to leave it asleep and wake it over the LAN, as with any laptop. The radio advertises it (iw phy0 wowlan show lists magic packet, lspci shows PME(D3hot+,D3cold+)), NetworkManager exposes 802-11-wireless.wake-on-wlan, and enabling it is accepted. It never wakes.

I traced it to the end. Everything here is in a repo with the patch series, the test harness, and every journal: https://github.com/theTechGoose/steam-frame-wowlan

What happens, measured on 7.2. The radio survives suspend with WoW armed (clean MHI M3, no reset). The firmware catches the magic packet and reports WOW_REASON_RECV_MAGIC_PATTERN on the next resume. It signals the event with an in-band PME#, and only if ath12k sets WMI_WOW_FLAG_SEND_PM_PME (0x2) in WMI_WOW_ENABLE_CMDID; mainline sends 0. With that one line added, the endpoint's PMCSR PME_Status and the root port's RTSTA PME are both set after the sleep. The WAKE# sideband (tlmm 96, PDC-wakeable) never toggles for the event, in L1ss or in L2, with or without the flag. It goes low only as a reaction to PERST# assertion, and a control run with no packets shows the same.

Why that cannot wake sm8650. The root port's PME interrupt is a GIC ITS MSI. enable_irq_wake() on it fails, and even with the PCI-MSI chip marked IRQCHIP_SKIP_SET_WAKE the sleep ends on the RTC, not the MSI (pm_wakeup_irq_after_last_suspend=143), in deep and in s2idle. No pcie0 interrupt is in the PDC ranges. CLKREQ# (tlmm 95) cannot carry it either: the TLMM sees zero edges while the PCIe controller owns the pad, and muxing the pad to GPIO for the sleep kills the link mid-suspend (the RC drives CLKREQ# to leave L1.2) and leaves Wi-Fi dead until reboot.

Root cause in the firmware. The function its own debug strings call pcie_i_assert_wake selects the wake signal by PERST# level. Verbatim strings: PERST GPIO line is HIGH. Not asserting WAKE#, D3 Hot State, PERST HIGH. Issue PME#, Endpoint assert WAKE# since PERST is LOW. There is no path that asserts WAKE# for a WoW event while PERST# is high, which is exactly the Linux suspend state. The firmware sends the one signal the SoC cannot receive and withholds the one it could. The WAKE# drive (pci_e0_wake) and the flag plumbing (g_pcie_pme_in_d3cold, what 0x2 toggles) already exist in the shipped image, so this is a gating change, not new hardware support. Paste-ready text for a Qualcomm ticket is in the repo at firmware/QUALCOMM.md.

Evidence, from the journals in the repo (logs/wake-handoff-v12-pme-s2idle-20261105-232758.log and logs/clkreq-probe-handoff-233235.log):

wow enable flags 0x2
PMCSR 0x810b (PME_Status SET)          # endpoint 01:00.0
RTSTA 0x00030100 (PME SET)             # root port, requester 01:00
WAKE# disarmed (level 1)               # never toggled low
pm_wakeup_irq_after_last_suspend=143   # the RTC safety alarm, not PME
CLKREQ# probe: 0 edges in 2000 ms      # idle and under a ping flood

Asks

1. Kernel side, landable now: set WMI_WOW_FLAG_SEND_PM_PME in ath12k_wmi_wow_enable(), and register pcie0's existing wake-gpios as a wakeup IRQ in pcie-qcom. Both are in the repo's patch against 9a8c8ea46950, built and run on the device. The second is inert until the firmware pulls the line; together they are the host half of the fix.
2. Firmware side, for Qualcomm: assert WAKE# on a WoW match regardless of PERST# level, or add a WMI flag selecting WAKE# as the carrier. Alternatively the AOP PCIe DRV / L1ss-sleep path (WMI_WOW_FLAG_ENABLE_DRV_PCIE_L1SS_SLEEP, 0x10), which is how Qualcomm phones on this SoC do it.
3. Backport the upstream pci_host_common_d3cold_possible() / skip_pwrctrl_off change to the 6.18 stable kernel, or ship 7.2 to stable. On 6.18 the port powers the radio off in suspend, so WoW cannot even arm. This part is read from the published sources; I did not keep a 6.18 journal because 7.2 already fixes it.
4. Until then, make NetworkManager's wake-on-wlan a no-op or report it unsupported.

I have the Frame on a custom-kernel A/B slot with a boot canary, a scripted acceptance test (tests/wake-test.sh, exit 0 on a magic-packet wake), and a saved baseline for every configuration. Send a firmware image or a driver change and I will return the full deep and s2idle journals within a day.

Steps for reproducing this issue:

1. Developer Mode on, SSH in. nmcli con modify <ssid> 802-11-wireless.wake-on-wlan magic && nmcli con up <ssid>; iw phy0 wowlan show lists magic packet. echo enabled > /sys/bus/pci/devices/0000:01:00.0/power/wakeup.
2. systemctl suspend (default deep, or echo s2idle > /sys/power/mem_sleep first).
3. From another LAN host send magic packets to the Frame's Wi-Fi MAC (broadcast and unicast, UDP 9 and 7) for a minute.
4. The headset does not wake. Press the power button; journalctl -k -b shows the lines above. Scripted: sh tests/wake-test.sh deep in the repo.