Some ASUS firmware carries 0xff in MTGS power slots. The driver narrows
the byte to s8, so the slot reads as -1 in its 0.5 dBm units, wins the
min() against the regulatory limit and caps every rate the driver
programs. On an ASUS Zenbook 14 UM3406HA (MT7922) all six MTGS tables
hold 0xff in every power byte, and txpower_sku shows tmac 3 on every
supported OFDM/HT/VHT/HE rate against EEPROM entries of 25-39, under
both the FR and the world regulatory domain. Huy Nguyen Dinh Quang saw
the same clamp on a Vivobook S 14 M5406WA, with 5 GHz TX at ~40 Mbps,
and proposed skipping the geo entry.

Skip a geo entry whose power byte is 0xff. The MTDS entry is narrowed
the same way on its way into the geo lookup, so give it the same
treatment, and clamp the dynamic value plus offset at 127 so a no-limit
entry cannot wrap.

Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2515420
Reported-by: Huy Nguyen Dinh Quang <huynguyendinhquang@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/20260827134820.2607530-1-huynguyendinhquang@gmail.com/
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
---
Fed the Zenbook's MTGS bytes through the two lookups in a host build of
these functions, once with a sane v2 MTDS and once with one full of
0xff. Before: -1 on every range in every region, -2 under ETSI with
the padded MTDS. After: the MTDS values with the sane table, 127 with
the padded one. No MT7922 here; the Zenbook reporter has offered to
test.

 .../wireless/mediatek/mt76/mt792x_acpi_sar.c   | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
index 946dd7956e4a..9f0ea3d23e0f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
@@ -279,10 +279,18 @@ mt792x_asar_get_geo_pwr(struct mt792x_phy *phy,
 	if (idx >= max)
 		return dyn_power;
 
-	geo_power = (band_pwr + idx)->pwr;
-	dyn_power += (band_pwr + idx)->offset;
+	band_pwr += idx;
 
-	return min(geo_power, dyn_power);
+	/* Some OEM tables carry 0xff here; narrowed to s8 that is -1 and
+	 * wins the min() below. Take it as no limit.
+	 */
+	if (band_pwr->pwr == 0xff)
+		return dyn_power;
+
+	geo_power = band_pwr->pwr;
+
+	return min_t(int, geo_power,
+		     min_t(int, dyn_power + band_pwr->offset, 127));
 }
 
 static s8
@@ -315,7 +323,9 @@ mt792x_asar_range_pwr(struct mt792x_phy *phy,
 	else
 		band = NL80211_BAND_2GHZ;
 
-	return mt792x_asar_get_geo_pwr(phy, band, limit[idx]);
+	/* 0xff: no dynamic limit, see mt792x_asar_get_geo_pwr() */
+	return mt792x_asar_get_geo_pwr(phy, band,
+				       limit[idx] == 0xff ? 127 : limit[idx]);
 }
 
 int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, bool set_default)
-- 
2.43.0

On Thu, 10 Sep 2026 09:23:00 +0800, Junjie Cao wrote:
> No MT7922 here; the Zenbook reporter has offered to test.

Tested on the Zenbook 14 UM3406HA, 7.2.4 plus this patch: channel
42 tmac 3 -> 27 on OFDM/HT/VHT/HE, iw 0.00 -> 14.00 dBm, matching
MD11 = 0x1b in its MTDS.
https://bugzilla.redhat.com/show_bug.cgi?id=2515420#c20

Tested-by: Fabien LAGARDE <fabienlagarde16@gmail.com>

On Thu, 10 Sep 2026 09:23:00 +0800, Junjie Cao wrote:
> Some ASUS firmware includes 0xff values in MTGS power slots.

Same failure on an ASUS Vivobook S 16 M5606WA (MT7922, mt7921e, BIOS
M5606WA.316), kernel 7.2.4 with this patch applied on top.

The DSDT carries MTCL version 2, MTDS with two identical tables
(1A 19 17 11 15 10 12 12 12 12 10) and MTGS version 4 with pwr 0xff in
every slot (offset 0x00 in entry 1, 0xff in entries 2-6). Region ETSI.

Before, txpower_sku showed tmac 3 for every OFDM/HT/VHT/HE rate on every
channel; the AP never answered auth frames from a few rooms away and TX
sat at 6 Mbit/s with ~3 retries per frame once associated.

After:
  5 GHz ch 36/80 MHz: tmac 29, TX/RX 866 Mbit/s VHT-MCS 9, 7 retries in
  776 frames, association succeeds from the spot that used to fail.
  2.4 GHz ch 11:      tmac 30, TX 117 / RX 104 Mbit/s.

Tested-by: Cristian Fleischer <cristian.fleischer@gmail.com>