From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72738377EAF for ; Sun, 17 May 2026 13:02:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.167.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779022937; cv=pass; b=MfVIKPwtR4nwL9H7HXkg6O/Eu6is1SX/WaSAitZ7oo/Gbc2nLFVpqJTkW642dhovIfK2+zxCBhPlX9dmiMmEsZ6CYuG6OPhTHUfxIJ3F1ZH/eWyv+Q+fCLBrhuXkp750fVoeHbn9VolX+xrpoH7BMeuM+m8l0SBSWgAcDH99uiA= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779022937; c=relaxed/simple; bh=cHLfInepgd6zPb/tpkxXUTHwI3zIh0WLknl+85pKlCo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=db+sWR+uZ2h6yDeCA904xnsXlH6BnMOmia8EpRI/dPrtax09EMQcg2Lg+hpE2PRU/27SVhMHRNbQCX29ShZCfj3EJSNOKuxtMyIIEGDsSv1y/7kAm5AP2TpzKFbNtwpT3bFOkSM6B6ESaR1agMUf1Borm+ODQlmqc6trzsUnphQ= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IeM8UHbd; arc=pass smtp.client-ip=209.85.167.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IeM8UHbd" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5a884815606so1785581e87.0 for ; Sun, 17 May 2026 06:02:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779022931; cv=none; d=google.com; s=arc-20240605; b=AKseHcvV6qVCnK2Fh6Tbi6xNIzLSWJUOm2atGIlJQDJp0jPM1BcatmNWKXGRWFCcgC hTxI7GOxVKQdWwlpojKK8Y6AqmTBD//D2vgErVuz+ZP8dXObGYiJysvViet8Q7XQr83q /ODHNlwsF4XA7H4W1qy3Gfi102F7R7sVELK4Y8nZntHEJe4K+xKyW3p/OfCjg9E4Ltea SBM3HjyX1wBJHqfBaXRYL+zaX7KiGSrXb9arta6I4uKETN1qaQ1NTlNjRZHT385T7frU 3zV0jgXPbQEMsYzGbXQNE2CGa0qEMCGokIU6Er9EytXfDrjvz5lh3paOsyTyaeYwtGB2 bKqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=FhotB3WmZS4RdLDhV3zhLMq1HMhtHjJJYY8Fard8AIs=; fh=D/pmspPd9NhfNJq2jLQg9PS+2rxaO/51GNJ07udxz04=; b=gwWPf5sttWOJWuDvJtT8f4j+3t1nJnILtMlpqJsOqVVzOUmsyD8/llKxWxuOvjuNFY 4GzjMvPdx7z95nVWE1n6hS+h1jxwxC17yj5VmSs1Nxm9QoOpCVPH+RCm0gOtRjD8igjc gEMYg2Vfc8Ful+Y4QKsmgefWESaZCr1IdWzB6Z3FBdYwRbGvqAA9xhZu2DaIZliP2ZqR dw2ERs0Pl9U+Khpk+8XAK+2nIXWys0iSviAWrWgDQbtP8JkCLvCT1d+iAJlYRNh1oixg xaVZA+RVsF26fcp+gcv20Jw49rYou0JB/sbh+0lAalXu4kls3oeFa4xX1Kum11YG8Xvf Xqfw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779022931; x=1779627731; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FhotB3WmZS4RdLDhV3zhLMq1HMhtHjJJYY8Fard8AIs=; b=IeM8UHbdRgPHVTL1JTUmGXwu34eKNQqyqFzILJ3jrqJG9LFdQ7W9676E9HJfeu7LC8 QBWtVLboTMnvIEFa36av1CoXpEXBKxWMLsiFV+QUM0tmIDaPAkVwd8O71bTpB4OTCOTt XuNmCJMPo5G/sbYVeKc4cb5ZV5PduxIiVDLm569QsD1qSivrVJEQXzfWzDEj++3ZnaSg NN44omCa5uvGN5MLwskG1aU1l1ojCJISNAoV7C8XQlUoUw2jq/Hx03VqHZ/59RRvCtwp gV3EO9rfS/oqs/VrGGFaleqZa8LkGFFRjPU02Fq6Z6wuciM6q+py1hx/d2jfY5ixkisT xpvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779022931; x=1779627731; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FhotB3WmZS4RdLDhV3zhLMq1HMhtHjJJYY8Fard8AIs=; b=AzPRl52SCwtipK7El2i7H6EHRNiQQmQcPtWe81j6XMarZCoK2mELELDhIpGArWuQDM S0AGDvtDN5D7BNc+Z2exXHJHHRJwd7elZnmZx5Ue3PnC1kY7E5l8JsYf7FEf1gBs21t+ vTVLJzzOC+EMy+WpNXFB18Jp8S4/ZFwAIiDNfGrcWpQ0zAabWHvj2WJd23tb68ihj3cg Q4pIopZ1ehG9fzRci6j3sLkFdbq3JXHxIyvxfSQPcZATsFj0Hqumos/9HLtY67kwREOl WOJ6WPdtujHtuqu+UMogvl8J6v4EzxUK/V+x7HKrLgzX9Yw0lVjheDFYqe3oH8J6bXjZ I3pQ== X-Forwarded-Encrypted: i=1; AFNElJ/gWG0oVWlh3NON/jqd6KBRrLltvQli9IPfEtvEYKKx+i39RgRUJxmnLxWfzrmOody7KyjFhcE6yV1b1K0=@vger.kernel.org X-Gm-Message-State: AOJu0YyDCiMkL0C5WL/zIL9k44aQ1fYm8trhTWOnP08Duw3TImW/pvgA JcEvPoUegLldBH/nnhnHu3g4IgvEb26XJCFXJ8UQdE9X+2wzGqeiSMEwU19WBbFPKG1nGHzuWHa NmKKwb4nUa4Ti7koB7JYIDFbok4fqh3s= X-Gm-Gg: Acq92OFYvlwQ2B5KXxRV04y1KNrBk06P5/u2DiDPEkL9kYlRuEAYZJDcGcG1Bf1ab+c uvqFMcHq33YedmWlGXFbCfuK1h++42IhEAkKc1P3OUpyp/rklFmYQudQGpNP3QP4EIhLZJy9oFS 2RZBDr7EclnGr45zqeNR1ihbrWB1Yfe2MBonc2/Z2GRz2cGGmnggjm7mf+kK4R4hTwIh1zh0LgM VfqwmbM9bEEWDVmSFg1VyG8s0rUj3Dx+vFwP/fI2xvwFoOZxOzGscVDAQksZhAn5VdZP24hHA6C +DS+XrXQeFL7WdK0bw== X-Received: by 2002:a05:6512:b9d:b0:5a9:d3a4:a25c with SMTP id 2adb3069b0e04-5aa0e7470d1mr2980752e87.37.1779022930147; Sun, 17 May 2026 06:02:10 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260506200918.D68321EA006C@mailuser.phl.internal> In-Reply-To: From: John Henry Date: Sun, 17 May 2026 09:01:59 -0400 X-Gm-Features: AVHnY4IMQ_YzMKlit-aEQHdc_R-PD7schhIkAMTGveoOUQVZ-GY9WU5-GFVhZ9s Message-ID: Subject: Re: [bug report] wifi: mt76: mt7925: iw set txpower fixed accepted but ignored To: Sean Wang Cc: Javier Tia , Bradley Pizzimenti , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org, ryder.lee@mediatek.com, shayne.chen@mediatek.com, sean.wang@mediatek.com, "moderated list:ARM/Mediatek SoC support" , Deren Wu , Nick Morrow Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a kind reminder of this issue, has anyone been able to reproduce this monitor mode issue? When scanning through channels, and the list of channels is > 4, there is a large transmit tick/burst coming from the MT7921u and the MT7925. This can easily be seen on an RF Spectrum Analyzer. Confirmed on an Alfa AWUS036AXML consumer product and the Netgear Nighthawk A9000. This can be reproduced with simple scripts. Reproduction with stock iw commands (no custom code): IFACE=3D$(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. On Mon, May 11, 2026 at 1:58=E2=80=AFPM John Henry = wrote: > > Bradley/Sean, > > Thank you all very much for the information. > I tested this on mt7921u based Alfa AWUS unit and also an mt7925 based > Netgear Nighthawk unit. > I can confirm that the RF tick issue is present on both models when in > Monitor Mode. I'm assuming it is in the base mt76? > > I attempted sudo iw dev wlxxx set txpower fixed nn where nn is the > minimum value, next few values up, and then a few near the max values, > and see no change in the signal strength of the RF Ticks when scanning > through 5 or more channels. > > Please keep this in mind when attempting to resolve the known txpower > 3dBm issue if possible, or please generate a new bug report for that > specifically so that I can track when it is patched, or in ??? version > so that I can test here locally. > > Incidentally, I'd appreciate it if anyone could please attempt to > repeat using the scripts I had shown in the previous posts and confirm > it is indeed seen by others. > > Thank you very much for your time and assistance > > John Henry > > > > > From: Bradley Pizzimenti > To: linux-wireless@vger.kernel.org > Cc: linux-kernel@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org, > ryder.lee@mediatek.com, shayne.chen@mediatek.com, > sean.wang@mediatek.com > Subject: [bug report] wifi: mt76: mt7925: iw set txpower fixed > accepted but ignored > Date: Mon, 4 May 2026 15:04:35 -0700 [thread overview] > Message-ID: > (raw) > > Hi there maintainers, > > `iw dev 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 > > On Wed, May 6, 2026 at 8:12=E2=80=AFPM Sean Wang w= rote: > > > > 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=E2=80=AFPM Javier Tia wrote= : > > > > > > On Sun May 4 22:04:48 2026 Bradley Pizzimenti wrote: > > > > `iw dev 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) =3D 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-wif= i-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 > > > > >