[PATCH AUTOSEL 6.19-6.12] wifi: rtw89: fix unable to receive probe responses under MLO connection

[Sasha Levin <sashal@kernel.org>]

From: Po-Hao Huang <phhuang@realtek.com>

[ 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 <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

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