Skip to content

FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072 - #955

Open
miaoqing-quic wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
miaoqing-quic:fix-4way-handshake-timeout
Open

FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072#955
miaoqing-quic wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
miaoqing-quic:fix-4way-handshake-timeout

Conversation

@miaoqing-quic

Copy link
Copy Markdown
Contributor

In MLO connections, ath12k_wifi7_dp_rx_set_link_id_wcn7850() attempts to resolve the IEEE 802.11 link ID for received frames by matching rxcb->peer_id against the link_peer->peer_id entries in dp_peer->link_peers[].

This fails for EAPOL frames because the firmware delivers them via the MLD peer path. In this case, rxcb->peer_id contains an MLD peer ID while link_peer->peer_id contains a link peer ID. The mismatch prevents status->link_valid from being set.

When mac80211 receives a data frame with link_valid=0 for an MLO station, it calls link_sta_info_get_bss() with hdr->addr2 to resolve the link ID. If hdr->addr2 contains the AP MLD address rather than a link address, the lookup fails because link_sta_info_get_bss() indexes by link address, and the frame is dropped in __ieee80211_rx_handle_packet(). This is observed on QCC2072 where EAPOL M3 uses the MLD address,

deauthenticated (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)

Fix this by resolving the link peer using the current operating frequency associated with each link peer.

For 6 GHz links, the received frequency corresponds to the operating center frequency, while for other bands it corresponds to the primary channel frequency. Match the received frame against associated links using the appropriate frequency for each band.

The frequency-based lookup is used only when exactly one associated link matches the received frequency. If multiple links share the same frequency, the match becomes ambiguous and no link ID is assigned. In that case, leave status->link_valid unset and let mac80211 fall back to its own link resolution logic.

Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3

Fixes: a2fe9dc ("wifi: ath12k: Fix low MLO RX throughput on WCN7850")

Link: https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/

CRs-Fixed: 4612924

In MLO connections, ath12k_wifi7_dp_rx_set_link_id_wcn7850() attempts
to resolve the IEEE 802.11 link ID for received frames by matching
rxcb->peer_id against the link_peer->peer_id entries in
dp_peer->link_peers[].

This fails for EAPOL frames because the firmware delivers them via
the MLD peer path. In this case, rxcb->peer_id contains an MLD peer
ID while link_peer->peer_id contains a link peer ID. The mismatch
prevents status->link_valid from being set.

When mac80211 receives a data frame with link_valid=0 for an MLO
station, it calls link_sta_info_get_bss() with hdr->addr2 to resolve
the link ID. If hdr->addr2 contains the AP MLD address rather than a
link address, the lookup fails because link_sta_info_get_bss()
indexes by link address, and the frame is dropped in
__ieee80211_rx_handle_packet(). This is observed on QCC2072 where
EAPOL M3 uses the MLD address,

  deauthenticated (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)

Fix this by resolving the link peer using the current operating
frequency associated with each link peer.

For 6 GHz links, the received frequency corresponds to the operating
center frequency, while for other bands it corresponds to the primary
channel frequency. Match the received frame against associated links
using the appropriate frequency for each band.

The frequency-based lookup is used only when exactly one associated
link matches the received frequency. If multiple links share the same
frequency, the match becomes ambiguous and no link ID is assigned. In
that case, leave status->link_valid unset and let mac80211 fall back
to its own link resolution logic.

Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3

Fixes: a2fe9dc ("wifi: ath12k: Fix low MLO RX throughput on WCN7850")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4612924 on any of the following entities:

Entities:

  • kernel.qli.2.0

CR: 4612924

Please ensure the CR has a change task associated with at least one of the entities for this branch.

@qlijarvis

Copy link
Copy Markdown

PR #955 — validate-patch

PR: #955

Verdict Issues Detailed Report
0 Full report

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
  2. Lore link matches PR commits: Yes — diff content identical; line number offset due to context differences in target tree
  3. Upstream patch status: In review — posted to linux-wireless on 2026-08-15; no maintainer decision yet
  4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence
Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #955 - FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072
Upstream commit: https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check Status Note
Subject matches upstream Subject identical except for FROMLIST: prefix (expected)
Body preserves rationale Complete problem description, fix rationale, and testing notes preserved
Fixes tag present/correct Fixes: a2fe9dc70f3b present and correct
Authorship preserved From: matches lore author (Miaoqing Pan miaoqing.pan@oss.qualcomm.com)
Backport note (if applicable) N/A FROMLIST: prefix indicates patch posted to mailing list, not yet merged

Diff

File Status Notes
drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c Diff content identical; line number offset (2262 vs 2331) is expected context difference

Upstream Patch Status

The lore thread contains only the initial posting (dated 2026-08-15). No maintainer replies, acceptance signals (applied, queued, Reviewed-by:, Acked-by:), or rejection signals (NAK, Nacked-by:) are present in the fetched mbox.

Community verdict: ⏳ Decision Pending — patch posted 2026-08-15; no maintainer decision yet

Verdict

Merge as-is — The PR faithfully represents the lore patch. Diff content is identical, commit message preserves all key information, authorship is correct, and the FROMLIST: prefix accurately reflects the patch's upstream status (posted to linux-wireless but not yet merged).

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/linux-wireless/20260815014329.3748059-1-miaoqing.pan@oss.qualcomm.com/
  2. Lore link matches PR commits: Yes — diff content identical; line number offset due to context differences in target tree
  3. Upstream patch status: In review — posted to linux-wireless on 2026-08-15; no maintainer decision yet
  4. PR present in qcom-next/topics: Partial — integration_presence_report.md shows "partial - subject or partial tree evidence found, but full change was not verified" (1/1 commit partial)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 49dbe0dae5cfb7a1eb3434cde6fc7ba37924fe94
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 [PATCH] FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on partial - subject or partial tree evidence found, but full change was not verified missing - no subject, patch-id, or full tree-content match found partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

@qlijarvis

Copy link
Copy Markdown

PR #955 — checker-log-analyzer

PR: #955
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31862360507

Checker Result Summary
Checker Result Summary
checkpatch 2 warnings: long commit line, unknown commit ID
dt-binding-check ⏭️ No DT binding changes
dtb-check ⏭️ No devicetree changes
sparse-check Passed
check-uapi-headers No UAPI changes
check-patch-compliance Passed
tag-check Subject has valid FROMLIST: prefix
qcom-next-check ⏭️ N/A (target is qcom-6.18.y, not qcom-next)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #955 - FROMLIST: wifi: ath12k: fix MLO 4-way handshake timeout on QCC2072
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/31862360507
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch 2 warnings: long commit line, unknown commit ID
dt-binding-check ⏭️ No DT binding changes
dtb-check ⏭️ No devicetree changes
sparse-check Passed
check-uapi-headers No UAPI changes
check-patch-compliance Passed
tag-check Subject has valid FROMLIST: prefix
qcom-next-check ⏭️ N/A (target is qcom-6.18.y, not qcom-next)

❌ checkpatch

Root cause: Two style warnings in commit 81ce8ac

Failure details:

WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#41: 
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1

WARNING: Unknown commit id 'a2fe9dc70f3b', maybe rebased or not pulled?
#44: 
Fixes: a2fe9dc70f3b ("wifi: ath12k: Fix low MLO RX throughput on WCN7850")

81ce8acab1382da2871a200a6a3d18631de73d5d total: 0 errors, 2 warnings, 0 checks, 69 lines checked

Analysis:

  1. Long line warning (75 chars): The Tested-on: line exceeds 75 characters. This is a common pattern in wireless driver commits where hardware identifiers are long. The line is:

    Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1
    

    This is 82 characters. While checkpatch flags it, Tested-on: lines with long hardware identifiers are generally acceptable in the wireless subsystem.

  2. Unknown commit ID warning: The Fixes: tag references commit a2fe9dc70f3b which is not present in the current tree. This typically means:

    • The commit exists in a different branch (e.g., upstream wireless-next)
    • The commit hasn't been pulled into qcom-6.18.y yet
    • The commit ID is from a rebased series

    This is not a blocker — the Fixes tag is correct for upstream submission. When the patch is merged upstream and later backported, the commit ID will resolve correctly.

Fix (optional):

For the long line, you could wrap it, but this is not required:

git rebase -i bfeb0e5567c0   # mark commit as 'edit'
# Edit commit message to wrap Tested-on line:
Tested-on: QCC2072 hw1.0 PCI
  WLAN.COL.1.0.c2-00228-QCACOLSWPL_V1_TO_SILICON-1
git commit --amend
git rebase --continue

For the unknown commit ID, no action is needed — this is expected for FROMLIST patches.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git bfeb0e5567c0..81ce8acab138

Verdict

Ready to merge with minor style warnings.

Both checkpatch warnings are non-blocking:

  • The long Tested-on: line is acceptable for wireless driver hardware identifiers
  • The unknown commit ID in Fixes: is expected for FROMLIST patches targeting upstream

All other checkers passed cleanly:

  • ✅ No DT/binding changes to validate
  • ✅ Sparse analysis passed
  • ✅ No UAPI changes
  • ✅ Patch compliance passed (valid FROMLIST: prefix, correct Link: tag)
  • ✅ Subject prefix check passed (FROMLIST: is valid for qcom-6.18.y)

The patch is well-formed and ready for merge. The checkpatch warnings can be addressed if desired, but are not blockers for this wireless driver fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants