[bug report] wifi: mt76: mt7925: iw set txpower fixed accepted but ignored

[John Henry]

Hi Sean,

Thanks for the pointer. I read through the patch — it addresses the
txpower reporting / display value (iw dev info showing the correct
dBm), which I think is a separate concern from the issue I reported.
Please forgive me if I am being presumptuous on this issue.

This issue is related to monitor mode retune's of >= 5 channels.
retunes of lists of 4 channels or less does not exhibit this issue.
Neither do I see these strong "RF Ticks" in managed mode.

Maybe a bit more clarification or other....
The behavior I'm seeing is a real very strong RF emission at channel
frequency on each retune, observable on a fast spectrum analyzer. It
only occurs in monitor mode and only when the per-channel-set sequence
touches >= 5 distinct frequencies. The same chip in managed mode being
driven through the offloaded scan path (NL80211_CMD_TRIGGER_SCAN) does
not exhibit it, even when sweeping the same set of 5+ frequencies.

Reproduction with stock iw commands (no custom code):

IFACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
iw reg set US ; sleep 1
ip link set "$IFACE" down
iw dev "$IFACE" set type monitor
ip link set "$IFACE" up

# This triggers narrowband bursts at channel center on each retune:
while true; do
  for f in 2412 2417 2422 2427 2432; do
    iw dev "$IFACE" set freq "$f" HT20
  done
done

# This does NOT (only 4 frequencies):
while true; do
  for f in 2412 2422 2462 2484; do
    iw dev "$IFACE" set freq "$f" HT20
  done
done

Bursts are ~800 kHz wide at the base, -30 to -50 dBm OTA at close
range, brief (estimated few hundred microseconds), at channel
frequency. tx_stats counters remain zero throughout. Behavior is
identical on a custom mt7921au board and a retail ALFA AWUS036AXML, in
an RF-quiet environment with no other 802.11 / Bluetooth devices
present.

The strong mode dependence (monitor per-tune yes, scan path no,
identical frequencies and counts) suggests the firmware is doing
something on the per-channel-set path that the offloaded scan path
skips — possibly per-channel TX calibration. Is there a known firmware
operation triggered by the monitor-mode channel-set MCU command that
could produce this, and is it suppressible for passive sniffer use
cases?

Thanks,
John Henry