Linux-mediatek Archive mirror
 help / color / mirror / Atom feed
From: Sean Wang <sean.wang@kernel.org>
To: ElXreno <elxreno@gmail.com>
Cc: Felix Fietkau <nbd@nbd.name>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>,
	 Shayne Chen <shayne.chen@mediatek.com>,
	Sean Wang <sean.wang@mediatek.com>,
	 Matthias Brugger <matthias.bgg@gmail.com>,
	 AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	 Soul Huang <Soul.Huang@mediatek.com>,
	Ming Yen Hsieh <mingyen.hsieh@mediatek.com>,
	 Deren Wu <deren.wu@mediatek.com>,
	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
Subject: Re: [PATCH 1/2] wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link
Date: Sun, 3 May 2026 12:53:57 -0500	[thread overview]
Message-ID: <CAGp9LzogKfGovfDw+=m4BkqWAakFTStXH20cQ_FA_5-zo+rmGA@mail.gmail.com> (raw)
In-Reply-To: <20260503-mt7925-tdls-fixes-v1-1-dde847e21081@gmail.com>

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
>
>


  reply	other threads:[~2026-05-03 17:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-03  1:38 [PATCH 0/2] wifi: mt76: fix TDLS direct-link on MediaTek MT7925 ElXreno
2026-05-03  1:38 ` [PATCH 1/2] wifi: mt76: mt792x: disable HW TX/RX encap offload to fix TDLS direct-link ElXreno
2026-05-03 17:53   ` Sean Wang [this message]
2026-05-06  1:00     ` ElXreno
2026-05-03  1:38 ` [PATCH 2/2] wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer ElXreno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGp9LzogKfGovfDw+=m4BkqWAakFTStXH20cQ_FA_5-zo+rmGA@mail.gmail.com' \
    --to=sean.wang@kernel.org \
    --cc=Soul.Huang@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=deren.wu@mediatek.com \
    --cc=elxreno@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mingyen.hsieh@mediatek.com \
    --cc=nbd@nbd.name \
    --cc=ryder.lee@mediatek.com \
    --cc=sean.wang@mediatek.com \
    --cc=shayne.chen@mediatek.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).