[qualcomm-yuanjiey (qualcomm-yuanjiey)]

Add support for building an EL2 combined DTB for the hamoa-advantech-som-db5830 in the Qualcomm DTS Makefile.

The new hamoa-advantech-som-db5830-el2.dtb is generated by combining the base hamoa-advantech-som-db5830.dtb with the x1-el2.dtbo overlay, enabling EL2-specific configurations required by the platform.

Link: https://lore.kernel.org/lkml/20261029-come_kvm-v1-1-576afbde32c4@oss.qualcomm.com/

CRs-fixed: 4727307

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

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

[qualcomm-yuanjiey (qualcomm-yuanjiey)]

qualcomm-linux/kernel-topics#2151 has been merged

[qlijarvis]

PR #1362 — validate-patch

PR: #1362

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/lkml/20261029-come_kvm-v1-1-576afbde32c4@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — code change identical; context-only delta (line 17 vs 23) due to vendor tree vs mainline base
3. Upstream patch status: ⏳ In review — posted Oct 29, 2026; no maintainer decision yet (normal for fresh submission)
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: #1362 - FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830
Upstream commit: https://lore.kernel.org/lkml/20261029-come_kvm-v1-1-576afbde32c4@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check	Status	Note
Subject matches upstream	✅	Subject adapted with FROMLIST: prefix (correct for pending upstream patch)
Body preserves rationale	✅	Body text identical to lore patch
Fixes tag present/correct	N/A	No Fixes tag in upstream patch
Authorship preserved	✅	From: matches lore author (Yuanjie Yang yuanjie.yang@oss.qualcomm.com) — correct for FROMLIST:
Backport note (if applicable)	N/A	Not a backport; FROMLIST: indicates pending upstream patch
Link tag present	✅	Correct lore.kernel.org link added

Diff

File	Status	Notes
arch/arm64/boot/dts/qcom/Makefile	✅	Code change identical; context-only delta (line 17 vs 23) due to different tree base

Diff Analysis:

• Added lines: Identical in both patches (4 lines: blank line, hamoa-advantech-som-db5830-el2-dtbs assignment, blank line, dtb-$(CONFIG_ARCH_QCOM) entry)
• Context difference: PR applies at line 17 (vendor tree context: apq8096-*, glymur-crd), lore applies at line 23 (mainline context: glymur-hp-elitebook-x-g2q, glymur-lenovo-yoga-slim7x, glymur-qcb)
• Verdict: Context-only delta is expected and acceptable for vendor tree integration

Upstream Patch Status

Commit	Community Verdict
arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830	⏳ Decision Pending — posted Oct 29, 2026 (today); no maintainer response yet

Status Details:

• Patch posted to linux-kernel@vger.kernel.org on Oct 29, 2026 at 15:55:43 +0800
• No Reviewed-by:, Acked-by:, applied, or queued signals in thread
• No NAK or rejection signals
• Thread is fresh (< 1 day old); normal review cycle in progress

qcom-next/topics Presence

Commit	Status
FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830	✅ Present in topics — all added lines verified

Integration Status: Per integration_presence_report.md, this commit is present in the kernel topics branches (checked via topics remote at https://github.com/qualcomm-linux/kernel-topics). Partial match in qcom-next (subject/tree evidence), full match in topics.

Issues

None. The patch faithfully represents the lore upstream with only expected context differences due to different tree bases.

Verdict

Merge as-is. The PR correctly applies the lore patch with the FROMLIST: prefix, preserves authorship, includes the proper lore link, and the code change is identical. Context differences are expected and acceptable for vendor tree integration. The patch is already present in the topics branches, confirming it's part of the integration workflow.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/lkml/20261029-come_kvm-v1-1-576afbde32c4@oss.qualcomm.com/
2. Lore link matches PR commits: Yes — code change identical; context-only delta (line 17 vs 23) due to vendor tree vs mainline base
3. Upstream patch status: ⏳ In review — posted Oct 29, 2026; no maintainer decision yet (normal for fresh submission)
4. PR present in qcom-next/topics: Yes — present in topics branch; all added lines verified

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

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for	partial - subject or partial tree evidence found, but full change was not verified	present - all checked added lines are present	present

Final Status

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

[qlijarvis]

PR #1362 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Pre-existing errors in base DTS files
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	✅	Passed
tag-check	✅	Valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1362 — FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/40840577648
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Pre-existing errors in base DTS files
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	✅	Passed
tag-check	✅	Valid FROMLIST: prefix

---

❌ dtb-check

Root cause: The PR adds a new DTB build target (hamoa-advantech-som-db5830-el2.dtb) by combining the base hamoa-advantech-som-db5830.dtb with the x1-el2.dtbo overlay. The dtb-check failures are pre-existing errors in the underlying DTS files (hamoa.dtsi, x1-el2.dtso) that are exposed when the new combined DTB is built. The PR itself only modifies arch/arm64/boot/dts/qcom/Makefile and does not introduce any new DTS content.

Failure details:

The newly built hamoa-advantech-som-db5830-el2.dtb triggers the following pre-existing schema validation errors:

1. CoreSight components — arm,coresight-cpu-funnel, arm,coresight-cpu-replicator, arm,coresight-cpu-tmc compatible strings do not match any schema:

   funnel@13401000 (arm,coresight-cpu-funnel): compatible: ['arm,coresight-cpu-funnel'] does not contain items matching the given schema
   replicator@13490000 (arm,coresight-cpu-replicator): compatible: ['arm,coresight-cpu-replicator'] does not contain items matching the given schema
   tmc@13409000 (arm,coresight-cpu-tmc): compatible: ['arm,coresight-cpu-tmc'] does not contain items matching the given schema
   

   → These are vendor-specific CoreSight compatible strings that lack upstream bindings.

2. ETM nodes — Multiple etm@* nodes fail 'anyOf' conditional checks (likely missing required properties or wrong property values).

3. CTCU node — qcom,hamoa-ctcu compatible string fails to match any schema:

   /soc@0/ctcu@10001000: failed to match any schema with compatible: ['qcom,hamoa-ctcu', 'qcom,sa8775p-ctcu']
   

   → Missing binding for qcom,hamoa-ctcu.

4. Video codec node — qcom,x1e80100-iris has multiple issues:

   video-codec@aa00000 (qcom,x1e80100-iris): 'iommus' is a required property
   video-codec@aa00000 (qcom,x1e80100-iris): Unevaluated properties are not allowed ('iommu-map', 'video-firmware' were unexpected)
   video-codec@aa00000 (qcom,x1e80100-iris): iommu-map:2: [0, 1] is too short
   

   → The binding expects iommus but the DTS uses iommu-map instead, and the iommu-map array is too short.

Analysis:

These errors are not caused by the PR. The PR only adds a Makefile rule to build a new combined DTB. The errors originate from:

• arch/arm64/boot/dts/qcom/hamoa.dtsi (base SoC DTSI with CoreSight, CTCU, video codec nodes)
• arch/arm64/boot/dts/qcom/x1-el2.dtso (EL2 overlay)
• Missing or incomplete upstream bindings for Hamoa-specific hardware blocks

The dtb-check CI subtracts errors present at base_sha from errors at head_sha to report only new errors. However, because this PR adds a new DTB target that was not built at base_sha, all errors from that DTB appear as "new" even though they are pre-existing in the source DTS files.

Fix:

No action required for this PR. The Makefile change is correct. The underlying DTS errors should be fixed separately:

1. CoreSight bindings — Add or update bindings for arm,coresight-cpu-funnel, arm,coresight-cpu-replicator, arm,coresight-cpu-tmc to accept these compatible strings, or change the DTS to use standard ARM CoreSight compatible strings with a fallback.

2. CTCU binding — Add Documentation/devicetree/bindings/.../qcom,hamoa-ctcu.yaml.

3. Video codec — Fix the qcom,x1e80100-iris binding to accept iommu-map and video-firmware, or update the DTS to use iommus instead of iommu-map and fix the cell count.

4. ETM nodes — Review and fix missing/incorrect properties in the ETM nodes per the ARM CoreSight ETM binding requirements.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/hamoa-advantech-som-db5830-el2.dtb

---

✅ tag-check

Status: PASS

The PR targets qcom-6.18.y (not qcom-next or qcom-next-staging), so the subject-prefix check is mandatory. The commit subject correctly starts with FROMLIST:, which is a valid prefix for patches posted to the mailing list.

---

Verdict

Merge as-is. The dtb-check failures are pre-existing errors in the base DTS files and do not block this PR. The Makefile change is correct and follows the existing pattern for EL2 overlay DTBs. The underlying DTS errors should be addressed in separate patches targeting the hamoa DTSI and x1-el2 overlay files.

[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	✅ 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	⚠️ skip	❌ 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	✅ 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	❌ Fail	✅ 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	❌ Fail	✅ 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 10cd091

• multimedia Job 262580 on hamoa-iot-evk
• multimedia Job 262573 on lemans-evk
• multimedia Job 262576 on monaco-evk
• multimedia Job 262578 on purwa-iot-evk
• multimedia Job 262577 on qcs615-ride
• multimedia Job 262571 on qcs6490-rb3gen2
• multimedia Job 262572 on qcs8300-ride
• multimedia Job 262574 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 262575 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1362

Job 262571 | SoC qcs6490-rb3gen2

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

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

  Case 1: Remoteproc Boot Failure — CDSP subsystem failed to boot

1. Failed case: Remoteproc Boot Failure — CDSP subsystem failed to boot
2. Root cause: CDSP remoteproc (remoteproc3) experienced an MMU fault during boot at 10.571s, followed by a watchdog timeout at 12.421s, resulting in a start timeout at 15.743s. The subsystem remained in offline state. This is a genuine remoteproc boot failure on qcs6490-rb3gen2, not related to the PR changes (which only add a DTS Makefile entry for a different platform: hamoa-advantech-som-db5830-el2).
3. Possible fix: This is a pre-existing platform/firmware issue unrelated to PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362. The PR only modifies the DTS Makefile for hamoa platform and does not touch any qcs6490 device trees, remoteproc drivers, or CDSP firmware. Recommend: (1) Check CDSP firmware version compatibility with kernel 6.18.52-03223-g425839c9ebec on qcs6490-rb3gen2; (2) Verify SMMU/IOMMU configuration for CDSP reserved memory regions in qcs6490 device tree; (3) Check if this failure reproduces on baseline (without PR) — if it does, this is a known platform issue and should not block the PR.
4. Detail analysis attachment: failed_case_job262571_1_detailed.md

  Case 2: GIC (Test Infrastructure Bug — Not a Kernel Issue)

1. Failed case: GIC (Test Infrastructure Bug — Not a Kernel Issue)
2. Root cause: GIC test script parsing bug at line 75 incorrectly reports offline CPUs (6-7) as failed when attempting to parse /proc/interrupts output; script assumes all possible CPUs are online and fails with "integer expected" error when encountering interrupt controller name string instead of CPU column data for offline CPUs.
3. Possible fix: Update GIC test script to check CPU online status before attempting to parse interrupt counts; skip offline CPUs or query /sys/devices/system/cpu/cpu*/online to filter the test set to only online CPUs.
4. Detail analysis attachment: failed_case_job262571_2_detailed.md

  Case 3: ** Probe_Failure_Check — Benign firmware load failures (non-PR-related)

1. Failed case: ** Probe_Failure_Check — Benign firmware load failures (non-PR-related)
2. Root cause: ** Two firmware load failures detected during boot on qcs6490-rb3gen2: (1) regulatory.db for cfg80211 (benign — WiFi functional tests passed), and (2) renesas_usb_fw.mem for xhci-pci-renesas USB controller (genuine but pre-existing platform limitation — Renesas USB controller firmware not included in rootfs). Neither failure is introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362, which only adds a DTS Makefile entry for hamoa-advantech-som-db5830-el2.dtb and does not modify qcs6490-rb3gen2 device tree, drivers, or firmware packaging.
3. Possible fix: Suppress the Probe_Failure_Check test failure as a false positive for this PR. The regulatory.db failure is benign (WiFi works). The xhci-pci-renesas failure is a known platform limitation (optional PCIe USB controller firmware not packaged in the test rootfs) and is unrelated to the PR changes. To permanently resolve: (1) add suppression rule for regulatory.db failures when WiFi functional tests pass, and (2) either package renesas_usb_fw.mem in the rootfs or suppress xhci-pci-renesas probe failures as expected for this platform configuration.
4. Detail analysis attachment: failed_case_job262571_3_detailed.md

  Case 4: ** Freq_Scaling

1. Failed case: ** Freq_Scaling
2. Root cause: ** Test infrastructure issue — the Freq_Scaling test script expects 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 only has 6 CPUs online (cpu0-cpu5) due to pre-existing PSCI boot failures for CPU6 and CPU7 (error -EINVAL). This is a known platform limitation, not a kernel regression.
3. Possible fix: Update the Freq_Scaling test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding an expected CPU count. The test should validate cpufreq interfaces only for CPUs that are actually present and online.
4. Detail analysis attachment: failed_case_job262571_4_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner marked the test suite as "unfinished" because result_parse.sh found leftover .res files (CPU_affinity.res and Freq_Scaling.res) in the working directory after all tests completed, triggering the "Marking unfinished test run as failed" error despite both tests having already executed and reported their results.
3. Possible fix: This is a LAVA test infrastructure issue, not a kernel regression. The PR changes (adding hamoa-advantech-som-db5830-el2.dtb to the Makefile) are unrelated to the failure. Re-trigger the CI job; if the issue persists, investigate the test runner's result_parse.sh script to ensure it properly cleans up or ignores already-processed .res files.
4. Detail analysis attachment: failed_case_job262571_5_detailed.md

Job 262572 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two probe failures detected: (1) xhci-hcd.0.auto probe failed with -ETIMEDOUT (-110) during hardware setup at boot time — a pre-existing qcs8300-ride platform issue unrelated to this PR's hamoa DTB Makefile change; (2) regulatory.db firmware load failed with -ENOENT (-2) — a known benign false positive suppressed because WiFi_OnOff and WiFi_Firmware_Driver tests passed, confirming WiFi functional.
3. Possible fix: The Probe_Failure_Check test failure is a false positive for this PR. The xhci-hcd probe failure is a pre-existing platform issue on qcs8300-ride (not introduced by this PR's Makefile-only change for hamoa). The regulatory.db failure is a known benign WiFi initialization race. Recommended action: (1) Suppress the regulatory.db failure per known-benign-failures Rule 2 (WiFi functional tests passed); (2) Investigate xhci-hcd.0.auto hardware timeout on qcs8300-ride separately as a platform-specific issue (check power/clock/reset sequencing for this USB controller, verify DT node configuration, and confirm hardware presence); (3) Approve this PR as the failures are not PR-introduced regressions.
4. Detail analysis attachment: failed_case_job262572_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing qcs8300-ride platform issue unrelated to PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362. The PR should not be blocked by this failure. For the platform issue: investigate qcs8300 device tree USB node configuration (DWC3 controller, USB PHY, clocks, resets, power domains) and ensure the DWC3 driver is enabled in the kernel config. Check for missing dwc3-qcom or USB PHY driver probe. If this is a known qcs8300-ride board limitation (e.g., USB host not supported on this board variant), mark the USBHost test as expected-fail or skip for this platform.
4. Detail analysis attachment: failed_case_job262572_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: /dev/kvm device node not created because KVM cannot initialize when Linux is running as a guest under the Gunyah hypervisor (nested virtualization not supported). The qcs8300-ride platform boots with Gunyah hypervisor active ("Hypervisor cold boot, version: gunyah-cdfb73831", "arm-pv: using stolen time PV"), which prevents KVM from creating /dev/kvm even though CONFIG_KVM=y.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR only adds DTS Makefile entries and does not modify KVM functionality. To enable KVM testing on qcs8300-ride: (1) boot the platform without Gunyah hypervisor (bare-metal mode), or (2) suppress KVM tests for platforms running under a hypervisor, or (3) implement nested virtualization support in Gunyah (long-term architectural change).
4. Detail analysis attachment: failed_case_job262572_3_detailed.md

  Case 4: KVM_EL2_DTB — /dev/kvm not available (system running at EL1)

1. Failed case: KVM_EL2_DTB — /dev/kvm not available (system running at EL1)
2. Root cause: The qcs8300-ride platform boots at EL1 (kernel message: "CPU: All CPU(s) started at EL1"), not EL2. KVM requires EL2 (hypervisor exception level) to create /dev/kvm. The Gunyah hypervisor is present but the kernel is running as a guest at EL1, preventing KVM initialization. This is a pre-existing platform configuration issue, not a regression introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (which only adds EL2 DTB support for the hamoa-advantech-som-db5830 platform).
3. Possible fix: This is not a PR-introduced failure. The qcs8300-ride platform requires an EL2-enabled DTB (similar to the x1-el2.dtbo overlay used for other platforms) to boot the kernel at EL2 and enable KVM functionality. Either: (1) exclude KVM tests from qcs8300-ride CI until EL2 DTB support is added for this platform, or (2) add qcs8300-ride-el2.dtb support to the Makefile following the same pattern as hamoa-iot-evk-el2.dtb and the newly added hamoa-advantech-som-db5830-el2.dtb.
4. Detail analysis attachment: failed_case_job262572_4_detailed.md

  Case 5: KVM_Infra — Test Infrastructure Limitation (Not a Kernel Regression)

1. Failed case: KVM_Infra — Test Infrastructure Limitation (Not a Kernel Regression)
2. Root cause: The qcs8300-ride platform runs under the Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-cdfb73831 perf"), which means the kernel is already running as a guest VM at EL1. KVM requires the kernel to run at EL2 (hypervisor mode) to create and manage virtual machines. Since the system is already virtualized under Gunyah, /dev/kvm cannot be created and KVM functionality is architecturally unavailable. This is not a kernel bug or PR-introduced regression—it's an expected platform limitation.
3. Possible fix: Mark KVM tests as SKIP (not FAIL) for qcs8300-ride and other Gunyah-based platforms in the LAVA test suite. Update the test runner to detect Gunyah presence (check for "Hypervisor cold boot" or gunyah reserved memory regions in dmesg) and automatically skip KVM tests with a clear message: "KVM tests skipped — platform running under Gunyah hypervisor (nested virtualization not supported)". The PR itself (adding EL2 overlay for hamoa platform) is unrelated to this failure and does not cause it.
4. Detail analysis attachment: failed_case_job262572_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: The test suite failed because three KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) could not run — /dev/kvm device node is not present on the qcs8300-ride target. The kernel has CONFIG_KVM enabled, but the system did not boot in hypervisor mode (no kvm-arm.mode=protected or kvm-arm.mode=nvhe in kernel command line). The PR adds EL2 DTB build support for hamoa-advantech-som-db5830 but does not affect qcs8300-ride boot configuration. This is a pre-existing platform configuration issue, not a regression introduced by the PR.
3. Possible fix: This is not a PR-introduced failure. The qcs8300-ride LAVA job definition needs to be updated to boot with an EL2-enabled DTB and include kvm-arm.mode=protected (or kvm-arm.mode=nvhe) in the kernel command line to enable KVM functionality. The PR itself is correct and does not require changes.
4. Detail analysis attachment: failed_case_job262572_6_detailed.md

Job 262573 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — False Positive (Suppressed Known Benign Failures)

1. Failed case: Probe_Failure_Check — False Positive (Suppressed Known Benign Failures)
2. Root cause: The Probe_Failure_Check test reported 3 firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv), but all are known benign false positives. WiFi_OnOff and BT_ON_OFF functional tests both passed, confirming that WiFi and Bluetooth firmware loaded successfully at runtime. The firmware load errors detected by Probe_Failure_Check are stale log entries (timestamp "Sep 10 19:22:23") from persistent system logs, not from the current boot (2026-10-29 09:29:47). The PR changes (adding EL2 DT overlay for hamoa-advantech-som-db5830) are unrelated to firmware loading on lemans-evk.
3. Possible fix: Apply LAVA Known Benign Failure Suppression Rules 2 and 3. The Probe_Failure_Check test should be enhanced to: (1) filter firmware load errors by timestamp to exclude stale entries from persistent logs, (2) suppress WiFi/BT firmware failures when corresponding functional ON/OFF tests pass, and (3) clear persistent system logs between test runs to prevent false positives from previous boots.
4. Detail analysis attachment: failed_case_job262573_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device (aa00000.video-codec) is not attached to any IOMMU group on lemans-evk, failing the test's critical master protection check, while all other critical masters (UFS, Ethernet, USB, GPU, Display) are correctly protected.
3. Possible fix: This is a pre-existing platform configuration issue on lemans-evk, not introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (which only adds a Makefile entry for hamoa-advantech-som-db5830-el2.dtb). Verify whether the video codec device tree node for lemans-evk includes the required iommus property; if missing, add it to the device tree. If the device is intentionally not IOMMU-protected on this platform, update the test's critical master list to exclude video codec for lemans-evk.
4. Detail analysis attachment: failed_case_job262573_2_detailed.md

  Case 3: 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 a LAVA test runner bug, not a kernel issue. The test infrastructure should either (1) delete .res files after processing them, or (2) track which results have been reported to avoid double-processing. Re-trigger the CI job — the kernel changes in PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (adding hamoa-advantech-som-db5830-el2.dtb Makefile entry) do not affect lemans-evk and are unrelated to this infrastructure failure.
4. Detail analysis attachment: failed_case_job262573_3_detailed.md

Job 262574 | SoC qcs9100-ride

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

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

  Case 1: ** Driver Probe Failure — Aquantia AQR115C PHY

1. Failed case: ** Driver Probe Failure — Aquantia AQR115C PHY
2. Root cause: ** The Aquantia AQR115C PHY driver probe fails on qcs9100-ride platform due to missing or malformed firmware-name device tree property in the PHY node at MDIO address stmmac-0:08, resulting in -EINVAL error. This is a pre-existing platform configuration issue unrelated to the PR, which only adds a hamoa platform EL2 DTB build target.
3. Possible fix: Add the required firmware-name property to the Aquantia AQR115C PHY device tree node in the qcs9100-ride DTS file (likely arch/arm64/boot/dts/qcom/qcs9100-ride.dts or included DTSI). Consult Aquantia AQR115C PHY driver documentation (drivers/net/phy/aquantia/) and device tree bindings to determine the correct firmware file name. If firmware is not required for this PHY configuration, modify the driver to make the property optional or provide a default.
4. Detail analysis attachment: failed_case_job262574_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is missing IOMMU group attachment on qcs9100-ride platform, indicating the device is either not present in the device tree, disabled, or missing the required iommus property for SMMU protection.
3. Possible fix: Add or enable the video codec device node in the qcs9100-ride device tree (arch/arm64/boot/dts/qcom/qcs9100-ride.dts or lemans-ride.dts) with the correct iommus property to attach it to an IOMMU group. This is a pre-existing platform configuration issue unrelated to the PR under test (which only adds EL2 overlay for hamoa platform).
4. Detail analysis attachment: failed_case_job262574_2_detailed.md

  Case 3: 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 the qcs9100-ride DTS file (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LPDDR4X_VER1.cld"; or the appropriate firmware file for this PHY variant), rebuild the DTB, and retest. This is a pre-existing device tree issue unrelated to PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362.
4. Detail analysis attachment: failed_case_job262574_3_detailed.md

  Case 4: ** KVM_Driver — KVM Host Initialization Failure

1. Failed case: ** KVM_Driver — KVM Host Initialization Failure
2. Root cause: ** Platform qcs9100-ride is not booting in EL2 (hypervisor exception level); kernel message "kvm [1]: HYP mode not available" at boot indicates CPU is running in EL1, preventing KVM from initializing and creating /dev/kvm device node.
3. Possible fix: Configure qcs9100-ride bootloader/firmware to boot kernel in EL2 mode, or add an EL2-enabled device tree overlay (similar to x1-el2.dtbo used by other platforms) and update the boot configuration to select it; verify EFI boot entry points to the EL2-enabled DTB.
4. Detail analysis attachment: failed_case_job262574_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM Host Unavailable (Platform Not Booted in EL2 Mode)

1. Failed case: KVM_EL2_DTB — KVM Host Unavailable (Platform Not Booted in EL2 Mode)
2. Root cause: qcs9100-ride board is not booted in EL2 (hypervisor) mode; KVM initialization reports "HYP mode not available" at kernel boot, preventing /dev/kvm device creation. This is a platform boot configuration issue, not a kernel driver failure.
3. Possible fix: This is not a PR-introduced regression (PR modifies hamoa platform, not qcs9100). To enable KVM on qcs9100-ride: (1) configure bootloader/ABL to boot kernel at EL2 instead of EL1, (2) ensure EFI boot entry uses an EL2-enabled DTB (e.g., qcs9100-ride-el2.dtb if available), (3) verify firmware supports EL2 boot mode. Alternatively, suppress KVM tests for qcs9100-ride in CI if EL2 boot is not supported on this platform.
4. Detail analysis attachment: failed_case_job262574_5_detailed.md

  Case 6: KVM_Infra — /dev/kvm not available (platform boot configuration issue)

1. Failed case: KVM_Infra — /dev/kvm not available (platform boot configuration issue)
2. Root cause: The qcs9100-ride platform booted in EL1 mode without hypervisor support enabled. Kernel message "kvm [1]: HYP mode not available" at boot time indicates the CPU did not enter EL2 (hypervisor mode), preventing KVM driver initialization and /dev/kvm device node creation. This is a platform firmware/bootloader configuration issue, not a kernel regression.
3. Possible fix: Configure the qcs9100-ride bootloader/firmware to boot the kernel in EL2 mode by selecting an EL2-enabled device tree blob (e.g., qcs9100-ride-el2.dtb if available) or enabling EL2 boot in the firmware configuration. Verify the EFI boot selection matches the intended EL2 configuration. This failure is unrelated to PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362, which only adds DTB build rules for the hamoa-advantech-som-db5830 board.
4. Detail analysis attachment: failed_case_job262574_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: qcs9100-ride platform boots kernel at EL1 without HYP mode available - KVM driver initialization fails with "HYP mode not available" because the bootloader/firmware does not enter kernel at EL2, and the platform lacks EL2 device tree overlay configuration.
3. Possible fix: Build and flash an EL2-enabled DTB for qcs9100-ride (similar to the hamoa-iot-evk-el2.dtb pattern already in the Makefile), or configure the bootloader to enter the kernel at EL2. This is a pre-existing platform limitation unrelated to the PR changes.
4. Detail analysis attachment: failed_case_job262574_7_detailed.md

Job 262575 | SoC shikra-iqs-evk

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

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

  Case 1: GIC Test Script Bug — False Failure

1. Failed case: GIC Test Script Bug — False Failure
2. Root cause: The GIC test script attempts to validate timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform only has 4 CPUs (0-3). The script fails at line 75 with bash integer comparison errors ([: GICv3: integer expected) when parsing non-existent CPU columns from /proc/interrupts, causing false test failures for CPUs 4-7 while CPUs 0-3 correctly pass.
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 assumption of 8 CPUs. The script should only validate timer counts for CPUs that actually exist on the target platform.
4. Detail analysis attachment: failed_case_job262575_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected pre-existing platform-specific probe failures unrelated to PR changes: (1) ucsi_ccg USB-C controller firmware missing (ccg_secondary.cyacd2), (2) tpm_tis_spi hardware timeout (-110), (3) regulatory.db WiFi firmware missing, (4) audio codec deferred probes (va_macro mclk clock, snd-sc8280xp cpu dai). PR only adds Makefile entry for hamoa-advantech-som-db5830-el2.dtb; test runs on shikra-iqs-evk — no code/DT overlap.
3. Possible fix: Suppress this test failure as pre-existing infrastructure/platform issue unrelated to PR. The PR changes (adding hamoa DTB Makefile entry) cannot affect shikra-evk probe behavior. To resolve underlying issues: (1) add ccg_secondary.cyacd2 firmware to rootfs, (2) investigate tpm_tis_spi hardware/DT configuration on shikra-evk, (3) add regulatory.db to rootfs, (4) fix audio codec clock/DT dependencies for shikra platform.
4. Detail analysis attachment: failed_case_job262575_2_detailed.md

  Case 3: ** PCIe — QPS615 Firmware/Driver Missing (Infrastructure Issue)

1. Failed case: ** PCIe — QPS615 Firmware/Driver Missing (Infrastructure Issue)
2. Root cause: ** The QPS615 PCIe-to-Ethernet bridge test failed because the required TC956X_Firmware_PCIeBridge.bin firmware file is not present in the rootfs firmware directories, and the tc956x_pcie_eth kernel driver module is not built or installed for this kernel. This is a pre-existing build/infrastructure configuration issue, not a regression introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (which only adds a hamoa DTB build rule and does not affect shikra-iqs-evk).
3. Possible fix: Enable CONFIG_TC956X_PCIE_ETH=m in the kernel config for shikra builds, ensure the tc956x_pcie_eth.ko module is installed to the rootfs, and package TC956X_Firmware_PCIeBridge.bin in /lib/firmware/ (or appropriate firmware directory) in the Yocto image recipe for shikra-iqs-evk.
4. Detail analysis attachment: failed_case_job262575_3_detailed.md

  Case 4: USBHost — USB Host Controller Driver Not Probing

1. Failed case: USBHost — USB Host Controller Driver Not Probing
2. Root cause: USB host controller drivers (dwc3-qcom and/or xhci-hcd) are not probing the USB platform devices (4c00000.usb, 4e00000.usb) on shikra-iqs-evk. Platform devices are registered and added to IOMMU groups, but no USB root hubs are exposed because the host controller drivers never bind. This is a pre-existing kernel configuration or device tree issue on this platform, not introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (which only modifies the DTS Makefile for a different board: hamoa-advantech-som-db5830-el2).
3. Possible fix: Verify that CONFIG_USB_DWC3_QCOM and CONFIG_USB_XHCI_HCD are enabled (built-in or as modules) in the kernel configuration for shikra-iqs-evk. If built as modules, ensure they are loaded during boot. Check the shikra device tree for correct USB controller node status (should be "okay" not "disabled"), compatible strings, and required properties (clocks, resets, power-domains, PHYs). This is a platform-specific configuration issue unrelated to the PR under test.
4. Detail analysis attachment: failed_case_job262575_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed at boot because HYP (Hypervisor/EL2) mode is not available on the shikra-iqs-evk platform. The kernel message "kvm [1]: HYP mode not available" at boot time (3.174109s) indicates the CPU is not running in a mode that supports virtualization, preventing the /dev/kvm device node from being created. This is a platform/firmware configuration issue, not a kernel bug introduced by the PR (which only adds a Makefile entry for a different board's EL2 DTB).
3. Possible fix: This failure is not caused by the PR under test (PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 adds EL2 DTB support for hamoa-advantech-som-db5830, not shikra-iqs-evk). The shikra-iqs-evk board requires either: (1) booting with an EL2-enabled device tree overlay (e.g., shikra-iqs-evk-el2.dtb if it exists) to configure the platform for hypervisor mode, or (2) updating the bootloader/firmware to boot the kernel at EL2 instead of EL1. If EL2 support is not available on this hardware revision, mark the KVM tests as expected-to-skip for this platform in the CI configuration.
4. Detail analysis attachment: failed_case_job262575_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on Shikra IQS EVK because the platform is running under Gunyah hypervisor which occupies EL2, preventing KVM from accessing HYP mode (kernel message: "kvm [1]: HYP mode not available" at boot time).
3. Possible fix: This is not a PR-introduced regression. The PR adds EL2 overlay support for Hamoa platform only. For Shikra platform: either (1) skip KVM tests in CI when Gunyah hypervisor is active, or (2) configure the platform to boot without Gunyah if KVM testing is required, or (3) use a platform that supports nested virtualization.
4. Detail analysis attachment: failed_case_job262575_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: /dev/kvm does not exist because the KVM driver could not initialize without EL2.
3. Possible fix: Add EL2 overlay support for shikra-iqs-evk by creating a shikra-iqs-evk-el2-dtbs target in arch/arm64/boot/dts/qcom/Makefile that combines the base shikra-iqs-evk.dtb with the x1-el2.dtbo overlay (following the pattern used for hamoa-iot-evk and hamoa-advantech-som-db5830 in the same Makefile). Update the LAVA job definition to flash and boot the EL2-enabled DTB (shikra-iqs-evk-el2.dtb) when running KVM tests on this board.
4. Detail analysis attachment: failed_case_job262575_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present on shikra-iqs-evk; kernel reports "kvm [1]: HYP mode not available" at boot, indicating the platform is not running in EL2 hypervisor mode or KVM support is not properly enabled in the boot configuration.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only adds DTS Makefile entries for hamoa-advantech-som-db5830-el2.dtb). The shikra-iqs-evk board requires either: (1) booting with an EL2-enabled DTB overlay (similar to the x1-el2.dtbo pattern used in the PR), or (2) bootloader/firmware configuration to enable HYP mode. Verify the LAVA job definition uses the correct DTB with EL2 overlay for shikra-iqs-evk if KVM testing is required on this platform.
4. Detail analysis attachment: failed_case_job262575_8_detailed.md

Job 262576 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: ath11k_pci WiFi driver probe failure (error -110 ETIMEDOUT) due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin on monaco-evk platform; this is a pre-existing platform issue unrelated to the PR which only modifies hamoa DTB Makefile entries.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk rootfs firmware directory, or update the firmware path in the device tree/driver configuration to match available firmware files.
4. Detail analysis attachment: failed_case_job262576_1_detailed.md

  Case 2: ** WiFi Driver Probe Failure — Missing Firmware Dependency

1. Failed case: ** WiFi Driver Probe Failure — Missing Firmware Dependency
2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required WCN6855 firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) is missing from the rootfs firmware directory, preventing MHI bus initialization and causing the probe to time out.
3. Possible fix: Install the missing WCN6855 firmware package in the Yocto build recipe or rootfs image. Add linux-firmware-ath11k or the vendor-specific firmware package to IMAGE_INSTALL in the Yocto layer, or manually place the firmware files in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ on the target rootfs.
4. Detail analysis attachment: failed_case_job262576_2_detailed.md

  Case 3: ** WiFi Driver Probe Failure — Missing Board-Specific Firmware

1. Failed case: ** WiFi Driver Probe Failure — Missing Board-Specific Firmware
2. Root cause: ** The ath11k_pci driver probe fails with -110 (ETIMEDOUT) on Monaco EVK because the required WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the test rootfs. The MHI subsystem cannot load the firmware (error -2: ENOENT), causing the power-up sequence to timeout and the probe to abort. This is a board-specific firmware packaging issue in the CI infrastructure, not a kernel regression.
3. Possible fix: Add the missing WCN6855 nfa765 board variant firmware files to the Monaco EVK test rootfs image. The required firmware package should include ath11k/WCN6855/hw2.1/nfa765/amss.bin and associated board files. This is a CI infrastructure fix, not a kernel code change. The PR under test (hamoa EL2 overlay) is unrelated and should not be blocked by this pre-existing Monaco EVK infrastructure issue.
4. Detail analysis attachment: failed_case_job262576_3_detailed.md

  Case 4: 0_qcom-next-ci-premerge-tests (LAVA Infrastructure False Positive)

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Infrastructure False Positive)
2. Root cause: LAVA dispatcher marked a completed test run as failed with "Marking unfinished test run as failed" despite the test runner explicitly signaling completion via <LAVA_TEST_RUNNER EXIT> and all individual tests finishing execution; this is a LAVA harness synchronization issue, not a kernel or PR-introduced failure.
3. Possible fix: Re-trigger the LAVA job; this is a known LAVA infrastructure race condition where the dispatcher's test completion detection logic fails to recognize a properly completed test run, typically occurring when the test runner exits immediately after the final test result is parsed.
4. Detail analysis attachment: failed_case_job262576_4_detailed.md

Job 262577 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure

1. Failed case: Probe_Failure_Check — cfg80211 regulatory.db firmware load failure
2. Root cause: The cfg80211 wireless regulatory subsystem attempted to load the regulatory.db firmware file during boot but failed with error -2 (ENOENT - file not found). This is a benign infrastructure issue: the regulatory.db file is not present in the rootfs firmware directory, but WiFi functionality is unaffected because cfg80211 falls back to compiled-in regulatory rules (X.509 certificates were successfully loaded). The Probe_Failure_Check test flagged this as a failure because it detected the firmware load error string in dmesg, but this is a false positive — WiFi is fully functional (WiFi_Firmware_Driver and WiFi_OnOff tests both passed).
3. Possible fix: This is a test infrastructure false positive, not a kernel regression. The PR (adding EL2 DTB overlay for hamoa-advantech-som-db5830) does not touch wireless, regulatory, or firmware loading code. Recommended action: Update the Probe_Failure_Check test to suppress regulatory.db firmware load failures when WiFi functional tests pass (similar to existing WiFi/BT firmware suppression rules), OR ensure regulatory.db is included in the rootfs firmware directory for completeness. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job262577_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation script incorrectly expects video codec child devices (video-decoder, video-encoder) to have separate IOMMU group attachments, but the qcs615 Venus video codec driver architecture uses a single parent device (aa00000.video-codec) with logical sub-devices that do not appear as independent platform devices in sysfs.
3. Possible fix: Update the smmu test script to remove the check for aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder IOMMU group attachments on qcs615-ride, or adjust the test to only validate the parent device attachment (which is correctly present in IOMMU group 7).
4. Detail analysis attachment: failed_case_job262577_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the bootloader skipped applying the EL2 device tree overlay on the qcs615-ride platform, preventing the kernel from entering HYP (EL2) mode. The bootloader log shows "HypDtFixupEventNotifyFunc: Dtb apply overlay skipped", and the kernel reports "kvm [1]: HYP mode not available" at boot. This is a pre-existing platform configuration issue on qcs615-ride, not introduced by the PR (which only adds EL2 overlay support for the hamoa platform).
3. Possible fix: Configure the qcs615-ride LAVA job to use an EL2-enabled device tree blob (e.g., qcs615-ride-el2.dtb) by ensuring the bootloader applies the x1-el2.dtbo overlay, or update the qcs615-ride DTS Makefile to include an EL2 combined DTB target similar to the hamoa platforms. Alternatively, exclude KVM tests from qcs615-ride CI runs until EL2 overlay support is added for this platform.
4. Detail analysis attachment: failed_case_job262577_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)
2. Root cause: QCS615 Ride boots under Gunyah hypervisor at EL1, not native EL2; KVM requires native EL2 (HYP mode) to create /dev/kvm device node. Kernel message "kvm [1]: HYP mode not available" at boot confirms KVM initialization failed because the CPU is not running at EL2.
3. Possible fix: This is not a PR-introduced regression — the PR only adds EL2 DTB support for hamoa platform. QCS615 Ride requires either: (1) boot configuration change to run kernel at native EL2 instead of under Gunyah, or (2) exclude KVM tests from QCS615 CI jobs when running under Gunyah hypervisor, as nested virtualization is not supported in this configuration.
4. Detail analysis attachment: failed_case_job262577_4_detailed.md

  Case 5: KVM_Infra — KVM Infrastructure Test Failure

1. Failed case: KVM_Infra — KVM Infrastructure Test Failure
2. Root cause: KVM cannot initialize on qcs615-ride because the Gunyah hypervisor (gunyah-cdfb73831) is already running at EL2, preventing KVM from accessing the required hypervisor privilege level. The kernel message "kvm [1]: HYP mode not available" confirms that KVM detected it cannot operate because EL2 is already occupied by the Gunyah hypervisor.
3. Possible fix: This is a platform configuration issue, not a kernel bug or PR-introduced regression. The qcs615-ride platform is configured to run with the Gunyah hypervisor at EL2, which is mutually exclusive with KVM operation. To enable KVM testing on this platform, either: (1) disable the Gunyah hypervisor in the boot configuration and reboot without hypervisor support, or (2) exclude KVM tests from the qcs615-ride CI test suite since this platform is designed for Gunyah virtualization, not KVM. The PR changes (adding EL2 overlay for hamoa platform) are unrelated to this failure.
4. Detail analysis attachment: failed_case_job262577_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 Ride platform does not support EL2 (hypervisor mode) — kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR only adds EL2 DTB build support for hamoa-advantech-som-db5830 (a different platform). No fix required for the PR; consider excluding KVM tests from QCS615 CI runs or marking them as expected failures on platforms without EL2 support.
4. Detail analysis attachment: failed_case_job262577_6_detailed.md

Job 262578 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark this test case as expected failure for purwa-evk platform until platform-specific fixes are applied: (1) Add PCIe PHY init sequences for 1bd0000/1bf8000 controllers or mark them as disabled in purwa-evk DT if ports are unpopulated; (2) Investigate QSEECOM secure world initialization order/dependencies; (3) Suppress regulatory.db false positive (already functional); (4) Add video codec IOMMU group attachment in purwa-evk DT. Since the PR only modifies Makefile for hamoa board EL2 overlay and does not touch purwa-evk configuration, these failures should not block PR merge.
4. Detail analysis attachment: failed_case_job262578_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test expects a video codec device at address aa00000.video-codec to be attached to an IOMMU group, but this device does not exist in the system (purwa-evk/iq-x5121-evk platform) — no kernel boot log entries, no platform device registration, and no IOMMU group attachment for this address, indicating either missing hardware support, disabled device tree node, or test configuration mismatch for this SoC.
3. Possible fix: Update the SMMU test configuration to exclude the aa00000.video-codec device check for purwa-evk platform, or verify whether the video codec hardware is present on this SoC and enable the corresponding device tree node if it exists but is disabled; this is a pre-existing platform/test configuration issue unrelated to PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 which only adds EL2 overlay support for a different platform (hamoa-advantech-som-db5830).
4. Detail analysis attachment: failed_case_job262578_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because the platform is not running in EL2 (hypervisor) mode — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: Boot the purwa-evk board with an EL2-enabled device tree overlay (e.g., purwa-iot-evk-el2.dtb) to enable hypervisor mode, or mark KVM tests as expected-to-skip on platforms without EL2 support in the LAVA test definition.
4. Detail analysis attachment: failed_case_job262578_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on purwa-evk because the Gunyah hypervisor is already running at EL2 (HYP mode), and both KVM and Gunyah require exclusive access to EL2 — they are mutually exclusive and cannot coexist on the same platform.
3. Possible fix: This is a platform configuration issue, not a kernel bug. Either: (1) Disable Gunyah hypervisor in the platform firmware/bootloader configuration if KVM support is required, or (2) Exclude KVM-related tests from the purwa-evk CI test suite since this platform is configured for Gunyah virtualization, not KVM virtualization.
4. Detail analysis attachment: failed_case_job262578_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize because the Gunyah hypervisor is running without EL2 virtualization support enabled for the host OS; the DTB overlay that enables KVM/EL2 mode was skipped during boot ("HypDtFixupEventNotifyFunc: Dtb apply overlay skipped"), and the PR only adds EL2 overlay support for hamoa-advantech-som-db5830, not for the purwa-evk board where this test is running.
3. Possible fix: This is not a PR-introduced regression. The PR adds EL2 overlay support for a different board (hamoa-advantech-som-db5830). To enable KVM on purwa-evk, either: (1) add an EL2 overlay DTB for purwa-iot-evk following the same pattern as the PR (create purwa-iot-evk-el2-dtbs combining purwa-iot-evk.dtb with x1-el2.dtbo), or (2) configure the LAVA job to flash and boot the correct EL2-enabled DTB for this board, or (3) exclude purwa-evk from KVM tests if EL2 support is not intended for this platform.
4. Detail analysis attachment: failed_case_job262578_5_detailed.md

  Case 6: KVM_Infra (Platform Hardware Limitation — Not PR-Related)

1. Failed case: KVM_Infra (Platform Hardware Limitation — Not PR-Related)
2. Root cause: The purwa-evk board does not support ARM Virtualization Extensions (EL2/HYP mode), as evidenced by the kernel message kvm [1]: HYP mode not available at boot time. CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware does not provide EL2 support, preventing /dev/kvm device creation.
3. Possible fix: This is not a bug to fix. The purwa-evk platform does not have virtualization hardware support. To resolve: (1) Skip KVM tests on purwa-evk in the CI test matrix, OR (2) Run KVM tests only on platforms with confirmed EL2/HYP support (e.g., boards with hypervisor firmware and EL2-enabled bootloaders), OR (3) If EL2 support is expected on purwa-evk, verify bootloader configuration and ensure the board is booting with hypervisor mode enabled (check ABL/UEFI settings and ensure EL2 is not being dropped to EL1 during boot).
4. Detail analysis attachment: failed_case_job262578_6_detailed.md

Job 262580 | SoC hamoa-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Two benign probe failures detected: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (secure app not available/in use), and (2) regulatory.db firmware load failed with -ENOENT (file missing from rootfs). Both are pre-existing platform configuration issues unrelated to the PR (which only adds a Makefile entry for a different board variant). Neither failure impacts system functionality — no deferred probes exist, and all functional tests (IPA, SMMU, rngtest) passed.
3. Possible fix: Suppress these known benign failures in the Probe_Failure_Check test by adding them to the test's allowlist/filter. For qcom_qseecom_uefisecapp: add -EBUSY probe failures to the benign list (secure app unavailability is expected on platforms without UEFI secure services). For regulatory.db: add this firmware to the rootfs image or suppress the error when CONFIG_CFG80211_CRDA_SUPPORT is disabled or regulatory DB is built-in. Alternatively, update the test to only fail on probe errors that result in deferred probes or functional test failures.
4. Detail analysis attachment: failed_case_job262580_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the iommus property to the aa00000.video-codec device node in arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts, referencing the appropriate SMMU phandle and stream ID. Example: iommus = <&apps_smmu 0x1800 0x0>; (stream ID must match hardware configuration).
4. Detail analysis attachment: failed_case_job262580_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 driver initialization failed with "HYP mode not available" because the board booted with the base DTB (hamoa-iot-evk.dtb) instead of the EL2-enabled DTB (hamoa-iot-evk-el2.dtb). The hypervisor (Gunyah) is running but KVM requires EL2 mode to be configured via the EL2 device tree overlay (x1-el2.dtbo), which was not applied during boot. This is NOT a PR-introduced regression — the PR only adds EL2 DTB support for a different board (hamoa-advantech-som-db5830); the test board (hamoa-iot-evk) already has EL2 support but the LAVA job did not flash/boot the EL2 DTB variant.
3. Possible fix: Update the LAVA job definition to flash and boot the EL2-enabled DTB (hamoa-iot-evk-el2.dtb) instead of the base DTB (hamoa-iot-evk.dtb) for all KVM-related test cases. The EL2 DTB is already available in the kernel tree (line 26 of the Makefile shows hamoa-iot-evk-el2-dtbs definition) and should be used when testing KVM functionality on hamoa-iot-evk.
4. Detail analysis attachment: failed_case_job262580_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM/EL2 Device Tree Overlay Not Applied

1. Failed case: KVM_EL2_DTB — KVM/EL2 Device Tree Overlay Not Applied
2. Root cause: The bootloader loaded the base hamoa-iot-evk.dtb instead of the EL2-enabled hamoa-iot-evk-el2.dtb, and the EL2 overlay (x1-el2.dtbo) was not applied at runtime (bootloader message: "HypDtFixupEventNotifyFunc: Dtb apply overlay skipped"). Without the EL2 overlay, the kernel cannot initialize KVM because HYP (Hypervisor/EL2) mode is unavailable, resulting in the kernel message "kvm [1]: HYP mode not available" and the absence of /dev/kvm.
3. Possible fix: Update the LAVA job definition for hamoa-evk to flash and boot the EL2-enabled device tree blob hamoa-iot-evk-el2.dtb instead of the base hamoa-iot-evk.dtb. This is a LAVA infrastructure configuration issue, not a kernel regression introduced by PR FROMLIST: arm64: dts: qcom: hamoa: Add EL2 overlay for hamoa-advantech-som-db5830 #1362 (which only adds EL2 support for a different board variant: hamoa-advantech-som-db5830).
4. Detail analysis attachment: failed_case_job262580_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM is unavailable because the hamoa-iot-evk board is running Linux as a guest under the Gunyah hypervisor (EL1), which prevents KVM from accessing EL2 (hypervisor mode) required for virtualization. The kernel message "kvm [1]: HYP mode not available" confirms Linux detected it's running under a hypervisor and cannot initialize KVM.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. Either: (1) run KVM tests only on boards configured to boot Linux at EL2 (bare-metal or with EL2 DTB overlay), or (2) skip KVM tests on boards running under Gunyah hypervisor. The PR is unrelated—it adds EL2 support for hamoa-advantech-som-db5830, while this test ran on hamoa-iot-evk.
4. Detail analysis attachment: failed_case_job262580_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: The EL2 device tree overlay was not applied during boot on the hamoa-iot-evk board, causing KVM to report "HYP mode not available" and preventing /dev/kvm device node creation, which is required for KVM virtualization infrastructure tests.
3. Possible fix: This is not a PR-introduced regression. The PR adds EL2 DTB support for hamoa-advantech-som-db5830 board, but the test ran on hamoa-iot-evk which already has EL2 DTB support (hamoa-iot-evk-el2.dtb exists in the Makefile). The LAVA job must be configured to flash and boot with the EL2-enabled DTB (hamoa-iot-evk-el2.dtb) instead of the base hamoa-iot-evk.dtb to enable KVM/virtualization tests. Update the LAVA job definition to use the correct EL2 DTB image for hamoa-iot-evk board.
4. Detail analysis attachment: failed_case_job262580_6_detailed.md