ath12k: spurious beacon-loss disconnects on WCN7850 (regression in 7.2.6)

[Izzet Beltir]

#regzbot invalid: not a kernel regression - the beacons really are 
missing, and a second client with a different vendor's chipset and 
driver misses them at the same instants

Hi,

I have to retract my report. I am sorry for the noise - my bisection was 
confounded and my conclusion was wrong. Please disregard the regression 
claim; there is no evidence that anything in ath12k changed for the worse.

What I got wrong

I reported that ath12k stops accounting received beacons while the link 
is alive, and that this started with kernel 7.2.6 because 7.2.4 had run 
for 11 days without a single event. I missed that the machine was 
powered off from 2026-09-22 to 2026-10-05. Kernel 7.2.4 therefore never 
ran while the actual trigger was present. The per-day counts I sent are 
real, but the kernel is not what distinguishes them.

What it actually is

A second client on the same AP misses beacons at the same instants: an 
older laptop with an Intel chipset running iwlwifi on an older kernel. 
Cluster boundaries from both machines' journals:

                    old client (iwlwifi)    current client (ath12k)
   cluster 1        16:08:15 - 16:14:42     16:08:27 - 16:13:04
   cluster 2        20:25:46 - 20:36:37     20:26:30 - 20:31:53
   cluster 3        00:41:41 - 00:48:20     00:42:02 - 00:47:14

Two vendors, two drivers, two kernels, same seconds. The iwlwifi side 
logs exactly the condition I measured on the ath12k side:

   iwlwifi 0000:04:00.0: missed beacons exceeds threshold, but receiving 
data.
                         Stay connected, Expect bugs.
   iwlwifi 0000:04:00.0: missed_beacons:19, missed_beacons_since_rx:1

So the beacons genuinely are not arriving, for both clients, and my 
measurement that unicast data keeps flowing at normal latency throughout 
still stands - it just means the AP (or something in the environment) 
stops delivering beacons while continuing to serve data. The clusters 
recur on a free-running ~4h17m period whose phase survives reboots and 
power-off, which also points away from anything on the client. I am now 
investigating the AP, an AVM FRITZ!Box 5690 Pro.

The one thing that may still be of interest

iwlwifi has explicit tolerance for this situation and stays associated 
when beacons are missing but data is being received. ath12k has no such 
tolerance and tears the connection down after the mac80211 timeout, 
costing about 10 s of connectivity each time - in my case 20-28 times a 
day while the environment misbehaves.

I am not reporting that as a bug, and I am not asking for it on the 
strength of one site. But if a similar relaxation is considered 
reasonable for ath12k, it would have turned a visible outage into a 
logged warning here. Happy to test anything in that direction.

Again, sorry for the misdirected report. The measurements in it are 
sound; the conclusion was not.

Regards,
Izzet Beltir