diff options
| author | Junjie Cao <junjie.cao@intel.com> | 2026-09-10 09:23:00 +0800 |
|---|---|---|
| committer | Felix Fietkau <nbd@nbd.name> | 2026-10-06 11:50:52 +0200 |
| commit | 45f53d98cbaa078907b6a300ff3974dfb5ae8776 (patch) | |
| tree | d5585849c462506dad6c285b072494d99f4a62e3 /tools/perf/scripts/python | |
| parent | 456de496b53ae73e6e3020fec815dbdc88aa7c07 (diff) | |
| download | linux-45f53d98cbaa078907b6a300ff3974dfb5ae8776.tar.gz linux-45f53d98cbaa078907b6a300ff3974dfb5ae8776.zip | |
wifi: mt76: mt792x: treat 0xff ACPI SAR entries as no limit
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>
Tested-by: Cristian Fleischer <cristian.fleischer@gmail.com>
Link: https://patch.msgid.link/acb947435fc78d5c06039c7bd5609c735468b0ee.1789002236.git.junjie.cao@intel.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
