From nobody Sat Sep 26 18:04:15 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 243F84A4C37; Mon, 31 Aug 2026 13:43:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183835; cv=none; b=FMbB6EWeryxkIHhSsFrbIp/YWv4hCjrx1+pkBdUEGRZEGx5/dadBuwxA2gno1cbofq8Mmicf+2MOUi/qmby7BG+OyE4sjj0729qfbV26HibN2ujpCQsSUcDIo9FCedrPlBZyXmEwvWmHybwCzoVgSH5zXX5FEEY4OVqln5Bb1Lk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183835; c=relaxed/simple; bh=guxvnReWjgaXVgEWIc//dRH3ZdumFVJN5IaHcZLXP48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ncc2kNXC/NTcGBdMXF558zCdaeN8YS3LmRwqxnhPy33Jma/aTZprY32upqd3N9rftK548VZaELlZGKcVeiw9BxWUrYrb0wLikh8PaLDI4NuFdnMhfLZfaUuO9BxVW/hlhetrVJQdMvJC4O955XYeI/3+RTE2sjQJ39QvHUoVy6c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MBxwbZ6f; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MBxwbZ6f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7798F1F00A3E; Mon, 31 Aug 2026 13:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788183833; bh=nqh6IQJMFyy0N8GbWvGTs8cWSqQT38lz1Wzeep5i/SE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=MBxwbZ6fZN26/SFl2FlA9nDDLKRScjJX35Mgp1BKs5rrb4Zs9WG0b94hdTKLbAy2T +r4MrdO0N27Bsgrw3ubibcYkojKObze2D7DYjfiqKxkOK0htthhNR+MGu0ymYCkJz1 0uqIJlDWRSqUOMk1Hz2B0BqyRLXrN1oO7QoVxwqkvUfmhKl9rExhp9nVmiIJn6kFCt HUfXntTkhg1/McqnnHNFDV+orNlV7CDXdLWRQk9tSEq4eAlt67ZCvCclbJryN3KHXo 32bNnY/Uae1lxbEK5hEBROuITVBKmuimwuPMKEgs5Zg2JAuYHXPdyaB9YgOtFsLrs6 rRvp0Ar5v3gTA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Javier Tia , =?UTF-8?q?=E5=BC=A0=E6=97=AD=E6=B6=B5?= , Marcin FM , Cristian-Florin Radoi , George Salukvadze , Evgeny Kapusta <3193631@gmail.com>, Samu Toljamo , Ariel Rosenfeld , Chapuis Dario , =?UTF-8?q?Thibaut=20Fran=C3=A7ois?= , Sean Wang , Felix Fietkau , Sasha Levin , lorenzo@kernel.org, ryder.lee@mediatek.com, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH AUTOSEL 6.18-6.12] wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv Date: Mon, 31 Aug 2026 09:25:59 -0400 Message-ID: <20260831133314.4125787-331-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org> References: <20260831133314.4125787-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.48 Content-Transfer-Encoding: quoted-printable From: Javier Tia [ Upstream commit efc9a10d1de1763baecd2031c1c6dfe6aac9ac38 ] bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch falls through to default and sends bw=3D0 (CMD_CBW_20MHZ) to firmware via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz and cannot decode the AP's 320MHz frames, resulting in complete data path failure at 320MHz. Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and center_chan2. Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to 841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11. Reported-by: =E5=BC=A0=E6=97=AD=E6=B6=B5 Closes: https://github.com/openwrt/mt76/issues/927 Tested-by: =E5=BC=A0=E6=97=AD=E6=B6=B5 Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut Fran=C3=A7ois Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Phase 1: Commit Message Forensics **Step 1.1 =E2=80=94 Subject line** Record: `[wifi: mt76: mt7925]` `[add]` =E2=80=94 add missing 320MHz bandwid= th handling in `bss_rlm_tlv()`. **Step 1.2 =E2=80=94 Tags** Record: - **Reported-by:** =E5=BC=A0=E6=97=AD=E6=B6=B5 \ - **Tested-by:** 8 testers (reporter plus Marcin FM, Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario, Thibaut Fran=C3=A7ois) - **Reviewed-by:** Sean Wang \ (MediaTek maintainer) - **Closes:** https://github.com/openwrt/mt76/issues/927 - **Link:** https://patch.msgid.link/20260425195011.790265-3-sean.wang@kernel.org - **Signed-off-by:** Javier Tia, Felix Fietkau - No `Fixes:`, no `Cc: stable@vger.kernel.org` (expected for candidate review) - Ignore pipeline `Signed-off-by: Sasha Levin` if present in prepared form Notable: broad real-world testing, maintainer review, public bug tracker reference. **Step 1.3 =E2=80=94 Body analysis** Record: - **Bug:** `mt7925_mcu_bss_rlm_tlv()` has no `NL80211_CHAN_WIDTH_320` case; falls through to `default` and sends `bw=3D0` (`CMD_CBW_20MHZ`) to firmware via `BSS_RLM` TLV. - **Symptom:** firmware configures RX for 20MHz, cannot decode AP 320MHz frames =E2=86=92 complete data-path failure (0 Mbps). - **Fix:** add `NL80211_CHAN_WIDTH_320` case with `CMD_CBW_320MHZ` and `center_chan2`. - **Evidence:** ASUS RT-BE92U test: 0 Mbps =E2=86=92 841 Mbps iperf3 (`-t30 -P8`), PHY 4803 Mbps EHT-MCS11. - **Root cause:** missing switch case when programming firmware RLM TLV. **Step 1.4 =E2=80=94 Hidden bug fix?** Record: **Yes.** Subject says =E2=80=9Cadd,=E2=80=9D but this is a function= al bug fix: wrong bandwidth programmed to firmware causes total connectivity loss at 320MHz. Not a style/cleanup change. --- ## Phase 2: Diff Analysis **Step 2.1 =E2=80=94 Inventory** Record: - **Files:** `drivers/net/wireless/mediatek/mt76/mt7925/mcu.c` (+4 lines) - **Function:** `mt7925_mcu_bss_rlm_tlv()` - **Scope:** single-file, surgical fix **Step 2.2 =E2=80=94 Code flow** Record: - **Before:** `chandef->width =3D=3D NL80211_CHAN_WIDTH_320` hits `default` =E2=86=92 `req->bw =3D CMD_CBW_20MHZ`. - **After:** explicit case sets `req->bw =3D CMD_CBW_320MHZ` and `req->center_chan2` from `freq2` (same pattern as `NL80211_CHAN_WIDTH_80P80`). - **Paths affected:** BSS association/channel-context updates via `mt7925_mcu_set_chctx()` and BSS enable path in `__mt7925_mcu_bss_req()`. **Step 2.3 =E2=80=94 Bug mechanism** Record: **Logic/correctness bug** =E2=80=94 incomplete switch on channel wi= dth. Category: driver/firmware configuration mismatch causing total RX failure. Not a crash/UAF, but complete loss of throughput at 320MHz. **Step 2.4 =E2=80=94 Fix quality** Record: **Obviously correct.** Mirrors existing `80P80` handling; uses `CMD_CBW_320MHZ` already defined in `mt76_connac.h`. Minimal regression risk; only affects 320MHz width path. --- ## Phase 3: Git History Investigation **Step 3.1 =E2=80=94 Blame** Record: - `mt7925_mcu_bss_rlm_tlv()` introduced in `ca64503a8f06ec` (2024-06-12, merged 2024-07-09): =E2=80=9Cadd mt7925_mcu_bss_rlm_tlv to constitue the = RLM TLV=E2=80=9D - Bandwidth switch written without `NL80211_CHAN_WIDTH_320` from the start - `c948b5da6bbec` (2023-09-18) introduced mt7925 driver with `[NL80211_CHAN_WIDTH_320] =3D 6` elsewhere in `mcu.c` **Step 3.2 =E2=80=94 Fixes: tag** Record: N/A =E2=80=94 no `Fixes:` tag. Bug introduced by omission in `ca64503a8f06ec`, which is present in this tree. **Step 3.3 =E2=80=94 Related file history** Record: - `mt7925_mcu_bss_rlm_tlv` added `ca64503a8f06ec`, refined in `22d66ef6653bb` - No prior fix for this specific issue in tree - Message-ID `-3` suggests patch 3 of a series, but this hunk is self- contained (no new symbols/structs) **Step 3.4 =E2=80=94 Author context** Record: Patch authored by Javier Tia; reviewed by Sean Wang (MediaTek). Felix Fietkau (mt76 maintainer) committed. Consistent with normal mt76 review path. **Step 3.5 =E2=80=94 Dependencies** Record: **Standalone.** `CMD_CBW_320MHZ`, `freq2`, and `NL80211_CHAN_WIDTH_320` already exist in this tree. No prerequisite commits required for this hunk to compile or function. --- ## Phase 4: Mailing List and External Research **Step 4.1 =E2=80=94 Original discussion** Record: `b4 dig` requires `-c COMMITISH`; commit hash not in this tree, so direct `b4 dig -c` failed. Lore fetch blocked by bot protection. Link points to linux-wireless thread `20260425195011.790265-3-sean.wang@kernel.org` (patch 3). **Step 4.2 =E2=80=94 Reviewers** Record: UNVERIFIED via `b4 dig -w` (no commit hash). Commit message itself documents **Reviewed-by: Sean Wang** and **Signed-off-by: Felix Fietkau**. **Step 4.3 =E2=80=94 Bug report** Record: GitHub issue #927 (MT7927/mt76 support) documents 320MHz failure. Contributor analysis (jetm, ~line 2620) identifies this exact missing `NL80211_CHAN_WIDTH_320` case as root cause: firmware told 20MHz, negotiates down, 0 throughput. Matches commit message. **Step 4.4 =E2=80=94 Related patches** Record: Issue thread mentions additional 320MHz work (EHT MCS maps, wiphy caps). **This commit is independently valuable** for the RLM TLV path; does not depend on those other changes to be correct. **Step 4.5 =E2=80=94 Stable list history** Record: UNVERIFIED =E2=80=94 lore stable search blocked. No in-tree evidenc= e of prior stable nomination. --- ## Phase 5: Code Semantic Analysis **Step 5.1 =E2=80=94 Key functions** Record: `mt7925_mcu_bss_rlm_tlv()` (modified). **Step 5.2 =E2=80=94 Callers** Record: - `mt7925_mcu_set_chctx()` =E2=80=94 channel context changes during STA operation - `__mt7925_mcu_bss_req()` =E2=80=94 BSS enable during association/setup Both are normal runtime WiFi paths, not init-only. **Step 5.3 =E2=80=94 Callees** Record: `mt76_connac_mcu_add_tlv()`, `ieee80211_frequency_to_channel()`, standard TLV population. Uses existing `CMD_CBW_*` constants. **Step 5.4 =E2=80=94 Reachability** Record: Triggered when `chandef->width =3D=3D NL80211_CHAN_WIDTH_320` during association or channel update. Reachable for hardware/firmware paths operating at 320MHz (e.g. MT6639/7927-class devices using mt7925 driver, tested setups on 6.18.x per GitHub thread). In vanilla tree, `mt7925_init_eht_caps()` currently advertises only 80/160 MHz MCS maps, so 320MHz association is less common without additional caps work =E2=80=94= but the buggy code path still exists and is incorrect whenever 320MHz width is presented. **Step 5.5 =E2=80=94 Similar patterns** Record: `mt76_connac_chan_bw()` in `mt76_connac.h` already maps `NL80211_CHAN_WIDTH_320 =E2=86=92 CMD_CBW_320MHZ`. `mt7996` uses that helpe= r for RLM TLV. mt7925=E2=80=99s manual switch was simply incomplete =E2=80=94 cle= ar oversight. --- ## Phase 6: Cross-Reference Against Local Tree **Step 6.1 =E2=80=94 Buggy code present?** Record: **Yes.** Local tree is **v6.18.44** (`make kernelversion` =3D 6.18.44). Current `mt7925_mcu_bss_rlm_tlv()` at lines 2325=E2=80=932350 lac= ks `NL80211_CHAN_WIDTH_320` case. Fix not yet applied (`git log -S "case NL80211_CHAN_WIDTH_320" -- mt7925/mcu.c` returns nothing). **Step 6.2 =E2=80=94 Backport difficulty** Record: **Clean apply expected** =E2=80=94 4-line insertion between `NL80211_CHAN_WIDTH_160` and `NL80211_CHAN_WIDTH_5` cases. No surrounding churn in that hunk. **Step 6.3 =E2=80=94 Related fixes already present?** Record: **No** equivalent fix in this tree. Other 320MHz references exist (`ch_width[]` at line 2151, `CMD_CBW_320MHZ` in `mt76_connac.h`) but not in `bss_rlm_tlv()`. --- ## Phase 7: Subsystem and Maintainer Context **Step 7.1 =E2=80=94 Subsystem criticality** Record: **IMPORTANT** =E2=80=94 `drivers/net/wireless/mediatek/mt76/mt7925`= WiFi driver. Affects users of MT7925-class hardware (PCI `0x7925`, `0x0717`; USB `0x7925`). Not core-kernel, but connectivity failure is user-visible and severe for affected hardware. **Step 7.2 =E2=80=94 Subsystem activity** Record: Actively maintained in 6.18.y =E2=80=94 recent stable commits inclu= de NULL-deref fix, crash fix, MLO fixes, TLV length fixes. --- ## Phase 8: Impact and Risk Assessment **Step 8.1 =E2=80=94 Who is affected** Record: **Driver-specific** =E2=80=94 users of mt7925/mt7925e/mt7925u (and related 0x0717 devices) connecting to 320MHz BSS. Growing install base on WiFi 7 platforms (motherboards, routers as STA). **Step 8.2 =E2=80=94 Trigger conditions** Record: Association or channel update at 320MHz width. Requires 320MHz- capable hardware and 320MHz AP/network. Not universal, but reproducible and documented with concrete iperf numbers. Unprivileged user can trigger by connecting to a 320MHz AP. **Step 8.3 =E2=80=94 Failure severity** Record: **HIGH** =E2=80=94 not a kernel oops, but complete data-path failur= e (0 Mbps, cannot decode frames). Effectively renders WiFi unusable at 320MHz. **Step 8.4 =E2=80=94 Risk/benefit** Record: - **Benefit:** HIGH for affected 320MHz users (restores full throughput; 0 =E2=86=92 841 Mbps demonstrated) - **Risk:** VERY LOW =E2=80=94 4 lines, no API change, only corrects firmwa= re TLV for one width enum - **Ratio:** Strongly favorable --- ## Phase 9: Final Synthesis **Step 9.1 =E2=80=94 Evidence summary** **FOR:** - Real, reproducible bug with 0 Mbps failure mode - Severe functional impact on 320MHz operation - Minimal, obviously correct fix (matches `80P80` pattern and `mt76_connac_chan_bw()`) - Extensively tested (8 Tested-by) - Reviewed by MediaTek maintainer - Buggy code present in v6.18.44 tree since `ca64503a8f06ec` - Standalone, no dependencies - Driver already has partial 320MHz support elsewhere =E2=80=94 this comple= tes a missing piece **AGAINST:** - In-tree `mt7925_init_eht_caps()` does not yet advertise 320MHz MCS maps, so vanilla users may not negotiate 320MHz today without additional upstream work - Could be viewed as part of broader 320MHz enablement for MT7927-class hardware - Full lore/stable discussion not accessible **UNRESOLVED:** - Exact upstream commit SHA (not in this tree) - Whether reviewers explicitly nominated for stable on lore The unresolved items do not outweigh the clear technical bug and fix quality. **Step 9.2 =E2=80=94 Stable rules checklist** 1. Obviously correct and tested? **PASS** =E2=80=94 4-line switch case; 8 Tested-by; maintainer reviewed 2. Fixes real bug affecting users? **PASS** =E2=80=94 documented 0 Mbps at 320MHz 3. Important issue? **PASS** =E2=80=94 complete connectivity failure at supported width enum 4. Small and contained? **PASS** =E2=80=94 4 lines, one function 5. No new features/APIs? **PASS** =E2=80=94 fixes firmware configuration for existing enum value 6. Can apply to local tree? **PASS** =E2=80=94 buggy code confirmed present= in v6.18.44 **Step 9.3 =E2=80=94 Exception categories** Record: Best classified as **hardware/driver quirk completion** =E2=80=94 completes missing bandwidth handling for hardware/firmware that already uses `CMD_CBW_320MHZ` elsewhere in the same driver. **Step 9.4 =E2=80=94 Decision rationale** For **v6.18.44**, the mt7925 driver is present, the incomplete switch has been wrong since `bss_rlm_tlv()` was added, and users connecting at 320MHz get a completely broken data path. The fix is tiny, safe, well- tested, and restores real-world functionality. This meets stable-kernel criteria for an important driver bug fix. --- ## Verification - [Phase 1] Parsed commit message, tags, and body from user-provided candidate - [Phase 1] Identified 8 Tested-by, 1 Reported-by, Reviewed-by Sean Wang, Closes GitHub #927 - [Phase 2] Diff: +4 lines in `mt7925_mcu_bss_rlm_tlv()` adding `NL80211_CHAN_WIDTH_320` case - [Phase 3] `git describe HEAD` =E2=86=92 v6.18.44; `make kernelversion` = =E2=86=92 6.18.44 - [Phase 3] `git blame` on lines 2325=E2=80=932357: switch introduced `ca64503a8f06ec` without 320MHz case - [Phase 3] `git show ca64503a8f06ec`: function added June 2024 without 320MHz handling - [Phase 3] `git show c948b5da6bbec`: mt7925 driver in tree since Sept 2023 - [Phase 3] `git merge-base --is-ancestor c948b5da6bbec HEAD` =E2=86=92 dri= ver present - [Phase 3] `git merge-base --is-ancestor ca64503a8f06ec HEAD` =E2=86=92 bu= ggy function present - [Phase 4] `b4 dig` without commit hash failed (needs `-c COMMITISH`) - [Phase 4] Lore/patch.msgid.link fetch blocked by bot protection =E2=80=94 UNVERIFIED - [Phase 4] GitHub issue #927 fetched; line ~2620 confirms same root cause and fix - [Phase 5] `grep mt7925_mcu_bss_rlm_tlv` =E2=86=92 callers at lines 2421, = 2867 in `mcu.c` - [Phase 5] `mt76_connac_chan_bw()` in `mt76_connac.h` lines 283=E2=80=93300 maps 320MHz correctly - [Phase 5] `CMD_CBW_320MHZ` exists at `mt76_connac.h:59` - [Phase 5] Other 320MHz reference at `mcu.c:2151` (`ch_width[]`) - [Phase 6] Read current `mcu.c:2325=E2=80=932350` =E2=80=94 missing 320MHz= case confirmed - [Phase 6] `git log -S "case NL80211_CHAN_WIDTH_320" -- mt7925/mcu.c` =E2= =86=92 empty (fix not in tree) - [Phase 6] PCI IDs `0x7925`, `0x0717` in `pci.c` since `c948b5da6bbec` - [Phase 8] `mt7925_init_eht_caps()` (`main.c:231=E2=80=93236`) advertises = only 80/160 MHz MCS =E2=80=94 noted as scope limiter for vanilla 320MHz negotiation, but does not negate the bug in `bss_rlm_tlv()` **YES** drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 1d63bfa58c437..0e45f9c757351 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -2342,6 +2342,10 @@ void mt7925_mcu_bss_rlm_tlv(struct sk_buff *skb, str= uct mt76_phy *phy, case NL80211_CHAN_WIDTH_160: req->bw =3D CMD_CBW_160MHZ; break; + case NL80211_CHAN_WIDTH_320: + req->bw =3D CMD_CBW_320MHZ; + req->center_chan2 =3D ieee80211_frequency_to_channel(freq2); + break; case NL80211_CHAN_WIDTH_5: req->bw =3D CMD_CBW_5MHZ; break; --=20 2.53.0