From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A88C929ACCD; Sat, 14 Feb 2026 21:26:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771104407; cv=none; b=MLgemPS2S3FxE+6AbtRWD6i6InsZWNkWnw3Pw6lNytnEd2VR9B2XCnutrEkDnMo+xuHNEywbdMlLj/nf5YQtu4mg8hHumIhJCXMhIkEw9HPkkr3tA8+TFsbaW7RdSYZhNDyk/7llKuNtFQCF4EcOdNR8HUtRBo3OPOjdcCkLwg8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771104407; c=relaxed/simple; bh=QNXAx61yo62+yAikrJh8S4s0QLVV0NqOQfBJAkGUL0M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Z2ChZvT4+nxOUW203vAidMm91mX67nbK1ZYbNRP3wU6EbochCweOzivq5l+couI/ILfPvT/i5sBzbi0NodfKJjS2BtsfBRPw/UVuDaiSJmY+hV5bUsU5V/tGoLOttjEzl/tuT0cB1bda8x4Z0Zx3T9q37tIlBCLl5XuFNDkt22Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tEHAfpoj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tEHAfpoj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4EEAC19423; Sat, 14 Feb 2026 21:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771104407; bh=QNXAx61yo62+yAikrJh8S4s0QLVV0NqOQfBJAkGUL0M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tEHAfpojozXVrKPFC1wV5QOdPFr1ZEQZgWUFE6v+Hf8QLBUpnYdFX/zt9EAibaInI iD2sF1/8MkxIfRQP9zROppe2eVEvoO7/5xL8F0mPEUtPBmuHx8k6U+gq/NbqUheSex 5dliuK5J/8E8nSB7JuIjJyJGBXQQY+D0C4uqnXFMRXV82KKzfI+6z+/xLMjaiBzVjj ELeVj4GEIRPvAU4dOxhUXSlKGN5CNWGDSELV4NffrXrn6dD+m8brjsF4QZUciFd96M CvnZs5+YRgvJDhmikPlBykc88irbbBQfLkLr9ORN/F6Ev12eWaMQ3k+qTCeUlhSEXR FQf3L73OnaTqQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Po-Hao Huang , Ping-Ke Shih , Sasha Levin , linux-wireless@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-6.12] wifi: rtw89: fix unable to receive probe responses under MLO connection Date: Sat, 14 Feb 2026 16:23:32 -0500 Message-ID: <20260214212452.782265-67-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260214212452.782265-1-sashal@kernel.org> References: <20260214212452.782265-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-wireless@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Po-Hao Huang [ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Analysis of commit: "wifi: rtw89: fix unable to receive probe responses under MLO connection" ### 1. Commit Message Analysis The commit message is clear and describes a real user-visible bug: - **Problem**: During MLO (Multi-Link Operation) connections, probe responses have A1 (destination address) set to the link address, but mac80211's `ieee80211_scan_accept_presp()` checks against the MLD address. This causes all probe responses to be dropped during scanning. - **Impact**: WiFi scanning is completely broken under MLO connections — the device cannot receive probe responses, which means it cannot discover or reconnect to access points while in an MLO connection. - **Fix**: Use the MLD address (from `vif->addr`) instead of the link address when initiating scans under MLO, unless random MAC scanning is requested. The word "fix" is in the subject, and the description clearly explains a real functional bug. ### 2. Code Change Analysis The change is minimal and surgical: 1. **One new variable declaration**: `struct ieee80211_vif *vif = rtwvif_link_to_vif(rtwvif_link);` — retrieves the VIF structure to access the MLD address. 2. **Two new lines of logic** added to the MAC address selection: ```c else if (ieee80211_vif_is_mld(vif)) ether_addr_copy(mac_addr, vif->addr); ``` This is inserted between the random MAC address case and the default link address case. The logic flow becomes: - If random MAC scanning → use random MAC (unchanged) - **NEW**: If MLO connection → use MLD address (`vif->addr`) - Else → use link address (unchanged, existing behavior) This is a clean, well-structured conditional addition that doesn't alter existing behavior for non-MLO cases. ### 3. Classification This is a **bug fix** — it fixes broken WiFi scanning functionality under MLO connections. Without this fix, probe responses are silently dropped, making scanning non-functional in MLO mode. ### 4. Scope and Risk Assessment - **Lines changed**: ~4 lines (1 variable declaration, 2 lines of new conditional logic, 1 existing line unchanged) - **Files changed**: 1 file (`drivers/net/wireless/realtek/rtw89/fw.c`) - **Risk**: Very low. The change only affects the MLO path (guarded by `ieee80211_vif_is_mld()`), so non-MLO operation is completely unaffected. The fix is logically correct — when in MLO mode, using the MLD address is the right thing to do since that's what mac80211 expects. ### 5. User Impact - **Who is affected**: Users of Realtek rtw89 WiFi adapters using MLO (WiFi 7 / 802.11be) connections. - **Severity**: High for affected users — scanning is completely broken under MLO, meaning the device can't discover networks while connected via MLO. - **Growing user base**: As WiFi 7 adoption grows, more users will encounter this issue. ### 6. Stability Indicators - **Author**: Po-Hao Huang (phhuang@realtek.com) — Realtek engineer with deep knowledge of the driver - **Signed-off-by**: Ping-Ke Shih (pkshih@realtek.com) — the rtw89 maintainer - **Link**: Proper patch submission via mailing list ### 7. Dependency Check The change uses: - `rtwvif_link_to_vif()` — likely a helper that exists in the driver - `ieee80211_vif_is_mld()` — a mac80211 API function - `vif->addr` — standard VIF field The key question is whether MLO support (and `ieee80211_vif_is_mld()`) exists in stable trees. MLO/WiFi 7 support is relatively recent (merged in 6.5+ timeframe). This fix would only be relevant for stable trees that already have MLO support in rtw89. ### 8. Stable Kernel Criteria Assessment - **Obviously correct**: Yes — using MLD address for MLO scans is the correct behavior per 802.11be spec - **Fixes a real bug**: Yes — scanning is completely broken under MLO - **Small and contained**: Yes — 4 lines in 1 file - **No new features**: Correct — this fixes existing MLO scanning functionality - **Tested**: Yes — from Realtek engineers, went through mainline ### Conclusion This is a small, surgical, well-understood bug fix that addresses a complete functional failure (broken WiFi scanning under MLO connections). It affects only MLO paths, has zero risk to non-MLO users, and is authored by the hardware vendor's driver team. It meets all stable kernel criteria for backporting (to kernels that have MLO support in rtw89). **YES** drivers/net/wireless/realtek/rtw89/fw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c index 7b9d9989e5170..2f68a04cc028f 100644 --- a/drivers/net/wireless/realtek/rtw89/fw.c +++ b/drivers/net/wireless/realtek/rtw89/fw.c @@ -8114,6 +8114,7 @@ int rtw89_hw_scan_start(struct rtw89_dev *rtwdev, struct cfg80211_scan_request *req = &scan_req->req; const struct rtw89_chan *chan = rtw89_chan_get(rtwdev, rtwvif_link->chanctx_idx); + struct ieee80211_vif *vif = rtwvif_link_to_vif(rtwvif_link); struct rtw89_vif *rtwvif = rtwvif_link->rtwvif; struct rtw89_chanctx_pause_parm pause_parm = { .rsn = RTW89_CHANCTX_PAUSE_REASON_HW_SCAN, @@ -8142,6 +8143,8 @@ int rtw89_hw_scan_start(struct rtw89_dev *rtwdev, if (req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) get_random_mask_addr(mac_addr, req->mac_addr, req->mac_addr_mask); + else if (ieee80211_vif_is_mld(vif)) + ether_addr_copy(mac_addr, vif->addr); else ether_addr_copy(mac_addr, rtwvif_link->mac_addr); -- 2.51.0