FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface

[DaizhuangBai]

Currently, the station always follows the listen interval regardless of the DTIM value. The DTIM function does not work as expected. The default value of the listen interval is 5 so that the STA wakes up every 500ms when power save is on. This can cause a data transmission delay.

Set the DTIM policy to DTIM stick mode so that the station follows the AP DTIM interval rather than the listen interval, which is set in the peer assoc command. DTIM stick mode is preferable per the firmware team's request.

Apply this only for STA vdevs and only when STA power save is supported, to avoid affecting unsupported targets and P2P client vdevs.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3

Link: https://lore.kernel.org/all/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com/

CRs-Fixed: 4603726

[qswat-orbit-external]

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]

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]

Merge Check Failed: No Change Task Found

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

Entities:

• kernel.qli.2.0

CR: 4603726

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

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

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

Entities:

• kernel.qli.2.0

CR: 4603726

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

[qlijarvis]

PR #974 — validate-patch

PR: #974

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — diff content is identical; commit message body preserved verbatim; FROMLIST: prefix correctly added
3. Upstream patch status: ✅ Upstreamed — Applied to ath-next as commit 4834ac1d4894a2c3513e8f28d5693170829b1e68 on 2026-07-19
4. PR present in qcom-next/topics: Yes - all 1 commit(s) are present in qcom-next or topics

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #974 - FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface
Upstream commit: https://lore.kernel.org/all/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check	Status	Note
Subject matches upstream	✅	FROMLIST: prefix added correctly; base subject identical
Body preserves rationale	✅	All paragraphs preserved verbatim
Fixes tag present/correct	✅	No Fixes tag in upstream; none expected
Authorship preserved	✅	From: matches lore author (FROMLIST allows submitter to differ, but here they match)
Backport note (if applicable)	N/A	FROMLIST commit, not a backport
Link tag present	✅	Correct lore.kernel.org link added
Original author Signed-off-by	✅	Daizhuang Bai's Signed-off-by present

Diff

File	Status	Notes
drivers/net/wireless/ath/ath12k/mac.c	✅	Code hunks identical; context line numbers differ (3982 vs 3985) due to tree state
drivers/net/wireless/ath/ath12k/wmi.h	✅	Code hunks identical; context line numbers differ (2322 vs 2330) due to tree state

Upstream Patch Status

Community verdict: ✅ ACKed — Applied to ath-next tree as commit 4834ac1d4894a2c3513e8f28d5693170829b1e68 by Jeff Johnson on Sun, 19 Jul 2026

Review trail:

• Reviewed-by: Baochen Qiang (Fri, 17 Jul 2026 09:59:41 +0800)
• Reviewed-by: Rameshkumar Sundaram (Fri, 17 Jul 2026 10:29:46 +0530)
• Applied by Jeff Johnson with message "Applied, thanks!" (Sun, 19 Jul 2026 08:02:54 -0700)

qcom-next/topics Presence

Status: ✅ Present in qcom-next
Commit found in qcom-next at df55c4b16b14e1425859edef59c6efeec6445178 (exact patch-id match per integration_presence_report.md)

Verdict

✅ Merge as-is — This is a faithful representation of the upstream lore patch with the correct FROMLIST: prefix. The patch has been accepted upstream (applied to ath-next) and is already present in qcom-next. All commit message elements are correct, authorship is preserved, and the diff content is identical to the lore source (context line number differences are expected and legitimate).

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — diff content is identical; commit message body preserved verbatim; FROMLIST: prefix correctly added
3. Upstream patch status: ✅ Upstreamed — Applied to ath-next as commit 4834ac1d4894a2c3513e8f28d5693170829b1e68 on 2026-07-19
4. PR present in qcom-next/topics: Yes — Present in qcom-next at df55c4b16b14e1425859edef59c6efeec6445178

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/1	[PATCH] FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for	present - exact patch-id match at df55c4b	skipped - not checked because qcom-next already contains the change	present

Final Status

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

[qlijarvis]

PR #974 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 warning: commit body line exceeds 75 chars
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	✅	Valid FROMLIST: prefix present

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #974 - FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32133522750
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	1 warning: commit body line exceeds 75 chars
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	✅	Valid FROMLIST: prefix present

---

❌ checkpatch

Root cause: Commit body line 14 exceeds the 75-character limit for commit message body text.

Failure details:

WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#14: 
assoc command. DTIM stick mode is preferable per the firmware team's request.

94507483f08d total: 0 errors, 1 warnings, 0 checks, 30 lines checked

The offending line in the commit message body is:

assoc command. DTIM stick mode is preferable per the firmware team's request.

This line is 77 characters long (excluding the newline), exceeding the recommended 75-character limit.

Fix: Wrap the commit body text to stay within 75 characters per line:

git rebase -i c57b63497cd72a45c8992e05373f7b32901cf029
# Mark commit 94507483f08d as 'edit'
git commit --amend
# In the editor, rewrap line 14 to:
#   assoc command. DTIM stick mode is preferable per the firmware
#   team's request.
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --summary-file --ignore FILE_PATH_CHANGES \
  --git c57b63497cd72a45c8992e05373f7b32901cf029..94507483f08d71e7e1665917fe70a77886a1f048

---

Verdict

One minor blocker to fix before merge: The commit message body has one line that exceeds 75 characters. This is a trivial formatting issue that can be resolved by rewrapping the text. The code changes are clean, and all other checkers passed successfully.

[qcomlnxci]

Test jobs on 9450748

• multimedia Job 214245 on hamoa-iot-evk
• multimedia Job 214248 on lemans-evk
• multimedia Job 214249 on monaco-evk
• multimedia Job 214246 on purwa-iot-evk
• multimedia Job 214247 on qcs615-ride
• multimedia Job 214253 on qcs6490-rb3gen2
• multimedia Job 214251 on qcs8300-ride
• multimedia Job 214252 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 214250 on shikra-iqs-evk

[qcomlnxci]

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	⚠️ skip	✅ Pass	⚠️ skip	◻️	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	◻️	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
GIC	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail
IPA	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
Interrupts	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
PCIe	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
Probe_Failure_Check	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail
RMNET	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip
USBHost	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	⚠️ skip
hotplug	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
irq	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
kaslr	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
pinctrl	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️
rngtest	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
shmbridge	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
smmu	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	✅ Pass	✅ Pass	◻️	✅ Pass
watchdog	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass

[qcomlnxci]

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	⚠️ skip	✅ Pass	⚠️ 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_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	◻️	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ 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	❌ Fail	◻️	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	❌ 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	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
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	⚠️ skip	✅ 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	❌ Fail	✅ Pass	✅ Pass	◻️	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass

[qcomlnxci]

Test jobs on 9450748

• multimedia Job 214245 on hamoa-iot-evk
• multimedia Job 214248 on lemans-evk
• multimedia Job 218080 on monaco-evk
• multimedia Job 214246 on purwa-iot-evk
• multimedia Job 214247 on qcs615-ride
• multimedia Job 214253 on qcs6490-rb3gen2
• multimedia Job 214251 on qcs8300-ride
• multimedia Job 214252 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 214250 on shikra-iqs-evk

[qcomlnxci]

Test jobs on 9450748

• multimedia Job 218272 on hamoa-iot-evk
• multimedia Job 218270 on lemans-evk
• multimedia Job 218269 on monaco-evk
• multimedia Job 218274 on purwa-iot-evk
• multimedia Job 218275 on qcs615-ride
• multimedia Job 218267 on qcs6490-rb3gen2
• multimedia Job 218271 on qcs8300-ride
• multimedia Job 218273 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 218268 on shikra-iqs-evk

[qcomlnxci]

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	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #974

Job 214245 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing driver probe failures unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (WiFi ath12k DTIM policy change): (1) qcom_qseecom_uefisecapp fails with -EBUSY due to secure world resource conflict on hamoa-evk, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED "reg" property in device tree, (3) regulatory.db firmware missing from rootfs (benign - cfg80211 falls back to built-in certificates).
3. Possible fix: These are known platform issues on hamoa-evk, not regressions from this PR. (1) qcom_qseecom_uefisecapp -EBUSY is a known secure firmware initialization race on this SoC - does not affect functionality; (2) qcom-spmi-lpg DT error requires fixing the PMIC PWM LED device tree node's "reg" property to match driver expectations; (3) regulatory.db firmware file should be added to the rootfs image or suppressed as a known benign failure. None of these failures are caused by the WiFi DTIM policy patch in PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974.
4. Detail analysis attachment: failed_case_job214245_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six critical devices (five USB controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800, and video codec at aa00000) are missing IOMMU group attachments on hamoa-evk, indicating incomplete device tree iommus property configuration for these devices.
3. Possible fix: Add missing iommus properties to the device tree nodes for the affected USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) in the hamoa-evk device tree, referencing the appropriate SMMU phandle and stream IDs.
4. Detail analysis attachment: failed_case_job214245_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because EL2 (Hypervisor mode) is not available on the hamoa-evk platform. The kernel log shows kvm [1]: HYP mode not available at boot time (timestamp 6.385343s). CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware does not provide EL2 access, preventing the KVM driver from creating the /dev/kvm device node.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression. The hamoa-evk board does not support KVM/virtualization because EL2 is not available (likely disabled in firmware or not supported by the SoC configuration). No kernel fix is possible. To enable KVM on this platform, the firmware must be configured to allow EL2 access, or the test suite should skip KVM tests on platforms where EL2 is not available. Recommended action: Update the LAVA test suite to check for /dev/kvm availability before running KVM tests, or add hamoa-evk to a platform exclusion list for KVM tests.
4. Detail analysis attachment: failed_case_job214245_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on hamoa-evk because the Gunyah hypervisor is already running at EL2 (HYP mode), preventing KVM from accessing the required privilege level; kernel correctly reports "kvm [1]: HYP mode not available" and does not create /dev/kvm.
3. Possible fix: This is a test environment limitation, not a kernel bug or PR regression. To enable KVM tests on hamoa-evk: (1) boot without the Gunyah hypervisor, or (2) exclude KVM tests from the hamoa-evk test suite, or (3) use a different platform that boots Linux directly at EL2 without a hypervisor. The PR (WiFi DTIM changes) is not related to this failure.
4. Detail analysis attachment: failed_case_job214245_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — HYP Mode Unavailable (Platform Limitation)

1. Failed case: KVM Infrastructure Test Failure — HYP Mode Unavailable (Platform Limitation)
2. Root cause: KVM driver initialization fails on Hamoa EVK because the platform runs under Gunyah hypervisor, which has exclusive control of EL2 (Exception Level 2). Line 3900: kvm [1]: HYP mode not available. ARM architecture allows only one hypervisor at EL2; Gunyah and KVM are mutually exclusive. This is an expected platform limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Update LAVA job definition to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on Gunyah-based platforms (Hamoa EVK). Add platform detection logic to test suite: if dmesg | grep -q "Hypervisor cold boot.*gunyah"; then skip KVM tests. Document in test suite README that KVM tests are not applicable on platforms running Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job214245_5_detailed.md

  Case 6: KVM_Infra (and KVM_Driver, KVM_EL2_DTB — all three KVM tests failed with identical root cause)

1. Failed case: KVM_Infra (and KVM_Driver, KVM_EL2_DTB — all three KVM tests failed with identical root cause)
2. Root cause: KVM is unavailable on hamoa-evk because the platform does not support HYP (EL2 hypervisor) mode. Kernel boot log shows kvm [1]: HYP mode not available at line 6.385343s, causing KVM driver initialization to abort and /dev/kvm device node to never be created. CONFIG_KVM is enabled in the kernel config, but the hardware/firmware does not provide EL2 support required for KVM operation.
3. Possible fix: This is not a regression introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k driver DTIM policy). The KVM test failures are a pre-existing platform limitation of hamoa-evk. Recommended action: Mark KVM tests as "skip" or "not applicable" for hamoa-evk in the LAVA test plan, or enable EL2 support in the platform firmware/bootloader if the hardware supports it. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job214245_6_detailed.md

Job 214246 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Suppress Probe_Failure_Check test for purwa-evk until platform enablement is complete, or add board-specific allowlist for known-benign probe failures (QSEECOM requires secure firmware, PCIe slots may be unpopulated, LPG PWM may have DT binding mismatch, regulatory.db is optional).
4. Detail analysis attachment: failed_case_job214246_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Six critical DMA masters (five USB controllers: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb; and one video codec: aa00000.video-codec) are missing iommus properties in the purwa-evk device tree, preventing IOMMU group attachment and violating platform security requirements for DMA isolation.
3. Possible fix: Add iommus = <&apps_smmu 0x... 0x0>; properties to the six missing device nodes in arch/arm64/boot/dts/qcom/x1e80100.dtsi (or purwa-specific overlay), using appropriate Stream IDs from the hardware integration manual, then verify all critical masters attach to IOMMU groups on next boot.
4. Detail analysis attachment: failed_case_job214246_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because HYP (EL2) mode is not available on the Purwa IoT EVK platform; the kernel message "kvm [1]: HYP mode not available" indicates the hypervisor privilege level is not accessible to Linux, preventing KVM from creating /dev/kvm.
3. Possible fix: This is a platform/firmware limitation, not a kernel bug or PR regression; if KVM support is required on Purwa IoT EVK, verify that the bootloader/firmware is configured to allow EL2 access to Linux (check for secure boot policies or hypervisor reservation of EL2); if EL2 is intentionally reserved by a hypervisor or secure firmware, KVM cannot be used and the test should be skipped for this platform.
4. Detail analysis attachment: failed_case_job214246_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM Driver Initialization Failure

1. Failed case: KVM_EL2_DTB — KVM Driver Initialization Failure
2. Root cause: KVM driver probe failed with "HYP mode not available" because the purwa-evk platform does not support EL2 hypervisor mode (either disabled in firmware/TZ or not available in hardware configuration).
3. Possible fix: This is a platform limitation, not a kernel bug. If KVM support is required on purwa-evk, enable EL2 in the secure boot chain (TZ/ABL firmware configuration). If KVM is not expected to work on this platform, mark KVM tests as "skip" for purwa-evk in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job214246_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because the platform does not support EL2/HYP mode — kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or virtualization extensions are disabled/unavailable on the purwa-evk platform.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The purwa-evk SoC does not support ARM virtualization extensions (EL2/HYP mode). Either: (1) exclude KVM tests from the purwa-evk test suite in the LAVA job definition, or (2) mark KVM tests as expected-to-skip for platforms without virtualization support, or (3) add a platform capability check to the test runner to skip KVM tests when HYP mode is unavailable.
4. Detail analysis attachment: failed_case_job214246_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add a platform capability check to the LAVA test definition to skip KVM tests (KVM_Infra, KVM_Driver, KVM_EL2_DTB) on boards that do not support ARM virtualization. Check for /sys/hypervisor/type or parse dmesg | grep "HYP mode" before running KVM tests, and mark as SKIP (not FAIL) when HYP mode is unavailable.
4. Detail analysis attachment: failed_case_job214246_6_detailed.md

Job 214247 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — Benign Firmware Load Failure

1. Failed case: Probe_Failure_Check — Benign Firmware Load Failure
2. Root cause: The cfg80211 wireless subsystem attempted to load the optional regulatory.db firmware file during boot, which is not present in the rootfs. Error -2 (ENOENT) indicates file not found. This is a benign failure because: (1) regulatory.db is optional and cfg80211 falls back to compiled-in regulatory rules, (2) WiFi functionality is confirmed working (WiFi_Firmware_Driver and WiFi_OnOff tests both passed), and (3) the failure is unrelated to the PR changes (PR modifies ath12k DTIM policy, not regulatory database handling).
3. Possible fix: Suppress this known benign failure in the Probe_Failure_Check test by adding regulatory.db to the firmware load failure whitelist, or install the wireless-regdb package in the rootfs to provide the regulatory.db file. The failure does not require kernel changes and does not indicate a regression introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974.
4. Detail analysis attachment: failed_case_job214247_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the smmu test to recognize that child video codec devices on qcs615-ride inherit IOMMU protection from their parent device and do not require separate IOMMU group attachments. Alternatively, suppress this check for qcs615-ride or adjust the device tree to explicitly attach child devices if required by hardware security policy.
4. Detail analysis attachment: failed_case_job214247_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: Exclude KVM tests from the LAVA test suite for QCS615 and other platforms without virtualization support. Add a platform capability check in the test runner to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when CONFIG_KVM=y but /proc/cpuinfo or device tree indicates no EL2 support.
4. Detail analysis attachment: failed_case_job214247_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The KVM test suite should be disabled or marked as expected-fail for qcs615-ride in the LAVA CI configuration. If KVM support is required, the platform bootloader/firmware must be reconfigured to boot the kernel at EL2 or enable VHE (Virtualization Host Extensions), which may require SoC fuse changes or secure firmware updates that are typically not available on IoT/embedded platforms.
4. Detail analysis attachment: failed_case_job214247_4_detailed.md

  Case 5: KVM_Infra — Platform Capability Limitation (HYP mode not available)

1. Failed case: KVM_Infra — Platform Capability Limitation (HYP mode not available)
2. Root cause: QCS615 platform does not support ARM EL2 (hypervisor mode), which is required for KVM functionality. Kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running in a mode that provides hypervisor extensions, preventing KVM driver initialization and /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The test expectation is incorrect for this platform. Either: (1) exclude KVM tests from the qcs615-ride test suite, or (2) verify the platform firmware/bootloader configuration supports booting into EL2 mode (unlikely for this SoC variant).
4. Detail analysis attachment: failed_case_job214247_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM/virtualization hardware not available on QCS615 platform — kernel reports "HYP mode not available" at boot, preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The QCS615 SoC does not support ARM virtualization extensions (EL2/HYP mode). Either: (1) skip KVM tests on QCS615 in the CI test matrix, or (2) run KVM tests only on platforms with virtualization support (e.g., SM8450, SM8550, SC8280XP).
4. Detail analysis attachment: failed_case_job214247_6_detailed.md

Job 214248 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test flagged deferred probe entries for four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and three benign firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv); the firmware failures are false positives per suppression rules (BT_ON_OFF and WiFi_OnOff tests passed), and the temp-alarm deferred probes are a pre-existing platform issue unrelated to the WiFi DTIM policy change in PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974.
3. Possible fix: Suppress the three firmware load failures per lava-known-benign-failures.md Rules 2 & 3 (functional tests passed); investigate the PMIC temp-alarm deferred probe separately as a platform/DT/driver dependency issue on lemans-evk — this is not introduced by the PR and does not block merge.
4. Detail analysis attachment: failed_case_job214248_1_detailed.md

  Case 2: smmu — Video codec IOMMU attachment missing

1. Failed case: smmu — Video codec IOMMU attachment missing
2. Root cause: The video codec device aa00000.video-codec is not attached to any IOMMU group on lemans-evk, causing the SMMU test to fail its critical master protection validation. The test detected that while 61 IOMMU groups exist and other critical masters (UFS, Ethernet, GPU, USB, Display) are properly protected, the video codec device lacks IOMMU group attachment. This is unrelated to the PR (WiFi DTIM policy change in ath12k driver) and indicates a pre-existing platform configuration or device tree issue specific to lemans-evk.
3. Possible fix: This is a pre-existing platform issue unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (WiFi driver change). The video codec device tree node or IOMMU binding is missing or incorrect for lemans-evk. Verify the device tree for aa00000.video-codec includes proper iommus property. If this is expected behavior for lemans-evk (video codec not enabled/supported), update the SMMU test's critical master list to exclude video codec for this platform, or mark it as optional rather than mandatory.
4. Detail analysis attachment: failed_case_job214248_2_detailed.md

  Case 3: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed because 2 out of 35 individual test cases failed (Probe_Failure_Check and smmu). The smmu test failed because the video codec device (aa00000.video-codec) is not attached to an IOMMU group on lemans-evk, which is a platform-specific hardware/DT configuration issue unrelated to the PR (PR only modifies ath12k WiFi driver DTIM policy). The Probe_Failure_Check test failed due to expected firmware load failures (regulatory.db, Bluetooth firmware files) that are benign and not related to the PR.
3. Possible fix: These are pre-existing platform issues not introduced by the PR. The smmu test failure requires investigation of the lemans-evk device tree to ensure the video codec device node includes proper iommus property. The Probe_Failure_Check failure is a false positive caused by missing firmware files in the test image. Re-run the CI job to confirm the PR does not introduce new failures; consider updating the test expectations to exclude known benign probe failures and platform-specific IOMMU configuration issues on lemans-evk.
4. Detail analysis attachment: failed_case_job214248_3_detailed.md

Job 214249 | SoC monaco-evk

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

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

  Case 1: login-action (Rootfs Mount Failure — Reboot Loop)

1. Failed case: login-action (Rootfs Mount Failure — Reboot Loop)
2. Root cause: The initramfs cannot find the root filesystem partition labeled "rootfs" (PARTLABEL=rootfs does not exist), causing the system to panic and enter an automatic reboot loop due to the panic= kernel boot argument. This is a LAVA job configuration or board storage provisioning issue, not a kernel regression.
3. Possible fix: Verify the LAVA job definition specifies the correct rootfs artifact and that the board's storage (UFS) has been properly flashed with a valid rootfs partition. If the rootfs artifact is missing or the partition table is incorrect, reflash the board with a complete system image including the rootfs partition. If this is a recurring issue on monaco-evk, update the LAVA job template to include explicit rootfs provisioning steps or use a known-good rootfs artifact URL.
4. Detail analysis attachment: failed_case_job214249_1_detailed.md

  Case 2: auto-login-action (kexec second-kernel boot failure)

1. Failed case: auto-login-action (kexec second-kernel boot failure)
2. Root cause: The first kernel booted successfully and initiated a kexec/warm reboot at ~45 seconds, but the second kernel failed to boot. The system entered a warm reset loop (warm reset count 3→2→1) and got stuck in download/EDL mode at the bootloader stage. LAVA auto-login timed out because no login prompt appeared — the second kernel never reached userspace.
3. Possible fix: This is a pre-existing kexec/warm-reboot infrastructure issue on monaco-evk, not introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi DTIM policy). The LAVA job uses copy-modules and reboot=panic_warm kernel parameters indicating a kexec-based test flow. Recommended actions: (1) Check if monaco-evk supports kexec in the current firmware/bootloader version; (2) Verify the kexec kernel image and DTB are correctly configured in the LAVA job definition; (3) Check bootloader logs for why the second kernel load failed (possible image corruption, wrong load address, or firmware incompatibility); (4) If kexec is not required for this test, remove copy-modules from kernel cmdline and use a standard boot flow instead.
4. Detail analysis attachment: failed_case_job214249_2_detailed.md

  Case 3: Root Filesystem Mount Failure — initramfs cannot find PARTLABEL=rootfs

1. Failed case: Root Filesystem Mount Failure — initramfs cannot find PARTLABEL=rootfs
2. Root cause: The initramfs boot process waits for the root filesystem device (PARTLABEL=rootfs) for ~20 seconds but the device never appears, causing the system to drop to an emergency shell and then reboot due to panic= boot argument. The root filesystem partition is either not present on the storage device, incorrectly labeled, or the storage driver/device failed to initialize properly during boot.
3. Possible fix: Verify the root filesystem partition exists and is correctly labeled as "rootfs" on the target storage device (UFS). Check kernel boot arguments (root=PARTLABEL=rootfs) match the actual partition label. If the partition exists but is not detected, investigate UFS driver initialization — check for UFS controller probe failures, missing firmware, or device tree configuration issues for the monaco-evk platform. Re-trigger the CI job to rule out transient storage initialization failure; if persistent, verify the LAVA job definition flashes the correct rootfs image to the correct partition.
4. Detail analysis attachment: failed_case_job214249_3_detailed.md

  Case 4: ** Driver Probe Failure — UFS storage controller initialization failed

1. Failed case: ** Driver Probe Failure — UFS storage controller initialization failed
2. Root cause: ** UFS host controller driver (ufshcd-qcom) failed to initialize the storage device with error -11 (EAGAIN) during ufshcd_verify_dev_init, preventing the kernel from mounting the rootfs partition (PARTLABEL=rootfs). The initramfs waited 30 seconds for the root device to appear, then triggered a panic reboot.
3. Possible fix: This is a pre-existing platform/board issue unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (WiFi DTIM policy patch). The UFS controller failed to respond to NOP OUT commands during initialization. Re-trigger the CI job to rule out transient hardware/firmware state. If the issue persists, check: (1) UFS firmware version compatibility with the kernel driver, (2) power sequencing and clock configuration in the device tree for the monaco-evk UFS node at 1d84000.ufs, (3) whether the UFS device requires a longer initialization timeout or reset sequence.
4. Detail analysis attachment: failed_case_job214249_4_detailed.md

Job 214250 | SoC shikra-iqs-evk

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

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

  Case 1: ** GIC

1. Failed case: ** GIC
2. Root cause: ** Test script parsing bug — the GIC test script (run.sh line 75) attempts to parse timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform has only 4 CPUs (0-3). The script fails with bash integer comparison errors ([: GICv3: integer expected, [: Level: integer expected, [: arch_timer: integer expected) when it tries to extract non-existent CPU columns from /proc/interrupts, causing false failures 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 (which correctly reports 0-3 for this platform) and only validate timer counts for CPUs that actually exist. The script should not hardcode an assumption about the number of CPUs.
4. Detail analysis attachment: failed_case_job214250_1_detailed.md

  Case 2: Probe_Failure_Check — Pre-existing Platform Probe Failures (Not PR-Introduced)

1. Failed case: Probe_Failure_Check — Pre-existing Platform Probe Failures (Not PR-Introduced)
2. Root cause: The test detected six probe-related messages during boot: (1) coresight-etm4x probe failures (error -22, EINVAL) on four ETM instances due to known shikra-iqs-evk platform ETM configuration limitations; (2) regulatory.db firmware missing (error -2, ENOENT) which is benign as WiFi works via ath12k; (3) cpufreq-dt probe failure (error -17, EEXIST) indicating another cpufreq driver already registered (expected behavior); (4) deferred probes for sound/audio/ath10k_snoc due to missing dependencies at early boot. None of these are introduced by the PR, which only modifies ath12k driver DTIM policy code.
3. Possible fix: No action required. These are pre-existing platform issues that do not affect functionality: (1) coresight-etm4x failures are a known shikra-iqs-evk limitation and do not impact system operation; (2) regulatory.db is optional and WiFi works correctly; (3) cpufreq-dt EEXIST is expected when a platform-specific cpufreq driver is present; (4) deferred probes resolve later in boot. To suppress this test failure, update the Probe_Failure_Check test to exclude known benign patterns for shikra-iqs-evk: coresight-etm4x error -22, regulatory.db error -2, cpufreq-dt error -17, and transient deferred probes that resolve before test execution.
4. Detail analysis attachment: failed_case_job214250_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller driver (dwc3/xhci_hcd) not loaded or probed on shikra-iqs-evk; USB PHY drivers present but no host controller functionality available, causing USB device enumeration to fail with zero devices detected.
3. Possible fix: Verify USB host controller driver (CONFIG_USB_DWC3, CONFIG_USB_XHCI_HCD) is enabled in kernel config and built as module or built-in; if module, ensure it's loaded via modprobe or initramfs; check device tree for correct dwc3/xhci node configuration for shikra platform; if driver probe is failing silently, enable USB debug (dyndbg="file drivers/usb/* +p") to capture probe failure reason.
4. Detail analysis attachment: failed_case_job214250_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 regression introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which modifies WiFi ath12k DTIM policy, unrelated to Bluetooth). Recommended action: Configure the LAVA lab to ensure at least one discoverable Bluetooth device (beacon, test phone, or dedicated BT test fixture) is powered on and within radio range of the shikra-iqs-evk board during test execution. Alternatively, mark BT_SCAN as an optional test or add a pre-check to skip the test gracefully when no BT environment is available.
4. Detail analysis attachment: failed_case_job214250_4_detailed.md

  Case 5: Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (ESR 0x96000010) in qcom_rng_read() at PC offset +0xc4 when attempting to read from the hardware RNG MMIO registers. The faulting instruction b940035c (ldr w28, [x26, #0]) attempted to read from address x26=0xffff800082c4d004, which caused a bus-level external abort. This indicates the qcom_rng hardware block is either not powered/clocked correctly on Shikra IQS EVK, or the MMIO mapping is incorrect for this SoC. This is a pre-existing platform/driver integration issue unrelated to the PR (which only modifies ath12k WiFi DTIM policy).
3. Possible fix: This is NOT a PR-introduced regression. The PR changes only touch drivers/net/wireless/ath/ath12k/ and are unrelated to qcom_rng. To fix the underlying qcom_rng crash: (1) verify the qcom_rng DT node for Shikra (shikra.dtsi or shikra-iqs-evk.dts) has correct reg address, clocks, and power-domain properties matching the SoC hardware manual; (2) add runtime PM or explicit clock/regulator enable in qcom_rng probe before accessing MMIO; (3) add proper error handling for MMIO read failures. For CI purposes: skip or disable the qcom_hwrng test on Shikra until the driver/DT is fixed, as this is a known board-specific issue.
4. Detail analysis attachment: failed_case_job214250_5_detailed.md

  Case 6: KVM_EL2_DTB (test infrastructure failure) + Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: KVM_EL2_DTB (test infrastructure failure) + Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: KVM_EL2_DTB failed because /dev/kvm device node is not present despite CONFIG_KVM being enabled (platform configuration issue). Subsequently, the board crashed with a synchronous external abort (hardware bus fault, ESR=0x96000010) when the qcom_rng driver attempted to read hardware registers at offset +0xc4 in qcom_rng_read() during the qcom_hwrng test. The fault indicates the RNG hardware block is either not powered, not clocked, or the MMIO region is not properly mapped/accessible on this Shikra IQS EVK board.
3. Possible fix: For KVM_EL2_DTB: This test expects KVM device node creation, which requires either (1) KVM driver to successfully initialize and create /dev/kvm, or (2) the test to be skipped on platforms where KVM is not functional. For the qcom_rng crash: Verify the RNG hardware block power/clock configuration in the Shikra device tree; check that the qcom_rng driver's MMIO region matches the hardware address map; add runtime PM and clock enable checks before register access; or disable the qcom_hwrng test on Shikra if the hardware block is known to be non-functional. Neither issue is related to the WiFi DTIM policy changes in PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974.
4. Detail analysis attachment: failed_case_job214250_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm is not present on the Shikra IQS EVK target despite CONFIG_KVM being enabled in the kernel config, indicating KVM driver failed to initialize or create the device node during boot.
3. Possible fix: Investigate KVM driver initialization logs during early boot to determine why /dev/kvm was not created; check for missing device tree properties (e.g., kvm-arm,mode or hypervisor node), firmware prerequisites (EL2 support), or driver probe failures; verify the platform supports KVM/virtualization in hardware and firmware.
4. Detail analysis attachment: failed_case_job214250_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: ** The qcom_rng (hardware random number generator) driver triggered a synchronous external abort at offset +0xc4 in qcom_rng_read() when userspace (dd command in hwrng test) attempted to read from /dev/hwrng. The fault indicates the driver accessed an unmapped or invalid hardware register address. After the initial crash, the kernel panic handler attempted to write crash logs via EFI pstore but encountered repeated "Unable to handle paging request in EFI runtime service" errors, preventing crashdump collection. The board then warm-rebooted instead of entering EDL/ramdump mode.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies ath12k WiFi DTIM policy). The qcom_rng driver crash indicates either: (1) incorrect device tree configuration for the RNG hardware on shikra-iqs-evk (wrong register base address or missing clock/power domain), (2) a kernel bug in the qcom_rng driver's register access logic, or (3) firmware/hardware state issue where the RNG block is not properly initialized. Recommended action: Re-trigger the CI job to confirm reproducibility. If the crash recurs, investigate the qcom_rng device tree node for shikra and verify the RNG hardware register mappings match the SoC datasheet. Check if the RNG driver requires platform-specific initialization that is missing for shikra. The PR itself (WiFi DTIM changes) can proceed independently as it does not touch RNG or related subsystems.
4. Detail analysis attachment: failed_case_job214250_8_detailed.md

  Case 9: Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: The qcom_rng hardware RNG driver triggered a synchronous external abort at offset +0xc4 in qcom_rng_read() when attempting to read from the hardware RNG MMIO registers. This indicates the RNG hardware block was either not powered/clocked, not mapped correctly, or in a bad state when accessed. The crash is a pre-existing platform/firmware issue on shikra-iqs-evk, not introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k DTIM policy).
3. Possible fix: This is a pre-existing hardware/platform issue on shikra-iqs-evk. The qcom_hwrng test should be skipped or the RNG hardware power/clock dependencies must be fixed in the device tree or firmware for this platform. PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 is not the cause and should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job214250_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 (hardware bus error 0x96000010) when attempting to read from MMIO address 0xbbe6bab1b8 during the qcom_hwrng test. The RNG hardware block did not respond to the bus transaction, indicating the hardware was either unpowered, unclocked, or inaccessible. This caused a fatal kernel panic, forcing the board into EDL/ramdump mode. The lava-test-retry timeout is a secondary consequence of the board becoming unresponsive after the crash. This is a pre-existing platform/driver issue on shikra-iqs-evk, NOT introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k driver code unrelated to RNG).
3. Possible fix: Short-term: Disable the qcom_hwrng test on shikra-iqs-evk in the LAVA job definition until the driver issue is resolved, allowing other PR validation tests to proceed. Long-term: Audit drivers/char/hw_random/qcom-rng.c to ensure pm_runtime_get_sync() and explicit clock enablement occur before any MMIO access; verify the shikra device tree RNG node has correct clocks and power-domains properties; add defensive checks to return -EIO gracefully instead of crashing if hardware is inaccessible. Test the fix by running dd if=/dev/hwrng of=/dev/null bs=1M count=20 and the full LAVA test suite on shikra-iqs-evk.
4. Detail analysis attachment: failed_case_job214250_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: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read from /dev/hwrng. The driver tried to access a memory-mapped I/O register (instruction at PC: b940035c — load word) that is either unmapped, powered down, or inaccessible on the shikra-iqs-evk platform, triggering a bus-level abort.
3. Possible fix: This is a pre-existing platform/driver issue unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which modifies ath12k WiFi driver). Disable the qcom_hwrng test for shikra-iqs-evk in the LAVA test suite until the qcom_rng driver MMIO mapping is fixed for this SoC. Investigate whether the HWRNG hardware block is present and properly configured in the shikra device tree, and whether the qcom_rng driver's MMIO base address matches the hardware specification for this platform.
4. Detail analysis attachment: failed_case_job214250_11_detailed.md

Job 214251 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)

1. Failed case: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)
2. Root cause: Two pre-existing probe/firmware failures on qcs8300-ride platform: (1) cfg80211 regulatory.db firmware file missing from rootfs (error -2 = -ENOENT), and (2) Aquantia AQR115C Ethernet PHY driver probe failure due to missing or invalid firmware-name DT property (error -22 = -EINVAL). Neither failure is related to the PR changes (ath12k WiFi DTIM policy).
3. Possible fix: Mark this test case as PASS with suppression annotation. These are known platform-specific issues unrelated to the PR under test (ath12k DTIM policy changes). The regulatory.db firmware is optional for wireless operation (cfg80211 falls back to built-in regulatory rules), and the Aquantia PHY probe failure is a board-specific DT/firmware configuration issue that does not affect the ath12k WiFi driver changes being validated.
4. Detail analysis attachment: failed_case_job214251_1_detailed.md

  Case 2: ** USBHost (Test Infrastructure Dependency Failure)

1. Failed case: ** USBHost (Test Infrastructure Dependency Failure)
2. Root cause: ** The USBHost test expects a physical USB device (storage, keyboard, mouse, etc.) to be connected to the board's USB host port for enumeration validation. Only the USB root hub (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub) is present. The kernel USB stack (xHCI host controller driver) is functioning correctly with no errors, but the test fails because no external USB device is physically connected to the qcs8300-ride board in the LAVA lab.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The WiFi DTIM policy patch (PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974) does not touch USB subsystem code. To resolve: (1) Connect a USB device (e.g., USB flash drive) to the qcs8300-ride board's USB host port in the LAVA lab, OR (2) Update the test to skip/pass when no external USB devices are available (test infrastructure fix), OR (3) Add USBHost to the known benign failures suppression list if external USB devices are not consistently available in the CI environment.
4. Detail analysis attachment: failed_case_job214251_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: PHY validation failure during phylink configuration — the Ethernet MAC driver (qcom-ethqos) attempted to attach to the PHY using 2500base-x mode, but the PHY's supported capabilities (0x000062cc) and advertised capabilities (0x000062c0) do not include 2500base-x, causing phylink_validate() to return -EINVAL and preventing interface bring-up on qcs8300-ride.
3. Possible fix: Verify the device tree configuration for the Ethernet PHY node on qcs8300-ride — ensure the phy-mode property matches the PHY hardware capabilities (likely should be "rgmii" or "sgmii" instead of "2500base-x"), or if 2500base-x is intended, confirm the PHY driver correctly advertises 2500base-x support in its supported_interfaces bitmap and link mode mask.
4. Detail analysis attachment: failed_case_job214251_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM is not supported on the qcs8300-ride (Monaco) platform despite CONFIG_KVM=y and CONFIG_VIRTUALIZATION=y being enabled in the kernel configuration. The /dev/kvm device node is never created because the platform lacks the necessary hardware virtualization support (EL2/VHE) or the KVM ARM driver fails to initialize silently due to missing platform prerequisites. The Gunyah hypervisor is present on this platform (evidenced by "Hypervisor cold boot, version: gunyah-cdfb73831" in boot log), which may conflict with or prevent KVM host mode operation.
3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k driver DTIM policy). Mark the KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as "not applicable" or "skip" for the qcs8300-ride platform in the LAVA test suite configuration, as this SoC does not support KVM host functionality.
4. Detail analysis attachment: failed_case_job214251_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver did not initialize at boot despite CONFIG_KVM being enabled in the kernel configuration. The /dev/kvm device node was never created because the KVM subsystem failed to initialize on the QCS8300 (Monaco) platform. This is a pre-existing platform limitation or configuration issue, not introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k driver DTIM policy).
3. Possible fix: Verify that the QCS8300 Ride platform hardware and firmware support KVM/virtualization (VHE/EL2). If supported, check that: (1) the bootloader is not disabling EL2/VHE, (2) CONFIG_KVM_ARM_HOST is enabled in addition to CONFIG_KVM, (3) the CPU supports ARMv8.1-VHE or later. If the platform does not support KVM, mark these test cases as expected failures or skip them for qcs8300-ride in the CI configuration.
4. Detail analysis attachment: failed_case_job214251_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS8300 Ride platform runs Gunyah hypervisor (not KVM); /dev/kvm device node cannot exist because Linux runs as a guest (PVM) under Gunyah, and EL2 (hypervisor mode) is owned by Gunyah, not available to Linux for KVM operation.
3. Possible fix: Skip KVM tests on Gunyah-based platforms by detecting hypervisor type at test runtime (check for "Hypervisor cold boot" + "gunyah" in dmesg or presence of /dev/gunyah) and marking tests as SKIP rather than FAIL when Gunyah is detected.
4. Detail analysis attachment: failed_case_job214251_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm is not created despite CONFIG_KVM being enabled in the kernel configuration. The kernel booted successfully (6.18.37-02478-g40a15f38bda6) on QCS8300 Ride platform, but KVM subsystem failed to initialize and create the /dev/kvm character device required for virtualization.
3. Possible fix: Investigate KVM initialization on QCS8300 platform by checking: (1) if KVM is built as module (CONFIG_KVM=m) and failed to load - check dmesg for kvm module load errors and verify module dependencies; (2) if KVM initialization failed silently - add debug prints to arch/arm64/kvm/arm.c kvm_arch_init() and check for early-exit conditions; (3) platform-specific requirements - verify QCS8300 meets KVM prerequisites (EL2 support, GICv3, virtualization extensions enabled in firmware/bootloader). This is a pre-existing kernel/platform issue unrelated to the WiFi driver patch in PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974.
4. Detail analysis attachment: failed_case_job214251_7_detailed.md

Job 214252 | SoC qcs9100-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort during SMMU initialization

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU initialization
2. Root cause: Hardware bus error (synchronous external abort) occurred when the SMMU driver attempted to write to the S2CR (Stream-to-Context Register) at address offset 0xc28 during SMMU device probe on qcs9100-ride; the SMMU hardware block at base address 0xffff800084000000 did not respond to the register write, indicating the SMMU is either not powered, not clocked, or the MMIO region is not correctly mapped for this SoC.
3. Possible fix: This is a pre-existing platform/hardware configuration issue unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (WiFi DTIM policy change); verify SMMU power domain, clock enablement, and MMIO address mapping in the qcs9100-ride device tree; check if SMMU driver probe order conflicts with power/clock dependencies; as an immediate workaround, disable SMMU or defer its probe until dependencies are ready; escalate to platform team to confirm qcs9100 SMMU hardware configuration and compare with working reference platforms.
4. Detail analysis attachment: failed_case_job214252_1_detailed.md

  Case 2: ** Kernel Crash — Synchronous External Abort (SMMU Register Access Fault)

1. Failed case: ** Kernel Crash — Synchronous External Abort (SMMU Register Access Fault)
2. Root cause: ** Synchronous external abort at qcom_smmu_write_s2cr+0x84/0x140 during SMMU device probe. The CPU attempted to write to SMMU S2CR register at offset 0x0c28, triggering a bus-level fault. This indicates the SMMU register space is either not properly mapped, the SMMU hardware is powered off/in reset, or the NOC path to the SMMU is not configured for qcs9100-ride platform.
3. Possible fix: Verify and fix the qcs9100-ride device tree SMMU node: (1) confirm SMMU base address and register region size match hardware spec, (2) ensure SMMU power domain and clocks are enabled before driver probe via power-domains and clocks properties, (3) verify NOC interconnect path is configured. If DT is correct, check bootloader/firmware SMMU initialization for qcs9100. This is a pre-existing platform issue, not introduced by PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi driver).
4. Detail analysis attachment: failed_case_job214252_2_detailed.md

  Case 3: minimal-boot

1. Failed case: minimal-boot
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Verify SMMU power domain and clock configuration in the qcs9100-ride device tree. Ensure the SMMU at base address 0x15000000 has correct power-domain and clock bindings, and that all dependent power domains are enabled before SMMU probe. Check if recent DT or clock driver changes affected SMMU power sequencing. The PR patch (ath12k WiFi DTIM policy) is unrelated to this SMMU hardware access failure — this is a pre-existing platform/DT configuration issue on qcs9100-ride.
4. Detail analysis attachment: failed_case_job214252_3_detailed.md

  Case 4: job

1. Failed case: job
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Verify SMMU power domain and clock dependencies in qcs9100-ride device tree; ensure SMMU GDSC and clocks are enabled before SMMU driver probe; check if platform-specific SMMU initialization sequence is required for qcs9100 SoC.
4. Detail analysis attachment: failed_case_job214252_4_detailed.md

Job 214253 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — regulatory.db firmware load false positive

1. Failed case: Probe_Failure_Check — regulatory.db firmware load false positive
2. Root cause: The Probe_Failure_Check test flagged a "Direct firmware load for regulatory.db failed with error -2" message from the cfg80211 regulatory subsystem during early boot. This is a known benign failure: the regulatory.db file is optional and cfg80211 falls back to built-in regulatory rules when the file is absent. WiFi functionality is confirmed working (WiFi_Firmware_Driver and WiFi_OnOff tests both passed), proving the regulatory subsystem initialized correctly despite this message.
3. Possible fix: Suppress this failure in the Probe_Failure_Check test logic by adding a suppression rule for "regulatory.db failed with error -2" messages when WiFi functional tests pass. Alternatively, package regulatory.db in the rootfs to eliminate the message entirely (though this is cosmetic, not functional).
4. Detail analysis attachment: failed_case_job214253_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller driver (dwc3/xhci) not loaded or not configured in kernel; no USB devices enumerated on qcs6490-rb3gen2 board despite USB platform device (a600000.usb) being registered and added to IOMMU group 9.
3. Possible fix: Verify kernel config includes CONFIG_USB_DWC3=y, CONFIG_USB_DWC3_QCOM=y, CONFIG_USB_XHCI_HCD=y, CONFIG_USB_XHCI_PLATFORM=y; if built as modules, ensure they are loaded at boot; verify USB device tree node status is "okay"; ensure physical USB device is connected to the board's USB host port for testing.
4. Detail analysis attachment: failed_case_job214253_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the system is running as a guest under Gunyah hypervisor (nested virtualization not supported). Kernel log shows "kvm [1]: HYP mode not available" at boot, and hypervisor boot message confirms "Hypervisor cold boot, version: gunyah-cdfb73831". The /dev/kvm device node is never created because KVM initialization fails when Linux detects it is already running under a hypervisor.
3. Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression (PR modifies WiFi ath12k driver only). To enable KVM testing on this platform: (1) reconfigure the board to boot Linux at EL2 without Gunyah hypervisor, or (2) exclude KVM tests from the test suite for Gunyah-based configurations, or (3) enable nested virtualization support in Gunyah (if available). For this PR validation, mark KVM tests as "not applicable" for rb3gen2-gunyah configuration.
4. Detail analysis attachment: failed_case_job214253_3_detailed.md

  Case 4: ** KVM_EL2_DTB — Driver Initialization Failure (KVM)

1. Failed case: ** KVM_EL2_DTB — Driver Initialization Failure (KVM)
2. Root cause: ** KVM driver initialization failed because the qcs6490-rb3gen2 board is not booting with EL2/HYP mode enabled; the bootloader/firmware configuration does not provide EL2 access, causing KVM to abort initialization with "HYP mode not available" and preventing /dev/kvm creation.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only modifies WiFi driver code). To enable KVM on qcs6490-rb3gen2: (1) verify the bootloader (ABL/XBL) is configured to enable EL2 mode, (2) ensure secure firmware (TZ) allows non-secure EL2 access, (3) confirm the device tree does not disable virtualization extensions, and (4) if the platform does not support EL2 in the current firmware, mark KVM tests as "not applicable" for this board in the CI test matrix.
4. Detail analysis attachment: failed_case_job214253_4_detailed.md

  Case 5: KVM_Infra — /dev/kvm device node not created (KVM driver initialization failed)

1. Failed case: KVM_Infra — /dev/kvm device node not created (KVM driver initialization failed)
2. Root cause: KVM driver failed to initialize because HYP (EL2) mode is not available on qcs6490-rb3gen2 (Kodiak). The kernel message kvm [1]: HYP mode not available at boot time (3.402546s) indicates the CPU is not running in hypervisor mode, preventing KVM from creating the /dev/kvm device node. This is a platform/firmware limitation where the bootloader/firmware does not boot Linux in EL2, or the SoC does not support virtualization extensions in the current configuration.
3. Possible fix: This is a pre-existing platform limitation unrelated to PR FROMLIST: wifi: ath12k: Set DTIM policy to stick mode for station interface #974 (which only modifies WiFi ath12k driver DTIM policy). To enable KVM on qcs6490-rb3gen2: (1) verify the SoC supports ARMv8 virtualization extensions, (2) configure the bootloader/firmware to boot Linux in EL2 mode instead of EL1, (3) ensure the device tree does not disable virtualization, and (4) verify no hypervisor is already running at EL2 that would prevent Linux KVM from using it. If the platform fundamentally does not support EL2 boot, mark KVM tests as expected-fail for this target.
4. Detail analysis attachment: failed_case_job214253_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because HYP (Hypervisor) mode is not available on the qcs6490-rb3gen2 (Kodiak) platform, preventing /dev/kvm device node creation. The kernel message "kvm [1]: HYP mode not available" at boot indicates the platform does not support virtualization extensions required for KVM.
3. Possible fix: This is a pre-existing platform limitation unrelated to the PR changes (which only modify WiFi ath12k driver). The test should either be skipped on platforms without HYP mode support, or the test framework should mark this as "SKIP" rather than "FAIL" when CONFIG_KVM is enabled but /dev/kvm is unavailable due to missing hardware virtualization support.
4. Detail analysis attachment: failed_case_job214253_6_detailed.md