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

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

[Bradley Pizzimenti]

Hi there maintainers,

`iw dev <iface> set txpower fixed N` returns success on mt7925 for any
N tested, but the reported txpower never changes from a stuck value of
3.00 dBm. The kernel accepts and ignores the call silently in both
directions (above and below the displayed value), and well below the
regulatory ceiling.

I'm aware there's prior art on the cosmetic 3.00 dBm display issue
(Razvan Grigore's v2 series, Feb 2025; Ming Yen Hsieh's txpower init
refactor, Sept 2025). What seems potentially distinct here is that the
user-issued `iw set txpower fixed N` itself is silently no-op'd,
separate from the reported-value question. Reporting as breadcrumbs
in case the second observation is a separate bug rather than the same
one.

Hardware
--------
MEDIATEK MT7925 [Filogic 360], 802.11be 2x2, PCI 14c3:7925
ASIC revision 0x79250000
Driver in use: mt7925e (in-tree)

Firmware (from dmesg at probe)
------------------------------
mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10,
                     Build Time: 20260106153007a
mt7925e 0000:01:00.0: WM Firmware Version: ____000000,
                     Build Time: 20260106153120
Files: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
       mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin

Kernel
------
6.18.18-1-MANJARO (close to vanilla 6.18 stable; not yet tested on
wireless-next or nbd168/wireless HEAD -- happy to retest if needed,
but flagging the data point in case it helps as-is).

Tools: iw version 6.17

Regulatory
----------
$ iw reg get
country US: DFS-FCC
   ...
   (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
   ...

Connection context: 5GHz channel 161 (5805 MHz), 80 MHz, VHT-MCS,
NSS 1. So we are on a band with a 30 dBm regulatory cap.

Observed
--------
$ iw dev wlp1s0 info | grep txpower
        txpower 3.00 dBm

$ sudo iw dev wlp1s0 set txpower fixed 100   # 1 dBm
$ iw dev wlp1s0 info | grep txpower
        txpower 3.00 dBm

$ sudo iw dev wlp1s0 set txpower fixed 1500  # 15 dBm
$ iw dev wlp1s0 info | grep txpower
        txpower 3.00 dBm

$ sudo iw dev wlp1s0 set txpower auto
$ iw dev wlp1s0 info | grep txpower
        txpower 3.00 dBm

All four `set` invocations return exit code 0. The reported value
never moves.

Expected
--------
Either:
  - The reported txpower follows the requested value (or, where
    capped, the actual applied value with extack indicating the
    cap reason), or
  - The set call returns an error rather than silently ignoring the
    request.

Caveats
-------
- Not yet tested on wireless-next or nbd168/wireless HEAD. If a
  reproduction on a current dev tree would be useful, I can do that.
- I have not verified whether the actual radiated TX power changes
  in response to `set txpower fixed`; I am reporting only the
  user-visible behavior.

Thanks,
Bradley

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

[Javier Tia]

On Sun May  4 22:04:48 2026 Bradley Pizzimenti wrote:
> `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> any N tested, but the reported txpower never changes from a stuck
> value of 3.00 dBm.

Hi Bradley,

The 3 dBm display bug is a known issue we have seen when using mt7927
and a tested fix has been working well so far. The root cause is that
mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
computes:

  DIV_ROUND_UP(0 + 6, 2) = 3

regardless of the actual power level. The RF output is unaffected;
it is a display-only bug.

The fix reads the effective TX power back from the rate power limits
after programming the SKU tables and writes it to phy->txpower_cur,
following the same pattern used by mt7996:

  https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch

This is part of a series we are targeting for wireless-next; not
yet upstream.

> What seems potentially distinct here is that the user-issued
> `iw set txpower fixed N` itself is silently no-op'd, separate
> from the reported-value question.

Agreed those are two separate issues. Our patch addresses the
display-only side: after applying it, iw will report the value the
firmware is actually using based on the SKU tables, rather than
always 3 dBm. Whether `set txpower fixed N` propagates to firmware
to change actual output power is orthogonal and not addressed here.

If you can test the patch on your MT7925 and confirm the displayed
value reflects the correct power after association, a Tested-by
would be appreciated.

Best,
Javier

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

[Sean Wang]

Hi,

The TX power reporting issue has already been investigated by Lucid
from the Linux WiFi USB community, and there is a proposed solution.
I think we can continue checking whether there are any remaining
issues on top of that work. Please refer to the patches here:
https://lists.infradead.org/pipermail/linux-mediatek/2026-April/105726.html
Thanks everyone for reporting and raising these concerns.

On Wed, May 6, 2026 at 3:09 PM Javier Tia <floss@jetm.me> wrote:
>
> On Sun May  4 22:04:48 2026 Bradley Pizzimenti wrote:
> > `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> > any N tested, but the reported txpower never changes from a stuck
> > value of 3.00 dBm.
>
> Hi Bradley,
>
> The 3 dBm display bug is a known issue we have seen when using mt7927
> and a tested fix has been working well so far. The root cause is that
> mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
> firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
> computes:
>
>   DIV_ROUND_UP(0 + 6, 2) = 3
>
> regardless of the actual power level. The RF output is unaffected;
> it is a display-only bug.
>
> The fix reads the effective TX power back from the rate power limits
> after programming the SKU tables and writes it to phy->txpower_cur,
> following the same pattern used by mt7996:
>
>   https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch
>
> This is part of a series we are targeting for wireless-next; not
> yet upstream.
>
> > What seems potentially distinct here is that the user-issued
> > `iw set txpower fixed N` itself is silently no-op'd, separate
> > from the reported-value question.
>
> Agreed those are two separate issues. Our patch addresses the
> display-only side: after applying it, iw will report the value the
> firmware is actually using based on the SKU tables, rather than
> always 3 dBm. Whether `set txpower fixed N` propagates to firmware
> to change actual output power is orthogonal and not addressed here.
>
> If you can test the patch on your MT7925 and confirm the displayed
> value reflects the correct power after association, a Tested-by
> would be appreciated.
>
> Best,
> Javier
>

Re: [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