Skip to content

Ath10k qcom 6.18 filter non utf - #990

Open
linghuiwu (linghuiwu-star) wants to merge 2 commits into
qualcomm-linux:qcom-6.18.yfrom
linghuiwu-star:ath-qcom-6.18-filter-non-utf
Open

Ath10k qcom 6.18 filter non utf#990
linghuiwu (linghuiwu-star) wants to merge 2 commits into
qualcomm-linux:qcom-6.18.yfrom
linghuiwu-star:ath-qcom-6.18-filter-non-utf

Conversation

@linghuiwu-star

@linghuiwu-star linghuiwu (linghuiwu-star) commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown

This series backports ath10k FTM TLV test command support to qcom-6.18.y
and filters non-UTF WMI events from the ath10k testmode userspace path.

The series contains two independent commits:

  1. wifi: ath10k: Support for FTM TLV test commands
  2. FROMLIST: wifi: ath10k: filter non-UTF testmode events

The first commit is the qcom-6.18.y backport of PR 912.

The second commit is based on PR 880 and depends on the event handling
introduced by the first commit. It is intentionally kept as a separate
commit so that the two changes can be reviewed independently.

When UTF monitor is enabled, ath10k can receive both UTF and non-UTF WMI
events through the testmode path. Non-UTF events may be forwarded to
userspace and confuse FTM tools that expect only UTF responses.

The second commit forwards only known UTF event IDs and consumes/drops
other WMI events while UTF monitor is active. The existing segmented and
unsegmented FTM TLV event handling from the first commit is preserved.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00093.2-QCAHLSWMTPL-1

CRs-Fixed:4627410

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

3 similar comments
@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

@linghuiwu-star linghuiwu (linghuiwu-star) changed the title Ath qcom 6.18 filter non utf Ath10k qcom 6.18 filter non utf Aug 20, 2026
@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

@qswat-orbit-external

qswat-orbit-external Bot commented Aug 20, 2026

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4627410 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4627410
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

Loic Poulain and others added 2 commits August 21, 2026 14:12
Loic Poulain @linghuiwu-star
UPSTREAM: wifi: ath10k: Support for FTM TLV test commands
f779157 
Existing tools like myftm use 'legacy' test command API. Similarly
to ath11k and ath12k, we want to support raw TLV payload submitted
from the test tool. This requires segmenting the TLV payload and
encapsulating it within a WMI command. The opposite operation needs
to be done upon corresponding event receiving.

Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20251020153759.407516-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
(cherry picked from commit 54be197)
@linghuiwu-star
FROMLIST: wifi: ath10k: filter non-UTF testmode events
62ec8be 
When UTF monitor is enabled, ath10k forwards WMI events to nl80211
testmode. Non-UTF events can therefore be delivered to userspace and
confuse FTM tools which expect only UTF responses.

Only forward known UTF event IDs from WMI event namespaces that route
events through ath10k_tm_event_wmi(), and drop other WMI events while UTF
monitor is active. READY events are still handled by the normal WMI
receive path.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00093.2-QCAHLSWMTPL-1

Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
@linghuiwu-star

linghuiwu (linghuiwu-star) commented Aug 21, 2026

Copy link
Copy Markdown
Author

PR #990 is a combined PR including the changes from PR #912 and PR #880. 880 depend on 912

@qcomlnxci

qcomlnxci commented Aug 21, 2026

Copy link
Copy Markdown

Test jobs on 62ec8be

@qcomlnxci

qcomlnxci commented Aug 21, 2026

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ❌ Fail
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
Ethernet ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ◻️ ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ❌ Fail ✅ Pass ✅ Pass ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ❌ Fail ✅ Pass ✅ Pass ❌ Fail
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️ ❌ Fail ❌ Fail ✅ Pass ❌ Fail
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️ ❌ Fail ❌ Fail ❌ Fail ❌ Fail
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ❌ Fail ❌ Fail ❌ Fail ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ◻️ ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ◻️ ✅ Pass ✅ Pass ❌ Fail ✅ Pass
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass ✅ Pass

@qlijarvis

qlijarvis commented Aug 25, 2026

Copy link
Copy Markdown

PR #990 — validate-patch

PR: #990

Verdict Issues Detailed Report
✅ 0 Full report

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/r/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
  2. Lore link matches PR commits: Yes — diff content is identical; context line number differences are due to PR commit 1/2 adding prerequisite code
  3. Upstream patch status: Upstreamed — applied as commit 35a3da9fe1b212a9012952a04f383b8dc3708dd7 in ath-next by Jeff Johnson on Aug 1, 2026, with Reviewed-by: tags from Baochen Qiang and Rameshkumar Sundaram
  4. PR present in qcom-next/topics: Yes - all 2 commit(s) are present in qcom-next or topics
Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #990 - wifi: ath10k: Support for FTM TLV test commands + filter non-UTF testmode events
Upstream commit: https://lore.kernel.org/r/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
Verdict: ✅ PASS

Commit Message

Check Status Note
Subject matches upstream ✅ Subject identical; FROMLIST: prefix correctly added
Body preserves rationale ✅ Complete body preserved verbatim from lore
Fixes tag present/correct ✅ No Fixes tag in upstream; none expected
Authorship preserved ✅ From: matches lore author; original Signed-off-by: present
Backport note (if applicable) N/A FROMLIST: commit; no backport note needed

Diff

File Status Notes
drivers/net/wireless/ath/ath10k/testmode.c ✅ Diff content identical; context line numbers differ due to PR commit 1/2 adding segmented event handling

Upstream Patch Status

Commit Community Verdict
wifi: ath10k: filter non-UTF testmode events ✅ ACKed — applied as 35a3da9fe1b212a9012952a04f383b8dc3708dd7 by Jeff Johnson on Aug 1, 2026; received Reviewed-by: from Baochen Qiang and Rameshkumar Sundaram

Issues

None. The PR commit faithfully represents the lore patch with appropriate FROMLIST: prefix and correct lore link.

Verdict

Merge as-is. The patch is a faithful representation of the upstream lore submission, which has been accepted and merged into the ath-next tree. The FROMLIST: prefix is correct at the time the PR was created (Jul 17, 2026), though the patch was subsequently accepted on Aug 1, 2026.

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/r/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
  2. Lore link matches PR commits: Yes — diff content is identical; context line number differences are due to PR commit 1/2 adding prerequisite code
  3. Upstream patch status: Upstreamed — applied as commit 35a3da9fe1b212a9012952a04f383b8dc3708dd7 in ath-next by Jeff Johnson on Aug 1, 2026, with Reviewed-by: tags from Baochen Qiang and Rameshkumar Sundaram
  4. PR present in qcom-next/topics: Yes — both commits present in qcom-next (commit 1/2 at 54be197109762d2a3c2b23d44e960ce7a43a3798, commit 2/2 verified by added-lines presence check)

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: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/2 [PATCH 1/2] UPSTREAM: wifi: ath10k: Support for FTM TLV test commands present - exact patch-id match at 54be197 skipped - not checked because qcom-next already contains the change present
2/2 [PATCH 2/2] FROMLIST: wifi: ath10k: filter non-UTF testmode events present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

Final Status

overall_status: PASS
present_commits: 2/2
partial_commits: 0/2
missing_commits: 0/2
topics_checked_for_commits: 0/2
final_summary: PR present in qcom-next/topics: Yes - all 2 commit(s) are present in qcom-next or topics

@qlijarvis

qlijarvis commented Aug 25, 2026

Copy link
Copy Markdown

PR #990 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ No binding changes
dtb-check ⏭️ No DTS changes
sparse-check ✅ No sparse warnings
check-uapi-headers ✅ No UAPI changes
check-patch-compliance ❌ Commit 1 missing required prefix
tag-check ❌ Commit 1 missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #990 — wifi: ath10k: Support for FTM TLV test commands + filter non-UTF testmode events
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32355727106
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ✅ No style issues
dt-binding-check ⏭️ No binding changes
dtb-check ⏭️ No DTS changes
sparse-check ✅ No sparse warnings
check-uapi-headers ✅ No UAPI changes
check-patch-compliance ❌ Commit 1 missing required prefix
tag-check ❌ Commit 1 missing required prefix

❌ check-patch-compliance

Root cause: Commit 64fbdb6 ("wifi: ath10k: Support for FTM TLV test commands") does not start with a required prefix.

Failure details:

Checking commit: wifi: ath10k: Support for FTM TLV test commands
Commit summary does not start with a required prefix

The checker requires all commits to start with one of: FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:.

  • Commit 1: "wifi: ath10k: Support for FTM TLV test commands" — ❌ missing prefix
  • Commit 2: "FROMLIST: wifi: ath10k: filter non-UTF testmode events" — ✅ has valid prefix

Fix:

The patch file shows this commit should have UPSTREAM: prefix (it was cherry-picked from mainline commit 54be197), but the prefix was stripped when the commit was applied to the tree.

git rebase -i 29d6dbd404bb875c4e6c234b6a168666d4b6c53e  # mark commit 64fbdb6eed13 as 'edit'
git commit --amend -m "UPSTREAM: wifi: ath10k: Support for FTM TLV test commands"
# Keep the rest of the commit message unchanged
git rebase --continue

Reproduce locally:

cd kernel
git log --oneline 29d6dbd404bb..HEAD
# Verify commit 64fbdb6eed13 subject line

❌ tag-check

Root cause: Commit 64fbdb6 subject line does not start with a required prefix tag.

Failure details:

Target branch qcom-6.18.y is not qcom-next or qcom-next-staging, so every commit must start with one of:

  • FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

Commits in PR:

  1. ❌ 64fbdb6 "wifi: ath10k: Support for FTM TLV test commands" — missing prefix
  2. ✅ 670c549 "FROMLIST: wifi: ath10k: filter non-UTF testmode events" — has valid prefix

Fix:

Same as check-patch-compliance fix above. Add UPSTREAM: prefix to commit 1:

git rebase -i 29d6dbd404bb875c4e6c234b6a168666d4b6c53e
# mark commit 64fbdb6eed13 as 'edit'
git commit --amend -m "UPSTREAM: wifi: ath10k: Support for FTM TLV test commands"
# Preserve the rest of the commit body (description, tags, cherry-pick note)
git rebase --continue

The correct subject should be:

UPSTREAM: wifi: ath10k: Support for FTM TLV test commands

This commit was cherry-picked from mainline (commit 54be197), so UPSTREAM: is the appropriate prefix.

Reproduce locally:

git log --format="%H %s" 29d6dbd404bb..HEAD | grep -vE '^[0-9a-f]+ (FROMLIST|FROMGIT|UPSTREAM|BACKPORT|QCLINUX|PENDING|WORKAROUND):'

Verdict

1 blocker to fix before merge:

The first commit (64fbdb6) is missing the UPSTREAM: prefix in its subject line. This is a simple fix — amend the commit to add the prefix. The patch file shows the prefix was intended but was stripped during commit application.

Once fixed, all checkers will pass. The code changes themselves are clean (checkpatch, sparse, UAPI all passed).

@qlijarvis

qlijarvis commented Aug 25, 2026

Copy link
Copy Markdown

PR #990 — validate-patch

PR: #990

Verdict Issues Detailed Report
✅ 0 Full report

Final Summary

  1. Lore link present: Yes — both commits have valid lore.kernel.org links in their commit messages
  2. Lore link matches PR commits: Yes — diff content is faithful to lore for both commits; line number differences in commit 2/2 are legitimate context shifts from commit 1/2
  3. Upstream patch status: ✅ ACKed — commit 1/2 merged into mainline; commit 2/2 applied by maintainer Jeff Johnson with Reviewed-by tags
  4. PR present in qcom-next/topics: Yes - all 2 commit(s) are present in qcom-next or topics
Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #990 - wifi: ath10k patches (2 commits)
Upstream commits:

Commit 1/2: UPSTREAM: wifi: ath10k: Support for FTM TLV test commands

Commit Message

Check Status Note
Subject matches upstream ✅ Subject identical (UPSTREAM: prefix added correctly)
Body preserves rationale ✅ Full commit message preserved
Fixes tag present/correct N/A No Fixes tag in upstream
Authorship preserved ✅ From: Loic Poulain matches upstream author
Backport note (if applicable) ✅ (cherry picked from commit 54be197109762d2a3c2b23d44e960ce7a43a3798) present

Diff

File Status Notes
drivers/net/wireless/ath/ath10k/core.h ✅ Faithful backport
drivers/net/wireless/ath/ath10k/testmode.c ✅ Faithful backport
drivers/net/wireless/ath/ath10k/testmode_i.h ✅ Faithful backport
drivers/net/wireless/ath/ath10k/wmi.h ✅ Faithful backport

Commit 2/2: FROMLIST: wifi: ath10k: filter non-UTF testmode events

Commit Message

Check Status Note
Subject matches upstream ✅ Subject identical (FROMLIST: prefix added correctly)
Body preserves rationale ✅ Full commit message preserved
Fixes tag present/correct N/A No Fixes tag in upstream
Authorship preserved ✅ From: Linghui Wu matches lore author; Signed-off-by present
Backport note (if applicable) N/A FROMLIST commit, not a backport

Diff

File Status Notes
drivers/net/wireless/ath/ath10k/testmode.c ✅ Diff content identical; line numbers differ due to context (commit 1/2 adds code earlier in file)

Diff comparison details:

  • Lore patch: function added at line 156, check added at line 182
  • PR patch: function added at line 31, check added at line 190
  • Reason: Commit 1/2 refactored testmode.c, moving code around. The PR correctly applies commit 2/2 on top of commit 1/2, resulting in different line numbers but identical code changes.

Upstream Patch Status

Commit Community Verdict
1/2: Support for FTM TLV test commands ✅ ACKed — merged as 54be197109762d2a3c2b23d44e960ce7a43a3798 (referenced in cherry-pick note)
2/2: filter non-UTF testmode events ✅ ACKed — applied by Jeff Johnson as commit 35a3da9fe1b212a9012952a04f383b8dc3708dd7 on 2026-08-01. Lore thread shows "Applied, thanks!" from maintainer plus Reviewed-by tags from Baochen Qiang and Rameshkumar Sundaram.

qcom-next Presence

Per integration_presence_report.md:

Commit Status
1/2: Support for FTM TLV test commands ✅ Present in qcom-next — exact patch-id match at 54be197109762d2a3c2b23d44e960ce7a43a3798
2/2: filter non-UTF testmode events ✅ Present in qcom-next — all checked added lines are present

Overall: PASS — all 2 commits present in qcom-next.

Issues Found

None. Both commits are faithful to their upstream sources.

Verdict

Merge as-is. Both commits correctly represent their upstream sources:

  1. Commit 1/2 is a clean cherry-pick from an already-merged upstream commit, with proper UPSTREAM: prefix and cherry-pick note.

  2. Commit 2/2 is a faithful representation of a lore patch that was posted to the mailing list and subsequently accepted by the maintainer. The FROMLIST: prefix is correct, authorship is preserved, and the diff content is identical (line number differences are due to the context changes introduced by commit 1/2).

Both commits are already present in qcom-next, confirming they have been integrated into the Qualcomm kernel tree.

Final Summary

  1. Lore link present: Yes — both commits have valid lore.kernel.org links in their commit messages
  2. Lore link matches PR commits: Yes — diff content is faithful to lore for both commits; line number differences in commit 2/2 are legitimate context shifts from commit 1/2
  3. Upstream patch status: ✅ ACKed — commit 1/2 merged into mainline; commit 2/2 applied by maintainer Jeff Johnson with Reviewed-by tags
  4. PR present in qcom-next/topics: Yes — both commits present in qcom-next (per integration_presence_report.md)

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: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/2 [PATCH 1/2] UPSTREAM: wifi: ath10k: Support for FTM TLV test commands present - exact patch-id match at 54be197 skipped - not checked because qcom-next already contains the change present
2/2 [PATCH 2/2] FROMLIST: wifi: ath10k: filter non-UTF testmode events present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

Final Status

overall_status: PASS
present_commits: 2/2
partial_commits: 0/2
missing_commits: 0/2
topics_checked_for_commits: 0/2
final_summary: PR present in qcom-next/topics: Yes - all 2 commit(s) are present in qcom-next or topics

@qlijarvis

qlijarvis commented Aug 25, 2026

Copy link
Copy Markdown

PR #990 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ✅ Passed
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ Content mismatch on commit 1/2
tag-check ✅ Both commits have valid prefixes

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #990 - wifi: ath10k: Support for FTM TLV test commands + filter non-UTF testmode events
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32453614635
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ✅ Passed
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ Content mismatch on commit 1/2
tag-check ✅ Both commits have valid prefixes

❌ check-patch-compliance

Root cause: The first commit's patch content differs from the upstream version referenced in the Link trailer.

Failure details:

Checking commit: UPSTREAM: wifi: ath10k: Support for FTM TLV test commands
Change is different from the one mentioned in Link

Analysis:

The commit is tagged as UPSTREAM: and includes:

  • Link: https://patch.msgid.link/20251020153759.407516-1-loic.poulain@oss.qualcomm.com
  • Cherry-pick note: (cherry picked from commit 54be197109762d2a3c2b23d44e960ce7a43a3798)

The checker detected that the patch content in the PR differs from the upstream version at the provided Link. This can happen for several reasons:

  1. Context-only differences — surrounding code has changed between upstream and qcom-6.18.y, causing context line shifts (not a real issue)
  2. Legitimate backport adaptations — the patch was modified to fit the target kernel version (should be documented)
  3. Missing or extra hunks — parts of the upstream patch were omitted or additional changes were added (needs review)

Fix:

To determine the nature of the difference:

# Fetch the upstream patch
b4 am --single-message -C -l -3 https://patch.msgid.link/20251020153759.407516-1-loic.poulain@oss.qualcomm.com -o /tmp/upstream

# Extract the PR patch
git format-patch -1 <commit-sha> --stdout > /tmp/pr-patch

# Compare only the diff content (ignore context shifts)
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')

Possible resolutions:

  • If context-only: This is a false positive due to the checker's limitation. The patch is functionally identical. No action needed.
  • If legitimate adaptation: Add a note to the commit message explaining the backport changes, e.g.: 
    [ Upstream commit 54be197109762d2a3c2b23d44e960ce7a43a3798 ]

Note: Minor context adjustments for qcom-6.18.y kernel version.
  • If missing/extra hunks: Review the differences carefully. If intentional, document them. If unintentional, align with upstream.

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base dc0f4d4280a7ecfcf8bc2d6bff1f42b1b8d33b08 \
  --head <PR-head-sha>

Verdict

1 non-blocking issue — The content mismatch on commit 1/2 requires investigation to determine if it's a false positive (context-only difference) or a legitimate backport adaptation that should be documented. The second commit passed all checks.

Recommendation: Investigate the content difference using the commands above. If it's context-only or a documented adaptation, the PR is ready to merge. If there are unexplained changes, align with upstream or document the rationale.

@qlijarvis

qlijarvis commented Aug 25, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #990

Job 208151 | SoC lemans-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208151

Failed test cases in LAVA job 208151 (SoC: lemans-evk).

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state on lemans-evk, indicating a missing dependency (likely thermal zone or IIO channel provider) preventing the qcom-spmi-temp-alarm driver from completing probe.
  3. Possible fix: This is a pre-existing platform integration issue unrelated to the PR (which only modifies ath10k WiFi testmode). The deferred probe is benign if thermal monitoring is not critical for the test suite. To resolve: verify device tree thermal-zones and IIO ADC channel bindings for lemans-evk PMIC temp-alarm nodes, ensure required providers (qcom-vadc, thermal framework) are enabled and probing before temp-alarm.
  4. Detail analysis attachment: failed_case_job208151_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test infrastructure failure — the SMMU test expects video codec device aa00000.video-codec to be attached to an IOMMU group, but the device is not present or did not probe on lemans-evk platform; this is a pre-existing platform/device-tree configuration issue unrelated to the PR's WiFi driver changes.
  3. Possible fix: Investigate why aa00000.video-codec is not probing on lemans-evk — check device tree for this SoC to confirm whether the video codec node exists, is enabled, and has correct compatible/reg properties; if the device is not supported on lemans-evk, update the SMMU test's platform-specific expectations to exclude this device for lemans-evk.
  4. Detail analysis attachment: failed_case_job208151_2_detailed.md
  Case 3: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA marked the test definition as failed because it contained two individual test case failures (Probe_Failure_Check and smmu). This is LAVA's standard behavior — when a test suite contains any failed test cases, LAVA marks the overall test definition result as "fail" with the message "Marking unfinished test run as failed". The kernel booted successfully (Linux version 6.18.37-02479-g1cd79b8b0124), all tests executed, and the test runner completed normally (LAVA_TEST_RUNNER EXIT). This is NOT a build load failure, kernel crash, or infrastructure issue.
  3. Possible fix: This is not a fixable LAVA issue — it is the expected behavior. The actual failures to investigate are the two individual test cases: (1) Probe_Failure_Check (case ID 1) which detected firmware load failures for regulatory.db and Bluetooth firmware, and (2) smmu (case ID 2). These individual test case failures should be triaged separately using the qlijarvis-triage skill as indicated in the .failed_cases_job208151.tsv manifest.
  4. Detail analysis attachment: failed_case_job208151_3_detailed.md
Job 208152 | SoC monaco-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208152

Failed test cases in LAVA job 208152 (SoC: monaco-evk).

  Case 1: ** Probe_Failure_Check — WiFi Driver Firmware Missing (Pre-existing Infrastructure Issue)
  1. Failed case: ** Probe_Failure_Check — WiFi Driver Firmware Missing (Pre-existing Infrastructure Issue)
  2. Root cause: ** The ath11k_pci driver probe fails with error -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the root filesystem. The board uses a WCN6855 hw2.1 WiFi card with board variant ID nfa765, but the Yocto build image does not include this specific firmware variant. This is a pre-existing build/infrastructure issue unrelated to the PR (which modifies ath10k, not ath11k).
  3. Possible fix: Add the missing WCN6855 nfa765 board variant firmware to the monaco-evk Yocto build recipe. Update meta-qcom layer to include firmware-qcom-ath11k-wcn6855-nfa765 package or equivalent. Verify the firmware file is present at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin in the built rootfs. If the board variant ID is incorrect, update the board data file or device tree to match available firmware variants.
  4. Detail analysis attachment: failed_case_job208152_1_detailed.md
  Case 2: ** WiFi_Firmware_Driver — WiFi driver probe failure
  1. Failed case: ** WiFi_Firmware_Driver — WiFi driver probe failure
  2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT because the required WCN6855 firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) is missing from the rootfs; MHI power-up timed out waiting for firmware load.
  3. Possible fix: Add the missing WCN6855 firmware files to the Yocto image recipe or rootfs overlay for monaco-evk; ensure linux-firmware-ath11k package includes the nfa765 board variant firmware, or manually copy firmware from linux-firmware.git to /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ on the target.
  4. Detail analysis attachment: failed_case_job208152_2_detailed.md
  Case 3: WiFi_OnOff — ath11k_pci driver probe failure
  1. Failed case: WiFi_OnOff — ath11k_pci driver probe failure
  2. Root cause: ath11k_pci PCIe WiFi driver probe failed with -ETIMEDOUT (-110) during MHI (Modem Host Interface) power-up sequence at boot time. The MHI bus controller failed to respond within the expected timeout window, preventing the WiFi device from initializing. This is a pre-existing platform/hardware initialization issue on monaco-evk, not introduced by PR Ath10k qcom 6.18 filter non utf #990 (which only modifies ath10k testmode code).
  3. Possible fix: This is a known hardware/firmware initialization race on monaco-evk where the PCIe WiFi device (ath11k) fails to power up via MHI during early boot. Recommended actions: (1) Verify PCIe link training completed successfully before ath11k probe; (2) Check if increasing MHI power-up timeout resolves the race; (3) Verify WiFi device power/clock sequencing in DT matches hardware requirements; (4) Check if firmware files for ath11k are present and accessible; (5) Re-run the test to confirm if this is a transient hardware initialization failure or a persistent regression.
  4. Detail analysis attachment: failed_case_job208152_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: ath11k WiFi driver probe failure (error -110 ETIMEDOUT) caused by missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2 ENOENT) on monaco-evk platform. This is a pre-existing infrastructure/firmware packaging issue unrelated to the PR, which only modifies ath10k driver code.
  3. Possible fix: Add the missing ath11k WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory for monaco-evk builds, or update the device tree/board configuration to use the correct firmware path that exists in the image.
  4. Detail analysis attachment: failed_case_job208152_4_detailed.md
Job 208153 | SoC purwa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208153

Failed test cases in LAVA job 208153 (SoC: purwa-evk).

  Case 1: Probe_Failure_Check — Platform driver probe failures (pre-existing, not PR-introduced)
  1. Failed case: Probe_Failure_Check — Platform driver probe failures (pre-existing, not PR-introduced)
  2. Root cause: Five platform drivers failed to probe during boot on purwa-evk: qcom_qseecom_uefisecapp (-EBUSY), qcom-spmi-lpg (-EINVAL), two qcom-pcie instances (-ENODATA), and regulatory.db firmware (-ENOENT). These are pre-existing platform/DT/firmware configuration issues unrelated to the PR, which only modifies ath10k WiFi driver testmode code for FTM TLV command support.
  3. Possible fix: These probe failures are expected/benign for this platform configuration and should be suppressed in the Probe_Failure_Check test for purwa-evk, or the underlying platform issues should be fixed: (1) qcom_qseecom_uefisecapp -EBUSY suggests secure app already loaded or resource conflict; (2) qcom-spmi-lpg -EINVAL indicates DT property mismatch; (3) qcom-pcie -ENODATA suggests PCIe endpoints not populated or DT incomplete; (4) regulatory.db -ENOENT is a known benign firmware file absence. The PR changes are isolated to ath10k testmode and do not affect these subsystems.
  4. Detail analysis attachment: failed_case_job208153_1_detailed.md
  Case 2: smmu — Missing IOMMU Group Attachments for USB and Video Codec Devices
  1. Failed case: smmu — Missing IOMMU Group Attachments for USB and Video Codec Devices
  2. Root cause: Six USB DWC3 controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec device (aa00000.video-codec) on purwa-evk are missing IOMMU group attachments, indicating incomplete device tree IOMMU bindings for these platform devices.
  3. Possible fix: Add missing iommus property entries in the purwa-evk device tree for the six USB DWC3 controllers and the video codec device, referencing the appropriate SMMU instance and stream IDs, following the pattern used by the successfully attached USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb).
  4. Detail analysis attachment: failed_case_job208153_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM requires ARM64 EL2 (Hypervisor mode) but the purwa-evk platform boots the kernel at EL1; kernel message kvm [1]: HYP mode not available at boot time (5.789s) confirms EL2 is unavailable, preventing /dev/kvm device node creation.
  3. Possible fix: Configure the bootloader (ABL/UEFI) on purwa-evk to boot the kernel at EL2, or verify that platform firmware/TrustZone policy allows EL2 access; if the platform does not support EL2 virtualization, mark KVM tests as expected-fail for this SoC in the CI test matrix.
  4. Detail analysis attachment: failed_case_job208153_3_detailed.md
  Case 4: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** The Purwa EVK platform runs the Gunyah hypervisor at EL2, which prevents the Linux kernel (running as a guest at EL1) from accessing HYP mode. KVM requires EL2 access to function as a host hypervisor and cannot initialize when another hypervisor is already present. This is expected behavior on Gunyah-based platforms.
  3. Possible fix: This is not a bug — it is the expected platform configuration. KVM host functionality and Gunyah are mutually exclusive. To run KVM tests, use a platform without Gunyah (bare-metal EL2 access), or disable Gunyah in the firmware/bootloader configuration. For CI: suppress KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests on Gunyah-based platforms (purwa-evk, and any other board with Gunyah hypervisor enabled).
  4. Detail analysis attachment: failed_case_job208153_4_detailed.md
  Case 5: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM infrastructure unavailable on purwa-evk platform because the kernel booted without EL2/HYP mode access — the bootloader or firmware did not enter the kernel at EL2, preventing KVM from initializing and creating /dev/kvm.
  3. Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression. The PR modifies only WiFi ath10k testmode code and does not touch KVM, ARM virtualization, or boot paths. To enable KVM on purwa-evk: (1) verify the bootloader (ABL/UEFI) is configured to enter Linux at EL2 instead of EL1, (2) confirm the device tree does not contain properties that force EL1 boot, and (3) check that TrustZone/hypervisor firmware allows EL2 access to the kernel. If KVM support is not required for this platform, mark these tests as expected-fail or skip them in the CI job definition for purwa-evk.
  4. Detail analysis attachment: failed_case_job208153_5_detailed.md
  Case 6: KVM_Infra (and related: KVM_Driver, KVM_EL2_DTB)
  1. Failed case: KVM_Infra (and related: KVM_Driver, KVM_EL2_DTB)
  2. Root cause: KVM is not available on purwa-evk because the Gunyah hypervisor is running in a mode that does not expose KVM functionality to the primary VM. The kernel message "kvm [1]: HYP mode not available" indicates that EL2 is already claimed by the Gunyah hypervisor, preventing KVM from initializing. This is a platform/board configuration issue, not a kernel regression.
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced issue. The PR changes only WiFi ath10k driver code and does not affect virtualization. The KVM tests should either be: (1) disabled for purwa-evk in the LAVA test suite configuration, or (2) marked as expected failures for boards running Gunyah hypervisor in non-nested-virtualization mode. No kernel code fix is required.
  4. Detail analysis attachment: failed_case_job208153_6_detailed.md
Job 208154 | SoC qcs615-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208154

Failed test cases in LAVA job 208154 (SoC: qcs615-ride).

  Case 1: Kernel Panic — Warm Reset During Boot (login-action timeout due to unexpected system reboot)
  1. Failed case: Kernel Panic — Warm Reset During Boot (login-action timeout due to unexpected system reboot)
  2. Root cause: System triggered a warm reset via PS_HOLD approximately 8-9 seconds after reaching the "Serial Getty on ttyMSM0" stage. Bootloader log confirms "PM: WARM reset by PS_HOLD" on the subsequent boot. The kernel cmdline includes reboot=panic_warm panic=-1, indicating that a kernel panic occurred but the panic message was not captured in the serial log before the warm reboot executed. The system never presented a login prompt to LAVA because it rebooted before the login-action timeout expired. This is a genuine kernel stability issue, not a LAVA infrastructure problem.
  3. Possible fix: Investigate the root cause of the kernel panic that triggered the warm reboot. The panic occurred during late-stage userspace initialization (after systemd started getty but before login prompt was fully established). Review the PR changes to ath10k WiFi driver (testmode FTM TLV support and UTF event filtering) for potential issues that could cause a panic during driver initialization or module loading. Enable crash dump collection (ramdump/pstore) to capture the panic backtrace on the next occurrence. If the issue is reproducible, add early_printk or increase console log buffer size to capture the panic message before warm reboot. Check if the ath10k driver is being loaded during boot and if the panic correlates with WiFi initialization.
  4. Detail analysis attachment: failed_case_job208154_1_detailed.md
  Case 2: Kernel Crash — Warm reset triggered by PS_HOLD, system entered ramdump mode preventing login
  1. Failed case: Kernel Crash — Warm reset triggered by PS_HOLD, system entered ramdump mode preventing login
  2. Root cause: The kernel experienced a crash or panic during the first boot that triggered a warm reset via PS_HOLD. On the subsequent boot, the bootloader detected TCSR register value 0x10 (download mode enabled) and entered ramdump/download mode instead of continuing normal boot. The system remained in ramdump mode waiting for USB ramdump transfer, preventing the login prompt from appearing and causing the auto-login-action to timeout.
  3. Possible fix: Investigate the kernel crash that occurred during the first boot (before the warm reset). The WARNING at kernel/sched/idle.c:267 in cpuidle_idle_call may be related but is typically non-fatal. Check for additional crash evidence (panic, oops, or watchdog bite) in the serial console logs between kernel boot and the warm reset. If no crash logs are visible, the issue may be a silent hang or watchdog timeout. Disable download mode for non-debug builds by removing qcom_scm.download_mode=1 from kernel cmdline, or investigate the root cause of the crash by enabling additional debug options (e.g., panic_on_warn, lockdep, KASAN) and reproducing the issue.
  4. Detail analysis attachment: failed_case_job208154_2_detailed.md
  Case 3: minimal-boot — Serial console hang with watchdog-triggered warm reset
  1. Failed case: minimal-boot — Serial console hang with watchdog-triggered warm reset
  2. Root cause: Serial console (ttyMSM0) stopped producing output after systemd reached "Login Prompts" target at 09:15:59. No login prompt appeared despite getty service starting successfully. System entered ramdump/EDL mode via warm reset (bootloader shows "WARM reset by PS_HOLD", "TCSR reg value 0x10", and "boot_dload_entry") approximately 7-9 seconds after last kernel message, consistent with watchdog-triggered reset due to serial console hang or system-level freeze.
  3. Possible fix: This is a LAVA infrastructure/board issue, not a PR-introduced regression. The PR changes only WiFi ath10k driver code (FTM TLV test commands) and cannot affect serial console or getty operation. Recommended actions: (1) Re-trigger the LAVA job to verify if this is a transient board/infrastructure issue, (2) If recurs, check qcs615-ride board serial console hardware connection and LAVA worker serial multiplexer status, (3) Review board watchdog configuration and timeout values, (4) Check for known qcs615-ride board-specific serial console stability issues in the LAVA lab.
  4. Detail analysis attachment: failed_case_job208154_3_detailed.md
  Case 4: Login Timeout — System Hang with Warm Reset
  1. Failed case: Login Timeout — System Hang with Warm Reset
  2. Root cause: System hung after reaching userspace (Login Prompts target) and triggered a warm reset via PS_HOLD (TCSR=0x10). The board failed to present a login prompt across 3 retry attempts, with LAVA timing out after sending '#' prompts with no response. Early boot showed a cpuidle WARNING at kernel/sched/idle.c:267, suggesting potential idle/power management instability on qcs615-ride.
  3. Possible fix: Investigate the cpuidle WARNING at kernel/sched/idle.c:267 cpuidle_idle_call+0x160/0x208 on CPU1 during early boot — this may indicate a race condition or misconfiguration in the idle driver for qcs615. Check if the PR's ath10k testmode changes inadvertently affect system stability (e.g., memory corruption, locking issues). Enable additional debug (CONFIG_LOCKDEP, CONFIG_DEBUG_ATOMIC_SLEEP) and capture a full dmesg log including the hang/panic that triggered the warm reset. If the issue is reproducible, bisect between the base and PR commits to isolate the regression.
  4. Detail analysis attachment: failed_case_job208154_4_detailed.md
Job 208155 | SoC qcs8300-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208155

Failed test cases in LAVA job 208155 (SoC: qcs8300-ride).

  Case 1: ** Probe_Failure_Check (2 pre-existing platform issues detected)
  1. Failed case: ** Probe_Failure_Check (2 pre-existing platform issues detected)
  2. Root cause: ** Two pre-existing platform/infra issues unrelated to PR Ath10k qcom 6.18 filter non utf #990: (1) Aquantia AQR115C PHY probe failure (-EINVAL) caused by missing firmware-name device tree property in qcs8300-ride DTS, and (2) regulatory.db firmware file missing from rootfs image (-ENOENT), a benign packaging issue that does not impact WiFi/BT functionality.
  3. Possible fix: (1) Add firmware-name property to Aquantia PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts or patch the Aquantia driver to gracefully handle missing property; (2) Include wireless-regdb package in Yocto image recipe to provide regulatory.db file. Note: PR Ath10k qcom 6.18 filter non utf #990 should NOT be blocked by these pre-existing issues.
  4. Detail analysis attachment: failed_case_job208155_1_detailed.md
  Case 2: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure issue — no external USB devices connected to qcs8300-ride board USB ports. The xHCI host controller initialized successfully and the USB root hub is detected, but the test expects functional USB peripherals (keyboard, mouse, storage) to be physically present. This is a LAVA lab hardware setup gap, not a kernel regression.
  3. Possible fix: Connect functional USB devices (keyboard, mouse, or USB storage) to the qcs8300-ride board's USB host ports in the LAVA lab. If devices are already connected, verify USB cable integrity and power delivery. This is not a kernel issue — the PR modifies WiFi (ath10k) code and does not touch USB subsystem.
  4. Detail analysis attachment: failed_case_job208155_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Mark KVM tests as expected-fail or skip them on QCS8300 platforms configured with Gunyah hypervisor. This is not a PR-introduced regression — the PR modifies WiFi driver code (ath10k FTM TLV) which is unrelated to KVM/virtualization. No kernel fix is needed; this is correct platform behavior.
  4. Detail analysis attachment: failed_case_job208155_3_detailed.md
  Case 4: KVM Runtime Initialization Failure
  1. Failed case: KVM Runtime Initialization Failure
  2. Root cause: KVM driver fails to initialize on QCS8300 Ride (Monaco) when running under Gunyah hypervisor (gunyah-1cb9db980) — CONFIG_KVM is enabled but KVM does not probe, /dev/kvm device node is never created, and no KVM initialization messages appear in kernel log, indicating KVM's early initialization check (likely CPU feature or hypervisor compatibility check) silently fails before driver registration.
  3. Possible fix: Verify KVM ARM64 support for nested virtualization under Gunyah hypervisor on QCS8300 — check if CONFIG_KVM_ARM_HOST is enabled, ensure CPU supports required EL2 features (VHE or nVHE), and confirm Gunyah hypervisor configuration allows KVM to run in guest mode; if KVM under Gunyah is not supported on this platform, disable KVM tests for qcs8300-ride or configure the platform to boot without Gunyah when KVM testing is required.
  4. Detail analysis attachment: failed_case_job208155_4_detailed.md
  Case 5: KVM Infrastructure Test — /dev/kvm unavailable (platform configuration issue)
  1. Failed case: KVM Infrastructure Test — /dev/kvm unavailable (platform configuration issue)
  2. Root cause: QCS8300 Ride platform is running under the Gunyah hypervisor at EL2, which prevents KVM from initializing because KVM requires direct EL2 access that is unavailable when Linux runs as a guest under another hypervisor. This is an architectural incompatibility, not a kernel bug.
  3. Possible fix: This is not a kernel issue and cannot be fixed in software. To enable KVM on QCS8300 Ride: (1) Boot Linux directly at EL2 without the Gunyah hypervisor, OR (2) Configure Gunyah to expose nested virtualization support to the guest kernel (if supported by the platform firmware). For CI purposes, suppress KVM tests on platforms running under Gunyah, or add a test precondition check that skips KVM tests when /sys/hypervisor/type indicates a hypervisor is present.
  4. Detail analysis attachment: failed_case_job208155_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM device node /dev/kvm is not present on qcs8300-ride platform despite CONFIG_KVM being enabled — KVM driver failed to initialize or create the device node during boot, likely due to missing hardware virtualization support (EL2/VHE) or platform-specific KVM initialization failure on this SoC.
  3. Possible fix: This is a pre-existing platform issue unrelated to the PR (which only modifies WiFi ath10k testmode). Verify qcs8300 hardware supports ARM virtualization extensions (EL2) and check kernel boot log for KVM initialization errors. If KVM is not supported on qcs8300-ride, exclude KVM tests from the CI test suite for this platform. If KVM should be supported, investigate why the KVM driver probe failed to create /dev/kvm.
  4. Detail analysis attachment: failed_case_job208155_6_detailed.md
Job 208156 | SoC shikra-iqs-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208156

Failed test cases in LAVA job 208156 (SoC: shikra-iqs-evk).

  Case 1: GIC Test Script Bug — Test Harness Defect
  1. Failed case: GIC Test Script Bug — Test Harness Defect
  2. Root cause: The GIC test script (run.sh line 75) attempts to parse /proc/interrupts for 8 CPUs but the shikra-iqs-evk platform has only 4 CPUs (0-3); the script's field extraction logic breaks when parsing the 4-column interrupt line, treating non-numeric fields (GICv3, Level, arch_timer) as CPU interrupt counts and failing bash integer comparison tests for CPUs 4-7.
  3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo before parsing /proc/interrupts, and only validate timer interrupt increments for CPUs that actually exist on the platform.
  4. Detail analysis attachment: failed_case_job208156_1_detailed.md
  Case 2: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Test detects 6 pre-existing probe failures on shikra-iqs-evk platform: (1) coresight-etm4x error -22 (EINVAL) due to DT/hardware config mismatch for CPU debug resources; (2) cpufreq-dt error -17 (EEXIST, benign — alternate qcom-cpufreq-hw driver functional, CPUFreq test passes); (3) regulatory.db firmware missing from rootfs (error -2, non-critical); (4) 4 deferred probes for audio codec, sound card, and WiFi regulator due to missing dependencies in this board configuration. None are introduced by PR Ath10k qcom 6.18 filter non utf #990 (which only modifies ath10k WiFi test mode code).
  3. Possible fix: Suppress benign probe failures in Probe_Failure_Check test logic: (1) Exclude cpufreq-dt error -17 when CPUFreq_Validation passes; (2) Exclude regulatory.db firmware load failures (non-critical); (3) Exclude deferred probes for audio/sound when Audio_Card_Registration is SKIP; (4) Exclude coresight-etm4x failures (tracing is non-critical for functional validation). Alternatively, fix the root causes: add CoreSight DT nodes for shikra, include regulatory.db in rootfs, wire audio codec clocks and WiFi regulators in DT if those subsystems are intended to be tested.
  4. Detail analysis attachment: failed_case_job208156_2_detailed.md
  Case 3: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** USB host controller drivers (dwc3/xhci) are not loaded or configured for the shikra-iqs-evk board in this LAVA environment. The test expects USB host mode with enumerable devices, but the board is either configured for USB gadget mode only, or USB host drivers are not included in the kernel build. This is a pre-existing board/infrastructure limitation, not a kernel regression introduced by PR 990 (which only modifies WiFi ath10k driver code).
  3. Possible fix: This is not a kernel bug requiring a code fix. To enable USB host testing on shikra-iqs-evk: (1) Verify the kernel config includes CONFIG_USB_DWC3=y and CONFIG_USB_XHCI_HCD=y, (2) Ensure the device tree for shikra-iqs-evk configures the USB controller in host mode (dr_mode = "host" or "otg", not "peripheral"), (3) Physically connect a USB device to the host port, (4) If the board hardware only supports USB gadget mode, mark this test as "skip" or "not applicable" for this platform in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job208156_3_detailed.md
  Case 4: BT_SCAN
  1. Failed case: BT_SCAN
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel bug requiring a code fix. To resolve: (1) Place a Bluetooth beacon or test device within range of the shikra-iqs-evk board in the LAVA lab, OR (2) Mark BT_SCAN as an optional/informational test that does not block PR merge when no devices are in range, OR (3) Add a LAVA job definition parameter to skip BT_SCAN when no test devices are available.
  4. Detail analysis attachment: failed_case_job208156_4_detailed.md
  Case 5: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware bus error (synchronous external abort 0x96000010) when qcom_rng_read attempted to access RNG hardware MMIO registers at offset +0xc4. The crash occurred during the qcom_hwrng test (not KVM_Driver test) when reading from /dev/hwrng. This is a hardware access fault indicating the RNG hardware block is either unpowered, unclock ed, or the MMIO mapping is invalid on Shikra IQS EVK platform.
  3. Possible fix: Verify qcom_rng device tree node for Shikra (qcm2290-based) includes correct MMIO base address, clock references (iface_clk, core_clk), and power domain. Check if RNG hardware block requires explicit power/clock enablement before access. Add runtime PM support or probe-time hardware readiness check to qcom_rng driver to prevent access to unpowered/unclocked hardware. Short-term: disable qcom_hwrng test on Shikra platform until hardware configuration is validated.
  4. Detail analysis attachment: failed_case_job208156_5_detailed.md
  Case 6: KVM_EL2_DTB — KVM driver initialization failure
  1. Failed case: KVM_EL2_DTB — KVM driver initialization failure
  2. Root cause: Shikra IQS EVK platform is configured with Gunyah hypervisor running at EL2 (confirmed by boot log: "Hypervisor cold boot, version: gunyah-mobile-798c4fbea" and "kvm [1]: HYP mode not available"). When a hypervisor occupies EL2, Linux KVM cannot initialize because it requires exclusive EL2 access to provide virtualization services. This is a platform firmware/configuration constraint, not a kernel software bug.
  3. Possible fix: This is not a bug introduced by PR Ath10k qcom 6.18 filter non utf #990 (which only touches ath10k WiFi driver). To enable KVM on this platform, the Gunyah hypervisor firmware must be removed or the platform must be reconfigured to boot without a hypervisor at EL2. Alternatively, if nested virtualization support is required, the Gunyah hypervisor would need to expose nested virtualization capabilities to the Linux guest, which is not currently supported. For CI purposes, either: (1) skip KVM tests on Shikra IQS EVK boards configured with Gunyah, or (2) use a different board configuration without Gunyah for KVM testing.
  4. Detail analysis attachment: failed_case_job208156_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Short-term**: Disable the qcom_hwrng test on Shikra IQS EVK in the LAVA job definition or blacklist the qcom_rng kernel module to prevent the crash. Long-term: Investigate Shikra IQS EVK hardware documentation to determine if the RNG block is present and accessible; if not supported, disable the RNG device tree node with status = "disabled" in arch/arm64/boot/dts/qcom/sm8450-shikra-iqs-evk.dts; if supported but misconfigured, add missing clock/power-domain dependencies to the device tree.
  4. Detail analysis attachment: failed_case_job208156_7_detailed.md
  Case 8: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware RNG (qcom_rng) driver encountered a synchronous external abort (bus error) at address access during qcom_rng_read() execution while the qcom_hwrng test was reading from /dev/hwrng. The abort indicates the hardware RNG peripheral was not responding or not properly powered/clocked when accessed, causing a fatal bus fault that triggered kernel panic. This is a platform-specific hardware/firmware/driver integration issue on shikra-iqs-evk, not related to the PR's ath10k WiFi changes.
  3. Possible fix: This is a pre-existing platform issue, not a PR regression. The PR (ath10k WiFi FTM test commands) should not be blocked by this failure. Recommended actions: (1) Disable the qcom_hwrng test in the CI test suite for shikra-iqs-evk until the hardware RNG driver/firmware/power sequencing issue is resolved. (2) Investigate qcom_rng driver probe logs and hardware RNG power/clock dependencies on shikra-iqs-evk — the peripheral may require additional power domain, clock, or reset sequencing that is missing or incorrect in the device tree or firmware. (3) Re-run the PR validation on a different platform or with qcom_hwrng test excluded to verify the ath10k changes.
  4. Detail analysis attachment: failed_case_job208156_8_detailed.md
  Case 9: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: Hardware register access fault in qcom_rng_read() when the qcom_hwrng test attempted to read from /dev/hwrng. The synchronous external abort (ESR 0x96000010) indicates the CPU attempted to read from a physical address that either does not respond or is not accessible, suggesting the PRNG hardware block on shikra-iqs-evk is not properly powered, clocked, or the register mapping is incorrect for this SoC variant.
  3. Possible fix: Disable the qcom_hwrng test for shikra-iqs-evk until the platform DT is corrected to either: (1) remove the qcom,prng node if the hardware block is not present/functional on this SoC, (2) add missing power-domain/clock bindings if the block requires runtime PM, or (3) mark the node as disabled (status = "disabled") if the hardware is present but not validated for this platform.
  4. Detail analysis attachment: failed_case_job208156_9_detailed.md
  Case 10: **Kernel Crash — Synchronous External Abort in qcom_rng driver**
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: The qcom_rng driver triggered a synchronous external abort (bus error) at qcom_rng_read+0xc4 when attempting to read from the hardware RNG MMIO register. The abort indicates the hardware register at the mapped address is not accessible (likely clock/power gating issue, incorrect MMIO mapping, or hardware not initialized). After the panic, the system correctly entered ramdump mode per the configured reboot=panic_warm cmdline, but LAVA timed out waiting for the board to return from EDL/ramdump, causing the lava-test-retry wrapper to fail.
  3. Possible fix: This is a pre-existing platform/driver bug unrelated to PR 990 (which only touches ath10k WiFi). The qcom_hwrng test should be marked as a known failure for shikra-iqs-evk until the root cause is fixed. Short-term: skip the qcom_hwrng test on this platform. Long-term: investigate why the PRNG MMIO region is not accessible — check clock/regulator dependencies in the qcom-rng DT node for shikra, verify the MMIO base address matches hardware documentation, and add runtime PM / clock enable calls if missing in the driver probe path.
  4. Detail analysis attachment: failed_case_job208156_10_detailed.md
  Case 11: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: The qcom_hwrng test triggered a synchronous external abort (bus fault) at PC qcom_rng_read+0xc4 when the dd process attempted to read entropy from /dev/hwrng. The fault occurred during a memory-mapped I/O read operation (instruction b940035c at offset 0xc4), indicating the hardware RNG peripheral became inaccessible or was not properly powered/clocked during the read operation. This is a pre-existing kernel/hardware issue unrelated to the PR's ath10k WiFi driver changes.
  3. Possible fix: This is not a PR-introduced regression. The PR modifies only ath10k WiFi testmode functionality and does not touch the qcom_rng driver or related clock/power infrastructure. The failure should be reported to the kernel maintainers as a qcom_rng driver robustness issue on shikra-iqs-evk. Short-term: skip the qcom_hwrng test on this platform until the driver is fixed. Long-term: investigate why the RNG hardware becomes inaccessible during sustained reads — likely a clock gating, power domain, or bus fabric issue specific to this SoC.
  4. Detail analysis attachment: failed_case_job208156_11_detailed.md
Job 208157 | SoC qcs9100-ride

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208157

Failed test cases in LAVA job 208157 (SoC: qcs9100-ride).

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test detected three pre-existing platform issues on qcs9100-ride: (1) Four PMIC temp-alarm devices stuck in deferred probe due to missing thermal zone or IIO ADC provider configuration in device tree, (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name property in device tree (error -22/-EINVAL), (3) cfg80211 regulatory.db firmware file not found (error -2/-ENOENT, benign cosmetic warning). None of these issues are introduced by PR Ath10k qcom 6.18 filter non utf #990, which only modifies ath10k WiFi driver test mode support.
  3. Possible fix: Mark this test failure as a false positive for PR Ath10k qcom 6.18 filter non utf #990 regression testing. The PR does not introduce any new probe failures. To resolve the underlying platform issues: (1) Add thermal zone and IIO ADC channel definitions for PMIC temp-alarm devices in qcs9100-ride device tree, (2) Add firmware-name property to Aquantia PHY device tree node or provide the required firmware file in rootfs, (3) Optionally add regulatory.db firmware file to rootfs or suppress this benign warning in the test filter.
  4. Detail analysis attachment: failed_case_job208157_1_detailed.md
  Case 2: smmu (test-level failure — platform-specific device expectation mismatch)
  1. Failed case: smmu (test-level failure — platform-specific device expectation mismatch)
  2. Root cause: The SMMU test expects a video codec device at address aa00000.video-codec to be present and attached to an IOMMU group, but this device does not exist on the qcs9100-ride platform. The actual video codec devices on this SoC are iris_non_pixel.0 (IOMMU group 27) and iris_pixel.0 (IOMMU group 28), which are both correctly attached and functional.
  3. Possible fix: Update the SMMU test's platform-specific device list for qcs9100-ride to expect iris_non_pixel.0 and iris_pixel.0 instead of aa00000.video-codec, or make the test query the actual device tree to discover video codec devices dynamically rather than using a hardcoded address.
  4. Detail analysis attachment: failed_case_job208157_2_detailed.md
  Case 3: USBHost
  1. Failed case: USBHost
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Update the LAVA job definition for qcs9100-ride to either: (1) physically connect USB test devices (keyboard, mouse, or mass storage) to the board's USB ports before running the USBHost test, or (2) mark USBHost as SKIP when no USB devices are detected (similar to how the Ethernet test handles no-cable scenarios), or (3) add USBHost to the known benign failures list if USB device availability cannot be guaranteed in the lab environment.
  4. Detail analysis attachment: failed_case_job208157_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test definition marked as "unfinished" because three individual test cases failed within the test suite: (1) Probe_Failure_Check detected deferred probe issues for temp-alarm devices and probe failures for regulatory.db firmware and Aquantia AQR115C Ethernet PHY; (2) smmu test failed because critical video codec device (aa00000.video-codec) is missing IOMMU group attachment; (3) USBHost test failed because no functional USB devices were connected (only USB hubs detected). These are test environment and hardware configuration issues, not kernel regressions introduced by the PR.
  3. Possible fix: The PR changes (ath10k WiFi FTM TLV test command support) are unrelated to the failed tests. All failures are pre-existing platform/test-environment issues on qcs9100-ride: (1) For Probe_Failure_Check: the temp-alarm deferred probes and Aquantia PHY probe failure are known board-specific issues unrelated to WiFi driver changes; (2) For smmu: add the video codec device to the expected critical masters list or fix the device tree to ensure IOMMU group attachment; (3) For USBHost: this is a test harness issue—connect a functional USB device to the board or mark this test as optional for automated CI. Re-trigger the CI job; the PR itself does not introduce any of these failures.
  4. Detail analysis attachment: failed_case_job208157_4_detailed.md
Job 208158 | SoC hamoa-evk

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208158

Failed test cases in LAVA job 208158 (SoC: hamoa-evk).

  Case 1: ** Probe_Failure_Check (pre-existing platform issues)
  1. Failed case: ** Probe_Failure_Check (pre-existing platform issues)
  2. Root cause: ** Three pre-existing probe failures detected on hamoa-evk platform: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to resource conflict or prior initialization, (2) qcom-spmi-lpg fails with -EINVAL due to invalid DT "reg" property for multi-LED configuration, (3) regulatory.db firmware file missing from rootfs causing cfg80211 regulatory database load failure. None are introduced by PR 990 which modifies only ath10k WiFi testmode code.
  3. Possible fix: These are known platform configuration issues unrelated to PR 990. No action required for this PR. To resolve the underlying issues: (1) investigate qcom_qseecom_uefisecapp resource conflict (check if QSEECOM is already initialized by firmware/bootloader), (2) fix hamoa-evk device tree SPMI-LPG multi-LED "reg" property per driver binding requirements, (3) add regulatory.db firmware file to rootfs image.
  4. Detail analysis attachment: failed_case_job208158_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test expectation mismatch — the smmu test expects certain USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) to have IOMMU group attachments, but these devices are not present in the device tree or are not configured with IOMMU bindings on the hamoa-evk platform. The SMMU subsystem itself is functional (no errors in dmesg, 34 devices successfully attached), and the PR changes only WiFi driver code unrelated to SMMU/USB/video.
  3. Possible fix: Update the smmu test's critical master list for hamoa-evk to exclude the missing USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec), or add IOMMU bindings for these devices in the hamoa device tree if they are expected to be present. This is a pre-existing platform configuration issue, not a regression introduced by PR Ath10k qcom 6.18 filter non utf #990.
  4. Detail analysis attachment: failed_case_job208158_2_detailed.md
  Case 3: KVM_Driver — Platform Configuration Issue (Gunyah Hypervisor Conflict)
  1. Failed case: KVM_Driver — Platform Configuration Issue (Gunyah Hypervisor Conflict)
  2. Root cause: KVM initialization failed with "HYP mode not available" because the hamoa-evk platform is running under the Gunyah hypervisor (gunyah-mobile-c487961e9), which occupies EL2 (HYP mode). KVM requires exclusive access to EL2 to function, creating a fundamental architectural conflict on this platform configuration.
  3. Possible fix: This is a platform configuration issue, not a kernel bug or PR-introduced regression. The KVM_Driver test should be skipped on hamoa-evk (and other Gunyah-enabled platforms) via LAVA job definition test filters, as KVM and Gunyah hypervisor cannot coexist. Alternatively, if KVM testing is required, the platform must be configured to boot without the Gunyah hypervisor.
  4. Detail analysis attachment: failed_case_job208158_3_detailed.md
  Case 4: KVM_EL2_DTB — Platform Limitation (HYP Mode Not Available)
  1. Failed case: KVM_EL2_DTB — Platform Limitation (HYP Mode Not Available)
  2. Root cause: The Hamoa IoT EVK platform does not support ARM Virtualization Extensions (EL2/HYP mode), as evidenced by the kernel message "kvm [1]: HYP mode not available" at boot time (line 3803). CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware does not provide EL2 support, preventing /dev/kvm device creation and causing all KVM-dependent tests to fail.
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR Ath10k qcom 6.18 filter non utf #990 contains only WiFi ath10k driver changes unrelated to KVM). The test should be skipped on platforms without EL2 support. Add a platform capability check to the LAVA job definition to skip KVM tests on Hamoa EVK, or update the test runner to detect "HYP mode not available" in dmesg and report SKIP instead of FAIL for KVM tests on such platforms.
  4. Detail analysis attachment: failed_case_job208158_4_detailed.md
  Case 5: KVM Infrastructure Test Failure — Platform Boot Mode Incompatibility
  1. Failed case: KVM Infrastructure Test Failure — Platform Boot Mode Incompatibility
  2. Root cause: The hamoa-evk platform boots Linux at EL1 (Exception Level 1) instead of EL2 (Hypervisor mode), preventing KVM initialization. The kernel log shows "kvm [1]: HYP mode not available" and "CPU: All CPU(s) started at EL1", which means the ARM64 KVM driver cannot create /dev/kvm because virtualization extensions require EL2 privilege level.
  3. Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression (PR Ath10k qcom 6.18 filter non utf #990 contains only WiFi ath10k changes). The hamoa-evk bootloader/firmware must be configured to boot Linux at EL2 to enable KVM support. Update the UEFI/ABL boot configuration to enter the kernel at EL2, or mark KVM tests as expected-fail for this platform until firmware support is added.
  4. Detail analysis attachment: failed_case_job208158_5_detailed.md
  Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA marked the test suite as failed with "Marking unfinished test run as failed" after the test runner completed normally. The test suite contained 5 genuine test failures (Probe_Failure_Check, smmu, KVM_Driver, KVM_EL2_DTB, KVM_Infra) that caused LAVA to mark the overall suite result as fail. This is expected LAVA behavior when individual tests within a suite fail - not a kernel crash or infrastructure failure.
  3. Possible fix: Review and address the 5 individual test failures: (1) Probe_Failure_Check failed due to 3 probe errors (qcom_qseecom_uefisecapp -EBUSY, qcom-spmi-lpg -EINVAL, regulatory.db -ENOENT); (2) smmu failed due to 3 USB/Video devices missing IOMMU group attachment; (3-5) All KVM tests failed because /dev/kvm device node is not present despite CONFIG_KVM being enabled. These are pre-existing platform issues unrelated to the WiFi ath10k patches in PR Ath10k qcom 6.18 filter non utf #990.
  4. Detail analysis attachment: failed_case_job208158_6_detailed.md
Job 208159 | SoC qcs6490-rb3gen2

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/208159

Failed test cases in LAVA job 208159 (SoC: qcs6490-rb3gen2).

  Case 1: ** GIC Test Script Bug — Test Parsing Error
  1. Failed case: ** GIC Test Script Bug — Test Parsing Error
  2. Root cause: ** The GIC test script has a bash parsing bug at line 75 that fails to correctly parse /proc/interrupts output when CPUs 6-7 are offline. The script encounters "GICv3" string instead of an integer when comparing timer counts for offline CPUs, causing a bash integer comparison error ([: GICv3: integer expected). CPUs 6-7 are legitimately offline on qcs6490-rb3gen2 (only CPUs 0-5 are online), but the test script incorrectly expects all 8 possible CPUs to have active timer interrupts.
  3. Possible fix: Fix the GIC test script (/lava-208159/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh line 75) to check CPU online status before attempting timer count comparison, or modify the parsing logic to handle cases where /proc/interrupts columns don't exist for offline CPUs. The script should skip offline CPUs or gracefully handle missing interrupt counter columns.
  4. Detail analysis attachment: failed_case_job208159_1_detailed.md
  Case 2: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Two pre-existing firmware/probe errors detected during boot: (1) cfg80211 regulatory.db firmware missing (error -2 / -ENOENT), and (2) Renesas USB xHCI controller firmware (renesas_usb_fw.mem) missing (error -2 / -ENOENT). Both are platform/rootfs packaging issues unrelated to the PR's ath10k WiFi testmode changes.
  3. Possible fix: Add regulatory.db and renesas_usb_fw.mem firmware files to the rootfs image. These are optional firmware files that do not impact core functionality (WiFi works without regulatory.db using built-in regulatory rules; USB host works via fallback xhci-hcd driver). To eliminate test noise, package linux-firmware-regulatory and linux-firmware-renesas in the build.
  4. Detail analysis attachment: failed_case_job208159_2_detailed.md
  Case 3: ** Freq_Scaling
  1. Failed case: ** Freq_Scaling
  2. Root cause: ** Test logic error — the Freq_Scaling test expects 8 CPUs (CPU0-7) to have cpufreq interfaces, but qcs6490-rb3gen2 only successfully boots 6 CPUs (CPU0-5). CPU6 and CPU7 fail to boot with PSCI error -22 (EINVAL), which is a known platform limitation or firmware configuration issue for this SoC/board combination. The test incorrectly assumes all 8 CPUs defined in the device tree will be online.
  3. Possible fix: Update the Freq_Scaling test script to dynamically detect online CPUs via /sys/devices/system/cpu/online or /sys/devices/system/cpu/cpu*/online before checking for cpufreq interfaces, rather than hardcoding an expectation of 8 CPUs. The test should only validate cpufreq interfaces for CPUs that successfully booted.
  4. Detail analysis attachment: failed_case_job208159_3_detailed.md
  Case 4: USBHost
  1. Failed case: USBHost
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the Renesas USB firmware file (renesas_usb_fw.mem) to the rootfs under /lib/firmware/. The firmware can be obtained from the linux-firmware repository or Renesas directly. Alternatively, if USB host functionality is not required for this platform configuration, disable the xhci-pci-renesas driver in the kernel config or mark the USBHost test as expected-to-skip for rb3gen2 in the CI configuration.
  4. Detail analysis attachment: failed_case_job208159_4_detailed.md
  Case 5: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** qcs6490-rb3gen2 platform is running Gunyah hypervisor at EL2; KVM cannot initialize because EL2 is already claimed. KVM and Gunyah are mutually exclusive hypervisors. This is a pre-existing platform configuration issue, not a regression introduced by PR Ath10k qcom 6.18 filter non utf #990 (which only modifies ath10k WiFi driver).
  3. Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test suite, as this platform is configured for Gunyah (not KVM). Alternatively, if KVM testing is required, provision a separate qcs6490-rb3gen2 board with a firmware/bootloader configuration that does not initialize Gunyah, allowing KVM to claim EL2 during Linux boot.
  4. Detail analysis attachment: failed_case_job208159_5_detailed.md
  Case 6: KVM_EL2_DTB — KVM Unavailable (HYP Mode Not Available)
  1. Failed case: KVM_EL2_DTB — KVM Unavailable (HYP Mode Not Available)
  2. Root cause: KVM driver initialization failed because the CPU is not running in EL2 (hypervisor mode). The kernel log shows kvm [1]: HYP mode not available at boot time, which prevents the creation of /dev/kvm. This is a platform/firmware configuration issue on qcs6490-rb3gen2, not a kernel regression introduced by the PR (PR only modifies ath10k WiFi driver).
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The qcs6490-rb3gen2 board firmware/bootloader does not boot the kernel in EL2 mode. To enable KVM: (1) verify the bootloader/firmware supports booting in EL2 mode for this SoC, (2) update the boot chain configuration to enter the kernel at EL2 instead of EL1, or (3) if the platform does not support EL2 virtualization, mark these KVM tests as expected-to-fail for this board in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job208159_6_detailed.md
  Case 7: KVM Infrastructure Test Failure — Platform Does Not Support Nested Virtualization
  1. Failed case: KVM Infrastructure Test Failure — Platform Does Not Support Nested Virtualization
  2. Root cause: qcs6490-rb3gen2 runs Gunyah hypervisor at EL2; Linux kernel executes at EL1 without HYP mode access, preventing KVM initialization and /dev/kvm creation. Kernel message: "kvm [1]: HYP mode not available" (line 2847).
  3. Possible fix: Disable KVM_Infra, KVM_Driver, and KVM_EL2_DTB tests for qcs6490-rb3gen2 in the LAVA test suite configuration, as this platform does not support nested virtualization (Linux KVM under Gunyah hypervisor). Alternatively, if nested virtualization support is required, configure Gunyah to expose EL2 to the guest kernel via nested virtualization extensions (requires Gunyah firmware and device tree changes).
  4. Detail analysis attachment: failed_case_job208159_7_detailed.md
  Case 8: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM is not available on qcs6490-rb3gen2 (Kodiak) because the platform does not support HYP (Hypervisor) mode — kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation.
  3. Possible fix: Exclude KVM tests from the CI test suite for qcs6490-rb3gen2 (Kodiak) platform, as this SoC does not support virtualization extensions (EL2/HYP mode). Alternatively, configure the LAVA job definition to skip KVM tests when running on platforms without virtualization support.
  4. Detail analysis attachment: failed_case_job208159_8_detailed.md

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

Reviewers

@shashim-quic Shiraz Hashim (shashim-quic) shashim-quic approved these changes
@idlethread Amit Kucheria (idlethread) Awaiting requested review from idlethread idlethread was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@yijiyang yijiyang Awaiting requested review from yijiyang yijiyang was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@jingyiwang42 jingyiwang42 Awaiting requested review from jingyiwang42 jingyiwang42 was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@linghuiwu-star @qcomlnxci @qlijarvis @shashim-quic