mt7925e: endpoint keeps a stale zero-latency LTR after s2idle resume, blocks package C6/C10 (Panther Lake laptop)

[Claudio Gratton]

Hi,

I may have found a resume issue with the MT7925 PCIe Wi-Fi card
(mt7925e) on a Panther Lake laptop. I am not sure whether the driver,
the firmware or the platform is at fault, so I'm asking here first.
Everything below is marked either "measured" or "guess".

Hardware / software
- HP OmniBook 7 14-hg0xxx, Core Ultra X7 358H (Panther Lake), Wi-Fi/BT
MT7925, mt7925e at 0000:2c:00.0, root port 0000:00:1c.0
- Reproduced on Arch linux 7.2.3.arch1-3 and on linux-omarchy 7.2.5-3
(Arch config plus patches). Not tested on a vanilla mainline kernel.

Symptom (measured)
- Fresh boot: the PMC LTR table (/sys/kernel/debug/pmc_core/ltr_show)
shows SOUTHPORT_B = 0x0 and the package reaches PC10 at idle.
- After the first s2idle resume in a boot, SOUTHPORT_B reads
0x80008000 (valid, zero latency) and stays there. The package then
stays in PC2 (PC6/PC10 residency 0%) although everything else is idle.
- Idle power on battery is roughly 0.5 W higher while it is stuck
(about 3.1-3.6 W vs 2.0-3.1 W, screen on). I also changed other things
in the same period (a Bluetooth autosuspend workaround), so treat the
0.5 W as approximate. With "echo 1 > ltr_ignore" the package reaches
PC10 again.

Why I think it is this Wi-Fi card (measured)
- Unloading mt7925e changes SOUTHPORT_B to a constant 0x88418841.
- Toggling the Wi-Fi radio (rfkill), NVMe I/O bursts and an empty USB4
port do not change it.

State across the resume (measured, one suspend cycle, "systemctl suspend")
- Before suspend: SOUTHPORT_B = 0x0.
- Immediately after resume, before any userspace hook: SOUTHPORT_B = 0x80008000.
- Endpoint 2c:00.0 stays in D0; DevCtl2 = 0x0409 (LTR Mechanism Enable
set) and the LTR capability max snoop/no-snoop latency 0x100f/0x100f
are identical before and after.
- Root port 00:1c.0: DevCtl2 = 0x0400 and LnkCtl = 0x0c43, unchanged.
- No kernel messages from mt7925e or PCI during the resume.

Workaround that fixes it (measured)
- About 6 s after resume, clear and re-set DevCtl2 bit 10 (LTR
Mechanism Enable) on the endpoint, 0.3 s apart:
setpci -s 2c:00.0 CAP_EXP+0x28.w=<old & ~0x0400>; sleep 0.3; setpci -s
2c:00.0 CAP_EXP+0x28.w=<old>
The endpoint then sends a fresh LTR message, SOUTHPORT_B returns to
0x0 and PC10 residency comes back (about 28% of samples in my run,
idle 1.99 W with the screen on).
- I run it from a systemd-sleep hook as a stop-gap. It has fixed the
state after every resume I have tried, including a repeat this
afternoon.

What I do not know (guess)
- My guess is that the chip or its firmware re-sends a "0 latency" LTR
message at resume and never sends the update. I cannot rule out that
the driver or the platform leaves something unprogrammed; the
unchanged config space only shows that it is not a PCI-level
difference I can see.
- I have not checked whether other MT7925/MT7922 platforms, or
Intel/AMD systems, show the same.

Questions
1. Has anyone seen the same behaviour, and is it known on the firmware side?
2. If it is a driver issue, would re-triggering the LTR message at
resume (as above) be acceptable in mt7925e, or is there a cleaner way?

I can provide full logs, run patches or test firmware versions.

Thanks,
Claudio Gratton