From nobody Sun Jun 14 06:08:23 2026 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 BA9481E5018 for ; Sun, 3 May 2026 01:39:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777772372; cv=none; b=Paz4bD+Dklqg91G45IiUGLLDCI2ABk1Imy0Qu9a0+8zeIahHO3OxkJsGyaEW0dA3OkIleUWVQTMenkZiZgx7jm1pvWTdzm4DrubqqWndC4iGxygW0FYjW0TXT8tpTrNJp7efo5grz0fU+3tZ1TDbFw2a35rCnj4KFMUs6jNyvbc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777772372; c=relaxed/simple; bh=7uwJxgvTxpOn6gNEIOPNEioHiEozfkGob7zPtdELUWI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=s/t9uS9ZPtQkHFN2Z0NVCHEqsiIwFc2pOV9A2z+eXyHRByAhcSyPh3PX140OwhGp7iqxBTalrfsZS/+KSnYFPWZ6xFJ3r9iLRvYOmxD9/1/AjjXSuoJtHCj7XluT6PN3ZD+U50kFiA56MGNRzYwcckAR6DVN2km2J0xNUmM5hhA= ARC-Authentication-Results: i=1; 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=Z6TYdVQ6; arc=none smtp.client-ip=209.85.208.46 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="Z6TYdVQ6" Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-67389cf78b0so5880573a12.2 for ; Sat, 02 May 2026 18:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777772368; x=1778377168; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=mCD/2g9DiH7IGmCylqgN8SVqRAlReG1YJkLOG3TO9pw=; b=Z6TYdVQ67nfpyM+Eky4qqdjd4e497GCIMbYd4QHCVjZ6qs01j1aYs6VUHihBfs22sX 9M5m/ZrQwC+YCE7X09PIrjZOYgS1Q9foAsm6n/AKPzfLe6TuwDKH+Q7h1WIINYGIBGrC CQOUeEYYeL682Np0WzDsw5iRytj7XeK+vtzf1qYuK6OVSYdspCeRuPDd6ImpDBHwvwAb MkvTJUviwS0m4Txd+0U4OzZFMOedbM/aereboqo7dDWT5NZhoI8hoJhSBvHzmksk3EAE 8oRORoxChAnGp3Wn8dbYSEDrJOxECSJtCzG88fPA+6ctaKhcbLRDP3u8PXyld7ncHT1o inkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777772368; x=1778377168; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=mCD/2g9DiH7IGmCylqgN8SVqRAlReG1YJkLOG3TO9pw=; b=IO99xOoZ5LYK9lQR9V3chTWTY8bftFyopou9D2qOJRTzxrz6lFPaeyZvE69+BVpV1P HwxTYRMF4gGdmJCSYLfz1eu2/SGkrXDp2mDOcU/xEN3YXekEaRgmqEiuY/t7SDQGOM5b JCObgfgIYAjd+IsVpF+GFr5GRKG6itTpuYkT1Ds/JziT03Kxk4XUhoV2zdi8+Rd9BfBl A2Ipu5qmvu4BEl0FR7tAI8ek2ZFyPweAoLFhrVnURCgLLmRIR8ohrW8Fl8mUeGMp/4U9 iESOs54KRXEH14gJBWNd3LN9gbLC+2e27IHs+c+5qyETuqYgvlBoEvGUf5bM/M6vzyHx LdiA== X-Forwarded-Encrypted: i=1; AFNElJ8NqmJLAe9c01l+FW3Appt0DMyj+fuXx/B/kG6A4GRr8GqAL5acxJ7ZxaGKIUSzXCHtaJy7iyM6Jcm7f+A=@vger.kernel.org X-Gm-Message-State: AOJu0YzqcizWCb3ssc6XtK7bRRc5xwuVlUq9nPFTHfEAlmYEI9ducbI4 B3fTy7PAde20osWfXE5Dw25k2jmX0gFQzfaRp1/5HpJhIqhA2InxcD6T X-Gm-Gg: AeBDieuknrhXy3ED4kuJ4aA8R2PP9qCCdzQ9GZzoONui4ir9wMG3dFVmN01t7B8jcoA u4Z8zULA4T6Lf+GK+zstI9+KRTeymPkw3OysWBeTulQ25t44LkowUnjo/Bj7KXESnhFbkwUI1OU 65J/ZJBjxD8QiJH0DcpS7c5AQ95eE+w0BegvD8DATN30sqGswYrGUxrzqMRoTro6306Lsjlzm3B TxE7Yre2KsLsgSMZ4ySWN9DFxHfztZux715RfHQn+Ir+064ip9MaNsRfFgGbOglQT+2Scmmk/qv zQ1B+Rf1bkH1yRHpjTge9WVU4fc8/GMCnr0dKcTU34CzdJLvdKirx/Q8XYvU0ouSSVC8WCuU2Pn eN2kzrITzCtbNv7IGKCz4repK+xfC3mA7jaMq6tUbP0rmjBrkX9Ro+VUVm/jSocA7BCY1hpMDSH BwoTYpSKABXTMqRIoRUok+Zb1RrBFungB1Fnt8GxN06cP58LgX6eVkXaLBc6aTGL3v/74Iiq8sV QvRq4UGomsFV+PE71h1bkVwQhbg X-Received: by 2002:a17:907:198c:b0:b9e:8e4:8765 with SMTP id a640c23a62f3a-bbffb23fe1amr237176266b.10.1777772368030; Sat, 02 May 2026 18:39:28 -0700 (PDT) Received: from KURWA.angora-ide.ts.net (mm-39-71-126-178.vitebsk.dynamic.pppoe.byfly.by. [178.126.71.39]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bc1671c1d3esm24796466b.42.2026.05.02.18.39.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 May 2026 18:39:27 -0700 (PDT) From: ElXreno Date: Sun, 03 May 2026 04:38:30 +0300 Subject: [PATCH 1/2] wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link 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" Content-Transfer-Encoding: quoted-printable Message-Id: <20260503-mt7925-tdls-fixes-v1-1-dde847e21081@gmail.com> References: <20260503-mt7925-tdls-fixes-v1-0-dde847e21081@gmail.com> In-Reply-To: <20260503-mt7925-tdls-fixes-v1-0-dde847e21081@gmail.com> To: Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Matthias Brugger , AngeloGioacchino Del Regno , Soul Huang , Ming Yen Hsieh , Deren Wu Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, stable@vger.kernel.org, ElXreno X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4215; i=elxreno@gmail.com; h=from:subject:message-id; bh=7uwJxgvTxpOn6gNEIOPNEioHiEozfkGob7zPtdELUWI=; b=owJ4nJvAy8zAJXa0WDmKX5v/EeNptSSGzG/LfTNMDDbv83x9t8ziV+VZJeNKo5MB9cwrXz83n G6x792x7W4dpSwMYlwMsmKKLDzn9tbmLKtbMrmeKwNmDisTyBAGLk4BmEgYD8P/JKl3nJpLa/Ka bl5Idnp1ekbCjzrz/qdJrJfP1259uTL4GsP/7BX+oeF7w3Y+5euOWn36UPq8FvE7J+wZ5pQrrju 6pUKAFQAL90r/ X-Developer-Key: i=elxreno@gmail.com; a=openpgp; fpr=0CCEBD7D6CA67EA4937F0A68C573235A0F2B0FE2 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 =3D 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 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) =20 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); --=20 2.53.0 From nobody Sun Jun 14 06:08:23 2026 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (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 F4223245012 for ; Sun, 3 May 2026 01:39:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777772373; cv=none; b=FYaDx8ee7HJOkW3WDPz9MOT5+Z+G9PJZpvvazcMXC/xOyCnBcEEi2AZzBeEc3VluvdO3UL72i2JRwmyfmYsiqB+vPkPDBvOpUL642rqymR2FvdqkQG9ajyQLLCNDBBozlCXhvZuS3o82LHOMcZNJgtLGQ9dmJLNX8BvX7/rdCjc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777772373; c=relaxed/simple; bh=uAMNZJNELeTW91RepEFHxSC/5cFK8pGWTHntf3vPjy0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XMbvb4oxlLhTuIrwjxvR7fev/kgOu9dBeuFQ3uvYxABu+siaTHeZkxG9QqeDIYDr3x6vGHL0AcLpLMtm1GtryFLF8ObmY5eTWQbEy133DUrPqErstKZi5salYHltURxL3EYNyxh5sSS5s7CJ7kFMMXsQMMeFRNX1hKMEIwG8VAw= ARC-Authentication-Results: i=1; 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=fLpPy3SN; arc=none smtp.client-ip=209.85.218.42 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="fLpPy3SN" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-b9c3a9fe80fso456485266b.3 for ; Sat, 02 May 2026 18:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777772369; x=1778377169; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=IkJvgTcI4nUUQ/9kKtwsMfSDSEk8uVrEpeWRMA7wuFg=; b=fLpPy3SNgOV03pbBxbrVcQffTMp0jHYaYs/K4qlIuvEF1esVOemrPYzlEh8N9PqCat 24KEMOFRrkn/0RWBJS/5sfE308B4P94CABsQv1UZ2ypRXxSBjDQxPg0wHXQUeVnVd1zc uzQ5FLcSHfKJiHOvVtjvzbAYcB4XuWCAa4QmmT4FX/qNtKxdGqtidi/RCM9IuP8tzyW/ Iy5iGMpWVakIcJSayyG6QUaFOL9E3GMpVYrx+5B8H1JxsUmrtTWPRQHwf5FUB9swjeD1 tS+5Ky7EvTU4a5qJoOxPh6zU5xdH4Mk4lassITUrzt+ds8jiw7vIfFaT31pB+BjfsYvV a97Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777772369; x=1778377169; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=IkJvgTcI4nUUQ/9kKtwsMfSDSEk8uVrEpeWRMA7wuFg=; b=Yau4DB0KqAlAKybK0dxVp/PnPl4FbDdFWEUpO0aBby09NuQRJbX/IclSrT+05xkuZV 6BPgqdDAtTTflGChGFDtHl2wLcy4epv38v1L0Ch4QnawiaOranCL9rhSrJr4TZT6jZTj zYNiGYHdhIKnpuola1G4wnxgpaiO/y9Jyp1uV+CIY+Y1N0WCCgC+MWkPzVIN2KFMV/kD x8FzVL81UyJjO30i2e0mEzp4ubboeZAiEqGm02kjWpOTcQjCfuVBF6Tuppf4g/HFPBxk bS6jWEMA1WkyU2laBclO3IoQGh11RerBgpGmvWNJdeBzKJiGIdsZdyC5CrgBJ0I/ch16 5xTg== X-Forwarded-Encrypted: i=1; AFNElJ+oKDzxg3nnDqbgz+6vIBejp9WuDYW3BbXmYP+jLZTyWprzhaPa9N1w3MKqInG4YMuhDBicUzVlc3zRqeA=@vger.kernel.org X-Gm-Message-State: AOJu0YwzUR3+2Y+991RzjV8Cip7ZB0TaZASIQSu6TkicMMotktMkHt0x Ne1HPjSnwUlUlMgwSjeemAQvluVLum7+ITvw+ydFcinnHvr8aP3HEDTh X-Gm-Gg: AeBDiesU4gyX72o4bal+1rJf10qKa8SuH8Okt1rhhI0GZrZzZcWGf3u1VJ40PKneyB1 pimYhG15gpT+D87qQZX0vuTp8rrsLZpb9RvVX/E/heGAtAHo+FxSBhp6avYcg7R9oTT9tZKcx3/ kRmVlE5T6QeMGw2sgTqbLJ2DoIQioU0kNIAspif6JLPGgycqzDlYpp8VU0bDTeDaJkMjqinTjlq Fz7W5zuVyFQSIfmci5GG2cgU+5pod9J/IXLwb/IsleGs+zejz7AKL4ZYZ+dniWjBpLdItLj2vc6 Ao41Xo5CdB5gT82Q7a4KNCxxWdNA5uRGYNSmQiJbTzwOESiM7zvH9V5Om4WjDmcp9JNQPqoLAKd jTXXbQPTW2BioeYh0TG2x6Zx2vZSeVOZWaveAAl0llc4Iuqgu3Om77vcqGN/tcO3mubl7E0kTAd 4WCAf2kQHcZnpkUlVv0E05rcjXHshXIw32oDfcIXqS7qWVlrK0pf5r/FlFLXfHLxcTAtuZuHdJ5 D6XtAR5qvL6q083heoZ/10EhFWd X-Received: by 2002:a17:907:a06:b0:bb9:c62:2c04 with SMTP id a640c23a62f3a-bbff9933024mr206200166b.10.1777772369341; Sat, 02 May 2026 18:39:29 -0700 (PDT) Received: from KURWA.angora-ide.ts.net (mm-39-71-126-178.vitebsk.dynamic.pppoe.byfly.by. [178.126.71.39]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bc1671c1d3esm24796466b.42.2026.05.02.18.39.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 May 2026 18:39:28 -0700 (PDT) From: ElXreno Date: Sun, 03 May 2026 04:38:31 +0300 Subject: [PATCH 2/2] wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer 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" Content-Transfer-Encoding: quoted-printable Message-Id: <20260503-mt7925-tdls-fixes-v1-2-dde847e21081@gmail.com> References: <20260503-mt7925-tdls-fixes-v1-0-dde847e21081@gmail.com> In-Reply-To: <20260503-mt7925-tdls-fixes-v1-0-dde847e21081@gmail.com> To: Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Matthias Brugger , AngeloGioacchino Del Regno , Soul Huang , Ming Yen Hsieh , Deren Wu Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, stable@vger.kernel.org, ElXreno X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3207; i=elxreno@gmail.com; h=from:subject:message-id; bh=uAMNZJNELeTW91RepEFHxSC/5cFK8pGWTHntf3vPjy0=; b=owJ4nJvAy8zAJXa0WDmKX5v/EeNptSSGzG/LfVlS+BMnzPKMFGComFxwcnOSX4zj+c2njmcvL HFa2jGR+WFHKQuDGBeDrJgiC8+5vbU5y+qWTK7nyoCZw8oEMoSBi1MAJiLxiZFhqnGD+9dv22e8 j+faISvyxHGrrHJ7m+aGV2l35AQm9F8MYvgf69L9rHvtLQuly6/WCE3Q4GHeHtf+XJMp2rL+pbb 3MxUeAFDqRN8= X-Developer-Key: i=elxreno@gmail.com; a=openpgp; fpr=0CCEBD7D6CA67EA4937F0A68C573235A0F2B0FE2 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=3Dfalse) 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=3D0 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 =3D=3D 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=3D0) 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 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 =3D=3D NL80211_IFTYPE_AP) break; =20 + /* 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 =3D=3D NL80211_IFTYPE_STATION && sta->tdls) + continue; + link_sta =3D mt792x_sta_to_link_sta(vif, sta, link_id); if (!link_sta) continue; --=20 2.53.0