[BUG] mt7921e: HIF_CTRL timeout after S3 resume on MT7922

[Hedi Hamida]

Hardware:
  03:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI
  Express Wireless Network Adapter [14c3:7922]
  Subsystem: AzureWave Device [1a3b:5916]
  Driver: mt7921e (mt76)

Kernel: 6.12.113+deb13-amd64 (Debian 13)

Firmware tested:
  20241106163310  (Debian firmware-misc-nonfree 20250410-2)
  20260724143402  (current linux-firmware, 2026-07-24)

Problem:
After suspend-to-RAM (S3), resume fails:

  Oct 24 09:43:17 kernel: PM: suspend entry (deep)
  Oct 24 09:46:11 kernel: mt7921e 0000:03:00.0: Message 00020007 (seq
13) timeout
  Oct 24 09:46:11 kernel: mt7921e 0000:03:00.0: PM:
dpm_run_callback(): pci_pm_resume returns -110
  Oct 24 09:46:11 kernel: mt7921e 0000:03:00.0: PM: failed to resume
async: error -110

00020007 is MCU_UNI_CMD(HIF_CTRL), sent by
mt76_connac_mcu_set_hif_suspend(mdev, false, true).

What I tested:
1. wait_resp=true: the command times out as above. The driver then
   calls mt792x_reset() and Wi-Fi recovers, but the PM core reports
   the resume as failed.
2. MT7925-style event handling: I added a handler for
   MCU_UNI_EVENT_HIF_CTRL and sent the resume command with
   wait_resp=false. No event is received at all.
3. wait_resp=false and no event wait: the card is left unusable.
   It reinitializes/reset but never reassociates:

     Oct 24 11:01:17 kernel: PM: suspend entry (deep)
     Oct 24 11:02:11 kernel: mt7921e 0000:03:00.0: HIF resume sent
without waiting
     Oct 24 11:02:11 kernel: mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10 ...
     Oct 24 11:02:11 kernel: PM: suspend exit
     Oct 24 11:02:28 kernel: wlp3s0: authentication with ... timed out
     ...

   Only a reset recovers it.

4. S4/hibernate: the same HIF handshake is not used. A .restore
   callback that skips it and resets the device works reliably.

The latest linux-firmware 20260724143402 behaves exactly like the
2024 firmware: no response, no event.

Question:
Is MT7922 firmware supposed to answer HIF_CTRL after D3, or send
MCU_UNI_EVENT_HIF_CTRL? If a different resume sequence is required,
what should the driver do instead of resetting? Is this fixable in
firmware?

Workaround under review (reset on timeout):
  https://patchwork.kernel.org/series/1192671/

I can provide full dmesg logs or test patches if useful.

Thanks,
Hedi Ben Hamida