UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes

[Kriskura176767]

Flatten usb controller nodes and update to using latest bindings and flattened driver approach.

Tested this patch on CRD platform. For testing purpose, modified dr_mode property and added usb-role-switch property to the 3 super speed capable DRD controllers and valdiated both host and device mode. Also validated host mode on the multiport controller.

Link: https://lore.kernel.org/r/[email protected]

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

[Shiraz Hashim (shashim-quic)]

qcom-6.18.y-check
qcom-6.18.y-checkFailing after 2s — Change Requests Validation Check

check CR related failure.

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

[qcomlnxci]

Test jobs on 18b4ab2

• multimedia Job 210672 on hamoa-iot-evk
• multimedia Job 210676 on lemans-evk
• multimedia Job 210674 on monaco-evk
• multimedia Job 210680 on purwa-iot-evk
• multimedia Job 210677 on qcs615-ride
• multimedia Job 210673 on qcs6490-rb3gen2
• multimedia Job 210675 on qcs8300-ride
• multimedia Job 210678 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 210679 on shikra-iqs-evk

[qlijarvis]

PR #1004 — validate-patch

PR: #1004

Verdict	Issues	Detailed Report
❌	3	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/r/[email protected]
2. Lore link matches PR commits: No — PR modifies 15 files vs 17 in lore; 3 files missing, 1 file path differs
3. Upstream patch status: ✅ ACKed — Applied by Bjorn Andersson as commit ab826cc75a90c5524522f5c015b9a18ae8df86a6
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: #1004 - UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes
Upstream commit: https://lore.kernel.org/r/[email protected]
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	✅	UPSTREAM: prefix correctly added; base subject matches lore v2
Body preserves rationale	✅	Commit message body identical to lore patch
Fixes tag present/correct	N/A	No Fixes tag in upstream or PR (not a bugfix)
Authorship preserved	✅	From: Krishna Kurapati <[email protected]> matches lore
Backport note (if applicable)	N/A	Not a backport; merged upstream as-is

Diff

File	Status	Notes
hamoa-iot-som.dtsi	✅	Content identical; line numbers differ (context shift)
hamoa.dtsi	✅	Content identical; line numbers differ (context shift)
purwa-iot-som.dtsi	✅	Content identical; line numbers differ (context shift)
x1-asus-vivobook-s15	❌	File path mismatch: PR has x1e80100-asus-vivobook-s15.dts, lore has x1-asus-vivobook-s15.dtsi
x1-microsoft-denali.dtsi	❌	Missing from PR: Present in lore patch, absent from PR
x1e80100-medion-sprchrgd-14-s1.dts	❌	Missing from PR: Present in lore patch, absent from PR
Other 12 files	✅	Content identical; line numbers differ (context shift)

Issues

Critical: File list divergence

The PR modifies 15 files while the upstream lore patch modifies 17 files. Specifically:

1. Missing from PR (present in lore):

   • arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi
   • arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
   • arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts

2. Extra in PR (not in lore):

   • arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts

The PR appears to have been rebased onto a tree where:

• x1-asus-vivobook-s15.dtsi was renamed to x1e80100-asus-vivobook-s15.dts
• x1-microsoft-denali.dtsi and x1e80100-medion-sprchrgd-14-s1.dts do not exist or were removed

This is not a faithful representation of the upstream patch. The PR should either:

• Include all 17 files from the lore patch (if they exist in the target tree), or
• Document why certain files are omitted (e.g., "Files X, Y, Z not present in qcom-next at rebase time")

Upstream Patch Status

Commit	Community Verdict
arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes	✅ ACKed — Applied by Bjorn Andersson on 2026-03-23; merged as ab826cc75a90c5524522f5c015b9a18ae8df86a6

Evidence: Bjorn Andersson replied "Applied, thanks!" on 2026-03-23 22:05:53 -0500 with commit SHA ab826cc75a90c5524522f5c015b9a18ae8df86a6.

qcom-next Presence

Commit	Status
UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb	✅ Present in qcom-next — all checked added lines are present (per integration_presence_report.md)

Verdict

Do not merge without correction.

While the commit message is correct and the upstream patch has been accepted, the PR fails to faithfully represent the upstream patch due to missing files. The PR omits 3 files that were part of the upstream change and substitutes a different file path for one of them.

Root cause: The PR was likely rebased onto a qcom-next tree where:

1. Some device tree files from the upstream patch do not exist yet (possibly because prerequisite patches adding those files have not landed in qcom-next)
2. A file rename occurred (x1-asus-vivobook-s15.dtsi → x1e80100-asus-vivobook-s15.dts)

Recommended fix:

1. Verify whether x1-microsoft-denali.dtsi and x1e80100-medion-sprchrgd-14-s1.dts exist in the target qcom-next branch
2. If they exist, add the missing hunks to the PR
3. If they don't exist, add a note to the commit message: "Note: Changes to x1-microsoft-denali.dtsi and x1e80100-medion-sprchrgd-14-s1.dts omitted as these files are not yet present in qcom-next"
4. Verify the x1-asus-vivobook-s15.dtsi → x1e80100-asus-vivobook-s15.dts rename and confirm the hunk was correctly adapted

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/r/[email protected]
2. Lore link matches PR commits: No — PR modifies 15 files vs 17 in lore; 3 files missing, 1 file path differs
3. Upstream patch status: ✅ ACKed — Applied by Bjorn Andersson as commit ab826cc75a90c5524522f5c015b9a18ae8df86a6
4. PR present in qcom-next/topics: Yes — all checked added lines are present in qcom-next

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present

Final Status

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

[qlijarvis]

PR #1004 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Unevaluated properties: vdd-supply, vdda12-supply
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	Content mismatch with upstream link
tag-check	✅	Subject has valid UPSTREAM: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1004 — UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32702002788
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	Unevaluated properties: vdd-supply, vdda12-supply
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	Content mismatch with upstream link
tag-check	✅	Subject has valid UPSTREAM: prefix

---

❌ dtb-check

Root cause: The patch introduces vdd-supply and vdda12-supply properties on the multiport USB controller (usb@a400000) in x1p42100-lenovo-thinkbook-16.dts, but the binding schema qcom,snps-dwc3.yaml does not declare these properties for the qcom,x1e80100-dwc3-mp compatible.

Failure details:

x1p42100-lenovo-thinkbook-16.dtb: usb@a400000 (qcom,x1e80100-dwc3-mp): 
  Unevaluated properties are not allowed ('vdd-supply', 'vdda12-supply' were unexpected)
  from schema $id: http://devicetree.org/schemas/usb/qcom,snps-dwc3.yaml

Analysis:
The patch flattens USB controller nodes by moving properties from the child dwc3 node to the parent wrapper node. However, x1p42100-lenovo-thinkbook-16.dts has vdd-supply and vdda12-supply properties on the multiport controller (usb@a400000), and the binding schema does not allow these properties for the multiport variant (qcom,x1e80100-dwc3-mp).

This is a genuine new error introduced by the flattening refactor. The properties were previously on the child node (which may have had a different compatible or looser validation), and moving them to the parent exposed the schema mismatch.

Fix:
Two options:

1. Update the binding schema (preferred if these properties are valid for multiport controllers):

   • Add vdd-supply and vdda12-supply to the properties: section of Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml for the qcom,x1e80100-dwc3-mp compatible.
   • Submit the binding update as a separate patch before this DTS change.

2. Remove the properties from the DTS (if they are not needed for multiport):

   • Remove vdd-supply and vdda12-supply from arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts for the usb@a400000 node.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dtb

---

❌ check-patch-compliance

Root cause: The patch content in the PR differs from the upstream patch at the provided lore link.

Failure details:

Checking commit: UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes
Change is different from the one mentioned in Link

Analysis:
The checker fetched the upstream patch from:

https://lore.kernel.org/r/[email protected]

and found that the PR's patch content does not match the upstream version. This can happen if:

1. The PR includes additional changes not present upstream (e.g., extra board files, additional properties).
2. The upstream patch was updated after the link was added to the commit message.
3. Context lines shifted due to a different base.

Fix:
Fetch the upstream patch and compare:

b4 am --single-message -C -l -3 https://lore.kernel.org/r/[email protected] -o /tmp/out
git format-patch -1 18b4ab24ae10 --stdout > /tmp/pr.patch
diff <(awk '/^diff/,/^--$/' /tmp/pr.patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

If the difference is:

• Context-only shift → Not a real issue; the checker has a known limitation with context diffs.
• Legitimate adaptation (e.g., additional board files) → Document the delta in the commit message: "Adapted for qcom-6.18.y: added x1p42100-lenovo-thinkbook-16.dts changes."
• Missing hunk → Add the missing change.
• Extra hunk → Remove it or attribute it separately.

If the upstream patch was updated after the link was added, update the Link: trailer to point to the correct version.

---

Verdict

2 blockers must be fixed before merge:

1. dtb-check failure — vdd-supply and vdda12-supply are not allowed by the binding schema for qcom,x1e80100-dwc3-mp. Either update the binding schema to allow these properties or remove them from the DTS.

2. check-patch-compliance failure — The patch content differs from the upstream link. Verify the delta and either update the commit message to document the adaptation or align the patch with upstream.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1004

Job 210672 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected 3 pre-existing probe/firmware errors during boot: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (secure world resource conflict), (2) qcom-spmi-lpg probe failed with -EINVAL (DT configuration issue for PMIC PWM), and (3) regulatory.db firmware missing (-ENOENT). None are related to the PR which only modifies USB controller DT nodes.
3. Possible fix: These are pre-existing platform issues unrelated to the PR. The PR can be merged as-is. To fix the underlying issues: (1) investigate QSEE secure app initialization order/conflicts, (2) audit PMIC PWM DT node properties in hamoa.dtsi for the c42d000.spmi:pmic@1:pwm device, and (3) add regulatory.db to the rootfs firmware directory if wireless regulatory compliance is required.
4. Detail analysis attachment: failed_case_job210672_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 hamoa-evk platform, causing the SMMU test to fail its critical master protection check.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (USB controller flattening). The video codec device tree node needs an iommus property to attach it to an IOMMU group. Add iommus = <&apps_smmu VIDEO_CODEC_SID 0x0>; to the video-codec@aa00000 node in arch/arm64/boot/dts/qcom/hamoa.dtsi (replace VIDEO_CODEC_SID with the correct stream ID from hardware documentation).
4. Detail analysis attachment: failed_case_job210672_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because HYP (hypervisor) mode is not available on the hamoa-evk platform — kernel logged "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation; CONFIG_KVM is enabled but the hardware/firmware does not support EL2 virtualization or the hypervisor (Gunyah) has reserved EL2 exclusively.
3. Possible fix: This is a platform limitation, not a kernel regression introduced by the PR (which only modifies USB DTS nodes). The test expectation is incorrect for hamoa-evk. Either: (1) exclude KVM tests from hamoa-evk CI runs since the platform does not support nested virtualization when running under Gunyah hypervisor, or (2) update the test to SKIP instead of FAIL when CONFIG_KVM is enabled but /dev/kvm is unavailable due to "HYP mode not available".
4. Detail analysis attachment: failed_case_job210672_3_detailed.md

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

1. Failed case: KVM Driver Initialization Failure — HYP mode not available
2. Root cause: The hamoa-evk platform bootloader/firmware does not enable EL2 (Hypervisor mode) for the Linux kernel, causing KVM driver initialization to fail with "HYP mode not available" and preventing /dev/kvm device node creation.
3. Possible fix: Configure the hamoa-evk bootloader to boot Linux at EL1 with EL2 available (non-VHE or VHE mode). This requires bootloader/ABL configuration changes to enable hypervisor mode, or verify that the platform's TrustZone/hypervisor firmware allows EL2 access to the kernel. This is a platform configuration issue unrelated to PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (USB DTS changes).
4. Detail analysis attachment: failed_case_job210672_4_detailed.md

  Case 5: KVM_Infra — KVM/ARM Virtualization Not Available (Platform Limitation)

1. Failed case: KVM_Infra — KVM/ARM Virtualization Not Available (Platform Limitation)
2. Root cause: KVM ARM virtualization is not available on hamoa-evk because the platform does not support EL2 (Hypervisor mode). The kernel log shows "kvm [1]: HYP mode not available" at boot time (line 3829), indicating the CPU is not running at EL2 or EL2 is disabled by the bootloader/firmware. CONFIG_KVM is enabled in the kernel configuration, but the KVM ARM driver initialization fails because the hardware prerequisite (EL2 support) is not met. This is a platform/firmware limitation, not a kernel regression.
3. Possible fix: This is not a bug — it is expected behavior for hamoa-evk platform. The KVM_Infra, KVM_Driver, and KVM_EL2_DTB test cases should be marked as "skip" or "not applicable" for hamoa-evk in the LAVA test suite configuration, as this platform does not support ARM virtualization (EL2/HYP mode). If EL2 support is required, verify the bootloader/firmware configuration and ensure the CPU is configured to enter the kernel at EL2; otherwise, accept this as a platform limitation and exclude KVM tests from hamoa-evk CI runs.
4. Detail analysis attachment: failed_case_job210672_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 definition marked as failed due to "unfinished test run" after multiple individual test failures: (1) Video codec device aa00000.video-codec missing IOMMU group attachment causing smmu test failure, (2) /dev/kvm device node absent causing three KVM-related test failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra), and (3) probe failures for qcom_qseecom_uefisecapp (-EBUSY), qcom-spmi-lpg (-EINVAL), and regulatory.db firmware (-ENOENT). The PR changes USB DT nodes only and does not touch video codec, KVM, or the failing probe paths—these are pre-existing platform/configuration issues unrelated to the USB controller flattening changes.
3. Possible fix: The test failures are not PR-introduced regressions. For the video codec IOMMU issue: verify the video codec DT node includes the correct iommus property and that the SMMU driver has probed successfully for that IOMMU instance. For the KVM failures: ensure CONFIG_KVM is built as a module (=m) or verify the kvm.ko module is loaded; if CONFIG_KVM=y, check for boot-time KVM initialization errors in dmesg. For probe failures: these are known benign failures on this platform (qseecom -EBUSY is expected when secure app is already loaded; lpg -EINVAL and regulatory.db -ENOENT are non-critical). Re-run the test suite on a baseline (pre-PR) kernel to confirm these failures exist independently of the PR changes.
4. Detail analysis attachment: failed_case_job210672_6_detailed.md

Job 210673 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Audio codec deferred probe (pre-existing platform issue)

1. Failed case: Probe_Failure_Check — Audio codec deferred probe (pre-existing platform issue)
2. Root cause: Audio codec devices (3240000.codec, 3250000.soundwire, 3370000.codec) and sound card are stuck in deferred probe waiting for pinctrl supplier states (wsa-swr-data-state, dmic23-data-state) from pinctrl@33c0000, which itself is deferred. This is a pre-existing qcs6490-rb3gen2 platform issue unrelated to the PR, which only modifies USB nodes on hamoa/purwa/x1e platforms.
3. Possible fix: This is a false positive test failure. The PR does not touch qcs6490-rb3gen2 device trees and cannot have caused this audio subsystem issue. The test should be updated to exclude known benign deferred probe patterns for non-critical audio devices on rb3gen2, or the underlying qcs6490 audio/pinctrl device tree should be fixed to resolve the circular dependency. Recommend merging the PR as the failure is unrelated.
4. Detail analysis attachment: failed_case_job210673_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB controller on qcs6490-rb3gen2 is configured in gadget/device mode (dr_mode=peripheral or otg with gadget active), not host mode. Test expects USB host functionality but no USB host controller driver (xhci-hcd/dwc3-host) is active. Boot log shows "Hardware activated USB gadget" target reached, confirming gadget mode. No USB devices can be enumerated because the controller is not operating as a host.
3. Possible fix: This is a board configuration issue unrelated to PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (which only modifies x1e/hamoa/purwa device trees). The test failure is expected on this board configuration. To resolve: (1) Update the qcs6490-rb3gen2 device tree to set dr_mode = "host" for the USB controller intended for host operation, or (2) Suppress this test for boards configured in gadget-only mode, or (3) Connect the board to a host PC and validate gadget functionality instead.
4. Detail analysis attachment: failed_case_job210673_2_detailed.md

  Case 3: KVM_Driver (Platform Limitation — HYP mode not available)

1. Failed case: KVM_Driver (Platform Limitation — HYP mode not available)
2. Root cause: The qcs6490-rb3gen2 platform does not boot in EL2 (Hypervisor mode), preventing KVM initialization. Kernel log shows "kvm [1]: HYP mode not available" at boot time (line 2349, timestamp 3.401114s). CONFIG_KVM is enabled and the module loads, but cannot create /dev/kvm because the CPU is not running in hypervisor mode.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The qcs6490-rb3gen2 board firmware/bootloader does not enable EL2 mode. To enable KVM support: (1) Update the board's bootloader/firmware to boot the kernel in EL2 mode, or (2) Exclude KVM tests from the CI test suite for this platform, as KVM functionality is not supported on this hardware configuration.
4. Detail analysis attachment: failed_case_job210673_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression. The test suite should exclude KVM tests for platforms configured with Gunyah hypervisor. Recommended action: Add platform-specific test filtering to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests on qcs6490-rb3gen2 when Gunyah is active, or reconfigure the platform to boot without Gunyah if KVM functionality is required for testing.
4. Detail analysis attachment: failed_case_job210673_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the board is running under Gunyah hypervisor at EL2, preventing KVM from accessing hypervisor mode. Log evidence: kvm [1]: HYP mode not available (line 2849) and Hypervisor cold boot, version: gunyah-1cb9db980 (line 2222).
3. Possible fix: This is expected behavior, not a bug. To enable KVM testing on this platform: (1) boot without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for qcs6490-rb3gen2, or (3) use a different board that boots Linux directly at EL2 without a pre-existing hypervisor.
4. Detail analysis attachment: failed_case_job210673_5_detailed.md

  Case 6: KVM Infrastructure Unavailable — Platform Configuration Limitation

1. Failed case: KVM Infrastructure Unavailable — Platform Configuration Limitation
2. Root cause: KVM initialization failed with "HYP mode not available" because qcs6490-rb3gen2 platform runs Gunyah hypervisor which occupies EL2, preventing KVM from accessing HYP mode required for virtualization.
3. Possible fix: This is a known platform limitation, not a regression. Either: (1) Skip KVM tests on qcs6490-rb3gen2 in CI (recommended), or (2) Use a different test platform without Gunyah hypervisor for KVM validation, or (3) Configure firmware to boot without Gunyah if KVM testing is required on this platform.
4. Detail analysis attachment: failed_case_job210673_6_detailed.md

Job 210674 | SoC monaco-evk

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

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

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

1. Failed case: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)
2. Root cause: The Probe_Failure_Check test detected 6 probe/firmware errors on monaco-evk (qcs8300): (1) cpufreq-dt probe failed with -EEXIST (error -17, device already exists — benign duplicate registration), (2-3) Bluetooth firmware files missing (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv — error -2, but BT_ON_OFF test PASSED indicating BT functional), (4) regulatory.db firmware missing (error -2 — benign, regulatory framework fallback works), (5) WiFi firmware missing (ath11k/WCN6855/hw2.1/nfa765/amss.bin — error -2), and (6) ath11k_pci probe failed with -ETIMEDOUT (error -110, MHI power-up timeout). These failures are not caused by the PR, which only modifies USB DT nodes for different SoCs (hamoa/purwa/x1e80100), not monaco/qcs8300. The monaco-evk platform has pre-existing firmware packaging and WiFi hardware initialization issues unrelated to this USB DT refactoring patch.
3. Possible fix: Mark Probe_Failure_Check as a known platform issue for monaco-evk and exclude from PR blocking criteria. For the underlying issues: (1) cpufreq-dt error -17 is benign (duplicate probe); (2-3) BT firmware errors are false positives (BT_ON_OFF passed — suppress per lava-known-benign-failures.md Rule 3 logic); (4) regulatory.db is optional; (5-6) WiFi failures require: add missing ath11k firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware package, and investigate MHI bus power-up timeout (check PCIe link training, power sequencing, and clocks for the WCN6855 WiFi module on monaco-evk hardware).
4. Detail analysis attachment: failed_case_job210674_1_detailed.md

  Case 2: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)

1. Failed case: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)
2. Root cause: The ath11k_pci driver probe failed with -ETIMEDOUT because the MHI (Modem Host Interface) firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. The MHI bus failed to load the firmware (error -2 / -ENOENT), causing the MHI power-up to timeout after waiting for firmware download, which cascaded into the ath11k_pci probe failure with -110.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/. This is a rootfs packaging issue, not a kernel regression. The firmware should be included in the linux-firmware package or the board-specific firmware overlay for Monaco EVK.
4. Detail analysis attachment: failed_case_job210674_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)

1. Failed case: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110 (ETIMEDOUT)
2. Root cause: Missing Monaco-specific WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs. The ath11k_pci driver detected WCN6855 hw2.1 hardware and attempted to load the Monaco-variant firmware from the nfa765 subdirectory, but the file was not present (error -2, ENOENT), causing MHI power-up to timeout (-110) and probe to fail.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). This is a Monaco EVK platform-specific firmware variant that must be included in the Yocto build recipe or manually installed in the rootfs for this SoC.
4. Detail analysis attachment: failed_case_job210674_3_detailed.md

  Case 4: Driver Probe Failure — ath11k_pci WiFi driver

1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (MHI firmware load failed with error -2 ENOENT). This is a pre-existing infrastructure issue on the monaco-evk platform, not introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 which only modifies USB DTS nodes for hamoa/purwa platforms.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). This firmware should be included in the linux-firmware package or the platform-specific firmware bundle for monaco-evk. Alternatively, if this WiFi hardware is not present or not intended to be used on monaco-evk, update the device tree to disable the ath11k_pci node or remove it from the test expectations.
4. Detail analysis attachment: failed_case_job210674_4_detailed.md

Job 210675 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check — Firmware Load Failure (False Positive)

1. Failed case: ** Probe_Failure_Check — Firmware Load Failure (False Positive)
2. Root cause: ** The regulatory.db firmware file is missing from the rootfs image, triggering a -ENOENT error during cfg80211 initialization; however, cfg80211 successfully falls back to its compiled-in regulatory database, and WiFi operates normally (all WiFi functional tests passed).
3. Possible fix: This is a test infrastructure false positive, not a kernel bug. Either: (1) add regulatory.db to the rootfs image build recipe, or (2) update the Probe_Failure_Check test to suppress benign firmware load failures when the corresponding subsystem functional tests pass (similar to existing WiFi/BT firmware suppression rules in lava-known-benign-failures.md).
4. Detail analysis attachment: failed_case_job210675_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 not a kernel bug requiring a code fix. The test failure is due to missing test hardware. Recommended actions: (1) Verify that a USB device (e.g., USB flash drive, keyboard, or hub with downstream devices) is physically connected to the qcs8300-ride board's USB host port in the LAVA lab; (2) If the board does not have external USB connectivity in the lab setup, mark this test as SKIP for qcs8300-ride or adjust the test to verify only that the USB host controller is functional (driver loaded, root hub enumerated) rather than requiring external devices; (3) Confirm this is not a PR regression by checking if the same test passes on the baseline (pre-PR) build on the same board.
4. Detail analysis attachment: failed_case_job210675_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver cannot initialize because the system is running under Gunyah hypervisor which owns EL2 (hypervisor mode). KVM requires direct EL2 access to function. The kernel boots at EL1 (guest mode) under Gunyah, preventing KVM from accessing the necessary hypervisor resources. CONFIG_KVM=y is enabled but the driver silently skips initialization when EL2 is unavailable.
3. Possible fix: Suppress the KVM test when a hypervisor is detected by adding a pre-flight check: if dmesg | grep -qi "Hypervisor\|Gunyah"; then echo "[SKIP] System running under hypervisor"; exit 0; fi. Alternatively, configure a separate LAVA job that boots the kernel bare-metal (without Gunyah) for KVM testing, or enable nested virtualization in Gunyah if the qcs8300 SoC supports ARMv8.3-NV.
4. Detail analysis attachment: failed_case_job210675_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: ** KVM driver failed to initialize on qcs8300-ride (Monaco) platform because the kernel is not running with EL2 (hypervisor) access or VHE (Virtualization Host Extensions) is not enabled by firmware. CONFIG_KVM is enabled in kernel config, but KVM's ARM64 architecture initialization silently fails when EL2/VHE is unavailable, resulting in no /dev/kvm device node creation and no error messages in kernel log.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on qcs8300-ride: (1) Verify bootloader/firmware enables EL2 and VHE for all CPU cores; (2) Ensure uniform virtualization feature support across heterogeneous big.LITTLE cores (CPU feature sanity checks show variation); (3) If firmware does not support EL2/VHE, KVM cannot function on this platform - mark KVM tests as "not applicable" for qcs8300-ride in CI configuration.
4. Detail analysis attachment: failed_case_job210675_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver cannot initialize because the system is running under Gunyah hypervisor (EL2 already occupied); /dev/kvm device node is not created despite CONFIG_KVM=y because KVM requires exclusive EL2 access for nested virtualization, which is not available on QCS8300 Ride platform running Gunyah.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR only modifies USB DT nodes and does not touch KVM or virtualization code. To enable KVM on this platform: (1) verify hardware supports nested virtualization under Gunyah, (2) enable nested virtualization in Gunyah hypervisor configuration if supported, or (3) exclude KVM tests from the CI test suite for platforms running under Gunyah hypervisor where nested virtualization is not enabled.
4. Detail analysis attachment: failed_case_job210675_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm is not created at runtime despite CONFIG_KVM=y being enabled in the kernel configuration on qcs8300-ride (Monaco) platform — this is a pre-existing platform configuration or KVM driver initialization issue unrelated to the PR under test (PR only modifies USB DT nodes for hamoa/purwa/x1e platforms, not qcs8300).
3. Possible fix: Investigate why the KVM driver does not create /dev/kvm on qcs8300-ride: check for missing KVM ARM64 initialization, EL2 hypervisor mode availability, or platform-specific KVM enablement requirements; verify kernel boot log for KVM initialization messages or errors; confirm the platform supports virtualization extensions and EL2 is accessible; if qcs8300-ride does not support KVM, mark KVM tests as SKIP for this platform in the CI test matrix.
4. Detail analysis attachment: failed_case_job210675_6_detailed.md

Job 210676 | SoC lemans-evk

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

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

  Case 1: ** Board Hang — PCIe initialization freeze (lemans-evk platform issue)

1. Failed case: ** Board Hang — PCIe initialization freeze (lemans-evk platform issue)
2. Root cause: ** lemans-evk board hangs completely during PCIe host bridge initialization at controller 1c10000. Last kernel message is [ 6.479320][ T64] qcom-pcie 1c10000.pcie: host bridge /pcie@1c10000 ranges: followed by complete system freeze with no further output. This is a pre-existing platform-specific issue unrelated to the PR, which only modifies USB DT nodes on hamoa/purwa/x1 platforms.
3. Possible fix: This is a pre-existing lemans-evk platform issue, not a PR regression. Recommended actions: (1) Disable PCIe controller 1c10000 in lemans-evk device tree by setting status = "disabled"; to allow boot to complete for USB testing. (2) File a separate bug for lemans-evk PCIe hang investigation with platform team. (3) For this PR validation, exclude lemans-evk from test matrix or use a lemans-evk build with PCIe disabled, as the PR changes are USB-specific and do not affect lemans platform.
4. Detail analysis attachment: failed_case_job210676_1_detailed.md

  Case 2: Board Hang — PCIe driver initialization hang

1. Failed case: Board Hang — PCIe driver initialization hang
2. Root cause: System hung during qcom-pcie driver probe for controller 1c10000.pcie on lemans-evk; last kernel message at 6.479s shows "host bridge /pcie@1c10000 ranges:" followed by complete loss of console output, indicating the PCIe driver entered an infinite loop or deadlock during resource enumeration or link training.
3. Possible fix: This is a pre-existing kernel/driver issue unrelated to the PR (PR only modifies USB DT nodes for hamoa/purwa/x1 platforms, not lemans-evk PCIe). Re-trigger the CI job; if the hang persists, disable PCIe controller 1c10000 in lemans-evk DT (status = "disabled") or add a kernel command-line parameter to skip PCIe enumeration (pcie_ports=compat or pci=nomsi) to allow boot to complete for USB testing.
4. Detail analysis attachment: failed_case_job210676_2_detailed.md

  Case 3: minimal-boot — System hang during PCIe initialization

1. Failed case: minimal-boot — System hang during PCIe initialization
2. Root cause: System stopped producing console output after PCIe controller initialization began at kernel timestamp [6.479320], causing LAVA login-action to timeout after 185 seconds waiting for a login prompt that never appeared.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR (PR only modifies hamoa/purwa USB DTS, not lemans PCIe). Re-trigger the CI job to confirm reproducibility. If the hang persists, investigate PCIe driver initialization on lemans-evk — check for known PCIe link training timeouts, firmware dependencies, or hardware-specific issues on this platform. Consider adding debug logging to qcom-pcie driver probe path or increasing LAVA job timeout as a temporary workaround.
4. Detail analysis attachment: failed_case_job210676_3_detailed.md

  Case 4: ** Boot Hang — System freeze during PCIe initialization

1. Failed case: ** Boot Hang — System freeze during PCIe initialization
2. Root cause: ** System hung completely at ~6.5 seconds into boot during qcom-pcie driver initialization on lemans-evk; last kernel message was PCIe host bridge enumeration for controller 1c10000.pcie, after which no further console output appeared despite LAVA sending multiple prompts over 200+ seconds, indicating a complete system freeze (not a login configuration issue).
3. Possible fix: This is a pre-existing platform/driver issue unrelated to the PR (PR only modifies USB DT nodes for hamoa/purwa/x1e platforms, not lemans-evk PCIe). Re-trigger the CI job; if the hang recurs consistently on lemans-evk, investigate the qcom-pcie driver probe sequence for 1c10000.pcie controller — check for missing clocks/regulators, PHY initialization failures, or firmware dependencies that may cause the driver to spin indefinitely without timeout.
4. Detail analysis attachment: failed_case_job210676_4_detailed.md

Job 210677 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — regulatory.db firmware load failure (benign)

1. Failed case: Probe_Failure_Check — regulatory.db firmware load failure (benign)
2. Root cause: The cfg80211 wireless regulatory subsystem attempted to load the optional regulatory.db firmware file during boot, which is not present in the rootfs. This is a benign failure because: (1) cfg80211 falls back to compiled-in regulatory certificates (X.509 certs loaded successfully), (2) all WiFi functional tests passed (WiFi_OnOff, WiFi_Firmware_Driver), (3) all Bluetooth functional tests passed (BT_ON_OFF, BT_FW_KMD_Service, BT_SCAN), and (4) the error is unrelated to the PR changes (USB DTS modifications only).
3. Possible fix: This is a false positive in the Probe_Failure_Check test. The test should be updated to exclude regulatory.db firmware load failures when WiFi/BT functional tests pass, or the rootfs should include the regulatory.db file. No kernel fix is required. The PR can proceed — this failure is pre-existing infrastructure noise unrelated to the USB DTS changes.
4. Detail analysis attachment: failed_case_job210677_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expectation mismatch — the SMMU test script expects video-decoder and video-encoder child devices (aa00000.video-codec:video-decoder, aa00000.video-codec:video-encoder) to have individual IOMMU group attachments, but on qcs615-ride these are not instantiated as separate platform devices with their own IOMMU groups; the parent video-codec device (aa00000.video-codec) is correctly attached to IOMMU group 7 and SMMU hardware is functioning normally with no faults or errors.
3. Possible fix: Update the SMMU test script to recognize that video-decoder and video-encoder may be child components of the parent video-codec device rather than separate platform devices, or adjust the qcs615 device tree to instantiate these as separate platform devices if individual IOMMU group attachment is a platform requirement; this is a pre-existing platform/test configuration issue not introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (which only modifies USB nodes on different platforms).
4. Detail analysis attachment: failed_case_job210677_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 QCS615: (1) Disable Gunyah hypervisor in the boot firmware/ABL configuration, OR (2) Mark KVM tests as "not applicable" for QCS615 Ride in the LAVA test suite, OR (3) Use a different platform that boots without a hypervisor for KVM testing. The PR does not introduce this issue (USB DTS changes only) and should not be blocked by this test failure.
4. Detail analysis attachment: failed_case_job210677_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 failed to initialize because the QCS615 platform kernel booted at EL1 instead of EL2; ARM64 KVM requires EL2 (hypervisor mode) to provide virtualization support, and the bootloader did not enter the kernel at EL2 or a secure hypervisor is blocking EL2 access.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on QCS615: (1) Configure the bootloader (ABL/UEFI) to enter the kernel at EL2 instead of EL1, or (2) if a secure hypervisor is present, ensure it exposes EL2 virtualization extensions to the kernel (e.g., via VHE or nested virtualization support). The PR patch does not affect this — the failure is pre-existing on this SoC/board configuration.
4. Detail analysis attachment: failed_case_job210677_4_detailed.md

  Case 5: KVM_Infra — /dev/kvm device node not created

1. Failed case: KVM_Infra — /dev/kvm device node not created
2. Root cause: KVM driver initialization failed during boot because the QCS615 platform does not support EL2/HYP mode, as indicated by the kernel message "kvm [1]: HYP mode not available" at boot time. The /dev/kvm device node is never created because KVM requires EL2 hypervisor support, which is not available on this SoC/board configuration.
3. Possible fix: This is not a PR-introduced regression — the PR modifies USB device tree nodes for hamoa/purwa (X1E platforms) and is unrelated to QCS615 or KVM. The KVM tests should be skipped or marked as expected-fail for QCS615-ride in the LAVA test suite, as this platform does not have the hardware capability (EL2/HYP mode) required for KVM virtualization. Update the test suite configuration to exclude KVM tests for platforms without EL2 support.
4. Detail analysis attachment: failed_case_job210677_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: Mark KVM_Infra test as SKIP (not FAIL) on QCS615 and other platforms without virtualization support. Update LAVA test definition to check for /dev/kvm presence before running the test, or add platform-specific test exclusions for non-virtualization-capable SoCs.
4. Detail analysis attachment: failed_case_job210677_6_detailed.md

Job 210678 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check — Aquantia AQR115C Ethernet PHY probe failure

1. Failed case: Probe_Failure_Check — Aquantia AQR115C Ethernet PHY probe failure
2. Root cause: Aquantia AQR115C PHY driver probe failed with -EINVAL (error -22) due to missing firmware-name DT property; the driver attempted to read the property at probe time and failed, causing probe to abort. This is a pre-existing qcs9100-ride platform issue unrelated to the PR's USB controller node flattening changes.
3. Possible fix: Add firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld"; property to the Aquantia PHY node (stmmac-0:08) in arch/arm64/boot/dts/qcom/qcs9100-ride.dts to satisfy the driver's firmware-name requirement and allow probe to succeed.
4. Detail analysis attachment: failed_case_job210678_1_detailed.md

  Case 2: smmu (test expectation failure — not a CoT-classified crash)

1. Failed case: smmu (test expectation failure — not a CoT-classified crash)
2. Root cause: The video codec device at address aa00000.video-codec on qcs9100-ride is not attached to any IOMMU group, failing the SMMU test's critical master protection check; kernel logs show no SMMU faults or errors, indicating the device either failed to probe or lacks IOMMU DT bindings for this SoC.
3. Possible fix: Verify the video codec driver probe status on qcs9100-ride; if the driver did not probe, investigate why (missing clocks/regulators/firmware); if the driver probed but lacks IOMMU attachment, add the missing iommus property to the aa00000.video-codec DT node in the qcs9100-ride device tree, referencing the appropriate SMMU stream ID.
4. Detail analysis attachment: failed_case_job210678_2_detailed.md

  Case 3: ** USBHost (Test Infrastructure Issue — No External USB Device Connected)

1. Failed case: ** USBHost (Test Infrastructure Issue — No External USB Device Connected)
2. Root cause: ** The USBHost test expects at least one external USB device (storage, keyboard, mouse, etc.) to be physically connected to the board's USB host ports. The test ran on qcs9100-ride with only USB root hubs enumerated, indicating no external devices were plugged in. The kernel USB subsystem is functioning correctly (3 xHCI controllers initialized successfully with no errors). This is a test infrastructure limitation, not a kernel regression.
3. Possible fix: Connect at least one external USB device (e.g., USB flash drive, keyboard, or mouse) to one of the qcs9100-ride board's USB host ports before running the USBHost test. Alternatively, update the test to skip or report "N/A" when no external devices are available, rather than failing.
4. Detail analysis attachment: failed_case_job210678_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test infrastructure issue — test runner completed all tests successfully (indicated by <LAVA_TEST_RUNNER EXIT> at line 6476) but LAVA dispatcher marked the test definition as failed with "Marking unfinished test run as failed" (line 6478). This is not a kernel crash or functional failure; the kernel booted successfully, all tests executed, and the system powered off cleanly. The failure is in LAVA's test result validation logic, likely due to a mismatch between expected and actual test result files or a timeout in the result parsing phase.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate the LAVA test definition's result parsing logic (result_parse.sh) and verify that all expected test result files are being generated and collected correctly. This is not a PR-introduced issue — the PR modifies USB device tree bindings which are unrelated to LAVA test infrastructure.
4. Detail analysis attachment: failed_case_job210678_4_detailed.md

Job 210679 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test infrastructure bug — the GIC test script assumes 8 CPUs but shikra-iqs-evk has only 4 CPUs (0-3); script line 75 attempts integer comparison on non-existent CPU columns, reading descriptor strings ("GICv3", "Level", "arch_timer") instead, causing bash "[: : integer expected" errors for CPUs 4-7.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding CPU count assumptions; validate only CPUs that exist on the target platform.
4. Detail analysis attachment: failed_case_job210679_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: These probe failures are not introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (USB controller DT flattening). The coresight-etm4x -22 errors indicate DT or hardware configuration issues for CoreSight ETM trace units; cpufreq-dt -17 suggests duplicate registration. The deferred probe entries (sound, codec, WiFi) indicate missing clock/regulator dependencies. No action required for this PR — failures are baseline platform issues that should be tracked separately.
4. Detail analysis attachment: failed_case_job210679_2_detailed.md

  Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** No USB devices physically connected to the shikra-iqs-evk board during test execution, or USB host controller not enabled in the device tree for this board variant. The USB DWC3 controller driver did not probe, resulting in no USB bus creation and zero enumerable devices.
3. Possible fix: Verify USB peripheral hardware is connected to the shikra-iqs-evk board in the LAVA lab. If hardware is connected, check the device tree for this board variant to confirm the USB controller node at 4e00000.usb has status = "okay". This is a test infrastructure issue, not a kernel regression.
4. Detail analysis attachment: failed_case_job210679_3_detailed.md

  Case 4: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add a Bluetooth beacon/device in RF range of the shikra-iqs-evk LAVA lab board, OR modify the BT_SCAN test to skip with a clear message when no devices are found (rather than fail), OR suppress BT_SCAN failures when BT_ON_OFF passes (similar to firmware load suppression rules).
4. Detail analysis attachment: failed_case_job210679_4_detailed.md

  Case 5: Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read from the hardware RNG device at physical address 0xffff800083295000. The crash is unrelated to the PR (USB DT node flattening) and indicates a pre-existing platform/firmware issue where the RNG hardware registers are not accessible or not properly mapped on the Shikra IQS EVK platform.
3. Possible fix: This is a pre-existing platform/firmware issue, not introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004. The KVM_Driver test failure is a cascading consequence of the kernel crash. To resolve: (1) Investigate why RNG hardware registers are not accessible on Shikra IQS EVK — check device tree RNG node, clock/power domain configuration, and firmware/bootloader RNG hardware initialization; (2) Disable the qcom_hwrng test on Shikra until the RNG hardware access issue is resolved; (3) Re-run the KVM_Driver test after fixing the RNG crash to determine if KVM has a genuine issue or if /dev/kvm absence is also platform-specific.
4. Detail analysis attachment: failed_case_job210679_5_detailed.md

  Case 6: Kernel Crash — synchronous external abort in qcom_rng driver (secondary: KVM_EL2_DTB test failure due to post-crash reboot)

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver (secondary: KVM_EL2_DTB test failure due to post-crash reboot)
2. Root cause: The qcom_rng driver crashed with a synchronous external abort (hardware bus error) when accessing RNG hardware registers during the qcom_hwrng test on Shikra IQS EVK. The hardware did not respond to MMIO access, indicating the RNG block was not accessible (likely powered down, not clocked, or in a bad state). The KVM_EL2_DTB test subsequently failed because it ran after the system rebooted from the crash, and /dev/kvm was not available in the post-crash boot state. This is a pre-existing platform/driver issue on Shikra IQS EVK, NOT introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004 (which only modifies USB device trees for hamoa/purwa platforms).
3. Possible fix: This is NOT a PR-introduced regression. The qcom_rng crash is a pre-existing Shikra platform issue. Recommended actions: (1) Investigate qcom_rng driver power management on Shikra — verify power domain, clock, and reset sequencing during runtime; (2) Add runtime PM checks before hardware access in qcom_rng_read(); (3) Check if Shikra device tree correctly describes RNG power domain and clock dependencies; (4) For CI: configure crashdump collection (add reboot=panic_warm qcom_scm.download_mode=1 to kernel cmdline) to capture full crash dumps for future triage; (5) Re-run the PR validation on a stable platform or after fixing the qcom_rng issue.
4. Detail analysis attachment: failed_case_job210679_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Skip KVM tests on Shikra IQS EVK platform in LAVA job definition until platform KVM support is enabled. To enable KVM: verify EL2 is available (dmesg | grep "EL2"), check for hypervisor DT node, ensure TrustZone/firmware allows EL2 access, and validate KVM driver probe succeeds (dmesg | grep kvm).
4. Detail analysis attachment: failed_case_job210679_7_detailed.md

  Case 8: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver encountered a synchronous external abort (bus error) at qcom_rng_read+0xc4/0x228 while attempting to read from the PRNG hardware MMIO register during the qcom_hwrng test. The hardware block became inaccessible at runtime, likely due to power/clock gating, hardware fault, or interconnect misconfiguration. This is a pre-existing kernel/driver issue on shikra-iqs-evk, not introduced by the PR (which only modifies X1E USB DT nodes).
3. Possible fix: This is a pre-existing kernel issue unrelated to the PR changes. The PR should not be blocked by this failure. Recommended actions: (1) File a separate bug for the qcom_rng driver crash on shikra-iqs-evk with the LAVA job URL and crash log. (2) Investigate PRNG hardware power/clock dependencies and runtime PM configuration on QCM2290. (3) Add error handling in qcom_rng_read to detect and recover from hardware access failures. (4) Re-run the LAVA job to confirm the failure is reproducible and not a transient hardware glitch.
4. Detail analysis attachment: failed_case_job210679_8_detailed.md

  Case 9: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver attempted to read from an unmapped or unpowered MMIO register during the qcom_hwrng test, triggering a synchronous external abort (ESR 0x96000010). This indicates the RNG hardware block is not properly initialized, clocked, or powered on the shikra-iqs-evk platform. The subsequent warm reboot failed to enter crashdump mode and hung, causing a LAVA timeout. This is a pre-existing platform/firmware issue; the PR only modifies USB DT nodes for hamoa/purwa/x1 platforms and does not affect shikra.
3. Possible fix: This is a pre-existing shikra-iqs-evk platform issue, not introduced by PR UPSTREAM: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes #1004. The PR should not be blocked by this failure. For the underlying issue: (1) Verify RNG hardware clock/power domain configuration in shikra DTS; (2) Ensure qcom_rng driver probe correctly enables clocks and power domains before accessing MMIO; (3) Add kernel cmdline reboot=panic_warm qcom_scm.download_mode=1 and verify TCSR DT node is present to enable crashdump on panic for future debugging.
4. Detail analysis attachment: failed_case_job210679_9_detailed.md

  Case 10: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** Hardware register access fault in qcom_rng_read() at offset +0xc4 when the qcom_hwrng test attempted to read random data from /dev/hwrng. The synchronous external abort (error code 0x96000010) indicates the CPU attempted to read from a physical address that either does not exist, is not mapped, or is not accessible due to power/clock gating. The crash occurred on shikra-iqs-evk during the qcom_hwrng functional test, causing a kernel panic and warm reboot into ramdump mode, which triggered the LAVA test shell 2400-second timeout.
3. Possible fix: This is a pre-existing hardware/platform issue unrelated to the PR (USB DT flattening changes). The qcom_rng hardware block is either not properly initialized (clocks/power not enabled), the MMIO region is incorrectly mapped in the device tree for shikra-iqs-evk, or the hardware block is non-functional on this specific board revision. Recommended actions: (1) Check shikra-iqs-evk device tree for qcom_rng node — verify reg property matches hardware documentation and clocks/clock-names are correct; (2) Add runtime PM and clock enable checks in qcom_rng_read() before accessing hardware registers; (3) If this board variant does not support the RNG block, mark the DT node status = "disabled" for shikra-iqs-evk; (4) Re-run the test on a different shikra board to confirm if this is board-specific or a systemic issue.
4. Detail analysis attachment: failed_case_job210679_10_detailed.md

  Case 11: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver attempted to read from an unmapped or inaccessible hardware register at offset 0xc4 in qcom_rng_read(), triggering a synchronous external abort (bus error). The crash occurred during the qcom_hwrng test when userspace (dd process) read from /dev/hwrng. This indicates the RNG hardware block is either not powered, not clocked, or the MMIO region is not correctly mapped for the shikra-iqs-evk platform.
3. Possible fix: Verify the qcom,prng-ee device tree node for shikra-iqs-evk includes correct reg property, clocks, and power-domains. If the hardware block is not present or functional on this SoC variant, disable the qcom_rng driver in the device tree (status = "disabled") or kernel config for shikra-iqs-evk. The PR under test (USB DT flattening) does not touch RNG code, so this is a pre-existing platform configuration issue exposed by the test suite.
4. Detail analysis attachment: failed_case_job210679_11_detailed.md

Job 210680 | SoC purwa-evk

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

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

  Case 1: Kernel Crash — Deadlock in fastrpc module initialization (rpmsg device registration)

1. Failed case: Kernel Crash — Deadlock in fastrpc module initialization (rpmsg device registration)
2. Root cause: The fastrpc module initialization triggers a self-deadlock during rpmsg device probe: udev-worker task 194 is blocked on a mutex (device_del → device_unregister → rpmsg_unregister_device → qcom_glink_destroy_ept → rpmsg_dev_probe) that it already owns, causing the task to deadlock with itself. This deadlock prevents userspace init from completing, leading to "run-init: opening console: No such file or directory" and "No init found" errors, ultimately causing the system to reboot and the login-action test to timeout. The underlying issue is triggered by an earlier fastrpc probe failure (-ENOMEM from qcom_scm SHM Bridge call failure) which causes the driver to attempt cleanup while still holding locks.
3. Possible fix: Apply the upstream fix for the fastrpc driver's error handling path to prevent device_unregister from being called while holding locks during probe failure. The immediate workaround is to blacklist the fastrpc module to allow the system to boot and complete login. The proper fix requires backporting the upstream patch that corrects the fastrpc driver's probe error path to avoid the self-deadlock scenario when SHM Bridge allocation fails.
4. Detail analysis attachment: failed_case_job210680_1_detailed.md

  Case 2: Kernel Crash — Hard LOCKUP on CPU3 leading to system hang

1. Failed case: Kernel Crash — Hard LOCKUP on CPU3 leading to system hang
2. Root cause: Watchdog detected hard LOCKUP on CPU3 at 99 seconds into boot while CPU was in cpuidle (handle_softirqs path). System continued but entered a hung state with multiple tasks blocked on device_del mutex (udev-worker task 194 blocked for 362+ seconds, reboot task 416 blocked waiting for device probe). The PR introduces USB DT node restructuring (flattening dwc3 child nodes into parent USB controller nodes) which likely triggers a device probe/removal race condition during boot on purwa-evk, causing the mutex deadlock in the device core layer.
3. Possible fix: Revert the USB DT node flattening changes for purwa-evk specifically, or investigate the device probe ordering and locking in the USB/dwc3 driver stack on this SoC. The hard lockup in cpuidle followed by hung tasks in device_del suggests a timing-sensitive race in device registration/unregistration triggered by the new DT structure. Verify USB driver probe/remove paths handle the flattened node structure correctly on X1E80100/purwa platforms.
4. Detail analysis attachment: failed_case_job210680_2_detailed.md

  Case 3: minimal-boot

1. Failed case: minimal-boot
2. Root cause: Userspace boot hang caused by udev-worker deadlock in device driver subsystem during fastrpc module initialization; udev-worker (pid 194) is blocked in mutex_lock at device_del→rpmsg_unregister_device→qcom_glink_destroy_ept→rpmsg_dev_probe path, preventing system from reaching login prompt and completing boot sequence.
3. Possible fix: This is a pre-existing kernel driver deadlock issue unrelated to the PR's USB DT node flattening changes; the PR modifies only USB controller device tree structure and does not touch rpmsg/glink/fastrpc drivers. Re-trigger the CI job to verify if the deadlock is transient; if it recurs consistently on purwa-evk, investigate the fastrpc/rpmsg/glink driver probe/remove race condition in the kernel (likely a lock ordering issue between device registration and removal during probe error paths).
4. Detail analysis attachment: failed_case_job210680_3_detailed.md

  Case 4: job

1. Failed case: job
2. Root cause: Userspace boot failure — initramfs cannot find /sbin/init on the root filesystem, causing "No init found. Try passing init= bootarg" error and automatic reboot. The root filesystem mounted successfully (EXT4-fs on sda2), but the init binary is missing or the console device nodes are not accessible ("run-init: opening console: No such file or directory").
3. Possible fix: This is a rootfs/image integrity issue unrelated to the PR (which only refactors USB DT nodes). Re-flash the target with a complete rootfs image that includes /sbin/init and proper /dev/console device nodes. If the issue persists, verify the LAVA job definition specifies the correct rootfs artifact URL and that the artifact is not corrupted.
4. Detail analysis attachment: failed_case_job210680_4_detailed.md

[Kriskura176767]

CRs-Fixed: 4660826