ath12k: WCN7850 fw stats permanently wedge after AP channel switch (v7.1.3, includes 8f153eb74546)

[Mike Garuccio]

Hi,

  On WCN7850, an AP channel switch (CSA) can permanently wedge the
  firmware stats path: after the CSA, every WMI_REQUEST_VDEV_STAT
  request times out with

    ath12k_wifi7_pci 0000:0d:00.0: time out while waiting for fw stats done

  repeating on every request until reboot or driver reload. The data
  path is unaffected (still associated, traffic flows). Because
  ath12k_mac_op_sta_statistics() falls back to the fw stats path exactly
  when the cached rssi_comb is 0 (the post-CSA state), every station
  statistics poll from NetworkManager then blocks ~6s in the driver,
  producing a continuous stream of these messages (~14k/day) and
  D-state polling processes.

  Environment:
  - WCN7850 hw2.0 PCI, chip_id 0x2 chip_family 0x4 board_id 0xff
    soc_id 0x40170200
  - fw_version 0x1103006c fw_build_timestamp 2026-03-06 09:10
    fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c7-00108-
    QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
  - Observed on 7.0.12 and 7.1.3 (distro-built stable kernels,
    CachyOS). I verified v7.1.3 already contains 8f153eb74546
    ("wifi: ath12k: use correct pdev id when requesting firmware
    stats") and 7259b1a0e54c, so the duplicate-reply issue fixed
    there is not the cause here.
  - STA mode, single vdev, 5 GHz.

  Reproducer / correlation: three occurrences over five days, each one
  starting seconds after a CSA from the AP, e.g.:

    Jul 14 03:48:01 wpa_supplicant[1403]: wlan0:
CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=0
ch_width=20 MHz cf1=5765 cf2=0
    Jul 14 03:48:02 wpa_supplicant[1403]: wlan0:
CTRL-EVENT-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=0
ch_width=20 MHz cf1=5765 cf2=0
    Jul 14 03:48:06 kernel: ath12k_wifi7_pci 0000:0d:00.0: time out
while waiting for fw stats done
    (then repeats every ~6s for the remaining 4h20m of that boot)

    Jul 15 00:10:01 wpa_supplicant[1273]: wlan0:
CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=-1
ch_width=80 MHz cf1=5775 cf2=0
    Jul 15 00:10:02 wpa_supplicant[1273]: wlan0:
CTRL-EVENT-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=-1
ch_width=80 MHz cf1=5775 cf2=0
    Jul 15 00:10:10 kernel: ath12k_wifi7_pci 0000:0d:00.0: time out
while waiting for fw stats done
    (then repeats every ~6s for ~23h until I reloaded the module)

  Boots without a CSA never show a single timeout. Uptime before the
  CSA doesn't matter (one wedge happened 40 minutes into a boot, one
  after ~2 days).

  Additional observations:
  - It is always "time out while waiting for fw stats done", never
    "time out while waiting for get fw stats" — i.e. fw_stats_complete
    still fires, firmware is still sending WMI_UPDATE_STATS_EVENTID.
  - The WMI pdev temperature path keeps working while wedged.
  - Recovery: reloading the driver modules recovers immediately.
    From code reading, nothing in the SSR/restart path resets
    ar->fw_stats, so firmware recovery would not clear it.

  Analysis: this looks like ar->fw_stats.num_vdev_recvd getting out of
  sync. In ath12k_wmi_fw_stats_process():

    is_end = ((++ar->fw_stats.num_vdev_recvd) == total_vdevs_started);

  num_vdev_recvd is only zeroed by ath12k_fw_stats_reset(), which
  callers invoke only on the success path, and ath12k_mac_get_fw_stats()
  does not reset it at request start. A CSA is executed as a vdev
  restart; if a stats event is lost/late or arrives while
  num_started_vdevs is transitioning, the request times out (no reset)
  or a stray event increments the counter with no consumer. Either way
  the counter is left non-zero, and since completion requires exact
  equality and the counter only ever increments, no subsequent request
  can ever complete — matching the observed permanent wedge on a kernel
  that already has 8f153eb74546.

  Happy to test patches — the AP in question does a CSA roughly daily,
  so I can usually confirm within a day or two.

  Thanks,
  Mike Garuccio