[RFC PATCH wireless] wifi: mt76: mt7925: get the survey airtime from the firmware

[Chris]

On Sat, Oct 24, 2026 at 6:29 PM Chris <hoopyfrood42 at gmail.com> wrote:
>
> On Sat, Oct 24, 2026 at 1:34 PM Devin Wittmayer
> <lucid_duck at justthetip.ca> wrote:
> >
> > Chris wrote:
> > > One thing on offset 20: in monitor mode it doesn't look like all of
> > > rx.
> >
> > You're right, it isn't all of rx. Your numbers made me curious, so I
> > tried it here with an A9000 as a 20 MHz monitor next to an Alfa. It
> > seems to come down to how strong the signal is. Share of the time:
> >
> >                                          offset 20   decoded frames
> >   one strong neighbour (-22 dBm)            2.3%          2.0%
> >   only weak neighbours (-73 dBm or less)    0.0%          3.6%
> >   my upload, monitor on a side channel     54.6%          7.5%
> >
> > Strong signals land in 20 even when the monitor can't decode them,
> > including spill from the next channel, and weak ones are left out.
> > That would fit what you saw on 5 GHz and on channels 2 to 4.
> >
> > As a station the A9000's own downlink does show up in 20, so I'd keep
> > it as the receive time.
> >
> > Thanks for the long run against the Wi-Spy, and for the Tested-by.
> >
> > Devin
>
>
> Devin Wittmayer wrote:
> > As a station the A9000's own downlink does show up in 20, so I'd keep
> > it as the receive time.
>
> Makes sense, thanks for running that down. Strong signals counting and
> weak ones not explains both of the oddities I saw. For my use, a monitor
> hopping channels, busy time is the figure that matters, and that one
> held up on every channel.
>
> Happy to test a v2 on the A9000 if one comes.
>
> Chris


Hi Devin,
One more from the long run, which you'll want before a v2: the busy
counter (offset 19) looks to be 32 bits wide, and it wraps.

Since fix 5 went in, about 2.5 days of channel hopping, my scanner's
sanity check threw out four survey readings where a channel's busy time
jumped by close to 2^64 us. Each one is a normal reading less exactly
2^32 us, e.g. 264 ms busy in 645 ms active, minus 2^32. So the firmware
counter wrapped (every ~71.6 minutes of busy time), and in

    state->cc_busy += __res_u64(IDX_BUSY_TIME) - state_ts->cc_busy;

the new value is smaller than the old, the difference goes negative,
and cc_busy wraps. It happens once per wrap; the readings after it are
fine.

Taking the difference in 32 bits would cover it, e.g.

    state->cc_busy += (u32)(__res_u64(IDX_BUSY_TIME) - state_ts->cc_busy);

and the same for tx and rx, if those are 32-bit too. I only see busy
directly, so I can't confirm the other two.

Happy to run a v2 against the same setup.

Chris