QCLINUX: qcom.config: Enable CAN_VCAN

[q-AnupKulkarni]

Enable Virtual-CAN(VCAN) support to support RTSS based CAN module from user-space

CRs-Fixed: 4672336

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4672336 is not eligible for merge.

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

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

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

[q-AnupKulkarni]

qli-2.1 pull-request freeze

[Salendarsingh Gaud (sgaud-quic)]

q-AnupKulkarni mainline PR not yet merged, merge it first.

[q-AnupKulkarni]

Salendarsingh Gaud

Got LGTM from my team

[qcomlnxci]

Test jobs on 5f11093

• multimedia Job 222416 on hamoa-iot-evk
• multimedia Job 222423 on lemans-evk
• multimedia Job 222422 on monaco-evk
• multimedia Job 222418 on purwa-iot-evk
• multimedia Job 222417 on qcs615-ride
• multimedia Job 222421 on qcs6490-rb3gen2
• multimedia Job 222419 on qcs8300-ride
• multimedia Job 222420 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 222415 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	⚠️ 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	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ 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	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	◻️	✅ Pass	❌ Fail	❌ 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	❌ Fail	❌ Fail	❌ Fail	❌ 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	◻️
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

[q-AnupKulkarni]

q-AnupKulkarni mainline PR not yet merged, merge it first.

Mainline PR merged
qualcomm-linux/kernel-topics#1801

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4672336 is not eligible for merge.

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

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

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

[qcomlnxci]

Test jobs on e22b513

• multimedia Job 223482 on hamoa-iot-evk
• multimedia Job 223486 on lemans-evk
• multimedia Job 223479 on monaco-evk
• multimedia Job 223483 on purwa-iot-evk
• multimedia Job 223485 on qcs615-ride
• multimedia Job 223481 on qcs6490-rb3gen2
• multimedia Job 223487 on qcs8300-ride
• multimedia Job 223484 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223488 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	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ 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	◻️	❌ Fail	❌ 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	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	◻️	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qlijarvis]

PR #1066 — validate-patch

PR: #1066

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1066 — QCLINUX: qcom.config: Enable CAN_VCAN Enable CAN and virtual CAN config for RTSS CAN module
Upstream commit: N/A (vendor-only QCLINUX: commit)
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	QCLINUX: vendor-only commit
Body preserves rationale	✅	Explains purpose: RTSS CAN module for SocketCAN APIs
Fixes tag present/correct	N/A	New feature, not a fix
Authorship preserved	✅	From: and Signed-off-by: match
Backport note (if applicable)	N/A	Not a backport

Diff

File	Status	Notes
arch/arm64/configs/qcom.config	✅	Clean addition of 3 CAN-related configs, alphabetically correct

Issues

• Subject line formatting: The subject contains redundant wording: "Enable CAN_VCAN Enable CAN" — the word "Enable" appears twice. Recommend: QCLINUX: qcom.config: Enable CAN and virtual CAN support

Verdict

Merge with minor subject line cleanup recommended. The change itself is correct and well-placed.

Final Summary

1. Lore link present: No — QCLINUX: prefix; no lore link expected or required
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — vendor-only change, not posted upstream
4. PR present in qcom-next/topics: No — 1/1 commit missing from both qcom-next and topics (expected for new vendor-only changes)

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

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] QCLINUX: qcom.config: Enable CAN_VCAN Enable CAN and virtual	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

[qlijarvis]

PR #1066 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	Missing commit description warning
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not in allowed list
tag-check	✅	Subject has valid prefix (QCLINUX:)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1066 - QCLINUX: qcom.config: Enable CAN_VCAN
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34570982769

Checker	Result	Summary
checkpatch	❌	Missing commit description warning
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No devicetree changes
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	QCLINUX: prefix not in allowed list
tag-check	✅	Subject has valid prefix (QCLINUX:)

---

❌ checkpatch

Root cause: Commit message body is missing — only the subject line is present.

Failure details:

WARNING: Missing commit description - Add an appropriate one

e22b5134a5655dc3bcec48efd46f0dffe1ba504c total: 0 errors, 1 warnings, 0 checks, 9 lines checked

Commit e22b5134a565 ("QCLINUX: qcom.config: Enable CAN_VCAN Enable CAN and virtual CAN config for  RTSS CAN module used to communicate with user-space applications using SocketCAN APIs.") has style problems, please review.

Fix:

The commit subject line contains the full description that should be in the body. Split it properly:

git rebase -i 9269f33cd5d258c7bc5d0f8ec6e0076174c053a1   # mark commit as 'edit'
git commit --amend

Then rewrite the commit message as:

QCLINUX: qcom.config: Enable CAN_VCAN

Enable CAN and virtual CAN config for RTSS CAN module used to
communicate with user-space applications using SocketCAN APIs.

Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 9269f33cd5d258c7bc5d0f8ec6e0076174c053a1..e22b5134a5655dc3bcec48efd46f0dffe1ba504c

---

❌ check-patch-compliance

Root cause: QCLINUX: prefix is not in the checker's allowed list (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:

Checking commit: QCLINUX: qcom.config: Enable CAN_VCAN Enable CAN and virtual CAN config for  RTSS CAN module used to communicate with user-space applications using SocketCAN APIs.
Commit summary does not start with a required prefix

Analysis:

This is a known limitation of the check-patch-compliance checker. The commit uses the QCLINUX: prefix, which is a valid vendor-internal prefix for Qualcomm-specific changes with no upstream equivalent. However, the checker only accepts upstream-linkable prefixes:

• FROMLIST: — posted to mailing list
• FROMGIT: — taken from maintainer tree
• UPSTREAM: — merged into mainline
• BACKPORT: — backported with modifications

Vendor-only commits (those with QCLINUX: or PENDING: prefixes) will always fail this checker because they have no upstream link to validate against.

Fix:

No patch change needed. This is a vendor-only kernel config change enabling CAN support for Qualcomm's RTSS module. It is correctly tagged with QCLINUX: and will not be posted upstream.

The checker failure is expected for vendor-only commits. The maintainer should approve this PR understanding that:

1. The QCLINUX: prefix is correct for vendor-only changes
2. The check-patch-compliance checker limitation is documented
3. The change itself is valid (config-only, no code changes)

---

Verdict

2 issues to address before merge:

1. Blocker: Fix the commit message format — move the description from the subject line to the body (checkpatch warning).
2. Non-blocker: The check-patch-compliance failure is expected for QCLINUX: prefixed commits and does not require a patch change.

After fixing the commit message format, the PR will be ready to merge. The check-patch-compliance failure can be ignored as it's a known limitation for vendor-only commits.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1066

Job 223479 | SoC unknown_soc_job223479

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

No failed cases detected from the LAVA results section.

Job 223481 | SoC unknown_soc_job223481

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

No failed cases detected from the LAVA results section.

Job 223482 | SoC unknown_soc_job223482

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

No failed cases detected from the LAVA results section.

Job 223483 | SoC unknown_soc_job223483

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

No failed cases detected from the LAVA results section.

Job 223484 | SoC unknown_soc_job223484

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

No failed cases detected from the LAVA results section.

Job 223485 | SoC unknown_soc_job223485

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

No failed cases detected from the LAVA results section.

Job 223486 | SoC unknown_soc_job223486

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

No failed cases detected from the LAVA results section.

Job 223487 | SoC unknown_soc_job223487

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

No failed cases detected from the LAVA results section.

Job 223488 | SoC unknown_soc_job223488

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

No failed cases detected from the LAVA results section.

[Salendarsingh Gaud (sgaud-quic)]

CR not in proper state, q-AnupKulkarni please move it to DevComplete

[qcomlnxci]

Test jobs on e22b513

• multimedia Job 227782 on hamoa-iot-evk
• multimedia Job 227778 on lemans-evk
• multimedia Job 227781 on monaco-evk
• multimedia Job 227784 on purwa-iot-evk
• multimedia Job 227783 on qcs615-ride
• multimedia Job 227786 on qcs6490-rb3gen2
• multimedia Job 227780 on qcs8300-ride
• multimedia Job 227785 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227779 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	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	◻️	✅ Pass	⚠️ skip	◻️	⚠️ skip	❌ Fail	❌ Fail	◻️
Freq_Scaling	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_Infra	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	◻️
OpenCV	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	◻️	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️
WiFi_Firmware_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	◻️	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	◻️	✅ Pass	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️

[q-AnupKulkarni]

CR not in proper state, q-AnupKulkarni please move it to DevComplete

Done

[qcomlnxci]

Test jobs on e22b513

• multimedia Job 227782 on hamoa-iot-evk
• multimedia Job 227799 on lemans-evk
• multimedia Job 227781 on monaco-evk
• multimedia Job 227784 on purwa-iot-evk
• multimedia Job 227797 on qcs615-ride
• multimedia Job 227786 on qcs6490-rb3gen2
• multimedia Job 227780 on qcs8300-ride
• multimedia Job 227785 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227798 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	❌ Fail	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	❌ Fail
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	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ 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	⚠️ skip	✅ 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: #1066

Job 227778 | SoC lemans-evk

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

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

  Case 1: login-action

1. Failed case: login-action
2. Root cause: Complete system hang after PCIe controller initialization at kernel timestamp [6.950291]; system stopped producing console output and never reached userspace login prompt despite kernel successfully starting init process and systemd-udevd.
3. Possible fix: This is NOT a PR-introduced regression. The PR only enables CAN kernel config options (CONFIG_CAN, CONFIG_CAN_DEV, CONFIG_CAN_VCAN as modules) which do not affect PCIe subsystem. The hang occurs during PCIe enumeration on lemans-evk, a known platform-specific issue. Re-run the LAVA job to confirm if this is a transient hardware/firmware issue. If reproducible, investigate PCIe controller firmware/DT configuration for lemans-evk platform independently of this PR.
4. Detail analysis attachment: failed_case_job227778_1_detailed.md

  Case 2: Complete System Hang — PCIe initialization hang

1. Failed case: Complete System Hang — PCIe initialization hang
2. Root cause: System stopped producing console output at 6.95 seconds after boot, immediately following PCIe host bridge initialization for qcom-pcie 1c10000.pcie. No kernel panic, oops, or crash signature present. LAVA login-action timed out after 186 seconds waiting for a prompt that never appeared because the system hung during PCIe link training or subsequent device enumeration on lemans-evk.
3. Possible fix: This is a pre-existing platform/driver issue unrelated to the PR (which only adds CAN config options). Investigate PCIe driver hang on lemans-evk: check if PCIe link training is stalling, add debug to qcom-pcie driver probe path, verify PCIe PHY/clock/regulator configuration in device tree, or disable PCIe in the LAVA job definition as a workaround to allow boot testing to proceed.
4. Detail analysis attachment: failed_case_job227778_2_detailed.md

  Case 3: Boot Hang — System stopped during PCIe initialization

1. Failed case: Boot Hang — System stopped during PCIe initialization
2. Root cause: Complete system hang during boot at PCIe controller initialization (~6.95s). The lemans-evk board stopped producing console output immediately after PCIe memory range configuration for controller 1c10000.pcie. No kernel panic, oops, or crash signature present. This is a pre-existing platform/kernel issue unrelated to the PR changes (which only add CAN config as modules).
3. Possible fix: This is a pre-existing lemans-evk boot hang issue, not introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066. The PR only adds CONFIG_CAN=m, CONFIG_CAN_DEV=m, and CONFIG_CAN_VCAN=m to qcom.config, which are loaded as modules after boot completes. Recommended actions: (1) Re-trigger the CI job to confirm reproducibility; (2) If reproducible, investigate PCIe driver initialization on lemans-evk platform - check for known PCIe hang issues on this SoC; (3) Test with PCIe disabled in device tree to isolate the hang; (4) Check if other lemans-evk LAVA jobs are also failing with the same pattern.
4. Detail analysis attachment: failed_case_job227778_3_detailed.md

  Case 4: ** LAVA Job Timeout — System Hang After PCIe Initialization

1. Failed case: ** LAVA Job Timeout — System Hang After PCIe Initialization
2. Root cause: ** The lemans-evk board stopped producing serial output after PCIe host bridge initialization completed at kernel timestamp 6.95s. The system did not reach the login prompt despite kernel and early userspace (systemd-udevd) starting successfully. LAVA dispatcher exhausted all 3 login retry attempts over 10 minutes with no response from the board, indicating a complete system freeze. The PR changes (enabling CAN_VCAN config) are unrelated to PCIe or boot flow and did not introduce this hang.
3. Possible fix: This is a pre-existing board/kernel hang issue unrelated to the PR. Re-trigger the CI job to confirm if the hang is reproducible. If it recurs, investigate PCIe driver initialization on lemans-evk: check if PCIe link training is stalling, review recent PCIe driver changes in the integration branch, and enable PCIe debug logging (pci=debug kernel cmdline) to capture where the hang occurs during PCIe enumeration.
4. Detail analysis attachment: failed_case_job227778_4_detailed.md

Job 227779 | SoC shikra-iqs-evk

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

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

  Case 1: Build Load Failure — UEFI bootloader crash

1. Failed case: Build Load Failure — UEFI bootloader crash
2. Root cause: Result: Build Load Failure. The UEFI bootloader crashes repeatedly with a data fault (PC at 0x9F41969C, FAR 0xC264000, ESR 0x96000046) during the DXE phase before the Linux kernel boot banner appears. The crash is in UEFI firmware, not kernel code. The PR changes only kernel config (CAN module enablement), which cannot affect UEFI behavior, indicating this is a pre-existing board/firmware issue or infrastructure problem specific to the shikra-iqs-evk platform.
3. Possible fix: This is an infrastructure/firmware issue unrelated to the PR. Re-trigger the CI job on a different shikra-iqs-evk board instance. If the issue persists across multiple boards, escalate to the LAVA lab team to investigate UEFI firmware corruption or board hardware failure on the shikra-iqs-evk fleet. The PR itself (kernel config change for CAN modules) is not the root cause and should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job227779_1_detailed.md

  Case 2: Build Load Failure — UEFI firmware crash before kernel launch

1. Failed case: Build Load Failure — UEFI firmware crash before kernel launch
2. Root cause: Result: Build Load Failure. UEFI DXE phase crashes with MMU translation fault (second level) at address 0xC264000 before launching the Linux kernel. UEFI assertion failure ASSERT Image.c +1853: Image->Tpl == gEfiCurrentTpl followed by data abort at PC 0xAA5E97E0. This is a firmware-level issue on the shikra-iqs-evk board, not related to the PR's kernel config changes (CAN module enablement). The kernel image never loads; LAVA times out waiting for the kernel boot banner.
3. Possible fix: This is a pre-existing UEFI firmware issue on shikra-iqs-evk, not introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN config options). Re-trigger the LAVA job to confirm if the failure is transient. If it recurs, escalate to the board/firmware team to investigate the UEFI DXE MMU fault at 0xC264000 — likely a firmware memory mapping or initialization bug. The PR changes are not the root cause and should not block merge based on this failure.
4. Detail analysis attachment: failed_case_job227779_2_detailed.md

  Case 3: ** Build Load Failure — UEFI Panic Loop (Data Abort)

1. Failed case: ** Build Load Failure — UEFI Panic Loop (Data Abort)
2. Root cause: ** Result: Build Load Failure. UEFI DXE stage encounters a repeating data abort (translation fault at FAR 0xC264000, PC 0x9F41969C) causing a boot loop; the Linux kernel never loads. This is a pre-existing board/firmware/image issue, not introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only changes kernel config).
3. Possible fix: Reflash the shikra-iqs-evk board with a known-good firmware and boot image to recover UEFI. If the issue persists, investigate the LAVA job's boot image artifact for corruption or incompatibility with this board's UEFI version. As a workaround, re-trigger the CI job on a different shikra-iqs-evk board to confirm whether the issue is board-specific.
4. Detail analysis attachment: failed_case_job227779_3_detailed.md

Job 227780 | SoC qcs8300-ride

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

Failed test cases in LAVA job 227780 (SoC: qcs8300-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: For Probe_Failure_Check test: suppress the regulatory.db failure (WiFi functional); fix the Aquantia PHY probe by adding the correct firmware-name property to the PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts (reference: Aquantia PHY driver binding documentation). These are pre-existing platform issues unrelated to PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (CAN config changes).
4. Detail analysis attachment: failed_case_job227780_1_detailed.md

  Case 2: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY device tree node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts (or the appropriate board DTS file), specifying the correct firmware file path for the AQR115C PHY (typically Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld or similar, depending on the PHY variant).
4. Detail analysis attachment: failed_case_job227780_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 pre-existing platform limitation, not a regression introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN driver support). KVM tests should be skipped on qcs8300-ride in the LAVA test plan, or the platform firmware/bootloader must be updated to boot the kernel at EL2 if KVM support is required.
4. Detail analysis attachment: failed_case_job227780_3_detailed.md

  Case 4: KVM Driver Initialization Failure — /dev/kvm device node not created

1. Failed case: KVM Driver Initialization Failure — /dev/kvm device node not created
2. Root cause: QCS8300 (Monaco) platform does not support KVM/virtualization; platform either lacks EL2 virtualization extensions, boots Linux at EL1 without EL2 access, or has Gunyah hypervisor already running at EL2, preventing Linux KVM from initializing.
3. Possible fix: This is a platform limitation, not a kernel bug or PR regression. If KVM support is required on QCS8300, verify: (1) platform firmware enables EL2 virtualization extensions, (2) bootloader boots Linux at EL2 (not EL1), (3) no conflicting hypervisor (Gunyah) is running. If platform intentionally does not support KVM, exclude KVM tests from the QCS8300 test suite.
4. Detail analysis attachment: failed_case_job227780_4_detailed.md

  Case 5: ** KVM_Infra (and KVM_Driver, KVM_EL2_DTB — same root cause)

1. Failed case: ** KVM_Infra (and KVM_Driver, KVM_EL2_DTB — same root cause)
2. Root cause: ** QCS8300 Ride is running as a guest VM under Gunyah hypervisor (evidenced by gunyah-md-region@91a80000 and arm-pv: using stolen time PV). KVM requires EL2 access, which is owned by the hypervisor; guest VMs run at EL1 and cannot initialize KVM. This is expected behavior, not a kernel defect.
3. Possible fix: Exclude KVM tests from the CI test suite for QCS8300 Ride when running under Gunyah hypervisor, or configure the platform to boot bare-metal (not as a VM guest) if KVM testing is required. The PR is not at fault — this is a test environment configuration issue.
4. Detail analysis attachment: failed_case_job227780_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 infrastructure issue — test runner completed normally and exited cleanly (<LAVA_TEST_RUNNER EXIT>), but LAVA dispatcher marked the test definition as "unfinished" and failed, likely due to a mismatch between expected and reported test results or a LAVA dispatcher state tracking issue.
3. Possible fix: Re-trigger the LAVA job; this is a known LAVA infrastructure transient issue where the dispatcher fails to properly track test completion despite the test runner exiting normally. If the issue persists, investigate the LAVA job definition for missing test result expectations or check LAVA dispatcher logs for state tracking errors.
4. Detail analysis attachment: failed_case_job227780_6_detailed.md

Job 227781 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) on monaco-evk board. The WiFi PCIe device (WCN6855 hw2.1) failed to respond during MHI initialization, likely due to missing firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin not found, error -2) or hardware power/clock sequencing issue specific to this board variant.
3. Possible fix: Verify WiFi firmware files are present in the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/. If missing, add the linux-firmware-ath11k package to the Yocto image recipe for monaco-evk. If firmware is present, investigate board-specific power sequencing or PCIe link training issues for the WCN6855 on this platform.
4. Detail analysis attachment: failed_case_job227781_1_detailed.md

  Case 2: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing ath11k WCN6855 firmware files to the rootfs image. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are present in /lib/firmware/. The firmware package linux-firmware-ath11k or equivalent must be included in the Yocto/build configuration for Monaco EVK.
4. Detail analysis attachment: failed_case_job227781_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Install the missing WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin into /lib/firmware/ in the rootfs image; verify the firmware package (linux-firmware-qcom-ath11k or equivalent) is included in the Yocto build configuration for monaco-evk.
4. Detail analysis attachment: failed_case_job227781_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Pre-existing WiFi hardware probe failure (ath11k_pci probe failed with error -110 due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin) unrelated to PR changes; PR only adds CAN config options.
3. Possible fix: This is a pre-existing infrastructure/firmware issue on monaco-evk, not a PR-introduced regression. The PR changes (adding CONFIG_CAN, CONFIG_CAN_DEV, CONFIG_CAN_VCAN) are unrelated to WiFi. No PR fix required; the WiFi firmware file needs to be added to the test image or the test expectation adjusted for monaco-evk.
4. Detail analysis attachment: failed_case_job227781_4_detailed.md

Job 227782 | SoC hamoa-evk

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

Failed test cases in LAVA job 227782 (SoC: hamoa-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: These are pre-existing platform/infrastructure issues that should be tracked separately. For this PR: No action required — the CAN config changes are unrelated to these failures. To resolve the underlying issues: (1) investigate secure world resource allocation for qcom_qseecom_uefisecapp on hamoa-evk, (2) fix PMIC PWM DT properties in hamoa device tree, (3) add regulatory.db to rootfs firmware directory or build it into the kernel.
4. Detail analysis attachment: failed_case_job227782_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expectation failure — the SMMU validation test detected that 6 critical USB controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and 1 video codec device (aa00000.video-codec) are missing IOMMU group attachments on the hamoa-evk platform, causing the test to fail despite SMMU hardware functioning correctly and no SMMU/IOMMU errors in dmesg.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only adds CAN config options). The missing IOMMU attachments indicate either: (1) these devices lack iommus properties in the hamoa-evk device tree, or (2) the test's critical device list includes devices not present or not expected to have IOMMU protection on this platform. Review the hamoa-evk device tree to add missing iommus properties for these USB/video devices, or update the test's critical device list to exclude devices that are legitimately not IOMMU-protected on this SoC.
4. Detail analysis attachment: failed_case_job227782_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on hamoa-evk because the platform runs Linux as a guest under the Gunyah hypervisor (at EL1), not at EL2 (HYP mode). KVM requires EL2 access to create nested virtualization, which is unavailable when Linux itself is a VM guest.
3. Possible fix: Mark KVM tests as "skip" or "not applicable" for hamoa-evk and other Gunyah-based platforms in the LAVA test suite configuration. This is a platform architectural limitation, not a kernel bug. The test expectation should be updated to reflect that KVM is only supported on platforms where Linux runs at EL2 (bare-metal or Type-1 hypervisor configurations).
4. Detail analysis attachment: failed_case_job227782_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 probe failed during kernel initialization because the Hamoa IoT EVK platform does not provide EL2 (Hypervisor) mode support. The kernel message "kvm [1]: HYP mode not available" at boot time (line 3593) indicates the CPU is not running at EL2 or VHE (Virtualization Host Extensions) is not available, preventing KVM from initializing and creating the /dev/kvm device node.
3. Possible fix: This is a pre-existing platform hardware limitation, not a regression introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN driver configs). The KVM tests should be excluded from the Hamoa EVK test suite, or the test should be updated to skip gracefully when /dev/kvm is unavailable. No kernel code fix is required — the platform does not support virtualization.
4. Detail analysis attachment: failed_case_job227782_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize because the Hamoa EVK platform boots CPUs at EL1 (kernel privilege level) without EL2 (hypervisor mode) available; kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is not accessible, preventing /dev/kvm device creation.
3. Possible fix: Configure the Hamoa EVK bootloader/firmware (UEFI/ABL) to boot the kernel at EL2 or with VHE (Virtualization Host Extensions) enabled; verify the device tree and bootloader settings allow EL2 access; this is a platform firmware configuration issue, not a kernel regression introduced by the CAN config PR.
4. Detail analysis attachment: failed_case_job227782_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 kernel regression or bug introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN driver configs). The KVM tests should be excluded from the test suite for hamoa-evk platform, or marked as expected-to-skip for platforms without EL2/HYP support. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job227782_6_detailed.md

Job 227783 | SoC qcs615-ride

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

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

  Case 1: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)

1. Failed case: ** Kernel Crash — Synchronous External Abort (Hardware Bus Error)
2. Root cause: ** The SWIOTLB bounce buffer physical address range allocated for USB DMA is not accessible on the qcs615-ride platform, resulting in a synchronous external abort when the kernel attempts to copy data into the bounce buffer during USB device enumeration.
3. Possible fix: Investigate qcs615-ride platform memory layout and SWIOTLB configuration. Check device tree reserved-memory nodes, bootloader memory carveouts, and SWIOTLB buffer placement. Verify the SWIOTLB buffer range (typically set via swiotlb= kernel cmdline or DT) does not overlap with firmware-reserved regions or unmapped address space. If the issue is board-specific, test on a different qcs615-ride unit to rule out hardware defect. The PR (CAN config changes) is not the cause and can proceed independently.
4. Detail analysis attachment: failed_case_job227783_1_detailed.md

  Case 2: auto-login-action

1. Failed case: auto-login-action
2. Root cause: Kernel crash (synchronous external abort) during USB device enumeration at ~7.6 seconds into boot. The crash occurred in __pi_memcpy_generic+0x2c called from swiotlb_bounce+0x104 while processing a USB low-speed device (1-1) on the xHCI controller. The external abort indicates a hardware bus fault during DMA bounce buffer copy, likely due to an invalid physical address access or IOMMU/SMMU mapping issue for the USB controller on qcs615-ride.
3. Possible fix: This crash is unrelated to the PR changes (CAN config additions). The failure is a pre-existing platform/hardware issue with USB DMA on qcs615-ride. Re-trigger the CI job to confirm reproducibility. If the crash reproduces consistently on qcs615-ride, investigate USB controller IOMMU domain configuration and SWIOTLB bounce buffer setup for this SoC; check if USB controller DMA address constraints are correctly declared in the device tree and whether the IOMMU mappings are valid for the USB controller's DMA range.
4. Detail analysis attachment: failed_case_job227783_2_detailed.md

  Case 3: Kernel Crash — Synchronous External Abort during USB DMA mapping

1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA mapping
2. Root cause: Synchronous external abort (memory bus fault) at 7.6s into boot while mapping USB descriptor DMA buffer via SWIOTLB/IOMMU during PCIe USB controller enumeration on qcs615-ride; fault occurred in __pi_memcpy_generic copying to SWIOTLB bounce buffer address 0xffff00007ff3f000, indicating hardware memory access violation or IOMMU misconfiguration for the PCIe-attached USB controller (device 0000:01:00.0).
3. Possible fix: This is a pre-existing platform/hardware issue unrelated to the PR (which only enables CAN config). Investigate IOMMU domain configuration for PCIe device 0000:01:00.0 (USB controller at 1c08000.pcie); verify SMMU stream mapping and reserved memory regions for this SoC; check if PCIe IOMMU group 23 has correct aperture/DMA mask; re-trigger CI on a known-good baseline to confirm this is board-specific flakiness rather than a kernel regression.
4. Detail analysis attachment: failed_case_job227783_3_detailed.md

  Case 4: Kernel Crash — Synchronous External Abort (SWIOTLB/USB)

1. Failed case: Kernel Crash — Synchronous External Abort (SWIOTLB/USB)
2. Root cause: Hardware memory access fault (synchronous external abort) during SWIOTLB bounce buffer memcpy operation while enumerating USB device; the fault occurred at physical address 0xffff0000917e6b60 during DMA mapping for USB control transfer, indicating either invalid SWIOTLB buffer allocation, IOMMU misconfiguration, or hardware bus fault on qcs615-ride platform.
3. Possible fix: This is a pre-existing platform/infra issue unrelated to the PR (PR only enables CAN config options). The crash occurs during USB hub enumeration in the first boot attempt; subsequent boot attempts time out waiting for login prompt. Short-term: disable USB host controller or SWIOTLB debugging to isolate root cause. Long-term: investigate SWIOTLB buffer allocation on qcs615-ride, verify IOMMU domain configuration for USB controller (dwc3/xhci), check for known errata on QCS615 USB/DMA subsystem, and validate device tree IOMMU bindings for USB nodes.
4. Detail analysis attachment: failed_case_job227783_4_detailed.md

Job 227784 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform-specific driver probe failures on purwa-evk (X5121) board for QSEECOM secure app (-EBUSY), PMIC RTC (-EIO), two PCIe controllers (-ENODATA), LED PWM controller (-EINVAL), and WiFi regulatory database (-ENOENT, benign). None are related to PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 which only enables CAN kernel config options.
3. Possible fix: These probe failures are not introduced by this PR and should be triaged separately as platform/board bring-up issues. For this PR: Accept the Probe_Failure_Check failure as a known pre-existing platform limitation. To resolve the underlying issues: (1) PCIe: verify hardware presence and link training on 1bf8000 and 1bd0000 controllers; (2) RTC: debug SPMI communication with PMIC RTC at c42d000.spmi:pmic@0:rtc@6100; (3) QSEECOM: resolve TrustZone resource conflict for uefisecapp; (4) LPG: fix device tree bindings for c42d000.spmi:pmic@1:pwm; (5) regulatory.db: ignore as benign (WiFi functional).
4. Detail analysis attachment: failed_case_job227784_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test infrastructure issue — the smmu test expects all USB controllers (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec (aa00000) to have IOMMU group attachments, but on purwa-evk platform only USB controllers a000000, a200000, a400000, a600000, and a800000 are enabled and probed; the test is checking for DWC3 wrapper nodes that are present in device tree but not enabled/functional on this platform.
3. Possible fix: Update the smmu test's critical master list for purwa-evk to exclude the non-functional USB wrapper nodes (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec (aa00000), or mark these as optional for this platform; this is a pre-existing platform configuration issue unrelated to PR 1066 (which only enables CAN config options).
4. Detail analysis attachment: failed_case_job227784_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 kernel bug. To enable KVM on Purwa IoT EVK: (1) Configure the bootloader/firmware (ABL/UEFI) to boot the kernel at EL2 instead of EL1, OR (2) Enable VHE in the CPU/firmware if supported by the hardware, OR (3) Mark KVM tests as "not applicable" for this platform if hypervisor support is not a requirement for Purwa IoT EVK.
4. Detail analysis attachment: failed_case_job227784_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 initialization fails because the purwa-evk platform boots with the Gunyah hypervisor occupying EL2, preventing KVM from accessing HYP mode required for nested virtualization. The kernel message kvm [1]: HYP mode not available at boot confirms EL2 is unavailable to Linux.
3. Possible fix: This is expected behavior on Gunyah-based platforms. Either: (1) Skip KVM tests on purwa-evk and other Gunyah platforms in CI, or (2) Use a non-Gunyah boot configuration if KVM testing is required. The PR is not at fault — this is a platform/test-environment mismatch.
4. Detail analysis attachment: failed_case_job227784_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update LAVA test suite to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg) and automatically skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when a hypervisor is detected, marking them as "SKIP" with reason "KVM not supported under hypervisor (nested virt not enabled)". Long-term: either enable nested virtualization in Gunyah configuration (if supported) or disable CONFIG_KVM in hypervisor-enabled kernel builds for this platform.
4. Detail analysis attachment: failed_case_job227784_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because the purwa-evk platform is not running in HYP mode (EL2 hypervisor exception level) — kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not in a virtualization-capable state, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by the PR (PR only enables CAN config options unrelated to KVM). If KVM support is required on purwa-evk, verify the bootloader/firmware boots the kernel at EL2 (not EL1), or update the LAVA test job definition to skip KVM tests on platforms without hypervisor support. If KVM is expected to work on this platform, check bootloader configuration and ensure the CPU is started in EL2 mode with VHE (Virtualization Host Extensions) enabled.
4. Detail analysis attachment: failed_case_job227784_6_detailed.md

Job 227785 | SoC qcs9100-ride

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Pre-existing platform issues unrelated to PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (CAN config changes): (1) Aquantia AQR115C Ethernet PHY probe failure due to missing/invalid firmware-name DT property (error -22 = -EINVAL), (2) Four PMIC temp-alarm devices stuck in deferred probe (missing thermal_zone IPA driver dependency), (3) Benign regulatory.db firmware load failure (cfg80211 wireless regulatory database not packaged in rootfs).
3. Possible fix: None required for PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 — the PR only enables CAN kernel configs and does not touch Ethernet PHY, PMIC thermal, or wireless drivers. The probe failures are pre-existing board/DT/firmware issues on qcs9100-ride that should be tracked separately: (1) Add firmware-name property to Aquantia PHY DT node or fix PHY driver to handle missing property gracefully, (2) Ensure thermal_zone IPA driver probes before PMIC temp-alarm devices (or accept deferred probe as non-critical for this platform), (3) Package wireless-regdb in rootfs if cfg80211 regulatory enforcement is needed.
4. Detail analysis attachment: failed_case_job227785_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on qcs9100-ride platform; the SMMU test validation script expects all critical DMA masters (UFS, Display, GPU, USB, Ethernet, Video) to be protected by IOMMU groups, but the video codec device lacks the required device tree iommus property or the driver failed to probe/attach.
3. Possible fix: Add the missing iommus property to the aa00000.video-codec device tree node in arch/arm64/boot/dts/qcom/qcs9100.dtsi (or the board-specific overlay) to bind the video codec to an SMMU context bank, or investigate why the video codec driver is not probing on this platform (check for missing firmware, disabled DT node status, or driver module not loaded).
4. Detail analysis attachment: failed_case_job227785_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: The qcom-ethqos driver for end0 (23040000.ethernet) fails to attach to its PHY with -EINVAL error during interface bring-up, indicating a device tree PHY configuration issue (missing or incorrect phy-handle/phy-mode/PHY node) on qcs9100-ride platform.
3. Possible fix: Verify the device tree node for 23040000.ethernet contains correct phy-handle phandle, phy-mode property, and that the referenced PHY node exists in the MDIO bus with proper compatible/reg properties; if missing, add the PHY DT node and reference it correctly from the Ethernet node.
4. Detail analysis attachment: failed_case_job227785_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a PR-introduced regression (PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 only adds CAN config options unrelated to virtualization). To enable KVM on qcs9100-ride, the platform must be configured to boot without Gunyah hypervisor, or the test expectation should be updated to skip KVM tests on Gunyah-enabled platforms. Recommended action: Update the LAVA test suite to check for Gunyah presence and skip KVM tests when Gunyah is active, OR provide a separate build/boot configuration for KVM testing without Gunyah.
4. Detail analysis attachment: failed_case_job227785_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark KVM_EL2_DTB, KVM_Driver, and KVM_Infra tests as "skip" or "not applicable" for qcs9100-ride and other Gunyah-enabled platforms in the LAVA test suite. Add a platform capability check to the test runner that skips KVM tests when Gunyah hypervisor is detected (check for "Gunyah based bootup" in boot logs or presence of /sys/hypervisor/type == "gunyah").
4. Detail analysis attachment: failed_case_job227785_5_detailed.md

  Case 6: KVM Driver Initialization Failure — HYP mode not available

1. Failed case: KVM Driver Initialization Failure — HYP mode not available
2. Root cause: qcs9100-ride platform does not provide EL2 (hypervisor mode) access to the Linux kernel; KVM driver initialization fails at EL2 availability check with "HYP mode not available" (line 3127), preventing /dev/kvm device creation and causing all KVM tests to fail.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on qcs9100-ride: (1) verify the platform supports virtualization, (2) configure bootloader to enter kernel at EL2 or provide EL2 access, (3) ensure TrustZone/secure firmware allows EL2 usage, (4) if using Qualcomm hypervisor, ensure hypervisor firmware is properly configured. If the platform does not support virtualization, disable KVM tests for this target in the LAVA test suite.
4. Detail analysis attachment: failed_case_job227785_6_detailed.md

  Case 7: KVM_Infra (Test Infrastructure Limitation — Not a Kernel Issue)

1. Failed case: KVM_Infra (Test Infrastructure Limitation — Not a Kernel Issue)
2. Root cause: qcs9100-ride platform boots with Gunyah hypervisor at EL2, preventing KVM from accessing virtualization hardware; kernel correctly reports "HYP mode not available" and does not create /dev/kvm device node.
3. Possible fix: This is not a kernel bug. The test should be skipped on platforms running with a hypervisor at EL2 (Gunyah/pKVM configurations). Add platform detection to the LAVA test definition to skip KVM tests when dmesg | grep "HYP mode not available" is present, or exclude qcs9100-ride from KVM test matrix.
4. Detail analysis attachment: failed_case_job227785_7_detailed.md

Job 227786 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC (Test Script Bug — Not a Kernel Issue)

1. Failed case: GIC (Test Script Bug — Not a Kernel Issue)
2. Root cause: The GIC test script incorrectly assumes all CPUs in the "possible" range (0-7) are online and attempts to parse /proc/interrupts columns for CPUs 6-7, which are offline on qcs6490-rb3gen2 (only CPUs 0-5 are online). This causes a bash integer comparison error at line 75 when the script tries to extract non-existent interrupt count columns.
3. Possible fix: Update the GIC test script to iterate only over online CPUs (read from /sys/devices/system/cpu/online) instead of assuming all possible CPUs are online. The script should skip offline CPUs or explicitly online them before testing.
4. Detail analysis attachment: failed_case_job227786_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: Update the Probe_Failure_Check test to apply known benign failure suppression rules from lava-known-benign-failures.md Rule 2 (WiFi firmware false positive when WiFi ON/OFF passes) and exclude board-specific firmware availability issues (xhci-pci-renesas on rb3gen2) from the failure criteria. Alternatively, mark this test case as PASS with a note about suppressed benign failures.
4. Detail analysis attachment: failed_case_job227786_2_detailed.md

  Case 3: ** Freq_Scaling — Test Infrastructure Issue (CPU Boot Failure)

1. Failed case: ** Freq_Scaling — Test Infrastructure Issue (CPU Boot Failure)
2. Root cause: ** The Freq_Scaling test failed because it expects all 8 CPUs (cpu0-cpu7) on qcs6490-rb3gen2 to have cpufreq interfaces, but CPU6 and CPU7 failed to boot during kernel SMP initialization with PSCI error -22 (EINVAL: psci: failed to boot CPU6 (-22), psci: failed to boot CPU7 (-22)). Only 6 of 8 CPUs came online. The test checked cpu0-cpu6 (all passed) then failed when checking cpu7 which was never brought online.
3. Possible fix: This is a pre-existing platform/firmware issue unrelated to PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN config options). The test should be updated to check only online CPUs (/sys/devices/system/cpu/online) rather than assuming all possible CPUs are online. For the underlying CPU boot failure: investigate PSCI firmware compatibility, device tree CPU node configuration for CPU6/CPU7, and platform-specific power sequencing requirements on qcs6490-rb3gen2. Check if CPU6/CPU7 are intentionally disabled in device tree or if PSCI firmware version has known issues with these CPUs.
4. Detail analysis attachment: failed_case_job227786_3_detailed.md

  Case 4: KVM_Driver (Pre-existing Platform Limitation)

1. Failed case: KVM_Driver (Pre-existing Platform Limitation)
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the Gunyah hypervisor is already running at EL2, preventing KVM from accessing HYP mode. The kernel logs show "kvm [1]: HYP mode not available" during boot, and the Gunyah hypervisor banner confirms "Hypervisor cold boot, version: gunyah-cdfb73831 perf" at early boot. This is a platform configuration issue where only one hypervisor can control EL2 at a time on ARM64 architecture.
3. Possible fix: This is not a regression introduced by PR QCLINUX: qcom.config: Enable CAN_VCAN #1066 (which only adds CAN driver configs). The KVM_Driver test failure is a pre-existing platform limitation on qcs6490-rb3gen2 boards running with Gunyah hypervisor enabled. To resolve: (1) Skip KVM tests on Gunyah-enabled builds in the CI test matrix, OR (2) Create a separate test configuration that boots without Gunyah hypervisor if KVM testing is required for this platform.
4. Detail analysis attachment: failed_case_job227786_4_detailed.md

  Case 5: 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 not a kernel bug or PR-introduced regression. The qcs6490-rb3gen2 platform requires bootloader/firmware configuration to enable EL2 (HYP mode) for KVM support. Options: (1) Update the LAVA test suite to skip KVM tests on platforms without EL2 support (check for /dev/kvm existence or dmesg | grep "HYP mode not available" before running KVM tests), or (2) If KVM support is required on this platform, work with the platform team to enable EL2 in the bootloader/firmware (ABL/XBL configuration).
4. Detail analysis attachment: failed_case_job227786_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM tests from the test suite for qcs6490-rb3gen2 (Kodiak) and other platforms without EL2 support. Add a platform capability check to the LAVA job definition to skip KVM tests when the target does not support virtualization. Alternatively, update the test to report SKIP instead of FAIL when /dev/kvm is absent due to platform limitations.
4. Detail analysis attachment: failed_case_job227786_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver loaded but /dev/kvm device node not created on qcs6490-rb3gen2 platform; CONFIG_KVM is enabled but hardware/firmware virtualization support appears unavailable; this is a pre-existing platform limitation unrelated to the PR's CAN config changes.
3. Possible fix: This is not a PR-introduced regression. If KVM support is required on qcs6490-rb3gen2, verify: (1) hardware supports ARM virtualization extensions (EL2), (2) bootloader/firmware enables EL2, (3) kernel command line doesn't disable KVM. Otherwise, mark KVM tests as expected-fail for this platform or skip them in CI.
4. Detail analysis attachment: failed_case_job227786_7_detailed.md