[PATCH AUTOSEL 7.0-6.18] wifi: ath12k: Fix the assignment of logical link index

[PATCH AUTOSEL 7.0-6.18] wifi: ath12k: Fix the assignment of logical link index

[Sasha Levin]

From: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>

[ Upstream commit aecb569d7fb689e3e5b0005ca7bd0a2ef28915e8 ]

Per-link logical index is assigned from the global counter,
ahsta->num_peer. This logical index is sent to firmware during peer
association. If there is a failure in creating a link station,
ath12k_mac_free_unassign_link_sta() clears the link, but does not decrement
the logical link index. This will result in a higher logical link index for
the next link station created. Also, if there is a leak in logical link
index as we assign the incremented num_peer, then the index can exceed the
maximum valid value of 15.

As an example, let's say we have a 2 GHz + 5 GHz + 6 GHz MLO setup. So the
logical link indices that they have are 0, 1 and 2, respectively. If the
5 GHz link is removed, logical link index 1 becomes available, and num_peer
is not reduced to 2 and still remains at 3. If a new 5 GHz link is added
later, it gets the index 3, instead of reusing link index 1. Also,
num_peer is increased to 4, though only 3 links are present.

To resolve these, create a bitmap, free_logical_link_idx, that tracks the
available logical link indices. When a link station is created, select the
first free logical index and when a link station is removed, mark its
logical link index as available by setting the bit.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1

Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226041911.2434999-1-roopni.devanathan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the final
analysis.

---

## Complete Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1:**
- Subsystem: `wifi: ath12k`
- Action verb: "Fix"
- Summary: Fixes the assignment of logical link index for MLO (Multi-
  Link Operation) link stations.

**Step 1.2: Tags:**
- `Tested-on: QCN9274 hw2.0 PCI` — hardware tested
- `Signed-off-by: Manish Dharanenthiran` — original author
- `Signed-off-by: Roopni Devanathan` — submitter
- `Reviewed-by: Rameshkumar Sundaram`, `Baochen Qiang`, `Vasanthakumar
  Thiagarajan` — 3 Qualcomm reviewers
- `Link:` to patch.msgid.link — original submission
- `Signed-off-by: Jeff Johnson` — ath12k maintainer applied it
- No Fixes: tag, no Reported-by, no syzbot, no Cc: stable — expected for
  autoselection candidates.

**Step 1.3:** The commit message describes a clear bug: `num_peer` is a
monotonically incrementing counter used to assign logical link indices.
When links are removed, the counter is never decremented, causing
"leakage" of index values. Over time with link add/remove cycles, the
index exceeds the firmware's maximum valid value of 15.

**Step 1.4:** This is NOT a hidden bug fix — the subject explicitly says
"Fix".

### PHASE 2: DIFF ANALYSIS

**Step 2.1:**
- `core.h`: 1 line changed (`u8 num_peer` -> `u16
  free_logical_link_idx_map`)
- `mac.c`: ~20 lines changed across 3 functions
- Functions modified: `ath12k_mac_free_unassign_link_sta`,
  `ath12k_mac_assign_link_sta`, `ath12k_mac_op_sta_state`
- Scope: well-contained, single-subsystem fix

**Step 2.2:**
- In `ath12k_mac_free_unassign_link_sta`: adds
  `ahsta->free_logical_link_idx_map |= BIT(arsta->link_idx)` — returns
  the freed index to the pool
- In `ath12k_mac_assign_link_sta`: replaces `arsta->link_idx =
  ahsta->num_peer++` with bitmap-based allocation using `__ffs()` + adds
  `-ENOSPC` check
- In `ath12k_mac_op_sta_state`: initializes
  `ahsta->free_logical_link_idx_map = U16_MAX` when a new station is
  created (all bits set = all indices free)

**Step 2.3:** Bug category: Logic/correctness bug — resource index leak.
The old approach only increments, never reuses indices. The new bitmap
approach properly tracks available indices.

**Step 2.4:** Fix quality:
- The fix is correct — bitmap tracks available indices, `__ffs` gets the
  lowest free bit, removal sets the bit back
- It adds a proper `-ENOSPC` check for when all indices are exhausted
- Minimal regression risk — the logic is straightforward and only
  touches the specific allocation/deallocation paths
- The U16_MAX initialization means 16 indices (0-15), which matches the
  firmware's maximum

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1:** `git blame` confirms both the buggy code (`num_peer++` at
line 7124) and the incomplete cleanup function were introduced by the
same commit: `8e6f8bc286031` ("Add MLO station state change handling")
by Sriram R, dated 2024-11-21, first in v6.14-rc1.

**Step 3.2:** No Fixes: tag present. The bug was introduced by
8e6f8bc286031.

**Step 3.3:** No intermediate fixes for the same issue. No prerequisites
found — the patch modifies code that exists in the tree as-is.

**Step 3.4:** The author (Manish Dharanenthiran) is a regular ath12k
contributor with 9+ commits in the subsystem. Jeff Johnson (ath12k
maintainer) applied it.

**Step 3.5:** This is a standalone single-patch fix. No dependencies on
other commits.

### PHASE 4: MAILING LIST RESEARCH

Lore was not accessible due to anti-bot protection. b4 dig could not
find the exact commit (it hasn't landed in the main tree yet from the
perspective of this 7.0 tree). The patch was sent to
`ath12k@lists.infradead.org` and `linux-wireless@vger.kernel.org`. It
was reviewed by 3 Qualcomm engineers and applied by the ath12k
maintainer Jeff Johnson.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Modified functions: `ath12k_mac_free_unassign_link_sta`,
`ath12k_mac_assign_link_sta`, `ath12k_mac_op_sta_state`

**Step 5.2:** `arsta->link_idx` is used in `ath12k_peer_assoc_h_mlo()`
(line 3531) to populate `ml->logical_link_idx` which is sent to firmware
via `wmi.c` line 2348 as `ml_params->logical_link_idx`. This is a WMI
command parameter — an invalid value directly impacts firmware behavior.

**Step 5.4:** The path: `ath12k_mac_op_sta_state` ->
`ath12k_mac_assign_link_sta` -> sets `link_idx` -> later used in
`ath12k_peer_assoc_h_mlo` -> sent via WMI to firmware. This is a
standard MLO station association path triggered during Wi-Fi connection
setup.

### PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code (`num_peer` field) was introduced in commit
`8e6f8bc286031`, first in v6.14-rc1. It is:
- **NOT in v6.13, v6.12, or any earlier LTS tree**
- Present in v6.14, v6.15, v6.16, v6.17, v6.18, v6.19, v7.0

For the 7.0.y stable tree specifically, the buggy code IS present.

**Step 6.2:** The code in v7.0 matches exactly what the patch expects
(verified by reading lines 7096-7137 and 6771-6798 of mac.c). The patch
should apply cleanly.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Subsystem: wireless driver (ath12k) — IMPORTANT for WiFi 7
users with Qualcomm QCN9274 and similar chipsets. MLO is a key WiFi 7
feature.

**Step 7.2:** ath12k is very actively developed (183 commits to mac.c
between v6.14 and v7.0).

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected users: Users of Qualcomm ath12k WiFi 7 hardware
with MLO enabled (QCN9274, etc.).

**Step 8.2:** Trigger: Happens when MLO links are removed and re-added —
occurs during roaming, channel switching, or temporary link degradation.
In a typical MLO setup with frequent link changes, this can be triggered
relatively easily.

**Step 8.3:** Failure mode: Sending an invalid logical link index (>15)
to firmware can cause firmware malfunction, potential firmware crash, or
incorrect MLO behavior. Severity: **HIGH** — firmware receives invalid
commands.

**Step 8.4:**
- Benefit: Prevents firmware from receiving invalid index values during
  MLO operations, which could cause connection instability or firmware
  crashes
- Risk: LOW — the change is ~20 lines, well-contained, uses standard
  bitmap operations, reviewed by 3 engineers plus maintainer
- Ratio: Favorable

### PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real, clearly described bug (index leak leading to invalid
  firmware commands)
- Small, well-contained fix (~20 lines across 2 files)
- Obviously correct bitmap-based approach
- 3 Reviewed-by tags from Qualcomm engineers + maintainer sign-off
- Tested on hardware (QCN9274 hw2.0)
- The buggy code exists in v7.0 (target tree)
- Should apply cleanly

**Evidence AGAINST backporting:**
- No Fixes: tag, no syzbot/crash report, no user-reported symptom
- Replaces a data structure member (counter -> bitmap), slightly more
  than a trivial patch
- MLO is relatively new; impact limited to WiFi 7 MLO users
- No explicit Cc: stable nomination
- The bug requires specific MLO link add/remove cycles to manifest

**Stable rules checklist:**
1. Obviously correct and tested? **Yes** — bitmap approach is
   straightforward, hardware tested
2. Fixes a real bug? **Yes** — index leak causing invalid firmware
   commands
3. Important issue? **Medium-High** — can cause firmware malfunction in
   MLO
4. Small and contained? **Yes** — ~20 lines in 2 files, single subsystem
5. No new features? **Correct** — pure bug fix
6. Can apply to stable? **Yes** — code matches cleanly

**Verification:**
- [Phase 1] Parsed tags: 3 Reviewed-by, tested-on, Link, maintainer SOB
- [Phase 2] Diff analysis: replaces `num_peer` counter with
  `free_logical_link_idx_map` bitmap across 3 functions
- [Phase 3] git blame: buggy code introduced in 8e6f8bc286031
  (v6.14-rc1), confirmed by `git merge-base --is-ancestor` checks
- [Phase 3] `git merge-base --is-ancestor 8e6f8bc286031 v6.13` → Not in
  v6.13; `v6.14` → Yes
- [Phase 3] Author has 9+ ath12k commits, is a regular contributor
- [Phase 4] b4 dig could not find the commit (not merged in this tree);
  lore blocked by anti-bot
- [Phase 5] Traced `link_idx` usage: set in `ath12k_mac_assign_link_sta`
  → used in `ath12k_peer_assoc_h_mlo` (line 3531) → sent to firmware via
  WMI (wmi.c line 2348)
- [Phase 6] Buggy code confirmed present in v7.0 tree; code at lines
  7096-7137 matches patch context exactly
- [Phase 6] NOT in v6.13 or earlier LTS trees (v6.12.y, v6.6.y, etc.)
- [Phase 8] Invalid logical_link_idx sent to firmware can cause firmware
  malfunction
- UNVERIFIED: Could not access lore discussion to check for reviewer
  stable nominations or concerns

This is a real bug fix for a resource index leak in WiFi 7 MLO handling
that can lead to invalid firmware commands. The fix is small, self-
contained, well-reviewed, and hardware-tested. The buggy code exists in
the target 7.0.y tree.

**YES**

 drivers/net/wireless/ath/ath12k/core.h |  2 +-
 drivers/net/wireless/ath/ath12k/mac.c  | 16 ++++++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 990934ec92fca..5498ff285102b 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -522,7 +522,7 @@ struct ath12k_sta {
 	u16 links_map;
 	u8 assoc_link_id;
 	u16 ml_peer_id;
-	u8 num_peer;
+	u16 free_logical_link_idx_map;
 
 	enum ieee80211_sta_state state;
 };
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index b253d1e3f4052..769d240e3ae24 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -6784,6 +6784,8 @@ static void ath12k_mac_free_unassign_link_sta(struct ath12k_hw *ah,
 		return;
 
 	ahsta->links_map &= ~BIT(link_id);
+	ahsta->free_logical_link_idx_map |= BIT(arsta->link_idx);
+
 	rcu_assign_pointer(ahsta->link[link_id], NULL);
 	synchronize_rcu();
 
@@ -7102,6 +7104,7 @@ static int ath12k_mac_assign_link_sta(struct ath12k_hw *ah,
 	struct ieee80211_sta *sta = ath12k_ahsta_to_sta(ahsta);
 	struct ieee80211_link_sta *link_sta;
 	struct ath12k_link_vif *arvif;
+	int link_idx;
 
 	lockdep_assert_wiphy(ah->hw->wiphy);
 
@@ -7120,8 +7123,16 @@ static int ath12k_mac_assign_link_sta(struct ath12k_hw *ah,
 
 	ether_addr_copy(arsta->addr, link_sta->addr);
 
-	/* logical index of the link sta in order of creation */
-	arsta->link_idx = ahsta->num_peer++;
+	if (!ahsta->free_logical_link_idx_map)
+		return -ENOSPC;
+
+	/*
+	 * Allocate a logical link index by selecting the first available bit
+	 * from the free logical index map
+	 */
+	link_idx = __ffs(ahsta->free_logical_link_idx_map);
+	ahsta->free_logical_link_idx_map &= ~BIT(link_idx);
+	arsta->link_idx = link_idx;
 
 	arsta->link_id = link_id;
 	ahsta->links_map |= BIT(arsta->link_id);
@@ -7630,6 +7641,7 @@ int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,
 	if (old_state == IEEE80211_STA_NOTEXIST &&
 	    new_state == IEEE80211_STA_NONE) {
 		memset(ahsta, 0, sizeof(*ahsta));
+		ahsta->free_logical_link_idx_map = U16_MAX;
 
 		arsta = &ahsta->deflink;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] wifi: ath12k: Set up MLO after SSR

[Sasha Levin]

From: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>

[ Upstream commit f33a8e41826831fc8ceb5f62833488cd9388ed59 ]

During recovery of an MLO setup from a core reset,
ATH12K_GROUP_FLAG_REGISTERED is set because ath12k_mac_unregister is not
called during core reset. So, when an MLO setup is recovering from a core
reset, ath12k_core_mlo_setup() is skipped. Hence, the firmware will not
have information about partner links. This makes MLO association fail
after recovery.

To resolve this, call ath12k_core_mlo_setup() during recovery, to set up
MLO. Also, if MLO setup fails during recovery, call
ath12k_mac_unregister() and ath12k_mac_destroy() to unregister mac and
then tear down the mac structures.

Also, initiate MLO teardown in the hardware group stop sequence to align
with the hardware group start sequence.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1

Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com>
Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260227041127.3265879-1-roopni.devanathan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the data I need. Let me write the comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: wifi: ath12k (Qualcomm ath12k wireless driver)
- **Action verb**: "Set up" - implies ensuring required initialization
  happens
- **Summary**: Set up MLO (Multi-Link Operation) after SSR (Subsystem
  Restart/Recovery)
Record: [wifi: ath12k] [Set up] [Ensure MLO is configured after SSR
recovery to avoid association failure]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Tested-on**: QCN9274 hw2.0 PCI
  WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1
- **Signed-off-by**: Ramya Gnanasekar (co-author), Roopni Devanathan
  (author), Jeff Johnson (maintainer)
- **Reviewed-by**: Baochen Qiang, Vasanthakumar Thiagarajan (both
  Qualcomm reviewers)
- **Link**: patch.msgid.link (original submission URL)
- **No Fixes: tag** (expected for autosel candidates)
- **No Cc: stable** (expected)
Record: Two Qualcomm reviewers reviewed the patch. Jeff Johnson (ath12k
maintainer) applied it. Tested on real hardware.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The bug: During recovery from a core reset with MLO setup,
`ATH12K_GROUP_FLAG_REGISTERED` remains set because
`ath12k_mac_unregister()` is NOT called during core reset. Therefore,
when `ath12k_core_hw_group_start()` is called during recovery, it sees
the flag is set and jumps over the `ath12k_core_mlo_setup()` call. This
means the firmware doesn't receive partner link information, causing MLO
association to fail after recovery.

Record: [Bug: MLO association fails after firmware recovery] [Symptom:
WiFi MLO cannot associate after SSR] [Root cause:
ath12k_core_mlo_setup() skipped during recovery because
ATH12K_GROUP_FLAG_REGISTERED is still set]

### Step 1.4: DETECT HIDDEN BUG FIXES
This is a clear bug fix - MLO association fails after recovery. The
commit message explicitly describes a failure mode. Not hidden at all.
Record: [This is an explicit bug fix for recovery failure]

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/net/wireless/ath/ath12k/core.c` only
- **Change 1**: `ath12k_core_hw_group_stop()` - 2 lines added (call to
  `ath12k_mac_mlo_teardown(ag)`)
- **Change 2**: `ath12k_core_hw_group_start()` - ~8 lines modified (add
  MLO setup in recovery path with error handling)
- **Total**: ~10 lines added/modified
- **Functions modified**: `ath12k_core_hw_group_stop()`,
  `ath12k_core_hw_group_start()`
Record: [Single file, ~10 lines changed, two functions modified,
surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE

**Hunk 1** (`ath12k_core_hw_group_stop`):
- Before: `ath12k_mac_unregister(ag)` then loop cleanup then
  `ath12k_mac_destroy(ag)` - no MLO teardown.
- After: `ath12k_mac_unregister(ag)` then `ath12k_mac_mlo_teardown(ag)`
  then loop cleanup then `ath12k_mac_destroy(ag)`.
- This aligns the stop sequence with the start sequence (MLO setup
  happens in start, so MLO teardown should happen in stop).

**Hunk 2** (`ath12k_core_hw_group_start`):
- Before: When `ATH12K_GROUP_FLAG_REGISTERED` is set, jumps directly to
  `core_pdev_create` - skipping all MLO setup.
- After: When the flag is set, calls `ath12k_core_mlo_setup(ag)` first,
  with error handling that calls `ath12k_mac_unregister()` and falls
  through to `err_mac_destroy` on failure. Then proceeds to
  `core_pdev_create` as before.

Record: [Fix adds MLO setup in recovery path and teardown in stop path
to match start/stop symmetry]

### Step 2.3: IDENTIFY THE BUG MECHANISM
- **Category**: Logic / correctness fix
- **Mechanism**: Missing initialization during recovery path. The MLO
  setup was only done on first-time start (when
  `ATH12K_GROUP_FLAG_REGISTERED` is not set), but needs to also be done
  on recovery (when the flag IS set but firmware state was lost).
Record: [Logic bug - MLO firmware setup skipped during recovery, causing
MLO association failure]

### Step 2.4: ASSESS THE FIX QUALITY
- The fix is obviously correct - adding `ath12k_core_mlo_setup()` to the
  recovery path is the logical fix.
- Error handling is properly added (if MLO setup fails during recovery,
  unregister and destroy).
- Adding teardown in stop path creates symmetry with start path.
- Low regression risk - only affects the recovery code path.
Record: [Fix is obviously correct, minimal, well-contained, proper error
handling added]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- The buggy code was introduced by commit `b716a10d99a28` ("wifi:
  ath12k: enable MLO setup and teardown from core", Dec 2024) and
  `a343d97f27f514` ("wifi: ath12k: move struct ath12k_hw from per device
  to group", Dec 2024).
- Both first appeared in v6.14.
Record: [Buggy code introduced in v6.14 by b716a10d99a28 and
a343d97f27f514]

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for autosel candidates).
Record: [N/A - no Fixes tag]

### Step 3.3: CHECK FILE HISTORY
- `core.c` has had extensive recovery-related fixes between v6.15 and
  v6.16 (the "fix_reboot_issues_with_hw_grouping" series with 9 commits
  in v6.16).
- This current commit is a continuation of that series, fixing another
  aspect of recovery that was missed.
Record: [This is a standalone fix that addresses an issue not covered by
the previous v6.16 recovery series]

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
- Roopni Devanathan (author) has 7+ commits in ath12k, is a regular
  contributor from Qualcomm.
- Ramya Gnanasekar (co-author) has 13+ commits in ath12k.
- Both Reviewed-by are from Qualcomm engineers who know the codebase.
Record: [Author is a regular contributor, reviewed by knowledgeable team
members]

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
- The functions used (`ath12k_core_mlo_setup`,
  `ath12k_mac_mlo_teardown`, `ath12k_mac_unregister`,
  `ath12k_mac_destroy`) all exist in the 7.0 tree.
- The recovery flow with `ath12k_core_reset()` and
  `ath12k_core_restart()` with hardware grouping exists in 7.0 (added in
  v6.16).
- The diff context matches the current 7.0 code exactly.
Record: [No additional dependencies needed - patch applies cleanly to
7.0]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
- Retrieved via b4 mbox. The patch was submitted as "[PATCH ath-next]"
  (single patch, not a series).
- Jeff Johnson replied "Applied, thanks!" with commit hash
  `f33a8e41826831fc8ceb5f62833488cd9388ed59`.
- Two Reviewed-by tags from Baochen Qiang and Vasanthakumar Thiagarajan
  were present on the original submission.
Record: [Single patch, applied by ath12k maintainer Jeff Johnson,
reviewed by 2 Qualcomm engineers]

### Step 4.2: CHECK WHO REVIEWED THE PATCH
- Baochen Qiang (Qualcomm) - regular ath12k reviewer
- Vasanthakumar Thiagarajan (Qualcomm) - senior ath12k developer
Record: [Reviewed by experienced ath12k engineers]

### Step 4.3: SEARCH FOR THE BUG REPORT
No external bug report linked. The bug was found during internal testing
at Qualcomm.
Record: [Internal finding, tested on QCN9274 hardware]

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
- This is a standalone patch, not part of a series.
- Related to the earlier v6.16 "fix_reboot_issues_with_hw_grouping"
  series but is an independent fix.
Record: [Standalone patch, no dependencies on other unmerged patches]

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
- Could not verify due to lore.kernel.org Anubis protection.
Record: [Unable to check stable mailing list - lore blocked]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `ath12k_core_hw_group_start()` - called during device bring-up and
  recovery
- `ath12k_core_hw_group_stop()` - called during device shutdown and
  error handling

### Step 5.2: TRACE CALLERS
- `ath12k_core_hw_group_start()` is called from
  `ath12k_core_qmi_firmware_ready()` (line 1319) during normal device
  bring-up AND from the recovery path.
- `ath12k_core_hw_group_stop()` is called from the error path of
  `ath12k_core_hw_group_start()` and from `ath12k_core_deinit()`.
Record: [Functions called during normal operation and recovery -
recovery path is common for QCN9274 users]

### Step 5.3-5.5: CALL CHAIN / SIMILAR PATTERNS
- The recovery path: firmware crash → `ath12k_core_reset()` →
  `ath12k_hif_power_up()` → firmware restarts → QMI ready →
  `ath12k_core_hw_group_start()` → (bug: skips MLO setup) → recovery
  fails
Record: [Bug is in a common recovery code path triggered by firmware
crashes]

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
- The buggy code was introduced in v6.14.
- The MLO hw_group code exists in: v6.14, v6.15, v6.16, v6.17, v6.18,
  7.0
- The recovery-with-grouping code was added in v6.16 (the series from
  6af396942bf13).
- **For the bug to be triggerable, BOTH the MLO setup code AND the
  recovery-with-grouping code must exist.**
- Both are present in v6.16+ and in 7.0.
Record: [Buggy code exists in v6.16+ stable trees and 7.0]

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
- The diff context matches the current 7.0 code exactly - the patch
  should apply cleanly.
- All referenced functions exist in 7.0.
Record: [Clean apply expected for 7.0]

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
- The v6.16 "fix_reboot_issues_with_hw_grouping" series is already in
  stable trees, but does NOT include the MLO setup fix that this commit
  provides.
Record: [No existing fix for this specific issue in stable]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM
- **Subsystem**: WiFi driver (ath12k) - Qualcomm QCN9274/WCN7850
- **Criticality**: IMPORTANT - affects users of QCN9274 WiFi hardware
  using MLO
Record: [WiFi driver, IMPORTANT - affects MLO users of QCN9274]

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
- ath12k is one of the most actively developed kernel subsystems - 62+
  commits to core.c between v6.14 and v7.0.
Record: [Highly active subsystem]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
- Users of QCN9274 WiFi hardware with MLO (Multi-Link Operation)
  enabled.
- This is WiFi 7 hardware that supports MLO for improved throughput and
  reliability.
Record: [Driver-specific - affects QCN9274 MLO users]

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- Trigger: Firmware crash (not uncommon with WiFi firmware) followed by
  SSR recovery.
- After recovery, MLO association fails completely - WiFi connectivity
  is broken until manual restart.
Record: [Triggered by firmware crash recovery - moderately common
scenario]

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- **Failure mode**: Complete MLO association failure after recovery -
  WiFi becomes non-functional for MLO connections.
- **Severity**: HIGH - loss of WiFi connectivity after firmware
  recovery, defeating the purpose of SSR.
Record: [HIGH - WiFi MLO connectivity lost after firmware recovery]

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- **Benefit**: Fixes complete MLO failure after firmware recovery -
  restores WiFi functionality.
- **Risk**: Very low - ~10 lines, well-contained, only affects recovery
  path, proper error handling added.
- **Ratio**: High benefit / very low risk = FAVORABLE.
Record: [High benefit, very low risk]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE
**FOR backporting:**
- Fixes a real bug (MLO association failure after SSR recovery)
- Small, surgical fix (~10 lines in one file)
- Tested on real hardware (QCN9274 hw2.0)
- Reviewed by 2 experienced engineers, applied by subsystem maintainer
- Obviously correct - adds missing initialization in recovery path
- All required functions exist in 7.0 tree
- Patch applies cleanly to current 7.0 code
- Proper error handling included

**AGAINST backporting:**
- Submitted to ath-next (not explicitly targeted for stable)
- No Fixes: tag (expected for autosel)
- No Cc: stable (expected for autosel)
- Affects only QCN9274 MLO users (limited user base, though growing with
  WiFi 7 adoption)
- The recovery infrastructure this depends on was introduced relatively
  recently (v6.16)

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - tested on QCN9274, reviewed
   by 2 engineers.
2. **Fixes a real bug that affects users?** YES - MLO connectivity fails
   after firmware recovery.
3. **Important issue?** MODERATE-HIGH - WiFi connectivity loss after
   recovery.
4. **Small and contained?** YES - ~10 lines in one file, single function
   scope.
5. **No new features or APIs?** CORRECT - no new features.
6. **Can apply to stable trees?** YES - verified code context matches
   7.0 exactly.

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category (not device ID, quirk, DT, or build fix).
Standard bug fix.

### Step 9.4: DECISION
The fix is small, obviously correct, tested, reviewed, and fixes a real
user-impacting bug (MLO WiFi connectivity failure after firmware crash
recovery). The risk is minimal and the patch applies cleanly. However,
this is a driver-specific issue affecting QCN9274 MLO users - a growing
but specific audience. The fix meets all stable kernel criteria.

---

## Verification:
- [Phase 1] Parsed tags: found Tested-on (QCN9274), 2 Reviewed-by
  (Baochen Qiang, Vasanthakumar Thiagarajan), SOBs from Qualcomm team
- [Phase 2] Diff analysis: ~10 lines added to two functions in core.c -
  adds ath12k_core_mlo_setup() call in recovery path and
  ath12k_mac_mlo_teardown() in stop path
- [Phase 3] git blame: buggy code introduced by b716a10d99a28 (v6.14)
  and a343d97f27f514 (v6.14)
- [Phase 3] git tag --contains: b716a10d99a28 first appears in v6.14
- [Phase 3] Recovery-with-grouping commits (6af396942bf13 through
  f5755c23ed8a4) first appear in v6.16
- [Phase 3] All required functions (ath12k_core_mlo_setup,
  ath12k_mac_mlo_teardown, etc.) verified present in 7.0 tree
- [Phase 3] File context at lines 1126-1127 verified: the exact buggy
  code (skipping MLO setup when REGISTERED flag set) exists in 7.0
- [Phase 4] b4 mbox: found 4 messages in thread, Jeff Johnson "Applied,
  thanks!" with commit f33a8e41826831fc8ceb5f62833488cd9388ed59
- [Phase 4] Patch submitted as "[PATCH ath-next]" - single standalone
  patch
- [Phase 5] ath12k_core_hw_group_start called from
  ath12k_core_qmi_firmware_ready (line 1319) - verified in code
- [Phase 6] Code exists in 7.0 tree - verified via grep and Read
- [Phase 6] Diff context matches current 7.0 code exactly - verified by
  reading lines 998-1020 and 1119-1184
- [Phase 8] Failure mode: WiFi MLO association failure after firmware
  recovery - severity HIGH

**YES**

 drivers/net/wireless/ath/ath12k/core.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 4ed608ba3c304..a1834985bb63b 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -1006,6 +1006,8 @@ static void ath12k_core_hw_group_stop(struct ath12k_hw_group *ag)
 
 	ath12k_mac_unregister(ag);
 
+	ath12k_mac_mlo_teardown(ag);
+
 	for (i = ag->num_devices - 1; i >= 0; i--) {
 		ab = ag->ab[i];
 		if (!ab)
@@ -1123,8 +1125,14 @@ static int ath12k_core_hw_group_start(struct ath12k_hw_group *ag)
 
 	lockdep_assert_held(&ag->mutex);
 
-	if (test_bit(ATH12K_GROUP_FLAG_REGISTERED, &ag->flags))
+	if (test_bit(ATH12K_GROUP_FLAG_REGISTERED, &ag->flags)) {
+		ret = ath12k_core_mlo_setup(ag);
+		if (WARN_ON(ret)) {
+			ath12k_mac_unregister(ag);
+			goto err_mac_destroy;
+		}
 		goto core_pdev_create;
+	}
 
 	ret = ath12k_mac_allocate(ag);
 	if (WARN_ON(ret))
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] wifi: ath12k: Skip adding inactive partner vdev info

[Sasha Levin]

From: Avula Sri Charan <quic_asrichar@quicinc.com>

[ Upstream commit 7d7dc26f72abb7a76abb4a68ebad75d5ab7b375e ]

Currently, a vdev that is created is considered active for partner link
population. In case of an MLD station, non-associated link vdevs can be
created but not started. Yet, they are added as partner links. This leads
to the creation of stale FW partner entries which accumulate and cause
assertions.

To resolve this issue, check if the vdev is started and operating on a
chosen frequency, i.e., arvif->is_started, instead of checking if the vdev
is created, i.e., arvif->is_created. This determines if the vdev is active
or not and skips adding it as a partner link if it's inactive.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1

Signed-off-by: Avula Sri Charan <quic_asrichar@quicinc.com>
Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260330040732.1847263-1-roopni.devanathan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have sufficient information. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1:** Subsystem: `wifi: ath12k:`. Action verb: "Skip" (which
implies avoiding incorrect behavior). Summary: Skip adding inactive
partner vdev info to prevent firmware assertions.

**Step 1.2:** Tags:
- Tested-on: QCN9274 hw2.0 PCI (hardware-tested)
- Signed-off-by: Avula Sri Charan (author), Roopni Devanathan
  (submitter), Jeff Johnson (ath12k maintainer)
- Reviewed-by: Rameshkumar Sundaram, Baochen Qiang (both active ath12k
  contributors)
- Link: patch.msgid.link URL for the submission
- No Fixes: tag (expected for review candidates)
- No Cc: stable (expected for review candidates)

**Step 1.3:** Bug: When MLD station mode has non-associated link vdevs
that are created but not started, they are incorrectly added as partner
links. This leads to stale FW partner entries that accumulate and
**cause firmware assertions** (FW crash). Root cause: the check used
`is_created` but should use `is_started` to ensure only active vdevs are
added.

**Step 1.4:** This is clearly a bug fix despite not using the word "fix"
prominently. "Skip adding" = avoiding incorrect behavior that causes
firmware crashes.

## PHASE 2: DIFF ANALYSIS

**Step 2.1:** Single file changed:
`drivers/net/wireless/ath/ath12k/mac.c`. Change is 1 line: `is_created`
-> `is_started`. Minimal scope.

**Step 2.2:** In `ath12k_mac_mlo_get_vdev_args()`, when iterating
partner link vdevs:
- BEFORE: Check `arvif_p->is_created` (vdev allocated in firmware)
- AFTER: Check `arvif_p->is_started` (vdev started and operating on
  frequency)
- This is a more restrictive check that filters out vdevs that exist but
  are not active.

**Step 2.3:** Bug category: Logic/correctness fix. A created-but-not-
started vdev should not be treated as an active partner, because it has
no channel context yet. Adding it causes stale FW partner entries ->
firmware assertion.

**Step 2.4:** Fix quality: Obviously correct. `is_started` is a subset
of `is_created` (a vdev must be created before it can be started), so
this is strictly more restrictive. The fix cannot introduce regressions
because any vdev that is started is also created. The fix is reviewed by
two ath12k developers and tested on real hardware.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1:** Blame shows the buggy line (`is_created` check) was
introduced by commit `315d80be304ac1` ("wifi: ath12k: allocate new links
in change_vif_links()") by Aditya Kumar Singh. This commit appeared at
v6.13-rc6, landing in v6.15.

**Step 3.2:** The original function `ath12k_mac_mlo_get_vdev_args()` was
introduced by `1ea0cdee6fb3a4` ("wifi: ath12k: MLO vdev bringup
changes") at v6.12-rc4, landing in v6.14. The `is_created` check was an
addition on top in v6.15.

**Step 3.3:** The fix is standalone. No other patches are needed as
prerequisites.

**Step 3.4:** Avula Sri Charan has one other commit in ath12k (napi
fix). Roopni Devanathan has multiple ath12k contributions. Reviewers
(Rameshkumar Sundaram, Baochen Qiang) are active ath12k contributors.

**Step 3.5:** No dependent commits needed. The fix only changes one
condition.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1:** b4 dig could not find the commit (it's not yet merged).
The submission URL is `https://patch.msgid.link/20260330040732.1847263-
1-roopni.devanathan@oss.qualcomm.com`. Lore is behind Anubis protection,
but we can confirm from the commit tags that it was reviewed by two
developers and accepted by the subsystem maintainer Jeff Johnson.

**Step 4.2:** Two reviewers (Rameshkumar Sundaram, Baochen Qiang)
reviewed the patch. Jeff Johnson (ath12k maintainer) signed off.

**Step 4.3-4.5:** Bug report details not available via web due to Anubis
protection. The commit message itself describes the bug mechanism
clearly.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Modified function: `ath12k_mac_mlo_get_vdev_args()`

**Step 5.2:** Called from `ath12k_mac_vdev_start_restart()` (line
11210), which is a key function in the vdev start path. This is called
during channel context assignment (common MLO WiFi operation).

**Step 5.3-5.4:** The function populates partner link info that gets
sent to firmware via `ath12k_wmi_vdev_start()`. Incorrect partner
entries lead to firmware state corruption and assertion failures.

**Step 5.5:** The `is_started` flag is well-established in the codebase
with clear semantics: set when vdev starts operating, cleared when it
stops.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code (`is_created` check in
`ath12k_mac_mlo_get_vdev_args()`) was introduced in v6.15 (commit
`315d80be304ac1`). It exists in:
- v7.0 (confirmed: `git merge-base --is-ancestor` = IN v7.0)
- v6.15+ (confirmed)
- NOT in v6.14 or earlier (MLO function is different or doesn't have the
  check)

**Step 6.2:** The fix is a single-line change. It will apply cleanly to
the 7.0 stable tree since the surrounding code is identical.

**Step 6.3:** No related fixes already in stable for this specific
issue.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Subsystem: WiFi/ath12k (wireless driver). Criticality:
IMPORTANT - ath12k supports Qualcomm WiFi 7 hardware (QCN9274, WCN7850)
used in modern systems.

**Step 7.2:** Very active subsystem - 232 commits to this file since the
MLO function was introduced.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected users: ath12k WiFi users in MLD/MLO station mode.
This is a growing user base as WiFi 7 hardware becomes more common.

**Step 8.2:** Trigger: MLD station connects with multiple links, non-
associated link vdevs are created but not started, then a vdev start
occurs. This is a normal MLO operation path, not an edge case.

**Step 8.3:** Failure mode: Firmware assertion (crash). Severity:
**CRITICAL** - the WiFi firmware crashes, requiring recovery.

**Step 8.4:**
- Benefit: HIGH - prevents firmware crashes during normal MLO operation
- Risk: VERY LOW - 1 line change, strictly more restrictive condition,
  cannot regress
- Ratio: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes firmware assertion (crash) - critical severity
- Single-line change, obviously correct
- `is_started` is a strict subset of `is_created` - no regression
  possible
- Reviewed by 2 developers, tested on real hardware
- Affects normal MLO WiFi operation path
- Clean apply to 7.0 stable

**Evidence AGAINST backporting:**
- Affects only MLO (WiFi 7) users with ath12k hardware (limited
  audience)
- Relatively new code (v6.15+)
- No explicit Fixes: tag or Cc: stable

**Stable rules checklist:**
1. Obviously correct and tested? **YES** - 1-line change, more
   restrictive check, HW-tested
2. Fixes a real bug? **YES** - firmware assertions/crashes
3. Important issue? **YES** - firmware crash
4. Small and contained? **YES** - 1 line in 1 file
5. No new features? **YES** - purely a fix
6. Can apply to stable? **YES** - clean apply

## Verification

- [Phase 1] Parsed tags: Tested-on: QCN9274, Reviewed-by: 2 developers,
  Signed-off-by: Jeff Johnson (maintainer)
- [Phase 2] Diff analysis: 1 line changed in
  `ath12k_mac_mlo_get_vdev_args()`, `is_created` -> `is_started`
- [Phase 3] git blame: buggy `is_created` check introduced in
  315d80be304ac1 (v6.15), added by Aditya Kumar Singh
- [Phase 3] git describe: 315d80be304ac1 = v6.13-rc6-1322, landed in
  v6.15
- [Phase 3] git merge-base: 315d80be304ac1 IS in v7.0, NOT in v6.14
- [Phase 3] git merge-base: 1ea0cdee6fb3a4 (original function) IS in
  v6.14, NOT in v6.13
- [Phase 5] Grep callers: `ath12k_mac_mlo_get_vdev_args()` called from
  `ath12k_mac_vdev_start_restart()` at line 11210
- [Phase 5] Grep `is_started`: set to true in vdev start path (lines
  11637, 12106, 12118), false in unassign path (lines 12168, 12179)
- [Phase 6] Buggy code exists in v6.15+ and v7.0 stable trees only
- [Phase 7] Active subsystem: 232 commits since MLO function
  introduction
- [Phase 8] Failure mode: firmware assertion = CRITICAL
- UNVERIFIED: Could not access lore.kernel.org discussion due to Anubis
  protection

The fix is a minimal, obviously correct, single-line change that
prevents firmware crashes during normal MLO WiFi operation. It meets all
stable kernel criteria.

**YES**

 drivers/net/wireless/ath/ath12k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 769d240e3ae24..6fca4418ab0bd 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -11122,7 +11122,7 @@ ath12k_mac_mlo_get_vdev_args(struct ath12k_link_vif *arvif,
 		if (arvif == arvif_p)
 			continue;
 
-		if (!arvif_p->is_created)
+		if (!arvif_p->is_started)
 			continue;
 
 		link_conf = wiphy_dereference(ahvif->ah->hw->wiphy,
-- 
2.53.0