Re: [BUG] mt7921e/MT7902: firmware programs near-zero Tx power for all 20/40 MHz rates -> assoc fails except at close range

Self-correction to my original report: the root cause is not in the MT7902
firmware. It is in mt76, in the ACPI SAR path, and it looks trivially
fixable. Apologies for the misdirection in the first mail.

## What actually happens

I instrumented the tx power path with kprobes on 7.1.8, while associated to
the same APs as in the original report:

  mt76_connac_get_ch_power()  in=40 -> 40 / 34 / 24  (correct, 0.5 dBm)
  mt76_get_sar_power()        in=40 -> -1            (684 of 684 calls)

mt76_get_rate_power_limits() then does

        memset(dest, target_power, sizeof(*dest) - sizeof(dest->path));

so the entire limits struct becomes -1, mt76_connac_mcu_build_sku() sends -1
for every rate group, and the firmware programs tmac = 4 (2 dBm) against
eeprom values of 38-40 (19-20 dBm).

So the firmware is not inventing the near-zero power. It is being told to
use it.

## Where the -1 comes from

mt76_get_sar_power() takes min() with phy->frp[i].power, which
mt792x_init_acpi_sar_power() fills from the machine's ACPI SAR tables:

        frp->power = min_t(s8, set_default ? 127 : frp->power,
                           mt792x_asar_range_pwr(phy, frp->range, i));

mt792x_asar_range_pwr() -> mt792x_asar_get_geo_pwr() returns
min(geo_power, dyn_power + offset) straight out of MTDS/MTGS. This laptop's
DSDT exports MTDS, MTGS and MTCL, and that path yields -1 for every
frequency range.

Whether the BIOS tables are bogus or we mis-parse them, mt76 applies the
value with no sanity check. A limit of -0.5 dBm is not a plausible SAR limit
and arguably should never reach the firmware.

## Confirmation

A kretprobe module forcing mt76_get_sar_power() to return its input
argument, nothing else changed:

  group     stock             with override
  OFDM      4 4 4 4 ...       39 39 39 39 ...
  HT40      4 4 4 4 ...       39 39 39 39 ...
  HE484     4 4 4 4 ...       39 39 39 38 ...

On air, same BSSID, tx rate control went from HE-MCS 3 (68.8 Mbit/s) to
HE-MCS 9 (229.4 Mbit/s) with 3 dB worse RSSI.

## What this invalidates from my first mail

- Not 802.11h / TPC / Country IE. The regulatory domain never changes:
  iw reg get stays at the user regdomain before and after associating to
  the APs advertising Country: CO.

- Not CLC. mt7921_common.disable_clc=1 gives a byte-identical txpower_sku
  on the same channel while associated.

- Not specific to those APs at all. The -1 is applied unconditionally on
  this machine. The airport deployment only exposes it, because 2 dBm is
  not enough at -72 dBm with heavy co-channel contention, while it is
  plenty at close range to a home AP. That also explains why 80 MHz looked
  healthy: the firmware appears to ignore the bogus limit for the
  VHT80/HE996 groups, and my home AP runs 80 MHz.

A much better reproducer than "association times out": the 40 MHz groups
read the correct 43 while idle and collapse to 4 on association, i.e. as
soon as SET_RATE_TX_POWER is pushed.

## Suggested fix

Reject non-positive ACPI SAR limits instead of applying them, e.g. in
mt792x_init_acpi_sar_power():

        s8 lim = mt792x_asar_range_pwr(phy, frp->range, i);

        if (lim <= 0)
                continue;

or a sanity floor in mt76_get_sar_power(). I did not want to guess which
one you prefer, nor whether it is worth warning once when the ACPI tables
are clearly out of range.

Happy to send a proper patch and to test anything on this hardware:

  MT7902 [14c3:7902], subsystem [1a3b:5520] (AzureWave), ASIC rev 79020000,
  mt7921e, kernel 7.1.8-200.fc44.x86_64, firmware WIFI_RAM_CODE_MT7902_1.bin
  build 20251212032127 (linux-firmware, unchanged since the first report).

Full kprobe traces, txpower_sku dumps before/after and the override module
are available on request.

Thanks,
Pablo Diaz

El mié, 15 jul 2026 a las 23:13, Pablo Diaz
(<[email protected]>) escribió:
>
> Hi,
>
> Reporting a connectivity bug on MT7902 (mt7921e). Following
> Documentation/admin-guide/reporting-issues.rst.
>
> ## The one-line problem
>
> mt7921e/MT7902 cannot authenticate/associate with a specific class of
> enterprise AP (Huawei, 802.11h + TPC + Country IE + MBSSID + HE), while it
> works at 100% with every other AP I use, including my home AP. Frames are
> transmitted (HW Tx counters increment) but the AP never replies:
>
>     wlo1: send auth to <bssid> (try 1/3..3/3)
>     wlo1: authentication with <bssid> timed out
>     (occasionally: authenticated, then association timed out)
>
> ## Scope / trigger (important)
>
> - FAILS only with the airport (Jorge Chavez, Lima) Huawei enterprise APs.
> - WORKS 100% with my home AP and all normal/consumer APs.
> - So the trigger is something these APs advertise, not general breakage.
>
> AP characteristics (from `iw scan`):
>   - Vendor: Huawei (BSSID OUIs 48:4c:29, 10:a4:da, 60:9b:b4, 3c:ff:d8)
>   - MBSSID: several SSIDs per radio (.FreeWifiJorgeChavez open, plus
>     WMIG_AIJCH/PACHACUTEC/T2_LAP incl. WPA3-SAE)
>   - 802.11ax / HE (HE Operation, BSS Color)
>   - 802.11h: SpectrumMgmt, Power constraint 0 dB, TPC report (9-16 dBm)
>   - Country IE = CO (Colombia) although the site is in Peru; my regdomain is PE
>   - fails on both 2.4 GHz (ch6) and 5 GHz (ch44)
>
> ## Observed correlate: 20/40 MHz Tx power programmed near-zero
>
> debugfs .../mt76/txpower_sku while in range of these APs
> (tmac = value the firmware programmed, eeprom = calibration):
>
>     group (bandwidth)          eeprom   tmac
>     CCK (2.4 legacy)           29-34     34    OK
>     OFDM (20 MHz)              31-36      4    near-zero
>     HT20 / HT40                29-34      4    near-zero
>     VHT20 / VHT40              27-34      4    near-zero
>     VHT80                      27-34     39    OK
>     VHT160                     23-30     35    OK
>     HE26/52/106/242/484        23-34      4    near-zero
>     HE996                      23-34     39    OK
>     HE996x2                    18-30     35    OK
>
> Every 20/40 MHz rate is programmed to ~4; only 80/160 MHz is correct.
> Auth/mgmt frames go out at OFDM 6 Mbps / 20 MHz, i.e. at ~near-zero power,
> which matches "frames sent, AP never answers, works only at very close range".
>
> Hypothesis: the MT7902 firmware mis-handles the 802.11h TPC / power-constraint
> / Country IE advertised by these APs and collapses the low-bandwidth Tx power.
> Consumer APs that do not advertise 802.11h do not trigger it. I could not fully
> prove causation in the field; maintainer insight is welcome.
>
> ## Environment
>
> - Adapter: [14c3:7902] MT7902 802.11ax PCIe [Filogic 310],
>   subsystem [1a3b:5520] (AzureWave), ASIC rev 79020000
> - Driver: mt7921e (in-tree mt76)
> - Kernel: 7.1.3-201.fc44.x86_64 (Fedora distro kernel)
> - Firmware (linux-firmware commit edc18bd, the only MT7902 WiFi fw published,
>   already the latest): WIFI_RAM_CODE_MT7902_1.bin 20251212032127 +
>   WIFI_MT7902_patch_mcu_1_1_hdr.bin 20251212032046a
> - Not a regression: MT7902 support is new; there is no known-good prior kernel.
>
> ## Steps to reproduce
>
> 1. Be in range of a Huawei enterprise AP advertising 802.11h TPC + Country IE.
> 2. Try to connect (open network). Auth/assoc time out repeatedly.
> 3. Same adapter connects fine to a home/consumer AP.
>
> ## What I already tried (ruled out)
>
> - Rebuilt in-tree mt76 (v7.1) with SUPPORTS_MULTI_BSSID /
>   SUPPORTS_ONLY_HE_MULTI_BSSID disabled in mt792x_core.c: no fix (failure only
>   moved from auth to assoc). So MBSSID handling is not the cause.
> - mt7921e disable_aspm=1 and Wi-Fi power-save off: marginal only.
> - Regdomain PE (correct for the site) vs forcing the AP-advertised CO:
> no change.
> - iw dev wlo1 set txpower fixed|auto: no effect (reports 0.00 dBm).
>
> ## Code trace (why this looks firmware-side, v7.1 mt76)
>
> - txpower_sku is read from the firmware via MCU_CE_CMD(GET_TXPWR)
>   (mt7921/mcu.c mt7921_get_txpwr_info): the fw reports correct eeprom (36) but
>   programs tmac = 4 for 20/40 MHz.
> - The only driver Tx-power input is a per-rate limit table
>   (mt76_connac_mcu_build_sku), which is bandwidth-agnostic (VHT20 and VHT80
>   share limits->mcs); yet the fw applies 4 vs 39, so the per-bandwidth
>   reduction is a firmware decision.
> - The driver writes no RF power registers (only MT_TMAC ODTR/CDTR/ICR0 timing);
>   mt7921 exposes no writable txpower override and no per-BW power MCU command.
> - is_mt7902 special-casing covers only MCU_WA ring/TXQ/DMA/runtime-PM, nothing
>   RF/Tx-power related.
>
> ## Request
>
> Can the MT7902 firmware be corrected to program the calibrated 20/40 MHz Tx
> power (the eeprom values already present) when these APs' 802.11h/Country IE is
> present, or is a driver-side workaround feasible? Happy to test patches or new
> firmware and to provide full dmesg, complete txpower_sku, and iw scan dumps.
>
> Thanks,
> Pablo Diaz