public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Ramanathan Choodamani <quic_rchoodam@quicinc.com>,
	Aishwarya R <aishwarya.r@oss.qualcomm.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Sasha Levin <sashal@kernel.org>,
	johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.1] wifi: mac80211: set default WMM parameters on all links
Date: Thu,  5 Mar 2026 10:36:47 -0500	[thread overview]
Message-ID: <20260305153704.106918-4-sashal@kernel.org> (raw)
In-Reply-To: <20260305153704.106918-1-sashal@kernel.org>

From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>

[ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ]

Currently, mac80211 only initializes default WMM parameters
on the deflink during do_open(). For MLO cases, this
leaves the additional links without proper WMM defaults
if hostapd does not supply per-link WMM parameters, leading
to inconsistent QoS behavior across links.

Set default WMM parameters for each link during
ieee80211_vif_update_links(), because this ensures all
individual links in an MLD have valid WMM settings during
bring-up and behave consistently across different BSS.

Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit fixes

In WiFi 7 Multi-Link Operation (MLO), mac80211 creates multiple links
per interface. During `do_open()` (iface.c:1519), default WMM (QoS)
parameters are only set on `sdata->deflink`. When additional links are
created via `ieee80211_vif_update_links()`, they never receive WMM
defaults. If hostapd doesn't explicitly configure per-link WMM
parameters, these secondary links operate with uninitialized/zeroed QoS
settings, causing inconsistent behavior across links.

### The fix

Two lines added to `ieee80211_vif_update_links()` in
`net/mac80211/link.c`:
1. A `bool non_sta` variable (mirrors the pattern at iface.c:1520)
2. A call to `ieee80211_set_wmm_default(&link->data, true, non_sta)` in
   the loop that initializes new links (line 340)

This is an exact mirror of what `do_open()` does for the deflink,
ensuring all newly allocated links get the same WMM defaults.

### Stable kernel criteria assessment

- **Fixes a real bug**: Yes — secondary MLO links have uninitialized WMM
  params leading to broken QoS behavior
- **Obviously correct**: Yes — mirrors existing call pattern from
  `do_open()`, same function, same parameter semantics
- **Small and contained**: Yes — 2 lines in a single file
- **No new features**: Correct — just initializing existing structures
  that were missed
- **Risk**: Very low — `ieee80211_set_wmm_default()` is called from many
  places already (iface.c, ibss.c, mlme.c) and is well-tested

### Scope and impact

MLO is increasingly used in WiFi 7 deployments. Without this fix, AP
operators using MLO who rely on mac80211 defaults (instead of explicit
hostapd WMM config per link) get broken QoS on secondary links. This
affects throughput prioritization for video, voice, and background
traffic on those links.

### Dependencies

The fix requires MLO infrastructure which was introduced around v6.1
(2022). The `ieee80211_vif_update_links()` function exists in
net/mac80211/link.c which was created in September 2022. Any stable tree
with MLO support needs this fix. The patch is self-contained with no
other dependencies.

### Verification

- Confirmed via grep that `ieee80211_set_wmm_default()` is called from
  10+ locations across mac80211 (iface.c, ibss.c, mlme.c) — the function
  is mature and well-tested
- Confirmed iface.c:1519 only calls `ieee80211_set_wmm_default` on
  `&sdata->deflink`, verifying the bug claim
- Read `ieee80211_vif_update_links()` in link.c and confirmed the new
  call is placed in the correct loop (`for_each_set_bit(link_id, &add,
  ...)`) right after `ieee80211_link_init()` and
  `ieee80211_link_setup()` — same initialization phase
- Confirmed the `non_sta` variable uses the identical expression
  `sdata->vif.type != NL80211_IFTYPE_STATION` from iface.c:1520
- The commit is authored by Qualcomm engineers and merged by Johannes
  Berg (mac80211 maintainer), indicating proper review
- Could NOT verify exact stable tree versions containing MLO
  infrastructure (unverified, but MLO was introduced ~v6.1)

### Conclusion

This is a clear, surgical bug fix for missing initialization of WMM
parameters on MLO secondary links. It's 2 lines, mirrors existing well-
tested patterns, was reviewed by the mac80211 maintainer, and fixes real
QoS issues for MLO deployments. Low risk, clear benefit.

**YES**

 net/mac80211/link.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/link.c b/net/mac80211/link.c
index 1e05845872afc..b659497680b51 100644
--- a/net/mac80211/link.c
+++ b/net/mac80211/link.c
@@ -281,6 +281,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
 	struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
 	struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
 	bool use_deflink = old_links == 0; /* set for error case */
+	bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
 
 	lockdep_assert_wiphy(sdata->local->hw.wiphy);
 
@@ -337,6 +338,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
 		link = links[link_id];
 		ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
 		ieee80211_link_setup(&link->data);
+		ieee80211_set_wmm_default(&link->data, true, non_sta);
 	}
 
 	if (new_links == 0)
-- 
2.51.0


           reply	other threads:[~2026-03-05 15:37 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20260305153704.106918-1-sashal@kernel.org>]

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=20260305153704.106918-4-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=aishwarya.r@oss.qualcomm.com \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=quic_rchoodam@quicinc.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