Re: [PATCH RFC] wifi: mt76: mt792x: treat ACPI MTGS 0xff as no geo limit
Devin Wittmayer <[email protected]>
| Newsgroups | org.kernel.vger.linux-wireless,org.infradead.lists.linux-mediatek |
|---|---|
| Message-ID | <[email protected]> |
Thanks for measuring both bands. There is another one of these from July with the same symptom and a different cause. ASUS ROG laptop, geo table in the v2 shape but the version byte says v1, so it gets read a byte early and the 5 GHz slot comes out 0x00 rather than 0xff. I sent a fix for that one on the 11th: https://lore.kernel.org/linux-wireless/[email protected]/ Both are probably real. Your MTGS and MTCL bytes would settle which one you have, and MTCL is the one that decides it, since every table gets read with whatever version that one declares. If yours look like the ASUS tables then the 0xff is wreckage from the misparse and the patch above already covers you. Building it would answer the same question. Two things on yours. Skipping the offset when the power byte is filler wants a sentence saying why. And I would test the raw field rather than the value after it has been through the signed conversion. Devin On Thu, Aug 27, 2026 at 8:48 PM Huy Nguyen Dinh Quang <[email protected]> wrote: > Some OEM ACPI MTGS tables fill unused geo power/offset slots with > 0xff. Windows treats that as "no cap". Linux assigned the u8 value > to s8 and min()'d it, clamping every rate to about -1 dBm > (txpower_sku tmac = 3). > > Skip geo capping when pwr is 0xff, and do not apply offset when it > is 0xff. > > Tested on ASUS Vivobook S 14 M5406WA (MT7922, mt7921e): > - 5 GHz: tmac 3 -> 25, TX ~40 Mbps -> 200-350 Mbps (80 MHz) > - 2.4 GHz: tmac 30 after the change (channel 6, 20 MHz) > > Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support") > Signed-off-by: Huy Nguyen Dinh Quang <[email protected]> > --- > drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c > index 946dd79..fa539cd 100644 > --- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c > @@ -280,7 +280,15 @@ mt792x_asar_get_geo_pwr(struct mt792x_phy *phy, > return dyn_power; > > geo_power = (band_pwr + idx)->pwr; > - dyn_power += (band_pwr + idx)->offset; > + /* > + * ASUS (and some other OEM) ACPI MTGS tables fill unused geo > + * slots with 0xFF. Windows treats that as "no cap". Linux took > + * it as s8 -1 dBm and min()'d every rate down to ~3 dBm tmac. > + */ > + if ((u8)geo_power == 0xff) > + return dyn_power; > + if ((band_pwr + idx)->offset != 0xff) > + dyn_power += (band_pwr + idx)->offset; > > return min(geo_power, dyn_power); > } > -- > 2.55.0