[PATCH 0/2] wifi: mt76: fix TDLS direct-link on MediaTek MT7925

[PATCH 0/2] wifi: mt76: fix TDLS direct-link on MediaTek MT7925

[ElXreno]

This series fixes two TDLS-related issues on the MediaTek MT7925
(Connac3) Wi-Fi 6E chip, observed reproducibly with Samsung phones
and other peers that auto-initiate TDLS direct links.

Patch 1 works around a TDLS direct-link issue on MT7925: QoS Data
frames whose destination WCID is a TDLS peer are silently dropped
after submission to firmware via the HW_80211_ENCAP TX path. mt76
advertises WIPHY_FLAG_SUPPORTS_TDLS via the shared
mt76_register_phy_helper(), but does not provide TDLS-aware
firmware-facing peer setup -- no CONNECTION_TDLS constant in
mt76_connac_mcu.h, no STA_REC_TDLS TLV, no TDLS bit in
mt76_wcid_flags, no TDLS-specific handling in
mt7925_mac_write_txwi_8023(); the proprietary out-of-tree MediaTek
driver carries an explicit cfg80211_tdls.c with no in-tree
equivalent. Whether the underlying gap is in the firmware HW_ENCAP
path or in mt76's missing TDLS-aware setup is unclear from the
kernel side; the software-encap path sidesteps it either way. This
patch stops advertising SUPPORTS_TX_ENCAP_OFFLOAD and
SUPPORTS_RX_DECAP_OFFLOAD in mt792x_init_wiphy(); mac80211 then
takes the software 802.11 encap path, which submits already-formed
802.11 frames via a different firmware path that handles all WCIDs
correctly. Verified on mt7925e at 5 GHz HE 80 MHz and 2.4 GHz
802.11n; TDLS direct link sustains ~750 Mbit/s and ~130 Mbit/s
respectively. The disable is applied to the shared
mt792x_init_wiphy() and so also covers the Connac2 family
(mt7921/22/20/02), which uses the same firmware HW_ENCAP path; if
Connac2 is later confirmed unaffected, the disable can be narrowed
with is_mt7925().

Patch 2 fixes a regression introduced by the MLO refactor in
commit 3878b4333602 ("wifi: mt76: mt7925: update
mt7925_mac_link_sta_[add, assoc, remove] for MLO"): the cleanup
loop in mt7925_mac_sta_remove_links() unconditionally calls
mt7925_mcu_add_bss_info(..., enable=false) for every link of the
station being removed, including TDLS peers on a STATION vif which
share the AP's bss_conf -- wiping the AP-side rate-control context
on every TDLS teardown and collapsing rx bitrate to 6 Mbit/s for
tens of seconds.

---
To: Felix Fietkau <nbd@nbd.name>
To: Lorenzo Bianconi <lorenzo@kernel.org>
To: Ryder Lee <ryder.lee@mediatek.com>
To: Shayne Chen <shayne.chen@mediatek.com>
To: Sean Wang <sean.wang@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Soul Huang <Soul.Huang@mediatek.com>
To: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
To: Deren Wu <deren.wu@mediatek.com>
Cc: linux-wireless@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
base-commit: 7baf5857e15d722776898510a10546d6b2f18645

---
ElXreno (2):
      wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link
      wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer

 drivers/net/wireless/mediatek/mt76/mt7925/main.c | 10 ++++++++++
 drivers/net/wireless/mediatek/mt76/mt792x_core.c | 10 ++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)
---
base-commit: 7baf5857e15d722776898510a10546d6b2f18645
change-id: 20260503-mt7925-tdls-fixes-1d1397420900

Best regards,
--  
ElXreno <elxreno@gmail.com>

[PATCH 1/2] wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link

[ElXreno]

On MediaTek MT7925 (Connac3), QoS Data frames whose destination WCID
is a TDLS direct-link peer are silently dropped after submission to
firmware via the HW_80211_ENCAP TX path. The driver sees submit and
complete counts match (firmware reports success on TX queue
submission), but the frames never reach the PHY. iw counters show
tx_packets growing, tx_failed = 0, tx_retries low; on the air,
nothing.

This breaks TDLS direct-link as soon as a peer auto-initiates one
(Samsung phones do this aggressively when both peers share a BSS and
traffic exceeds a threshold). Pattern is:

  1. Any sustained direct traffic between two STAs sharing the BSS
     reaches the auto-TDLS threshold within ~1 s.
  2. Peer initiates TDLS; mac80211 routes data frames to the TDLS-peer
     WCID and the AP stops forwarding peer-to-peer traffic per the
     802.11z spec.
  3. Direct-link frames are accepted by firmware, completed in the TX
     descriptor pool, but never PHY-transmitted.
  4. TCP collapses; the peer eventually tears down the TDLS link with
     reason WLAN_REASON_TDLS_TEARDOWN_UNSPECIFIED. Cycle repeats.

Effective TCP throughput drops from ~300 Mbit/s (AP route) to ~6
Mbit/s with TDLS active.

Verified on mt7925e (PCIe) at 5 GHz HE NSS 2 MCS 11 80 MHz and at
2.4 GHz 802.11n HT NSS 2 MCS 15. With this patch, TDLS direct link
sustains ~750 Mbit/s and ~130 Mbit/s respectively.

mt76 advertises WIPHY_FLAG_SUPPORTS_TDLS via the shared
mt76_register_phy_helper() but does not provide TDLS-aware
firmware-facing peer setup: no CONNECTION_TDLS constant in
mt76_connac_mcu.h, no STA_REC_TDLS TLV, no TDLS bit in
mt76_wcid_flags, and no TDLS-specific code in
mt7925_mac_write_txwi_8023(). TDLS peers are registered as
CONNECTION_INFRA_STA with peer_addr set to the peer's MAC and
nothing else. The proprietary out-of-tree MediaTek driver carries an
explicit cfg80211_tdls.c (PTK/TK install paths, etc.) with no
in-tree equivalent. Whether the underlying gap is in the firmware
HW_ENCAP path or in mt76's missing TDLS-aware setup is unclear from
the kernel side; the software-encap path sidesteps it either way.

Work around the issue by not advertising SUPPORTS_TX_ENCAP_OFFLOAD
and SUPPORTS_RX_DECAP_OFFLOAD in mt792x_init_wiphy(). mac80211 then
takes the software 802.11 encap path, which submits already-formed
802.11 frames via a different firmware path that handles all WCIDs
correctly, including TDLS peers.

mt792x_init_wiphy() is shared with the Connac2 family (mt7921/22/20/02),
which uses the same firmware HW_ENCAP path; the disable is applied
globally to cover the likely-affected chips. If Connac2 is later
confirmed unaffected, the disable can be narrowed with is_mt7925().

Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support")
Cc: stable@vger.kernel.org
Signed-off-by: ElXreno <elxreno@gmail.com>
Assisted-by: Claude:claude-opus-4-7 bpftrace
---
 drivers/net/wireless/mediatek/mt76/mt792x_core.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
index 152cfcca2f90..f9610c6c1597 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
@@ -681,8 +681,14 @@ int mt792x_init_wiphy(struct ieee80211_hw *hw)
 
 	ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS);
 	ieee80211_hw_set(hw, HAS_RATE_CONTROL);
-	ieee80211_hw_set(hw, SUPPORTS_TX_ENCAP_OFFLOAD);
-	ieee80211_hw_set(hw, SUPPORTS_RX_DECAP_OFFLOAD);
+	/* HW TX/RX 802.11 encap offload is intentionally NOT advertised:
+	 * the firmware HW_80211_ENCAP path silently drops QoS Data frames
+	 * whose destination WCID is a TDLS direct-link peer, breaking TDLS
+	 * data flow. The mac80211 software encap path submits already-formed
+	 * 802.11 frames, which the firmware handles correctly for all WCIDs.
+	 * Re-add SUPPORTS_TX_ENCAP_OFFLOAD / SUPPORTS_RX_DECAP_OFFLOAD here
+	 * once the firmware HW_ENCAP path is fixed.
+	 */
 	ieee80211_hw_set(hw, WANT_MONITOR_VIF);
 	ieee80211_hw_set(hw, SUPPORTS_PS);
 	ieee80211_hw_set(hw, SUPPORTS_DYNAMIC_PS);

-- 
2.53.0

Re: [PATCH 1/2] wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link

[Sean Wang]

Hi ElXreno,

On Sat, May 2, 2026 at 8:40 PM ElXreno <elxreno@gmail.com> wrote:
>
> On MediaTek MT7925 (Connac3), QoS Data frames whose destination WCID
> is a TDLS direct-link peer are silently dropped after submission to
> firmware via the HW_80211_ENCAP TX path. The driver sees submit and
> complete counts match (firmware reports success on TX queue
> submission), but the frames never reach the PHY. iw counters show
> tx_packets growing, tx_failed = 0, tx_retries low; on the air,
> nothing.
>
> This breaks TDLS direct-link as soon as a peer auto-initiates one
> (Samsung phones do this aggressively when both peers share a BSS and
> traffic exceeds a threshold). Pattern is:
>
>   1. Any sustained direct traffic between two STAs sharing the BSS
>      reaches the auto-TDLS threshold within ~1 s.
>   2. Peer initiates TDLS; mac80211 routes data frames to the TDLS-peer
>      WCID and the AP stops forwarding peer-to-peer traffic per the
>      802.11z spec.
>   3. Direct-link frames are accepted by firmware, completed in the TX
>      descriptor pool, but never PHY-transmitted.
>   4. TCP collapses; the peer eventually tears down the TDLS link with
>      reason WLAN_REASON_TDLS_TEARDOWN_UNSPECIFIED. Cycle repeats.
>
> Effective TCP throughput drops from ~300 Mbit/s (AP route) to ~6
> Mbit/s with TDLS active.
>
> Verified on mt7925e (PCIe) at 5 GHz HE NSS 2 MCS 11 80 MHz and at
> 2.4 GHz 802.11n HT NSS 2 MCS 15. With this patch, TDLS direct link
> sustains ~750 Mbit/s and ~130 Mbit/s respectively.
>
> mt76 advertises WIPHY_FLAG_SUPPORTS_TDLS via the shared
> mt76_register_phy_helper() but does not provide TDLS-aware
> firmware-facing peer setup: no CONNECTION_TDLS constant in
> mt76_connac_mcu.h, no STA_REC_TDLS TLV, no TDLS bit in
> mt76_wcid_flags, and no TDLS-specific code in
> mt7925_mac_write_txwi_8023(). TDLS peers are registered as
> CONNECTION_INFRA_STA with peer_addr set to the peer's MAC and
> nothing else. The proprietary out-of-tree MediaTek driver carries an
> explicit cfg80211_tdls.c (PTK/TK install paths, etc.) with no
> in-tree equivalent. Whether the underlying gap is in the firmware
> HW_ENCAP path or in mt76's missing TDLS-aware setup is unclear from
> the kernel side; the software-encap path sidesteps it either way.
>
> Work around the issue by not advertising SUPPORTS_TX_ENCAP_OFFLOAD
> and SUPPORTS_RX_DECAP_OFFLOAD in mt792x_init_wiphy(). mac80211 then
> takes the software 802.11 encap path, which submits already-formed
> 802.11 frames via a different firmware path that handles all WCIDs
> correctly, including TDLS peers.
>
> mt792x_init_wiphy() is shared with the Connac2 family (mt7921/22/20/02),
> which uses the same firmware HW_ENCAP path; the disable is applied
> globally to cover the likely-affected chips. If Connac2 is later
> confirmed unaffected, the disable can be narrowed with is_mt7925().
>
> Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support")
> Cc: stable@vger.kernel.org
> Signed-off-by: ElXreno <elxreno@gmail.com>
> Assisted-by: Claude:claude-opus-4-7 bpftrace
> ---
>  drivers/net/wireless/mediatek/mt76/mt792x_core.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
> index 152cfcca2f90..f9610c6c1597 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
> @@ -681,8 +681,14 @@ int mt792x_init_wiphy(struct ieee80211_hw *hw)
>
>         ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS);
>         ieee80211_hw_set(hw, HAS_RATE_CONTROL);
> -       ieee80211_hw_set(hw, SUPPORTS_TX_ENCAP_OFFLOAD);
> -       ieee80211_hw_set(hw, SUPPORTS_RX_DECAP_OFFLOAD);
> +       /* HW TX/RX 802.11 encap offload is intentionally NOT advertised:
> +        * the firmware HW_80211_ENCAP path silently drops QoS Data frames
> +        * whose destination WCID is a TDLS direct-link peer, breaking TDLS
> +        * data flow. The mac80211 software encap path submits already-formed
> +        * 802.11 frames, which the firmware handles correctly for all WCIDs.
> +        * Re-add SUPPORTS_TX_ENCAP_OFFLOAD / SUPPORTS_RX_DECAP_OFFLOAD here
> +        * once the firmware HW_ENCAP path is fixed.
> +        */

I do not think disabling TX/RX encap offload globally in
mt792x_init_wiphy() is the right fix.

The reported failure is specific to TDLS direct-link peers, while this
change affects all normal STA/AP/P2P data paths and all mt792x chips,
including mt7925/mt7921/22/20/02. This is too broad for a TDLS-specific issue.

The commit message already points out that mt76 lacks TDLS-aware
firmware-facing peer setup, and also mentions that the proprietary
out-of-tree MediaTek driver has an explicit cfg80211_tdls.c
implementation. If that driver supports TDLS on top of the firmware HW
encap model, I think we should try to align the in-tree driver with that
design by adding the missing TDLS-aware firmware-facing peer setup,
instead of disabling HW encap globally.

In particular, I would prefer to first check whether adding
CONNECTION_TDLS / proper TDLS peer setup on top of the current code is
enough to fix the issue.

Please avoid removing SUPPORTS_TX_ENCAP_OFFLOAD and
SUPPORTS_RX_DECAP_OFFLOAD globally from mt792x_init_wiphy().

>         ieee80211_hw_set(hw, WANT_MONITOR_VIF);
>         ieee80211_hw_set(hw, SUPPORTS_PS);
>         ieee80211_hw_set(hw, SUPPORTS_DYNAMIC_PS);
>
> --
> 2.53.0
>
>

[PATCH 2/2] wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer

[ElXreno]

On a STATION vif, removing a TDLS peer takes the mt7925_mac_sta_remove
-> mt7925_mac_sta_remove_links path. The first loop in that function
calls mt7925_mcu_add_bss_info(..., enable=false) for every link of the
station being removed. For a non-MLO STATION vif there is exactly one
link, link 0, whose bss_conf is the AP's. TDLS peers do not have their
own bss_conf - they share the AP's BSS.

The result is that every TDLS peer teardown sends a BSS_INFO_UPDATE
with enable=0 for the AP's BSS to the firmware, which wipes the AP-side
rate-control context. The connection stays associated and TX from the
host still works at the negotiated rate, but the AP's downlink to us
collapses to the lowest mandatory OFDM rate (HE-MCS 0 / 6 Mbit/s OFDM)
and only slowly recovers as rate adaptation re-learns under sustained
traffic. With brief or bursty traffic the link can stay at 6-72 Mbit/s
indefinitely, requiring a manual reconnect.

mt7925_mac_link_sta_remove() already guards its own
mt7925_mcu_add_bss_info(..., false) call with
"vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls".
Add the equivalent guard at the top of the cleanup loop in
mt7925_mac_sta_remove_links(), above the link_sta / link_conf /
mlink / mconf lookups, so TDLS peer teardown skips the loop body
entirely without doing the per-link work that would just be thrown
away.

Verified on mt7925e by triggering Samsung-S938B auto-TDLS via iperf3
and watching iw rx bitrate after teardown:

  Before: rx bitrate collapses to 6.0-72.0 Mbit/s, oscillates 17/72/
          137/288/432 Mbit/s for 30+ seconds, no full recovery without
          an NM reconnect.
  After:  rx bitrate stays at 1200.9 Mbit/s HE-MCS 11 NSS 2 80 MHz
          across the entire TDLS lifecycle.

bpftrace confirms a single mt7925_mcu_add_bss_info(enable=0) call per
teardown before the fix; zero such calls after.

Fixes: 3878b4333602 ("wifi: mt76: mt7925: update mt7925_mac_link_sta_[add, assoc, remove] for MLO")
Cc: stable@vger.kernel.org
Signed-off-by: ElXreno <elxreno@gmail.com>
Assisted-by: Claude:claude-opus-4-7 bpftrace
---
 drivers/net/wireless/mediatek/mt76/mt7925/main.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 73d3722739d0..7220bf2c0afa 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1265,6 +1265,16 @@ mt7925_mac_sta_remove_links(struct mt792x_dev *dev, struct ieee80211_vif *vif,
 		if (vif->type == NL80211_IFTYPE_AP)
 			break;
 
+		/* TDLS peers on a STATION vif share the AP's bss_conf. The
+		 * link_conf retrieved below would be the AP's, and calling
+		 * mcu_add_bss_info(..., false) for a TDLS peer teardown
+		 * would disable the AP's BSS in firmware, wiping its
+		 * rate-control context. mt7925_mac_link_sta_remove() has
+		 * the symmetric guard for its own bss-info call.
+		 */
+		if (vif->type == NL80211_IFTYPE_STATION && sta->tdls)
+			continue;
+
 		link_sta = mt792x_sta_to_link_sta(vif, sta, link_id);
 		if (!link_sta)
 			continue;

-- 
2.53.0