[Shiraz Hashim (shashim-quic)]

When the kernel issues an SMC (Secure Monitor Call) and the firmware
requests the kernel to wait, the waiting thread enters an
uninterruptible (D) state. In case of an extended wait request by the
firmware, any device suspend request, cannot proceed because of the
thread stuck in D state. This blocks the device suspend.

Replace wait_for_completion() with wait_for_completion_state(...,
TASK_IDLE), so that the waiting thread, show up in TASK_IDLE state,
instead of TASK_UNINTERRUPTIBLE (D state). This allows the thread to
block until completion, without blocking the device suspend.

CRs-Fixed: 4738102

[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 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.

[qlijarvis]

PR #1167 — validate-patch

PR: #1167

Verdict	Issues	Detailed Report
⚠️	3	Full report

Final Summary

1. Lore link present: Yes — all 4 commits have valid lore.kernel.org links in their Link: trailers
2. Lore link matches PR commits: Yes — diff content, commit messages, authorship, and Fixes tags are faithful to lore sources; only missing UPSTREAM: prefix
3. Upstream patch status: ✅ Upstreamed — Commits 1-3 applied by Bjorn Andersson on Jan 5, 2026 (commit da9e6b1, ccd207e, 366f05e); Commit 4 applied by Bjorn Andersson on Jul 30, 2026
4. PR present in qcom-next/topics: Yes - all 4 commit(s) are present in qcom-next or topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1167 - SCM: Support latest version of waitq-aware firmware + NULL dereference fix
Upstream commits:

• Commit 1: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-1-f21e50e792b8@oss.qualcomm.com
• Commit 2: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-2-f21e50e792b8@oss.qualcomm.com
• Commit 3: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
• Commit 4: https://lore.kernel.org/r/20260724094939.613844-2-mukesh.ojha@oss.qualcomm.com
  Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	✅	All 4 commits match lore subjects exactly
Body preserves rationale	✅	All commit bodies faithfully preserve upstream rationale
Fixes tag present/correct	✅	Commit 4 has correct Fixes tag matching upstream
Authorship preserved	✅	Commits 1-3: Unnathi; Commit 4: Mukesh - all match lore
Backport note (if applicable)	⚠️	Missing UPSTREAM: prefix on all 4 commits

Diff

File	Status	Notes
drivers/firmware/qcom/qcom_scm.c	✅	All 4 commits: diff content matches lore exactly
drivers/firmware/qcom/qcom_scm.h	✅	Commits 1 & 4: changes match lore
drivers/firmware/qcom/qcom_scm-smc.c	✅	Commit 4: changes match lore

Issues

• Missing UPSTREAM: prefix: All 4 commits have been accepted upstream (applied by Bjorn Andersson on Jan 5, 2026 for commits 1-3, and Jul 30, 2026 for commit 4) but lack the UPSTREAM: prefix in their subject lines. Per Qualcomm kernel conventions, merged patches should be prefixed with UPSTREAM:.
• Additional sign-offs: PR commits include additional Reviewed-by: Mukesh Ojha (commits 1-3) and Signed-off-by: Shiraz Hashim (all commits) which are expected for internal integration and do not affect patch integrity.
• Maintainer sign-off: Commit 4 correctly includes Signed-off-by: Bjorn Andersson <andersson@kernel.org> from the upstream merge.

Verdict

Merge with minor correction: Add UPSTREAM: prefix to all 4 commit subjects before merging. The diff content, commit messages, authorship, and tags are all correct and faithful to the upstream lore patches.

Final Summary

1. Lore link present: Yes — all 4 commits have valid lore.kernel.org links in their Link: trailers
2. Lore link matches PR commits: Yes — diff content, commit messages, authorship, and Fixes tags are faithful to lore sources; only missing UPSTREAM: prefix
3. Upstream patch status: ✅ Upstreamed — Commits 1-3 applied by Bjorn Andersson on Jan 5, 2026 (commit da9e6b1, ccd207e, 366f05e); Commit 4 applied by Bjorn Andersson on Jul 30, 2026
4. PR present in qcom-next/topics: Yes — all 4 commits are present in qcom-next per integration_presence_report.md (commits 2 & 3 exact patch-id match; commits 1 & 4 all added lines present)

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

Commit	Subject	qcom-next	topics	Final
1/4	[PATCH 1/4] firmware: qcom_scm: Add API to get waitqueue IRQ info	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present
2/4	[PATCH 2/4] firmware: qcom_scm: Support multiple waitq contexts	present - exact patch-id match at ccd207e	skipped - not checked because qcom-next already contains the change	present
3/4	[PATCH 3/4] firmware: qcom_scm: Use TASK_IDLE state in	present - exact patch-id match at 366f05e	skipped - not checked because qcom-next already contains the change	present
4/4	[PATCH 4/4] firmware: qcom: scm: Fix NULL dereference in IRQ handler	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: 4/4
partial_commits: 0/4
missing_commits: 0/4
topics_checked_for_commits: 0/4
final_summary: PR present in qcom-next/topics: Yes - all 4 commit(s) are present in qcom-next or topics

[qlijarvis]

PR #1167 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	All commits pass style checks
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	No static analysis warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	4 commits missing required prefix
tag-check	❌	All 4 commits missing subject prefix (mandatory for qcom-6.18.y)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1167 - firmware: qcom_scm: Add API to get waitqueue IRQ info (+ 3 more commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/35739582949

Checker	Result	Summary
checkpatch	✅	All commits pass style checks
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	No static analysis warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	4 commits missing required prefix
tag-check	❌	All 4 commits missing subject prefix (mandatory for qcom-6.18.y)

---

❌ check-patch-compliance

Root cause: All 4 commits are missing the required subject-line prefix (FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:).

Failure details:

Checking commit: firmware: qcom_scm: Add API to get waitqueue IRQ info
Commit summary does not start with a required prefix

Checking commit: firmware: qcom_scm: Support multiple waitq contexts
Commit summary does not start with a required prefix

Checking commit: firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
Commit summary does not start with a required prefix

Checking commit: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published
Commit summary does not start with a required prefix

Analysis:
All 4 commits have Link: tags pointing to lore.kernel.org, indicating they were posted upstream. Since they have upstream links, they should use the FROMLIST: prefix (if not yet merged) or UPSTREAM: prefix (if already merged into Linus's tree).

Fix:
Rebase and add the appropriate prefix to each commit subject:

git rebase -i <base_sha>   # mark each commit as 'edit'

# For each commit:
git commit --amend -m "FROMLIST: firmware: qcom_scm: Add API to get waitqueue IRQ info"
# (keep the rest of the commit message body unchanged)

git rebase --continue

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base 8a24e588aae78855ad3badf95e30e3b0609097c9 \
  --head 5e3301495a1bb8d8612188239642f891a9642648

---

❌ tag-check (mandatory for qcom-6.18.y)

Root cause: The PR targets qcom-6.18.y, which requires all commits to have a subject-line prefix. None of the 4 commits have a prefix.

Failure details:

Commit 7158383f94ca ("firmware: qcom_scm: Add API to get waitqueue IRQ info")
  → Missing prefix

Commit baf80fc50061 ("firmware: qcom_scm: Support multiple waitq contexts")
  → Missing prefix

Commit 15a62571cfb3 ("firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()")
  → Missing prefix

Commit 5e3301495a1b ("firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published")
  → Missing prefix

Required prefixes:
All branches except qcom-next and qcom-next-staging require one of:

• FROMLIST: — Patch posted to mailing list (lore.kernel.org)
• FROMGIT: — Patch taken from a maintainer git tree
• UPSTREAM: — Patch merged into Linus's mainline tree
• BACKPORT: — Upstream patch backported with modifications
• QCLINUX: — Vendor-only change with no upstream equivalent
• PENDING: — Work-in-progress, not yet posted upstream
• WORKAROUND: — Temporary fix not suitable for upstream

Recommended prefix: FROMLIST: (since all commits have lore.kernel.org links and appear to be posted but not yet merged).

Fix:
Same as above — rebase and prepend FROMLIST: to each commit subject.

---

Verdict

4 blockers must be fixed before merge:

1. Add FROMLIST: prefix to commit 1: firmware: qcom_scm: Add API to get waitqueue IRQ info
2. Add FROMLIST: prefix to commit 2: firmware: qcom_scm: Support multiple waitq contexts
3. Add FROMLIST: prefix to commit 3: firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
4. Add FROMLIST: prefix to commit 4: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published

All other checkers passed. Once the subject prefixes are added, the PR will be ready to merge.

[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.

[qlijarvis]

PR #1167 — validate-patch

PR: #1167

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
2. Lore link matches PR commits: Yes — diff content is identical; context differences (line numbers, function signature with extra struct device *dev parameter) are due to additional changes in qcom-next and are expected
3. Upstream patch status: ✅ ACKed — Applied by Bjorn Andersson (qcom maintainer) on Jan 5, 2026 as commit 366f05e348b2 in qcom-next
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: #1167 - firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
Upstream commit: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
Verdict: ✅ PASS

Commit Message

Check	Status	Note
Subject matches upstream	✅	Identical to lore patch
Body preserves rationale	✅	Complete problem description and fix rationale preserved
Fixes tag present/correct	✅	No Fixes tag in upstream or PR (not a bug fix, enhancement)
Authorship preserved	✅	From: matches lore author (Unnathi Chalicheemala)
Backport note (if applicable)	N/A	Not a backport - patch posted Dec 17, 2025 and applied Jan 5, 2026
Co-developed-by used correctly	✅	Not used; dual Signed-off-by: correctly represents co-authorship
Link tag present	✅	Correct lore link present
Additional trailers	✅	Extra Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> and maintainer Signed-off-by: Shiraz Hashim added during merge - appropriate

Diff

File	Status	Notes
drivers/firmware/qcom/qcom_scm.c	✅	Identical code change; context differs (line 2701 vs 2305, function signature has extra struct device *dev param in PR tree) due to additional changes in qcom-next - this is expected and correct

Upstream Patch Status

Commit	Community Verdict
firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()	✅ ACKed — Applied by Bjorn Andersson on Jan 5, 2026 as commit 366f05e348b2 in qcom-next

Evidence:

• Lore thread shows "Applied, thanks!" from Bjorn Andersson (maintainer) on Jan 5, 2026
• Commit SHA: 366f05e348b2ba454869ba7148ace6f25f229540
• Formal reviews from Mukesh Ojha and Bartosz Golaszewski present in upstream

qcom-next Presence

Commit	Status
firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()	✅ Present in qcom-next as 366f05e348b2ba454869ba7148ace6f25f229540 (exact patch-id match)

Issues Found

None. This is a clean, faithful representation of the upstream patch.

Recommendation

Merge as-is. This patch faithfully represents the upstream commit that was accepted into qcom-next on January 5, 2026. The context differences (line numbers, function signature) are due to additional changes already present in the target tree and do not affect the correctness of the fix. All commit message elements are properly preserved, authorship is correct, and the lore link is present.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
2. Lore link matches PR commits: Yes — diff content is identical; context differences (line numbers, function signature with extra struct device *dev parameter) are due to additional changes in qcom-next and are expected
3. Upstream patch status: ✅ ACKed — Applied by Bjorn Andersson (qcom maintainer) on Jan 5, 2026 as commit 366f05e348b2 in qcom-next
4. PR present in qcom-next/topics: Yes — exact patch-id match at 366f05e348b2ba454869ba7148ace6f25f229540 in qcom-next

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

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] firmware: qcom_scm: Use TASK_IDLE state in	present - exact patch-id match at 366f05e	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 #1167 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped - no DT binding changes
dtb-check	⏭️	Skipped - no DTS changes
sparse-check	✅	No sparse warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Missing subject prefix
tag-check	❌	Subject prefix required (non-qcom-next branch)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1167 - firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/38286255710

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped - no DT binding changes
dtb-check	⏭️	Skipped - no DTS changes
sparse-check	✅	No sparse warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Missing subject prefix
tag-check	❌	Subject prefix required (non-qcom-next branch)

❌ check-patch-compliance

Root cause: Commit subject line does not start with a required prefix (FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:).

Failure details:

Checking commit: firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
Commit summary does not start with a required prefix

Analysis:

The commit subject is:

firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

This patch:

• Has a valid Link: tag pointing to lore.kernel.org: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
• Was posted to the mailing list on Dec 17, 2025
• Was accepted and merged by Bjorn Andersson (qcom maintainer) on Jan 5, 2026
• Is already present in qcom-next as commit 366f05e348b2ba454869ba7148ace6f25f229540

Fix:

Since this patch was accepted upstream and is already in qcom-next, the correct prefix is UPSTREAM:. Update the commit subject:

git rebase -i 143c1172c89b56ba26b8c9fd7bdc63cb04bb79d0
# mark commit 63bf03c17168 as 'edit'
git commit --amend -m "UPSTREAM: firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()"
# Keep the rest of the commit message body unchanged
git rebase --continue

Reproduce locally:

cd kernel
./scripts/check-patch-compliance.sh --base 143c1172c89b56ba26b8c9fd7bdc63cb04bb79d0 --head 63bf03c17168dd7cc725dfa46421cbd115b28739

❌ tag-check

Root cause: Subject line missing required prefix tag for non-qcom-next branch.

Failure details:

The commit subject does not start with any of the required prefixes:

• FROMLIST: (posted to mailing list)
• FROMGIT: (from maintainer tree)
• UPSTREAM: (merged into mainline/qcom-next)
• BACKPORT: (backported with modifications)
• QCLINUX: (vendor-only)
• PENDING: (work-in-progress)
• WORKAROUND: (temporary fix)

Note: This check applies to all branches except qcom-next and qcom-next-staging. Based on the integration presence report showing the commit is already in qcom-next at 366f05e348b2, this PR is likely targeting a downstream integration branch that requires the prefix.

Fix: Same as check-patch-compliance above - add UPSTREAM: prefix to the subject line.

Verdict

Fix 1 blocker before merge: Add UPSTREAM: prefix to the commit subject line.

This is a straightforward fix - the patch itself is correct and has been accepted upstream. The only issue is the missing subject prefix required by the branch policy. Once the prefix is added, the patch will pass all checkers.

Context: This patch was accepted into qcom-next on January 5, 2026 as commit 366f05e348b2. The PR is bringing this upstream change into a downstream branch that enforces subject prefix requirements.

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-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	✅ Pass	✅ 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	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ 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	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
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	⚠️ skip	✅ Pass	✅ Pass	❌ 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	✅ 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

[qcomlnxci]

Test jobs on 63bf03c

• multimedia Job 260970 on hamoa-iot-evk
• multimedia Job 260966 on lemans-evk
• multimedia Job 260971 on monaco-evk
• multimedia Job 260968 on purwa-iot-evk
• multimedia Job 260972 on qcs615-ride
• multimedia Job 260967 on qcs6490-rb3gen2
• multimedia Job 260969 on qcs8300-ride
• multimedia Job 260973 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 260965 on shikra-iqs-evk

[Salendarsingh Gaud (sgaud-quic)]

Please add CR to PR.

[Salendarsingh Gaud (sgaud-quic)]

Mukesh Ojha (@mukeshojha-linux) please add CRs-Fixed:

[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.

[qcomlnxci]

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
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	⚠️ skip	⚠️ 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	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
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	⚠️ skip	❌ Fail	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	◻️	❌ Fail	✅ Pass	✅ 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	⚠️ skip	⚠️ 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	✅ Pass
rngtest	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on aa7235a

• multimedia Job 269820 on hamoa-iot-evk
• multimedia Job 269823 on lemans-evk
• multimedia Job 269825 on monaco-evk
• multimedia Job 269824 on purwa-iot-evk
• multimedia Job 269819 on qcs615-ride
• multimedia Job 269821 on qcs6490-rb3gen2
• multimedia Job 269822 on qcs8300-ride
• multimedia Job 269818 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269826 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1167

Job 269818 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing platform-specific probe failures unrelated to the PR: (1) nvmem-reboot-mode driver cannot find the "reboot-mode" nvmem cell in device tree (deferred probe), (2) regulatory.db firmware file missing from rootfs (benign — cfg80211 falls back to built-in regulatory rules), (3) Aquantia AQR115C PHY driver fails to read optional "firmware-name" property from device tree (error -22 / -EINVAL), causing probe failure on qcs9100-ride platform.
3. Possible fix: These are pre-existing platform/board configuration issues not introduced by PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 (which only changes qcom_scm wait state). (1) For nvmem-reboot-mode: add the missing nvmem cell "reboot-mode" to the qcs9100 device tree or mark the driver as optional if the feature is not required on this platform. (2) For regulatory.db: this is benign — cfg80211 continues with built-in rules; optionally install wireless-regdb package in rootfs if explicit regulatory database is needed. (3) For Aquantia PHY: add the optional "firmware-name" property to the PHY node in qcs9100-ride device tree, or fix the PHY driver to tolerate missing optional properties without failing probe (the driver should fall back to default firmware or probe without firmware if it's truly optional).
4. Detail analysis attachment: failed_case_job269818_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test infrastructure mismatch — the SMMU test checks for legacy video codec device aa00000.video-codec IOMMU attachment, but qcs9100-ride uses the newer Iris video driver which creates virtual devices iris_non_pixel.0 and iris_pixel.0 (both successfully attached to IOMMU groups 17 and 18). The test script has not been updated to recognize the new driver architecture.
3. Possible fix: Update the SMMU test script to recognize Iris video driver devices (iris_non_pixel.0, iris_pixel.0) as valid video codec IOMMU attachments for platforms using the Iris driver, or add platform-specific device name mappings for qcs9100-ride.
4. Detail analysis attachment: failed_case_job269818_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: The Aquantia AQR115C PHY driver probe failed during boot with error -22 (EINVAL) due to missing firmware-name property in device tree, preventing the end0 interface from attaching to the PHY when brought up administratively during the test.
3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs9100-ride device tree (stmmac-0:08 MDIO address). The PHY driver expects this property to locate the firmware file. This is a pre-existing device tree configuration issue, not introduced by PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 (which only modifies qcom_scm wait state behavior).
4. Detail analysis attachment: failed_case_job269818_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 qcs9100-ride platform is booted with Gunyah hypervisor running at EL2, which prevents Linux KVM from accessing hypervisor mode; KVM driver initialization fails with "HYP mode not available" because Linux is running as a guest at EL1 without EL2 access.
3. Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM on qcs9100-ride: (1) boot the platform in native/VHE mode without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled builds, as KVM and Gunyah are mutually exclusive configurations.
4. Detail analysis attachment: failed_case_job269818_4_detailed.md

  Case 5: KVM Platform Incompatibility — HYP mode unavailable (Gunyah hypervisor conflict)

1. Failed case: KVM Platform Incompatibility — HYP mode unavailable (Gunyah hypervisor conflict)
2. Root cause: qcs9100-ride platform boots with Gunyah hypervisor occupying EL2, preventing KVM initialization; KVM requires exclusive EL2 access and reports "HYP mode not available", causing /dev/kvm device node to not be created.
3. Possible fix: Exclude KVM tests from qcs9100-ride CI runs, or reconfigure the platform to boot without Gunyah hypervisor if KVM testing is required (mutually exclusive configurations).
4. Detail analysis attachment: failed_case_job269818_5_detailed.md

  Case 6: KVM Infrastructure Test — KVM unavailable due to Gunyah hypervisor conflict

1. Failed case: KVM Infrastructure Test — KVM unavailable due to Gunyah hypervisor conflict
2. Root cause: The qcs9100-ride board booted with Gunyah hypervisor active (confirmed by boot log "Hypervisor cold boot, version: gunyah-3fe287d48"), which reserves EL2 (Hypervisor mode) for itself. KVM requires exclusive EL2 access to provide virtualization services and correctly reports "HYP mode not available" when another hypervisor owns EL2. This is a test environment configuration mismatch, not a kernel regression. The PR patch (qcom_scm wait queue change) does not affect hypervisor initialization or KVM availability.
3. Possible fix: Re-run the LAVA job with the board configured to boot in el2kvm mode (without Gunyah hypervisor) to allow KVM to access EL2. The boot log shows "EFI selection='el2kvm'" but the system actually booted with Gunyah, indicating a boot configuration or image selection mismatch. Verify the LAVA job definition is flashing the correct el2kvm boot image for qcs9100-ride, not the Gunyah-enabled image. Alternatively, skip KVM tests when Gunyah hypervisor is detected at boot.
4. Detail analysis attachment: failed_case_job269818_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform booted with Gunyah hypervisor owning EL2, making HYP mode unavailable to Linux KVM. Kernel message kvm [1]: HYP mode not available indicates KVM initialization failed because EL2 is not accessible. This is a pre-existing test environment configuration issue, not a PR-introduced regression (PR only changes SCM wait state behavior).
3. Possible fix: Re-flash the board with the EL2/KVM boot configuration (not Gunyah mode) by selecting the correct device tree overlay or bootloader configuration that enables native KVM mode. Verify the boot selection in the LAVA job definition ensures el2kvm DTB/DTBO is used instead of the Gunyah hypervisor configuration.
4. Detail analysis attachment: failed_case_job269818_7_detailed.md

Job 269819 | SoC qcs615-ride

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

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

  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: Add regulatory.db firmware file to the rootfs image at /lib/firmware/regulatory.db, OR update the Probe_Failure_Check test to suppress known-benign optional firmware failures (similar to the existing WiFi/BT firmware suppression rules in lava-known-benign-failures.md). Recommended: Add suppression rule for regulatory.db since it's optional and has working fallbacks.
4. Detail analysis attachment: failed_case_job269819_1_detailed.md

  Case 2: **smmu** (test expectation mismatch - not a genuine SMMU hardware failure)

1. Failed case: smmu (test expectation mismatch - not a genuine SMMU hardware failure)
2. Root cause: The smmu test expects video codec child devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to appear as separate entries in IOMMU groups, but on qcs615-ride the parent device aa00000.video-codec is correctly attached to IOMMU group 7 while child devices are not separately enumerated in sysfs. This is a test implementation issue, not a kernel regression. Additionally, a BUG message appears during boot (BUG: sleeping function called from invalid context at drivers/firmware/qcom/qcom_scm.c:320) triggered by qcom_scm_call() being invoked from atomic context (preemption disabled, IRQs disabled) during qcom_scm_probe() → qcom_tzmem_enable() → qcom_scm_shm_bridge_enable() → __qcom_scm_is_call_available(), but this does not cause the smmu test failure and the system continues normal operation.
3. Possible fix: For the smmu test failure**: Update the test script to recognize that video codec child devices on qcs615-ride are not expected to have separate IOMMU group entries when the parent device is correctly protected. The parent device aa00000.video-codec is successfully attached to IOMMU group 7, which provides the required DMA protection. For the BUG message: The PR patch changes qcom_scm_wait_for_wq_completion() to use TASK_IDLE but does not address the root cause that qcom_scm_call() contains might_sleep() checks and is being called from atomic context during probe. The atomic context originates from __do_once_start() which disables preemption. This is a pre-existing issue unrelated to the PR patch (the PR only changes the wait state, not the calling context). To fix: either remove the might_sleep() check from qcom_scm_call() for early boot paths, or refactor qcom_scm_shm_bridge_enable() to defer the SCM call to a non-atomic context.
4. Detail analysis attachment: failed_case_job269819_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: This is a platform configuration issue, not a PR-introduced regression. The PR patch (qcom_scm wait state change) does not affect KVM initialization. To enable KVM on this platform: (1) boot without Gunyah hypervisor by selecting a non-EL2 boot configuration, OR (2) use nested virtualization if supported, OR (3) mark KVM tests as expected-fail for qcs615-ride when Gunyah is active. For CI: add platform-specific test skip logic for KVM tests when hypervisor boot mode is detected.
4. Detail analysis attachment: failed_case_job269819_3_detailed.md

  Case 4: 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 initialization failed with "kvm [1]: HYP mode not available" because the qcs615-ride target is running Linux as a guest under the Gunyah hypervisor (EL1), not at EL2 (hypervisor mode). KVM requires EL2 access to create and manage virtual machines, which is not available when Linux itself is a guest VM.
3. Possible fix: This is not a kernel regression or bug. The KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) should be skipped or marked as "not applicable" for qcs615-ride in the LAVA test suite, as this platform runs under Gunyah hypervisor where nested virtualization (KVM inside a VM) is not supported. Update the LAVA job definition to exclude KVM tests for targets running under Gunyah.
4. Detail analysis attachment: failed_case_job269819_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 platform does not support KVM virtualization — kernel reports "HYP mode not available" during KVM initialization, indicating EL2 (hypervisor exception level) is not available on this SoC, preventing /dev/kvm device creation.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. Exclude KVM tests from the QCS615 test suite, or mark them as expected-to-skip on platforms without EL2 support. To verify EL2 availability on other platforms, check for "HYP mode not available" in dmesg during KVM initialization.
4. Detail analysis attachment: failed_case_job269819_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: This is not a PR-introduced regression. The PR modifies qcom_scm wait behavior (TASK_IDLE vs TASK_UNINTERRUPTIBLE) and does not affect KVM/virtualization support. The test failure is a pre-existing platform limitation: QCS615 hardware does not support KVM. Either skip KVM tests on QCS615 targets in the CI configuration, or mark them as expected failures for this platform.
4. Detail analysis attachment: failed_case_job269819_6_detailed.md

Job 269820 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The Probe_Failure_Check test detected two probe failures: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY, likely caused by incomplete qcom_scm initialization due to a "sleeping function called from invalid context" BUG during qcom_scm_probe() when qcom_scm_call() is invoked from atomic context within __do_once_start(); (2) regulatory.db firmware load failure (-ENOENT), which is a known benign issue unrelated to the PR.
3. Possible fix: The qcom_scm_shm_bridge_enable() initialization path must not be called from atomic context; refactor the code to move the DO_ONCE logic outside the atomic section, or defer the SCM bridge enable call to a context where sleeping is allowed (e.g., a workqueue or after __do_once_start() completes).
4. Detail analysis attachment: failed_case_job269820_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test script 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 in the hamoa-evk platform configuration. The kernel booted successfully, SMMU/IOMMU subsystem is functional (35 devices attached to IOMMU groups, no SMMU errors in kernel log), but the test has a hardcoded expectation for a video codec device that is not present on this SoC.
3. Possible fix: Update the SMMU test script to make the video codec device check conditional based on platform/SoC type, or remove the video codec from the list of "critical masters" for hamoa-evk. The PR patch (qcom_scm wait state change) is unrelated to this failure—this is a pre-existing test configuration issue specific to hamoa-evk.
4. Detail analysis attachment: failed_case_job269820_2_detailed.md

  Case 3: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** KVM driver initialization failed because the hamoa-evk platform boots the kernel at EL1 (OS mode) instead of EL2 (Hypervisor mode). The kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running in EL2, which is a mandatory requirement for ARM64 KVM support. This is a platform/firmware limitation where the bootloader does not configure EL2 entry before kernel handoff.
3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167. The KVM test should be skipped on hamoa-evk until the platform firmware is updated to support EL2 boot. To enable KVM: (1) Update the bootloader/ABL to configure the CPU to enter EL2 before kernel handoff, or (2) Add a test skip rule for hamoa-evk in the KVM test suite configuration, as this platform does not support virtualization in its current firmware configuration.
4. Detail analysis attachment: failed_case_job269820_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed because EL2/HYP mode is occupied by the Gunyah hypervisor (version gunyah-mobile-1f99e07c2) on the hamoa-evk platform; kernel message "kvm [1]: HYP mode not available" at boot indicates KVM cannot access EL2 as it is already claimed by Gunyah, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression — the hamoa-evk board is configured to boot with Gunyah hypervisor at EL2 (boot selection 'el2gh'), which prevents native KVM from running; to enable KVM tests, either (1) reconfigure the board to boot without Gunyah hypervisor (native EL2 mode), or (2) exclude KVM tests from the hamoa-evk test suite as they are incompatible with Gunyah-enabled boot configurations.
4. Detail analysis attachment: failed_case_job269820_4_detailed.md

  Case 5: KVM_Infra (Test Infrastructure Issue — Platform Limitation)

1. Failed case: KVM_Infra (Test Infrastructure Issue — Platform Limitation)
2. Root cause: The hamoa-evk platform does not support KVM virtualization because HYP mode (EL2) is not available on this hardware. The kernel correctly detected this during boot (kvm [1]: HYP mode not available) and did not create /dev/kvm, causing all KVM tests to fail. This is a platform hardware/firmware limitation, not a kernel regression introduced by the PR.
3. Possible fix: Exclude KVM tests from the hamoa-evk test suite, as this platform does not support virtualization extensions. The PR changes to qcom_scm_wait_for_wq_completion() are unrelated to KVM initialization and do not cause this failure. If KVM support is required, verify that: (1) the SoC supports EL2/HYP mode, (2) the bootloader/firmware enables EL2, and (3) the device tree does not disable virtualization.
4. Detail analysis attachment: failed_case_job269820_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test harness marked the test definition as failed with "Marking unfinished test run as failed" despite all scheduled tests completing execution. This is a LAVA infrastructure/harness issue, not a kernel regression. The PR changes (qcom_scm wait state modification) do not affect test execution or completion.
3. Possible fix: Re-trigger the CI job. If the issue persists, investigate the LAVA test runner's completion detection logic - the test suite completed all tests but LAVA incorrectly flagged it as unfinished.
4. Detail analysis attachment: failed_case_job269820_6_detailed.md

Job 269821 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Benign Firmware Load Failures (Pre-existing)

1. Failed case: Probe_Failure_Check — Benign Firmware Load Failures (Pre-existing)
2. Root cause: The test detected two firmware load failures during boot: (1) cfg80211 regulatory.db missing from rootfs (error -2/ENOENT), and (2) Renesas USB controller firmware missing (error -2/ENOENT). Both are pre-existing, platform-specific firmware packaging issues unrelated to the PR under test. WiFi functionality is confirmed working (WiFi_OnOff PASSED), and the Renesas USB controller is optional hardware not used on qcs6490-rb3gen2.
3. Possible fix: Suppress these two known-benign firmware load failures in the Probe_Failure_Check test for qcs6490-rb3gen2, or package the missing firmware files in the test rootfs. The PR (qcom_scm TASK_IDLE change) is not the cause and should not be blocked by this test failure.
4. Detail analysis attachment: failed_case_job269821_1_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test infrastructure marked the test run as "unfinished" despite all tests completing successfully. The Probe_Failure_Check test detected two pre-existing probe failures (regulatory.db firmware missing, xhci-pci-renesas probe error -ENOENT) that are unrelated to the PR's SCM wait queue changes.
3. Possible fix: Re-trigger the LAVA job. The Probe_Failure_Check failures are pre-existing infrastructure issues (missing regulatory.db firmware file and Renesas USB controller firmware) that should be addressed separately in the test environment configuration, not in this PR.
4. Detail analysis attachment: failed_case_job269821_2_detailed.md

Job 269822 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing platform issues unrelated to PR1167: (1) xhci-hcd probe failure with -ETIMEDOUT (-110) during USB controller initialization on qcs8300-ride, and (2) regulatory.db firmware file missing from rootfs (benign — cfg80211 falls back to compiled-in regulatory database).
3. Possible fix: For xhci-hcd: investigate USB PHY/clock/power sequencing on qcs8300-ride platform — error -110 (ETIMEDOUT) indicates hardware not responding during xHCI controller setup; check USB PHY driver probe status, USB controller power domain state, and USB reference clocks in ClockDumps. For regulatory.db: add wireless-regdb package to rootfs or suppress this known-benign firmware warning in the test filter (cfg80211 operates correctly with compiled-in certificates).
4. Detail analysis attachment: failed_case_job269822_1_detailed.md

  Case 2: ** USBHost — xHCI Host Controller Probe Failure (Driver Initialization Failure)

1. Failed case: ** USBHost — xHCI Host Controller Probe Failure (Driver Initialization Failure)
2. Root cause: ** The xHCI host controller driver (xhci-hcd.0.auto) probe failed with error -110 (ETIMEDOUT) after an 18-second timeout during controller setup on qcs8300-ride. The controller failed to respond to initialization commands, preventing USB root hub enumeration. This is a pre-existing platform/hardware issue unrelated to the PR patch (qcom_scm wait state change).
3. Possible fix: Investigate xHCI controller hardware initialization on qcs8300-ride: verify USB PHY power/clock sequencing, check DWC3 controller configuration in device tree (a400000.usb, a600000.usb), confirm firmware dependencies, and validate reset/power domain states. If this is a known qcs8300 platform limitation, update the LAVA test expectations to skip USBHost validation for this SoC.
4. Detail analysis attachment: failed_case_job269822_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm device node not present

1. Failed case: KVM_Driver — /dev/kvm device node not present
2. Root cause: KVM cannot initialize on qcs8300-ride because the platform is running under Gunyah hypervisor at EL2. The boot log shows "Hypervisor cold boot, version: gunyah-3fe287d48" and "EFI selection='el2gh'", confirming Gunyah owns EL2. KVM requires exclusive EL2 access to create the /dev/kvm device node, but when a hypervisor like Gunyah is already running at EL2, KVM initialization is silently skipped (no error message), leaving CONFIG_KVM enabled but /dev/kvm absent.
3. Possible fix: This is not a PR-introduced regression — the PR modifies qcom_scm wait behavior and does not affect KVM or hypervisor initialization. The KVM_Driver test is not applicable to qcs8300-ride when running under Gunyah hypervisor. Either: (1) skip KVM tests on Gunyah-enabled platforms in the CI test suite, or (2) use a non-Gunyah boot configuration (standard EL1 Linux) if KVM testing is required for this SoC.
4. Detail analysis attachment: failed_case_job269822_3_detailed.md

  Case 4: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** Test infrastructure configuration mismatch — KVM tests require bare-metal EL2 access but QCS8300 Ride is configured to boot under the Gunyah hypervisor (version gunyah-3fe287d48), which occupies EL2 and prevents KVM from initializing. CONFIG_KVM is enabled but /dev/kvm cannot be created because nested virtualization is not supported/enabled on this platform configuration.
3. Possible fix: Exclude KVM test suite (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test definition for QCS8300 Ride when running under Gunyah hypervisor, or reconfigure the platform to boot without Gunyah if KVM testing is required. This is not a kernel bug or PR-introduced regression.
4. Detail analysis attachment: failed_case_job269822_4_detailed.md

  Case 5: KVM_Infra — /dev/kvm device unavailable (platform configuration limitation)

1. Failed case: KVM_Infra — /dev/kvm device unavailable (platform configuration limitation)
2. Root cause: Gunyah hypervisor is running at EL2 on qcs8300-ride, preventing KVM from initializing; KVM requires exclusive EL2 access and cannot coexist with another hypervisor.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms; exclude KVM tests from qcs8300-ride CI runs, or use a non-Gunyah boot configuration if KVM testing is required.
4. Detail analysis attachment: failed_case_job269822_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver failed to initialize on qcs8300-ride platform — /dev/kvm device node not created despite CONFIG_KVM=y; no "Hyp mode initialized" message in boot log indicates EL2 (hypervisor mode) is not available or not enabled by firmware on this SoC.
3. Possible fix: This is a platform limitation, not a PR-introduced regression. The qcs8300-ride platform either does not support EL2/KVM or requires firmware/bootloader configuration to enable hypervisor mode. Skip KVM tests on this platform or enable EL2 support in the bootloader/firmware if the SoC hardware supports it.
4. Detail analysis attachment: failed_case_job269822_6_detailed.md

Job 269823 | SoC lemans-evk

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

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

  Case 1: Kernel Bug — Sleeping function called from invalid context (qcom_scm)

1. Failed case: Kernel Bug — Sleeping function called from invalid context (qcom_scm)
2. Root cause: The PR patch changes wait_for_completion() to wait_for_completion_state(wq, TASK_IDLE) in qcom_scm_wait_for_wq_completion(), but this function is being called from an atomic context (preempt_count=1, irqs_disabled=1) during qcom_scm_probe() → qcom_tzmem_enable() → qcom_scm_shm_bridge_enable() path on lemans-evk, where __do_once_start() has disabled preemption; wait_for_completion_state() can sleep and is not safe to call from atomic context, causing the kernel to detect and report this violation, which then leads to a system hang preventing userspace from reaching the login prompt.
3. Possible fix: Revert the patch or modify the implementation to use a non-sleeping wait primitive when called from atomic context; specifically, check if in_atomic() or irqs_disabled() and use wait_for_completion_timeout() with a short timeout in atomic context, or restructure the probe path to avoid calling SCM functions that may wait while in atomic context.
4. Detail analysis attachment: failed_case_job269823_1_detailed.md

  Case 2: auto-login-action

1. Failed case: auto-login-action
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Revert the PR or modify the implementation to avoid calling wait_for_completion_state() from atomic context. The original wait_for_completion() worked because it could be called from atomic context in certain scenarios, but wait_for_completion_state() with TASK_IDLE requires a schedulable context. The proper fix requires either: (1) ensuring the SCM call path is never invoked from atomic context during probe, or (2) using a different synchronization primitive that is safe in atomic context for this specific code path.
4. Detail analysis attachment: failed_case_job269823_2_detailed.md

  Case 3: Boot Hang — System hangs during userspace initialization, no login prompt

1. Failed case: Boot Hang — System hangs during userspace initialization, no login prompt
2. Root cause: Kernel boots successfully and starts init/systemd-udevd at ~5-6 seconds, but system completely stops producing output and never reaches login prompt. Last kernel message is PCIe initialization at 6.2s. The PR changes SCM waitqueue behavior from TASK_UNINTERRUPTIBLE to TASK_IDLE, which may cause a thread waiting on SCM completion to be incorrectly handled during early boot on lemans-evk, leading to a deadlock or stall in a critical boot path (likely device initialization requiring SCM calls).
3. Possible fix: Revert the PR patch temporarily to confirm the SCM waitqueue change is the root cause. If confirmed, investigate which early-boot driver on lemans-evk issues SCM calls that may be affected by the TASK_IDLE state change — likely candidates are PCIe, UFS, or other platform drivers that interact with TrustZone during probe. Add targeted logging around qcom_scm_wait_for_wq_completion() to identify the stalled caller, then determine if the TASK_IDLE change requires additional synchronization or if the completion signaling path needs adjustment for this platform.
4. Detail analysis attachment: failed_case_job269823_3_detailed.md

  Case 4: System Hang — PCIe initialization deadlock during SCM call

1. Failed case: System Hang — PCIe initialization deadlock during SCM call
2. Root cause: Kernel hangs at 6.2s during qcom-pcie driver probe when issuing SCM calls; PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 changed qcom_scm_wait_for_wq_completion() from wait_for_completion() to wait_for_completion_state(..., TASK_IDLE), causing PCIe driver's SCM-dependent initialization path to deadlock on lemans-evk platform where PCIe probe requires secure firmware interaction.
3. Possible fix: Revert the TASK_IDLE change in qcom_scm_wait_for_wq_completion() or add platform-specific handling for lemans-evk PCIe initialization; investigate why TASK_IDLE state prevents completion signaling in the PCIe+SCM interaction path on this SoC.
4. Detail analysis attachment: failed_case_job269823_4_detailed.md

Job 269824 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Platform-specific probe failures on purwa-evk (x1p42100 SoC): qcom_qseecom_uefisecapp fails with -EBUSY (secure app unavailable/busy), two qcom-pcie instances fail with -ENODATA (PCIe endpoints not connected or powered), and regulatory.db firmware file missing from rootfs. These are pre-existing platform/configuration issues unrelated to the PR's SCM wait state change.
3. Possible fix: These probe failures are expected on this platform configuration and do not indicate a kernel regression introduced by PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167. The test should either: (1) suppress these known platform-specific probe failures for purwa-evk, or (2) verify that the failures existed in the baseline build before this PR. The PR only changes SCM wait task state and does not affect driver probe logic.
4. Detail analysis attachment: failed_case_job269824_1_detailed.md

  Case 2: ** smmu

1. Failed case: ** smmu
2. Root cause: ** Video codec device (aa00000.video-codec) is not probing or not present in the device tree for the purwa-evk (iq-x5121) platform, causing it to be absent from IOMMU group enumeration; this is a pre-existing platform configuration issue unrelated to the PR's SCM wait state change.
3. Possible fix: Verify that the video codec device node (aa00000.video-codec) is present and correctly configured in the purwa-evk device tree; if the device is not supported on this platform, update the SMMU test's critical device list to exclude it for purwa-evk, or mark this test as expected-fail for this SoC until video codec support is enabled.
4. Detail analysis attachment: failed_case_job269824_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because HYP (Hypervisor/EL2) mode is not available on the purwa-evk platform — kernel message at boot: "kvm [1]: HYP mode not available", resulting in /dev/kvm device node not being created despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The purwa-evk board either lacks virtualization extensions, boots at the wrong exception level, or has firmware that does not enable EL2. To resolve: (1) verify the board supports ARM virtualization extensions (VHE/nVHE), (2) check bootloader/firmware configuration to ensure the kernel boots at EL2 or with HYP mode accessible, (3) if the platform genuinely lacks virtualization support, mark KVM tests as "skip" for purwa-evk in the CI test matrix rather than "fail".
4. Detail analysis attachment: failed_case_job269824_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: KVM driver initialization failed because the purwa-evk platform does not support EL2 (Hypervisor) mode. The kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or the hypervisor is not accessible, preventing KVM from creating the /dev/kvm device node.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The purwa-evk board either: (1) does not have EL2 enabled in the bootloader/firmware, (2) is running under a hypervisor that does not expose nested virtualization, or (3) has hardware that does not support virtualization extensions. To resolve: verify the bootloader/firmware configuration enables EL2 mode for the kernel, or exclude KVM tests from the purwa-evk test suite if the platform does not support virtualization.
4. Detail analysis attachment: failed_case_job269824_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: The purwa-evk platform is running with Gunyah hypervisor already occupying EL2 (boot selection: el2gh, hypervisor version: gunyah-mobile-1f99e07c2). KVM requires exclusive access to HYP/EL2 mode to function, but EL2 is already claimed by Gunyah, preventing KVM from initializing and creating /dev/kvm.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on purwa-evk, boot without the Gunyah hypervisor (use a non-el2gh boot selection that boots Linux directly at EL2). Alternatively, if virtualization is required, use Gunyah's VM infrastructure instead of KVM, as both cannot coexist on the same boot.
4. Detail analysis attachment: failed_case_job269824_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (Hypervisor) mode is not available on the purwa-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The purwa-evk board does not support EL2/HYP mode required for KVM. Either: (1) skip KVM tests on purwa-evk in the CI test matrix, or (2) if HYP mode support is expected, verify bootloader/firmware configuration enables EL2 and check device tree for virtualization extensions.
4. Detail analysis attachment: failed_case_job269824_6_detailed.md

Job 269825 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check — WiFi Driver Firmware Dependency Failure (ath11k WCN6855)

1. Failed case: ** Probe_Failure_Check — WiFi Driver Firmware Dependency Failure (ath11k WCN6855)
2. Root cause: ** Missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the Monaco EVK rootfs firmware package causes ath11k_pci driver probe to fail with -ETIMEDOUT during MHI power-up; this is a pre-existing infrastructure/packaging issue unrelated to PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 (which only modifies SCM wait behavior).
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Monaco EVK firmware package at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ in the rootfs build; verify the firmware is sourced from the correct linux-firmware repository or vendor drop for WCN6855 hw2.1 nfa765 variant.
4. Detail analysis attachment: failed_case_job269825_1_detailed.md

  Case 2: WiFi Driver Probe Failure — ath11k_pci

1. Failed case: WiFi Driver Probe Failure — ath11k_pci
2. Root cause: ath11k_pci probe failed with -110 (ETIMEDOUT) on monaco-evk because the required MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory. MHI initialization timed out waiting for firmware load, causing the entire WiFi driver probe to fail. This is a pre-existing platform/image packaging issue, not introduced by PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 (which modifies qcom_scm wait state behavior).
3. Possible fix: Add the missing WCN6855 WiFi firmware files to the rootfs image build recipe. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related firmware blobs are included in /lib/firmware/ on the monaco-evk target image. Verify the firmware package (linux-firmware-ath11k or equivalent) is installed in the Yocto/distro build configuration for monaco-evk.
4. Detail analysis attachment: failed_case_job269825_2_detailed.md

  Case 3: WiFi_OnOff — Driver Probe Failure (ath11k_pci)

1. Failed case: WiFi_OnOff — Driver Probe Failure (ath11k_pci)
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) on monaco-evk because MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (-2 = ENOENT), causing MHI power-up to time out during WCN6855 WiFi chip initialization.
3. Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/), or if the firmware path is incorrect, update the device tree or driver to reference the correct firmware location for the monaco-evk board's WiFi module.
4. Detail analysis attachment: failed_case_job269825_3_detailed.md

  Case 4: Driver Probe Failure — WiFi ath11k_pci

1. Failed case: Driver Probe Failure — WiFi ath11k_pci
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT because required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -ENOENT). Without firmware, the WiFi hardware (WCN6855 hw2.1) cannot initialize, causing the MHI bus probe to timeout after waiting for device ready.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). This is a build/packaging issue — ensure the linux-firmware package or equivalent includes the nfa765 variant firmware for WCN6855 hw2.1. The PR patch (SCM wait state change) is unrelated to this failure.
4. Detail analysis attachment: failed_case_job269825_4_detailed.md

Job 269826 | SoC shikra-iqs-evk

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

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

  Case 1: GIC Test Script Bug — Test Infrastructure Issue

1. Failed case: GIC Test Script Bug — Test Infrastructure Issue
2. Root cause: The GIC test script assumes an 8-CPU system but shikra-iqs-evk has only 4 CPUs (0-3). The script attempts to parse interrupt counts for non-existent CPUs 4-7 from /proc/interrupts, causing bash integer comparison errors at line 75 when it encounters non-numeric fields (GICv3, Level, arch_timer) instead of interrupt count columns.
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 instead of hardcoding an 8-CPU assumption. The script should iterate only over CPUs that actually exist on the target platform.
4. Detail analysis attachment: failed_case_job269826_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add missing firmware files to rootfs (/lib/firmware/ccg_secondary.cyacd2 and /lib/firmware/regulatory.db); investigate TPM hardware connectivity and DT configuration for shikra-iqs-evk; verify audio functionality or fix DT clock/DAI bindings if non-functional. PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167 can proceed — these failures are not regressions introduced by the SCM wait state change.
4. Detail analysis attachment: failed_case_job269826_2_detailed.md

  Case 3: ** PCIe

1. Failed case: ** PCIe
2. Root cause: ** Test infrastructure configuration gap — required firmware file TC956X_Firmware_PCIeBridge.bin for QPS615 PCIe switch validation is not present in the rootfs firmware directories (/lib/firmware or standard firmware search paths). The PCIe controller, link training, device enumeration, and kernel health checks all passed; only the QPS615-specific firmware validation failed.
3. Possible fix: Add TC956X_Firmware_PCIeBridge.bin to the Yocto image recipe firmware package list or to the LAVA overlay for shikra-iqs-evk. The firmware should be placed in /lib/firmware/ or a subdirectory scanned by the test harness. This is a test environment fix, not a kernel code change.
4. Detail analysis attachment: failed_case_job269826_3_detailed.md

  Case 4: USBHost — Driver/Module Initialization Failure

1. Failed case: USBHost — Driver/Module Initialization Failure
2. Root cause: USB host controller drivers (dwc3-qcom, xhci-hcd) failed to probe on shikra-iqs-evk platform; USB core subsystem loaded successfully but no USB root hubs were exposed because the platform-specific USB controller drivers never attempted probe, likely due to missing kernel module configuration or device tree status="disabled" preventing driver binding.
3. Possible fix: Verify that CONFIG_USB_DWC3_QCOM=y or =m and CONFIG_USB_XHCI_PLATFORM=y or =m are enabled in the kernel configuration; if built as modules, ensure they are included in the rootfs and loaded during boot; check device tree for usb@4c00000 and usb@4e00000 nodes to confirm status="okay" and that all required dependencies (clocks, regulators, PHYs, interconnects) are properly defined and enabled.
4. Detail analysis attachment: failed_case_job269826_4_detailed.md

  Case 5: BT_SCAN — Bluetooth Device Discovery Failure (Test Infrastructure / Environment Issue)

1. Failed case: BT_SCAN — Bluetooth Device Discovery Failure (Test Infrastructure / Environment Issue)
2. Root cause: The BT_SCAN test failed because no Bluetooth devices were discovered during scanning, despite the Bluetooth stack (hci0 adapter, firmware, driver, and bluetoothd service) initializing and operating correctly. The test executed 3 scan attempts plus 2 fallback methods over ~6 minutes, all returning zero devices. This is a test environment issue: no scannable Bluetooth devices were present in RF range of the shikra-iqs-evk board during the test window, not a kernel regression introduced by the PR.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The PR changes only the task state during SCM waitqueue completion (TASK_UNINTERRUPTIBLE → TASK_IDLE) and does not affect Bluetooth functionality. The BT_ON_OFF and BT_FW_KMD_Service tests passed, confirming the Bluetooth stack is functional. To resolve: (1) verify the LAVA lab environment has active Bluetooth beacon/test devices within RF range of the shikra-iqs-evk board, (2) if beacons are present, check RF shielding or interference, (3) re-run the test to confirm this is an intermittent environment issue, not a persistent failure.
4. Detail analysis attachment: failed_case_job269826_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the Shikra IQS EVK test suite, or configure the platform firmware/bootloader to enable EL2 mode if the hardware supports it. This is not a kernel issue and is unrelated to PR firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() #1167.
4. Detail analysis attachment: failed_case_job269826_6_detailed.md

  Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM tests from the Shikra IQS EVK LAVA test suite by adding SKIP_TESTS: "KVM_Driver,KVM_EL2_DTB,KVM_Infra" to the job definition, or add a runtime check in test scripts to skip KVM tests when /dev/kvm is absent. For a proper fix, work with the firmware team to enable EL2 support in the bootloader/firmware if the SoC supports it.
4. Detail analysis attachment: failed_case_job269826_7_detailed.md

  Case 8: KVM Infrastructure Limitation — HYP Mode Not Available

1. Failed case: KVM Infrastructure Limitation — HYP Mode Not Available
2. Root cause: The Shikra IQS EVK platform runs the Gunyah Type-1 hypervisor at EL2, preventing KVM from initializing because KVM requires exclusive EL2 access. The kernel message "kvm [1]: HYP mode not available" confirms EL2 is occupied by the hypervisor.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms, not a bug. To enable KVM testing: (1) use a platform configuration without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job269826_8_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM virtualization is not available on shikra-iqs-evk because the kernel detected "HYP mode not available" during boot, preventing /dev/kvm device creation. This is a platform hardware/firmware limitation, not a kernel regression introduced by the PR.
3. Possible fix: This is not a PR-introduced failure. The shikra-iqs-evk platform does not support EL2/HYP mode required for KVM virtualization. Either: (1) exclude KVM tests from the shikra-iqs-evk test suite, or (2) run KVM tests only on platforms with virtualization support (e.g., platforms with EL2 enabled in firmware/bootloader).
4. Detail analysis attachment: failed_case_job269826_9_detailed.md