Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

[Salendarsingh Gaud (sgaud-quic)]

Name SHA Commits

tech/bsp/clk b662153 14
tech/bsp/devfreq 0837ca4 7
tech/bsp/sched 9c2e4b8 3
tech/security/firmware-smc 16b0235 9
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 8c716bc 1
tech/bus/peripherals c191e3d 10
tech/bus/pci/all 99c5b35 40
tech/bus/usb/dwc d90fb64 4
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing 257e1ef 26
tech/pmic/misc e7bb366 12
tech/mem/iommu cdc9e80 9
tech/mm/audio/all 762de76 2
tech/mm/camss f9a60f5 43
tech/mm/drm a5b4a5e 66
tech/mm/fastrpc fab5742 4
tech/mm/video bfab35e 47
tech/mm/gpu e065d5a 1
tech/net/ath 284d6dc 7
tech/net/bluetooth e352848 8
tech/pm/power 0d87ce2 10
tech/pm/thermal a58f3b3 8
tech/security/crypto 4c71afd 13
tech/security/ice dc34f45 14
tech/storage/all cb6192d 7
tech/all/dt/qcs6490 55b5c3b 20
tech/all/dt/qcs9100 3e3223b 22
tech/all/dt/qcs8300 6a513e3 28
tech/all/dt/qcs615 c3eea9f 13
tech/all/dt/agatti 2ca1b63 2
tech/all/dt/eliza 2709842 13
tech/all/dt/hamoa 3f57af0 34
tech/all/dt/glymur a43a2eb 27
tech/all/dt/kaanapali 35871da 17
tech/all/dt/pakala 9e50a87 12
tech/all/shikra bba7654 119
tech/all/config 5dbc967 81
tech/overlay/dt 3c5f17c 85
tech/all/workaround 42fd140 13
tech/noup/debug/all f017bf6 33
tech/hwe/unoq a2d85fe 4
early/hwe/nord 814d772 74
early/hwe/staging/nord 56b4e2c 89

[qcomlnxci]

Test jobs on 239cdce

• multimedia Job 227690 on glymur-crd
• multimedia Job 227686 on hamoa-iot-evk
• multimedia Job 227693 on kaanapali-mtp
• multimedia Job 227696 on lemans-evk
• multimedia Job 227695 on monaco-evk
• multimedia Job 227694 on purwa-iot-evk
• multimedia Job 227691 on qcs615-ride
• multimedia Job 227692 on qcs6490-rb3gen2
• multimedia Job 227689 on qcs8300-ride
• multimedia Job 227697 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227688 on shikra-iqs-evk
• multimedia Job 227687 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 239cdce

• multimedia Job 227750 on glymur-crd
• multimedia Job 227752 on hamoa-iot-evk
• multimedia Job 227748 on kaanapali-mtp
• multimedia Job 227742 on lemans-evk
• multimedia Job on monaco-evk
• multimedia Job 227746 on purwa-iot-evk
• multimedia Job 227744 on qcs615-ride
• multimedia Job 227743 on qcs6490-rb3gen2
• multimedia Job 227749 on qcs8300-ride
• multimedia Job 227751 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227747 on shikra-iqs-evk
• multimedia Job 227745 on sm8750-mtp

[qcomlnxci]

Test Matrix

Test Case	glymur-crd-multimedia	hamoa-iot-evk-multimedia	kaanapali-mtp-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	sm8750-mtp-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
USBHost	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	◻️	⚠️ skip	✅ Pass	❌ Fail	❌ Fail	⚠️ skip	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ 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	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass
watchdog	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1085

Job 225058 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a false positive test failure. The Probe_Failure_Check test is overly strict and flags any firmware load failure regardless of functional impact. Recommended actions: (1) Short-term: Suppress this specific regulatory.db failure in the Probe_Failure_Check test logic, as it is a known benign failure when WiFi tests pass. (2) Long-term: Either include the regulatory.db file in the rootfs image (package wireless-regdb or equivalent), or refine the Probe_Failure_Check test to exclude known-optional firmware files from failure criteria.
4. Detail analysis attachment: failed_case_job225058_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Venus video codec child devices (video-decoder and video-encoder) are not attached to IOMMU groups because the qcs615-ride device tree is missing the required iommu-map property for the venus node. The PR introduces iommu-map support for venus firmware IOMMU domain attachment (via new dt-binding VENUS_FIRMWARE in include/dt-bindings/media/qcom,qcs615-venus.h) and updates the talos-el2.dtso overlay, but does not update the base qcs615-ride.dts file.
3. Possible fix: Add the iommu-map property to the venus node in arch/arm64/boot/dts/qcom/qcs615-ride.dts following the pattern used in talos-el2.dtso: iommu-map = <VENUS_FIRMWARE &apps_smmu 0xe42 0x0 0x1>; and include the header #include <dt-bindings/media/qcom,qcs615-venus.h> at the top of the file.
4. Detail analysis attachment: failed_case_job225058_2_detailed.md

  Case 3: KVM_Driver — KVM device node unavailable

1. Failed case: KVM_Driver — KVM device node unavailable
2. Root cause: Gunyah hypervisor (gunyah-1cb9db980) is running at EL2 on QCS615 Ride, preventing KVM from initializing. KVM requires exclusive EL2 access to create /dev/kvm, but EL2 is already occupied by the Gunyah hypervisor. The kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected it cannot access EL2.
3. Possible fix: This is not a PR-introduced regression — it is a platform configuration issue. QCS615 Ride firmware is configured to boot with Gunyah hypervisor enabled, which is incompatible with KVM. To enable KVM: (1) rebuild firmware with Gunyah hypervisor disabled, or (2) configure bootloader to boot Linux directly at EL2 without a hypervisor, or (3) mark KVM tests as expected-fail for QCS615 Ride in the CI test matrix since this platform is configured for Gunyah, not KVM.
4. Detail analysis attachment: failed_case_job225058_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM subsystem initialization failed because ARM EL2 (Hypervisor mode) is not available on the qcs615-ride platform. Kernel log shows kvm [1]: HYP mode not available at boot time (2.259894s), preventing /dev/kvm device node creation. CONFIG_KVM is enabled in kernel config but the underlying hardware/firmware does not support virtualization extensions.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The qcs615-ride board does not support ARM virtualization extensions (EL2/HYP mode). Mark KVM tests as SKIP for this platform in the LAVA test suite, or exclude qcs615-ride from KVM test runs. If EL2 support is expected, verify bootloader/TrustZone firmware configuration allows EL2 entry.
4. Detail analysis attachment: failed_case_job225058_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The qcs615-ride board requires bootloader/firmware configuration to boot Linux at EL2. Options: (1) Configure ABL/XBL to load hypvm.mbn and boot Linux at EL2, or (2) Mark KVM tests as "not applicable" for qcs615-ride in the CI test suite if this platform is not intended to support KVM/virtualization. The PR changes (PCIe, PSCI reboot modes, QSPI) do not affect KVM and are unrelated to this failure.
4. Detail analysis attachment: failed_case_job225058_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 platform does not support ARM EL2 (Hypervisor mode), which is required for KVM functionality. Kernel message at boot shows "kvm [1]: HYP mode not available", preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
3. Possible fix: Exclude KVM tests from the qcs615-ride test suite, as this platform lacks hardware virtualization support (no EL2). Add platform capability detection to skip KVM tests on non-virtualization-capable SoCs.
4. Detail analysis attachment: failed_case_job225058_6_detailed.md

Job 225059 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check — Pre-existing Hardware/Platform Issues

1. Failed case: ** Probe_Failure_Check — Pre-existing Hardware/Platform Issues
2. Root cause: ** Three probe failures detected on qcs8300-ride platform: (1) Two PCIe controllers (1c00000.pcie, 1c10000.pcie) fail with -ETIMEDOUT due to PCIe PHY initialization timeouts, indicating hardware not responding or power/clock/reset sequencing issues; (2) Aquantia AQR115C Ethernet PHY fails with -EINVAL due to missing firmware-name DT property. These are pre-existing platform issues unrelated to the PR, which only modifies documentation and DT bindings without touching driver code or qcs8300 device trees.
3. Possible fix: Mark this test case as a known platform issue for qcs8300-ride and exclude from PR validation. For permanent resolution: (1) Debug PCIe PHY power/clock/reset sequencing on qcs8300-ride hardware — verify PHY power domains, clocks, and reset lines are correctly configured in the device tree and that hardware is functional; (2) Add missing firmware-name property to the Aquantia PHY node in qcs8300-ride device tree if firmware loading is required for this platform configuration.
4. Detail analysis attachment: failed_case_job225059_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 because PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 adds a new video codec node with the iommus property only on child nodes (non-pixel and pixel), leaving the parent device without IOMMU protection. The SMMU test expects critical masters like video codec to be attached to IOMMU groups at the device level.
3. Possible fix: Add an iommus property to the top-level iris: video-codec@aa00000 node in arch/arm64/boot/dts/qcom/glymur.dtsi, or update the SMMU test to check child nodes for IOMMU attachment when the parent uses a hierarchical IOMMU binding model.
4. Detail analysis attachment: failed_case_job225059_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe PHY initialization timeout (-ETIMEDOUT) caused by PR-introduced device tree error: duplicate vdda-qref-supply property (both vreg_l4a and vreg_l7a defined) and undefined regulator reference &refgen in qcs8300-ride.dts, preventing the qcom-qmp-pcie-phy driver from acquiring required regulators after the PR changed the PHY configuration to expect 4 regulators (vdda-phy, vdda-pll, vdda-qref, vdda-refgen) instead of 2.
3. Possible fix: Remove the duplicate vdda-qref-supply property and either define the refgen regulator node in qcs8300-ride.dts or replace vdda-refgen-supply = <&refgen>; with the correct regulator phandle (likely split into vdda-refgen0p9-supply and vdda-refgen1p2-supply following the pattern used in other platforms like sa8775p).
4. Detail analysis attachment: failed_case_job225059_3_detailed.md

  Case 4: USBHost — Test Infrastructure Issue (Not a Kernel Bug)

1. Failed case: USBHost — Test Infrastructure Issue (Not a Kernel Bug)
2. Root cause: USBHost test expects external USB devices to be connected to the qcs8300-ride board, but only the USB root hub is present. The USB host controller (xHCI at 0x0a400000) initialized correctly and detected 1 port, but no external devices are plugged in.
3. Possible fix: This is not a kernel bug and does not require a code fix. The test failure is due to missing test infrastructure (no USB device connected). To resolve: (1) Connect a USB device (keyboard, mouse, flash drive, or hub) to the board's USB host port before running the test, OR (2) Update the USBHost test script to gracefully handle the case where no external devices are present and mark it as SKIP instead of FAIL when only the root hub is detected.
4. Detail analysis attachment: failed_case_job225059_4_detailed.md

  Case 5: Ethernet_Basic_Validation — PHY Attach Failure

1. Failed case: Ethernet_Basic_Validation — PHY Attach Failure
2. Root cause: The qcom-ethqos Ethernet MAC driver fails to attach to the PHY during interface bring-up on qcs8300-ride. The phylink validation of 2500base-x mode fails with -EINVAL because the PHY's advertised capabilities (0x000062c0) don't match the MAC's supported capabilities (0x000062cc). This is likely caused by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085's changes to the dp83867 PHY driver which added regulator power-on logic in the probe path — if the PHY regulators are not properly defined in the qcs8300-ride device tree or fail to enable, the PHY may not initialize correctly, leading to incomplete capability advertisement and subsequent phylink validation failure.
3. Possible fix: Verify that the qcs8300-ride device tree includes all required regulator supplies for the dp83867 PHY (vdda-2p5, vdd-1p0, vdda-1p8, vddio) as introduced in PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. If regulators are missing or misconfigured, add them to the ethernet PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts. If regulators are correctly defined, check dmesg for regulator enable failures during PHY probe and address the root cause (missing PMIC configuration, wrong regulator names, or supply not available). As a temporary workaround to isolate the issue, revert the dp83867 regulator changes from PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 and confirm whether Ethernet works without them.
4. Detail analysis attachment: failed_case_job225059_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: CONFIG_KVM is enabled in kernel config but the KVM driver did not initialize during boot, resulting in /dev/kvm device node not being created. No KVM initialization messages appear in dmesg, indicating the KVM ARM driver failed to probe or was not compiled into the kernel despite CONFIG_KVM=y. This is a pre-existing platform/kernel configuration issue unrelated to the PR (which contains only device tree interconnect changes and documentation updates).
3. Possible fix: Verify that CONFIG_KVM_ARM_HOST=y (or CONFIG_KVM=m with kvm.ko and kvm-arm.ko modules present and loaded). Check that the platform's device tree and bootloader support EL2/hypervisor mode and that the CPU supports ARM virtualization extensions. If KVM is built as a module, ensure the modules are included in the rootfs and loaded during boot. If the qcs8300-ride platform does not support KVM/virtualization in hardware or firmware, mark the KVM tests as expected-fail or skip for this platform.
4. Detail analysis attachment: failed_case_job225059_6_detailed.md

  Case 7: KVM Driver Initialization Failure — /dev/kvm unavailable due to heterogeneous CPU features

1. Failed case: KVM Driver Initialization Failure — /dev/kvm unavailable due to heterogeneous CPU features
2. Root cause: KVM initialization silently aborted on QCS8300 (Monaco) due to CPU feature heterogeneity between Cortex-A78 (0x410fd4b2) and Cortex-X1C (0x412fd050) cores. ARM64 KVM requires all CPUs to have identical instruction set and memory model features (SYS_ID_AA64ISAR0_EL1, SYS_ID_AA64ISAR1_EL1, SYS_ID_AA64MMFR2_EL1) to safely migrate VMs between cores; the kernel detected "Unsupported CPU feature variation" during boot and skipped KVM initialization, preventing /dev/kvm creation.
3. Possible fix: This is a platform hardware limitation, not a software bug. KVM cannot be enabled on QCS8300 without either: (1) disabling big cores to create a homogeneous CPU configuration (boot with maxcpus=4 to use only Cortex-A78 cores), or (2) waiting for upstream ARM64 KVM asymmetric CPU support (experimental patches exist but are not production-ready). For CI: mark KVM tests as SKIP (not FAIL) on heterogeneous platforms like QCS8300; update test runner to detect CPU heterogeneity via /sys/devices/system/cpu/cpu*/regs/identification/midr_el1 and skip KVM tests when CPUs differ.
4. Detail analysis attachment: failed_case_job225059_7_detailed.md

  Case 8: KVM_Infra — KVM driver initialization failure

1. Failed case: KVM_Infra — KVM driver initialization failure
2. Root cause: KVM driver failed to initialize and create /dev/kvm device node on qcs8300-ride platform running under Gunyah hypervisor in protected virtualization mode; CONFIG_KVM is enabled but the KVM ARM driver did not probe successfully, likely due to incompatibility between KVM and the Gunyah protected virtualization environment where the kernel is running as a guest VM.
3. Possible fix: This is a platform/hypervisor configuration issue, not a PR-introduced regression. The qcs8300-ride target runs under Gunyah hypervisor in protected mode, which prevents nested virtualization (KVM requires EL2 access that is not available to guest VMs). Either: (1) disable KVM tests for qcs8300-ride in the LAVA test suite since this platform does not support KVM, or (2) if KVM support is intended, reconfigure the platform to boot the kernel at EL2 (native/host mode) instead of as a Gunyah guest VM.
4. Detail analysis attachment: failed_case_job225059_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm not created despite CONFIG_KVM=y because QCS8300-ride platform runs under a hypervisor (hypvm.mbn/sailhyp.elf) at EL2, preventing KVM from initializing - KVM requires exclusive EL2 access which is unavailable in this configuration.
3. Possible fix: This is expected behavior on QCS8300-ride when running under a hypervisor. Mark KVM tests as SKIP for this platform configuration, or use a non-hypervisor boot configuration if KVM testing is required. Add platform detection to test suite to automatically skip KVM tests on hypervisor-enabled QCS8300 builds.
4. Detail analysis attachment: failed_case_job225059_9_detailed.md

Job 225060 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Limitation (ath11k WiFi hardware timeout)

1. Failed case: Probe_Failure_Check — Pre-existing Platform Limitation (ath11k WiFi hardware timeout)
2. Root cause: ath11k_pci probe failed with -ETIMEDOUT (-110) during MHI power-up on lemans-evk; WiFi PCIe hardware did not respond, indicating missing/unpowered hardware, missing firmware, or incomplete platform bringup. regulatory.db firmware load failure is benign (fallback to built-in certs succeeded). Bluetooth firmware load failures are false positives (BT_ON_OFF test passed). PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 contains only documentation/DT binding updates and does not modify WiFi, Bluetooth, or PCIe drivers.
3. Possible fix: This is a pre-existing platform issue, not a PR regression. No action required for PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. To resolve the underlying issue: (1) verify WiFi PCIe card is installed and powered on lemans-evk, (2) ensure ath11k firmware files are present in /lib/firmware/ath11k/, (3) verify lemans-evk device tree has correct PCIe/WiFi node configuration (clocks, regulators, GPIOs, resets), or (4) suppress Probe_Failure_Check for lemans-evk if WiFi is not supported in the CI lab configuration.
4. Detail analysis attachment: failed_case_job225060_1_detailed.md

  Case 2: smmu (device tree configuration issue — not a CoT-classified failure)

1. Failed case: smmu (device tree configuration issue — not a CoT-classified failure)
2. Root cause: Video codec device at aa00000.video-codec on SA8775P/lemans-evk is missing iommus property in device tree, preventing IOMMU group attachment required for DMA protection.
3. Possible fix: Add iommus property to the video codec device node in arch/arm64/boot/dts/qcom/lemans.dtsi referencing the appropriate SMMU and stream ID, following the pattern used by other critical masters (GPU, Display, USB) on this platform.
4. Detail analysis attachment: failed_case_job225060_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci MHI timeout

1. Failed case: WiFi Driver Probe Failure — ath11k_pci MHI timeout
2. Root cause: The ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the MHI (Modem Host Interface) subsystem could not load the WiFi firmware image over BHI (Boot Host Interface) within the expected timeout period. The wcn6855 hw2.1 WiFi card on PCIe bus 0000:01:00.0 did not respond to the firmware boot handshake, causing the entire driver initialization chain to fail. This is a hardware/firmware communication timeout, not a kernel driver bug.
3. Possible fix: This is a pre-existing intermittent hardware/firmware issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (which only touches documentation, device trees for camera/display, and ath11k AHB driver, not the PCI path). Recommended actions: (1) Re-trigger the LAVA job to confirm if the failure is intermittent; (2) If persistent on lemans-evk, check WiFi card power sequencing, PCIe link stability, and firmware version compatibility with wcn6855 hw2.1 on SA8775P platform; (3) Increase MHI BHI timeout if the card requires longer boot time on this SoC.
4. Detail analysis attachment: failed_case_job225060_3_detailed.md

  Case 4: WiFi_OnOff — ath11k_pci probe failure (driver initialization)

1. Failed case: WiFi_OnOff — ath11k_pci probe failure (driver initialization)
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT during MHI (Modem Host Interface) firmware boot handshake on WCN6855 hw2.1 WiFi chip. Root cause is an SMMU (IOMMU) context fault (fsr=0x402, iova=0xffa00000) occurring immediately after MHI power-on at timestamp 7.013s, preventing the WiFi firmware from loading over BHI (Boot Host Interface), leading to a 21-second timeout and probe failure at 28.528s.
3. Possible fix: Investigate and fix the SMMU context fault for the ath11k_pci device (0000:01:00.0, IOMMU group 23). Verify that: (1) the device tree IOMMU mapping for the PCIe WiFi device is correct, (2) the SMMU context bank configuration matches the device's DMA requirements, (3) the WiFi firmware's DMA address range (iova=0xffa00000) is within the allowed IOMMU aperture. Check if the PR introduces any IOMMU/SMMU configuration changes for SA8775P (lemans-evk) or PCIe devices. If the SMMU fault is a pre-existing platform issue, add a workaround to disable SMMU for this device or expand the IOMMU aperture.
4. Detail analysis attachment: failed_case_job225060_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 suite marked as failed due to multiple pre-existing platform issues on lemans-evk: (1) ath11k_pci WiFi driver probe timeout (-110) during MHI power-up, indicating hardware/firmware communication failure; (2) video codec device aa00000.video-codec missing IOMMU group attachment; (3) Probe_Failure_Check detecting these probe failures. PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes only ath11k_ahb (not ath11k_pci) and documentation/bindings, so these failures are NOT PR-introduced regressions.
3. Possible fix: These are known lemans-evk platform issues. No PR changes required. For WiFi: investigate MHI/PCIe link stability and firmware availability on lemans-evk hardware. For video codec SMMU: verify device tree IOMMU bindings for aa00000.video-codec on lemans-evk. Re-run CI on a different board (e.g., rb3gen2, kodiak) to confirm PR does not introduce regressions on stable platforms.
4. Detail analysis attachment: failed_case_job225060_5_detailed.md

Job 225061 | SoC purwa-evk

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

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

  Case 1: Kernel Crash — BUG: sleeping function called from invalid context (qcom_scm atomic context violation)

1. Failed case: Kernel Crash — BUG: sleeping function called from invalid context (qcom_scm atomic context violation)
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes DO_ONCE to DO_ONCE_SLEEPABLE in qcom_tzmem_enable() (drivers/firmware/qcom/qcom_tzmem.c:519), but DO_ONCE_SLEEPABLE internally calls __do_once_sleepable_start() which disables preemption and IRQs. When qcom_tzmem_do_init() subsequently calls qcom_scm_shm_bridge_enable() → qcom_scm_call(), the latter attempts to sleep (via might_sleep() at qcom_scm.c:334) while in atomic context (preempt_count=1, irqs_disabled=1), triggering the BUG. The system then hangs during boot at ~3.8s, never reaching userspace or presenting a login prompt, causing LAVA login-action timeout.
3. Possible fix: Revert the change from DO_ONCE_SLEEPABLE back to DO_ONCE in drivers/firmware/qcom/qcom_tzmem.c line 519, or refactor qcom_tzmem_enable() to avoid calling sleeping functions from the DO_ONCE context. The original DO_ONCE macro is correct here because the initialization path (qcom_tzmem_do_init → qcom_scm_shm_bridge_enable) requires sleeping context, and DO_ONCE does not disable preemption/IRQs.
4. Detail analysis attachment: failed_case_job225061_1_detailed.md

  Case 2: Kernel Crash — BUG: sleeping function called from invalid context

1. Failed case: Kernel Crash — BUG: sleeping function called from invalid context
2. Root cause: PR incorrectly changed DO_ONCE to DO_ONCE_SLEEPABLE in drivers/firmware/qcom/qcom_tzmem.c:519, causing qcom_tzmem_do_init to attempt sleeping SCM calls while in atomic context (preemption disabled by __do_once_start). The purwa-evk SoC requires SCM bridge initialization during qcom_scm probe, which now triggers this atomic-sleep violation.
3. Possible fix: Revert the change from DO_ONCE_SLEEPABLE back to DO_ONCE in drivers/firmware/qcom/qcom_tzmem.c:519, and ensure qcom_tzmem_do_init uses non-sleeping SCM call variants, or refactor the initialization to occur in a sleepable context outside the DO_ONCE macro.
4. Detail analysis attachment: failed_case_job225061_2_detailed.md

  Case 3: Kernel Crash — System hang after BUG in qcom_scm probe

1. Failed case: Kernel Crash — System hang after BUG in qcom_scm probe
2. Root cause: The kernel encountered "BUG: sleeping function called from invalid context at drivers/firmware/qcom/qcom_scm.c:334" during qcom_scm_probe(). The qcom_scm driver attempted to call a potentially sleeping function (qcom_scm_call) while in atomic context (preempt_count: 1, irqs_disabled: 1) during the qcom_tzmem_enable() → qcom_scm_shm_bridge_enable() path. After printing the BUG message and call trace, the system hung and made no further progress. The watchdog eventually triggered a warm reset into ramdump mode approximately 7 seconds later. The system never reached userspace init, and LAVA's login-action timed out waiting for a prompt that never appeared.
3. Possible fix: This is a pre-existing kernel bug in the qcom_scm driver, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (the PR contains only documentation, device tree bindings, and unrelated driver changes). The immediate fix is to identify why qcom_scm_call() is being invoked in atomic context during probe and either: (1) defer the shm_bridge_enable call to a non-atomic context, or (2) ensure the calling path does not disable preemption/IRQs. Check the __do_once_start() mechanism at the call site — it appears to be holding a lock or disabling preemption. For CI purposes, this failure should be marked as a known issue unrelated to the PR under test, and the PR should not be blocked by this pre-existing bug.
4. Detail analysis attachment: failed_case_job225061_3_detailed.md

  Case 4: Kernel Boot Hang — BUG: sleeping function called from invalid context

1. Failed case: Kernel Boot Hang — BUG: sleeping function called from invalid context
2. Root cause: qcom_scm_call() invoked from atomic context (preemption disabled, IRQs disabled) during qcom_scm_probe → qcom_tzmem_enable → qcom_scm_shm_bridge_enable path; qcom_scm_call uses mutexes which can sleep, violating atomic context constraints. System continues boot after BUG but hangs before reaching login prompt, likely due to subsequent driver initialization failures or resource starvation caused by the atomic context violation.
3. Possible fix: This is a pre-existing kernel bug, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR contains no changes to drivers/firmware/qcom/qcom_scm.c probe path or qcom_tzmem code that would cause this issue. The fix requires upstream kernel patch to refactor qcom_scm_shm_bridge_enable to avoid sleeping calls in atomic context, or to defer the shm_bridge_enable call to a context where sleeping is allowed. For immediate CI unblocking, consider: (1) bisecting upstream kernel to identify the commit that introduced the __do_once_start atomic section around this call path, (2) applying a local workaround to defer qcom_tzmem_enable to a workqueue context, or (3) disabling CONFIG_QCOM_TZMEM if not required for purwa-evk platform.
4. Detail analysis attachment: failed_case_job225061_4_detailed.md

Job 225062 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC Test Infrastructure Failure

1. Failed case: GIC Test Infrastructure Failure
2. Root cause: Test script assumes all 8 CPUs (0-7) are online, but CPUs 6-7 failed to boot during kernel initialization with PSCI error -22 (EINVAL). The test script has a bash parsing bug at line 75 ([: GICv3: integer expected) when attempting to parse /proc/interrupts for CPUs that don't exist in the interrupt counter output, causing false failures for CPUs 6-7.
3. Possible fix: Update the GIC test script to dynamically detect online CPUs from /sys/devices/system/cpu/online before testing, and only validate timer interrupts for CPUs that are actually online. The script should skip offline CPUs rather than reporting them as failures.
4. Detail analysis attachment: failed_case_job225062_1_detailed.md

  Case 2: Probe_Failure_Check — False Positive Test Failure

1. Failed case: Probe_Failure_Check — False Positive Test Failure
2. Root cause: The Probe_Failure_Check test flags four benign firmware load failures as errors: (1) regulatory.db for cfg80211 (WiFi works, WiFi_OnOff test passed), (2) renesas_usb_fw.mem for optional PCIe xHCI controller (not critical for qcs6490-rb3gen2 platform functionality), (3) modem.mbn for remoteproc0 (modem is intentionally offline as a non-autoboot processor, remoteproc test passed). All failures are -ENOENT (error -2) for optional/non-critical firmware files that do not impact platform functionality.
3. Possible fix: Update the Probe_Failure_Check test to suppress known benign firmware load failures: (1) regulatory.db when WiFi functional tests pass, (2) renesas_usb_fw.mem for optional PCIe devices, (3) modem.mbn when modem remoteproc is configured as non-autoboot and remoteproc test passes. Alternatively, provide these optional firmware files in the test image to eliminate the warnings.
4. Detail analysis attachment: failed_case_job225062_2_detailed.md

  Case 3: Freq_Scaling

1. Failed case: Freq_Scaling
2. Root cause: Test expects 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 platform only successfully booted 6 CPUs (cpu0-cpu5); CPU6 and CPU7 failed to boot via PSCI with error -22 (EINVAL), causing the Freq_Scaling test to fail when checking for cpufreq interface on cpu7.
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, or adjust the test expectations for qcs6490-rb3gen2 to account for the 6-CPU configuration (CPU6/CPU7 boot failure is a known platform limitation, not a regression).
4. Detail analysis attachment: failed_case_job225062_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Connect a USB device (e.g., USB flash drive, USB keyboard, or USB hub) to the board's USB host port before running the USBHost test. Alternatively, mark this test as SKIP when no USB host hardware is available in the test environment, or update the test to check for USB controller presence rather than requiring a connected device.
4. Detail analysis attachment: failed_case_job225062_4_detailed.md

  Case 5: KVM_Driver — KVM initialization failure (HYP mode not available)

1. Failed case: KVM_Driver — KVM initialization failure (HYP mode not available)
2. Root cause: The qcs6490-rb3gen2 board is running under the Gunyah hypervisor in the Primary VM (PVM), which prevents nested virtualization. KVM requires direct access to EL2 (HYP mode), but when Linux runs as a guest under Gunyah, it executes at EL1 and cannot access EL2. The kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected it cannot initialize because the CPU is not in HYP mode.
3. Possible fix: This is not a PR-introduced regression — it is a platform configuration issue. The KVM_Driver test should be skipped on boards running under Gunyah hypervisor (PVM configuration). Add a test precondition check to skip KVM tests when /sys/hypervisor/type indicates Gunyah or when the boot log contains "Gunyah based bootup". Alternatively, to enable KVM functionality, the board must be configured to boot Linux directly at EL2 without the Gunyah hypervisor layer.
4. Detail analysis attachment: failed_case_job225062_5_detailed.md

  Case 6: KVM/Virtualization Failure — HYP mode not available (Gunyah hypervisor conflict)

1. Failed case: KVM/Virtualization Failure — HYP mode not available (Gunyah hypervisor conflict)
2. Root cause: KVM driver initialization failed because ARM EL2 (hypervisor exception level) is already claimed by the Gunyah hypervisor running on qcs6490-rb3gen2. KVM requires exclusive EL2 access but detected "HYP mode not available" at boot (log line showing "[ 3.037639][ T1] kvm [1]: HYP mode not available"). This is a platform firmware configuration issue where Gunyah and KVM are mutually exclusive - only one hypervisor can control EL2.
3. Possible fix: Skip KVM tests on Gunyah-enabled platforms by updating the LAVA test job definition to detect Gunyah presence (check for "Hypervisor cold boot" in early boot logs or "kvm.*HYP mode not available" in dmesg) and mark KVM tests as SKIP rather than FAIL. Alternatively, if KVM functionality is required, disable Gunyah in the bootloader/firmware configuration to allow Linux to boot at EL2 and enable KVM initialization.
4. Detail analysis attachment: failed_case_job225062_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the board runs under Gunyah hypervisor at EL1; KVM requires EL2 (HYP mode) which is not available when a hypervisor is already running. The kernel message "kvm [1]: HYP mode not available" confirms this architectural limitation.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM test suite should be skipped on platforms running under a hypervisor (Gunyah). Add a pre-test check in the LAVA job definition to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor) and skip all KVM tests when a hypervisor is detected, or mark them as expected failures for this platform configuration.
4. Detail analysis attachment: failed_case_job225062_7_detailed.md

  Case 8: KVM_Infra (test infrastructure issue — platform limitation)

1. Failed case: KVM_Infra (test infrastructure issue — platform limitation)
2. Root cause: KVM driver initialization failed with "HYP mode not available" because the qcs6490-rb3gen2 platform does not support EL2 hypervisor mode, which is a hardware prerequisite for KVM functionality. CONFIG_KVM is enabled in the kernel config, but the platform lacks the necessary hardware virtualization extensions.
3. Possible fix: Exclude KVM tests from the CI test suite for qcs6490-rb3gen2 (and other platforms without HYP/virtualization support), or mark them as expected-to-skip when /dev/kvm is not present. This is not a kernel regression — it's a pre-existing platform limitation.
4. Detail analysis attachment: failed_case_job225062_8_detailed.md

Job 225063 | SoC glymur-crd

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

Failed test cases in LAVA job 225063 (SoC: glymur-crd).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test flagged a benign cfg80211 regulatory database firmware load failure (regulatory.db failed with error -2) that occurs during normal boot when the regulatory.db file is not present in the filesystem. This is not a kernel regression — cfg80211 successfully loaded compiled-in X.509 certificates and fell back to built-in regulatory rules, and all WiFi/BT functionality is working correctly (as evidenced by passing WiFi and Bluetooth tests later in the job).
3. Possible fix: Update the Probe_Failure_Check test to suppress cfg80211 regulatory.db firmware load failures (error -2) when cfg80211 successfully loads X.509 certificates and falls back to built-in regulatory data. This is a known benign pattern in upstream cfg80211 when regulatory.db is not packaged in the rootfs.
4. Detail analysis attachment: failed_case_job225063_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test detected that the critical master device "Video aa00000.video-codec" (iris video codec) is missing IOMMU group attachment on glymur-crd, despite the device node being added to the device tree in this PR with proper iommus properties in its sub-nodes.
3. Possible fix: Enable the iris video codec device in the glymur-crd board-specific device tree file by adding &iris { status = "okay"; }; to arch/arm64/boot/dts/qcom/glymur-crd.dtsi, or update the SMMU test's critical master list to exclude the iris device if it's intentionally disabled on this board variant.
4. Detail analysis attachment: failed_case_job225063_2_detailed.md

  Case 3: ** USBHost (Test Infrastructure Issue — Not a Kernel Failure)

1. Failed case: ** USBHost (Test Infrastructure Issue — Not a Kernel Failure)
2. Root cause: ** The USBHost test expects external USB devices (keyboard, mouse, storage) to be physically connected to the board's USB ports, but none are present in the LAVA lab setup. The kernel USB host stack initialized successfully (xHCI controller registered, root hubs detected), but the test fails because it requires at least one non-hub USB device to be enumerated.
3. Possible fix: This is NOT a kernel bug or PR-introduced regression. The PR contains only documentation and device tree binding updates with no functional USB driver changes. To resolve: (1) Connect a USB device (keyboard, mouse, or storage) to the glymur-crd board's USB port in the LAVA lab, OR (2) Update the USBHost test to skip/pass when no external devices are available (test infrastructure fix), OR (3) Mark this test as expected-fail for lab configurations without USB peripherals attached.
4. Detail analysis attachment: failed_case_job225063_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 suite marked as failed because 3 individual test cases failed: (1) Probe_Failure_Check detected regulatory.db firmware load error -2 (benign, pre-existing), (2) smmu test detected Video codec aa00000.video-codec missing iommu_group attachment (pre-existing driver/DT issue), (3) USBHost test found no USB devices connected (test environment issue - only USB hubs present, no devices plugged in). The kernel booted successfully and all tests executed; this is NOT a build load failure or kernel crash.
3. Possible fix: Re-trigger the CI job. The 3 failures are pre-existing issues unrelated to this PR (which only adds documentation for AEST debugfs and STP policy configfs). If failures persist: (1) regulatory.db firmware error is benign and can be suppressed, (2) investigate Video codec IOMMU binding in glymur-crd DT, (3) connect a USB device to the test board for USBHost validation.
4. Detail analysis attachment: failed_case_job225063_4_detailed.md

Job 225064 | SoC monaco-evk

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

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

  Case 1: 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) on monaco-evk (iq-8275-evk) because the MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to time out during WiFi device initialization.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/), or if the firmware path is incorrect for this board variant (nfa765 vs standard WCN6855), update the board-specific firmware path configuration in the ath11k driver or device tree to match the available firmware files in the rootfs.
4. Detail analysis attachment: failed_case_job225064_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) exists in the monaco-evk device tree but lacks IOMMU group attachment because the device tree node is missing the iommus property, leaving this critical DMA master unprotected by the SMMU.
3. Possible fix: This is a pre-existing platform configuration issue on monaco-evk, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR adds video codec nodes to other SoCs (glymur, etc.) but does not modify monaco's video codec configuration. To fix: add the iommus property to the video codec node in arch/arm64/boot/dts/qcom/monaco.dtsi with the appropriate SMMU stream IDs for the platform, or if the video codec is intentionally disabled/not supported on monaco-evk, mark the node status = "disabled" or remove it from the enabled device tree.
4. Detail analysis attachment: failed_case_job225064_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure failure — no USB host devices physically connected to the monaco-evk board's USB host ports during test execution. The kernel USB subsystem is not initialized because no USB host controller driver (dwc3/xhci) probe messages appear in the boot log, indicating the USB host functionality is either not enabled in the device tree for this platform or the hardware lacks external USB host peripherals.
3. Possible fix: This is a known test infrastructure limitation for monaco-evk. The USBHost test expects external USB devices (keyboard, mouse, storage) to be physically connected to USB host ports. Either: (1) connect USB host peripherals to the board before running the test suite, (2) mark this test as "skip" or "not applicable" for monaco-evk in the LAVA job definition if the board does not expose USB host ports in the lab setup, or (3) verify the monaco-evk device tree enables USB host controller nodes (usb@a400000, usb@a600000) with dr_mode = "host" or "otg" and required PHY/clock/regulator dependencies.
4. Detail analysis attachment: failed_case_job225064_3_detailed.md

  Case 4: WiFi Driver Probe Failure — ath11k_pci firmware dependency

1. Failed case: WiFi Driver Probe Failure — ath11k_pci firmware dependency
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (error -110) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (-ENOENT, error -2), causing MHI power-up to time out during driver initialization.
3. Possible fix: Add the missing ath11k WCN6855 firmware files to the rootfs image under /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin and any required companion files (m3.bin, regdb.bin) — then rebuild and reflash the image.
4. Detail analysis attachment: failed_case_job225064_4_detailed.md

  Case 5: ** WiFi_OnOff — WiFi Driver Probe Failure (ath11k_pci)

1. Failed case: ** WiFi_OnOff — WiFi Driver Probe Failure (ath11k_pci)
2. Root cause: ** ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to timeout during driver initialization on monaco-evk.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). Verify the firmware package (linux-firmware or board-specific firmware package) includes WCN6855 hw2.1 nfa765 variant firmware, or add it explicitly to the build recipe.
4. Detail analysis attachment: failed_case_job225064_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests (LAVA Test Infrastructure Issue)

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Test Infrastructure Issue)
2. Root cause: LAVA test runner marked the test suite as "unfinished" after detecting unprocessed result files (Ethernet_Basic_Validation.res, WiFi_OnOff.res) in the working directory, even though these tests had already been executed and reported. This is a LAVA test harness cleanup/parsing issue, not a kernel regression. The underlying genuine failures (WiFi ath11k_pci probe timeout -110, USBHost no devices) are pre-existing monaco-evk platform issues unrelated to this documentation-only PR.
3. Possible fix: This is not a PR-blocking issue. The PR modifies only documentation and DT bindings and cannot cause WiFi driver probe failures or LAVA test harness issues. Recommended actions: (1) Re-trigger the CI job to confirm the LAVA test harness issue is transient; (2) If WiFi/USB failures persist across runs, file separate platform-specific bugs for monaco-evk ath11k_pci probe timeout and USB enumeration, as these are board/firmware issues independent of this PR's changes.
4. Detail analysis attachment: failed_case_job225064_6_detailed.md

Job 225065 | SoC sm8750-mtp

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

Failed test cases in LAVA job 225065 (SoC: sm8750-mtp).

  Case 1: PCIe

1. Failed case: PCIe
2. Root cause: PCIe test script failure due to missing test-specific device tree node or sysfs entry — PCIe hardware is functional (link up, devices enumerated), but test validation logic expects a specific DT node or sysfs capability file that is not present on sm8750-mtp.
3. Possible fix: Update the PCIe test script to handle sm8750-mtp platform-specific PCIe configuration, or add the expected DT node/sysfs entry if it represents a genuine platform requirement. Verify test expectations against sm8750-mtp hardware capabilities.
4. Detail analysis attachment: failed_case_job225065_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (xhci-hcd) driver not initialized on sm8750-mtp; dwc3_qcom glue driver loaded but no xHCI host mode enabled, likely due to missing USB host hardware, incorrect device tree configuration for host mode, or USB controller configured in device/peripheral mode only.
3. Possible fix: Verify sm8750-mtp hardware supports USB host mode; if supported, check device tree usb@a600000 node for correct dr_mode property (should be "host" or "otg", not "peripheral"), ensure USB PHY and Type-C port-controller configurations enable host mode, and confirm xhci-hcd module is built into kernel or loaded; if hardware does not support USB host, mark test as SKIP for this platform.
4. Detail analysis attachment: failed_case_job225065_2_detailed.md

  Case 3: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Provision a valid Bluetooth BD address for the sm8750-mtp board via device tree local-bd-address property, bootloader environment variable, or userspace configuration file; verify address persistence across reboots and re-run BT_FW_KMD_Service test.
4. Detail analysis attachment: failed_case_job225065_3_detailed.md

  Case 4: BT_ON_OFF — Bluetooth Runtime Initialization Failure

1. Failed case: BT_ON_OFF — Bluetooth Runtime Initialization Failure
2. Root cause: Bluetooth adapter hci0 failed to obtain a valid BD (Bluetooth Device) address within the 40-second initialization timeout, causing the BT_ON_OFF functional test to fail after 2 recovery attempts; PR modifies Qualcomm Bluetooth drivers (btqca.c, hci_qca.c) which are directly responsible for BD address provisioning on sm8750-mtp.
3. Possible fix: Revert or debug the Bluetooth driver changes in drivers/bluetooth/btqca.c and drivers/bluetooth/hci_qca.c introduced by this PR; specifically investigate BD address read/provisioning logic for sm8750 platform; verify firmware loading sequence and NVM (non-volatile memory) access paths for BD address retrieval.
4. Detail analysis attachment: failed_case_job225065_4_detailed.md

  Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth firmware download failure — WCN7850 controller repeatedly fails to respond to firmware download commands (command 0xfc00 tx timeout, error -110 ETIMEDOUT), preventing hci0 adapter initialization and leaving it without a valid BD address after multiple recovery attempts.
3. Possible fix: Investigate WCN7850 hardware/firmware communication path on SM8750-MTP: verify UART transport configuration (baud rate, flow control, pinctrl), check power sequencing and regulators for the Bluetooth subsystem, confirm firmware file qca/hmtbtfw20.tlv is present and valid, and review recent changes to QCA Bluetooth UART driver or device tree that may affect command/response timing or interrupt delivery.
4. Detail analysis attachment: failed_case_job225065_5_detailed.md

  Case 6: ** KVM_Driver (Test Infrastructure Limitation — Not a Kernel Bug)

1. Failed case: ** KVM_Driver (Test Infrastructure Limitation — Not a Kernel Bug)
2. Root cause: ** /dev/kvm device node is not present because the SM8750-MTP target is running under the Gunyah hypervisor (reserved memory region gunyah-hyp@80000000 detected at boot line 3036). KVM requires EL2 (Exception Level 2) access to create the /dev/kvm device, but EL2 is already occupied by Gunyah. Nested virtualization (running KVM inside a VM or under another hypervisor) is not supported on this platform. This is not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085, which does not modify any KVM or virtualization code.
3. Possible fix: Update the KVM test suite (KVM_Driver/run.sh, KVM_EL2_DTB/run.sh, KVM_Infra/run.sh) to detect hypervisor presence before running tests. Add a check at the start of each test script:
4. Detail analysis attachment: failed_case_job225065_6_detailed.md

  Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM failed to initialize because the system is running under Gunyah hypervisor (nested virtualization not supported). CONFIG_KVM is enabled but /dev/kvm was never created because KVM silently skips initialization when it detects it's running as a guest under another hypervisor.
3. Possible fix: This is not a PR-introduced regression. KVM tests are expected to fail on sm8750-mtp when booted under Gunyah hypervisor. Either: (1) skip KVM tests on Gunyah-enabled platforms, or (2) boot without Gunyah to test native KVM functionality, or (3) add a test gate that checks for nested virtualization support before running KVM tests.
4. Detail analysis attachment: failed_case_job225065_7_detailed.md

  Case 8: KVM Infrastructure Test Failure — /dev/kvm not available

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm not available
2. Root cause: KVM cannot initialize on SM8750 MTP because the platform is running under Gunyah hypervisor at EL2; KVM requires direct EL2 access to create /dev/kvm, but Gunyah occupies EL2 and prevents KVM from initializing, even though CONFIG_KVM is enabled in the kernel configuration.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (which contains no KVM-related changes). To enable KVM testing on SM8750 MTP, either: (1) disable Gunyah hypervisor in the firmware/boot configuration to allow KVM direct EL2 access, or (2) skip KVM tests on platforms configured with Gunyah, or (3) use a different test platform without a pre-installed hypervisor for KVM validation.
4. Detail analysis attachment: failed_case_job225065_8_detailed.md

  Case 9: ** DPU Display Driver Runtime Failure — PR-Introduced Encoder Interface Selection Regression

1. Failed case: ** DPU Display Driver Runtime Failure — PR-Introduced Encoder Interface Selection Regression
2. Root cause: ** PR 1085 modified dpu_encoder_get_intf() to add MST stream_id matching logic (&& cnt++ == stream_id). On sm8750-mtp, encoder 35's display_info has a non-zero stream_id (likely 1) for a non-MST display with only one matching interface. The counter-based check fails (cnt=0 when stream_id=1), returning NULL. Encoder 35 operates without a hardware interface, causing continuous frame done timeouts (-ETIMEDOUT) starting at boot.
3. Possible fix: Modify dpu_encoder_get_intf() logic to handle non-MST displays: change condition to (stream_id == 0 || cnt++ == stream_id) OR ensure disp_info->stream_id is initialized to 0 for non-MST displays in display init paths (msm_dsi_modeset_init(), msm_dp_modeset_init()). Verify sm8750 DT and driver code correctly initialize stream_id=0 for single-stream displays.
4. Detail analysis attachment: failed_case_job225065_9_detailed.md

Job 225066 | SoC shikra-iqs-evk

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

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

  Case 1: login-action

1. Failed case: login-action
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Enable CONFIG_KASAN=y in the kernel build to get precise alloc/free stacks for the freed OPP table object. Revert the OPP core error handling change in drivers/opp/core.c (lines 137583-137625 of pr.patch) and retest. If crash persists, audit all device tree OPP table additions in the PR for shikra-iqs-evk to ensure correct phandle references and table structure. Apply a targeted fix to correct the refcount/lifetime issue in _update_opp_table_clk or fix malformed device tree OPP table references.
4. Detail analysis attachment: failed_case_job225066_1_detailed.md

  Case 2: Kernel Crash — Use-after-free in OPP table initialization

1. Failed case: Kernel Crash — Use-after-free in OPP table initialization
2. Root cause: Use-after-free memory corruption in _of_add_table_indexed() during cpufreq driver probe. The function dereferenced a freed OPP table structure (poison value 0x6b6b6b6b6b6b6b6b indicates SLUB freed memory), causing a kernel Oops followed by panic. The crash occurred during deferred probe of the dt-cpufreq driver on shikra-iqs-evk when attempting to add OPP tables for CPU frequency scaling.
3. Possible fix: This is a kernel memory safety bug in the OPP subsystem. The PR introduces new OPP table definitions for the Iris GPU (iris_opp_table) in device tree, which may have exposed a latent use-after-free race in the OPP core during concurrent probe/table-add operations. Immediate mitigation: revert the OPP table additions from the PR and re-test. Proper fix: investigate the OPP core lifetime management in drivers/opp/of.c — likely missing refcount or premature free of OPP table during error path or concurrent access. Check if dev_pm_opp_of_cpumask_add_table() and _of_add_table_indexed() properly serialize access to shared OPP table structures.
4. Detail analysis attachment: failed_case_job225066_2_detailed.md

  Case 3: Kernel Crash — Use-After-Free in OPP subsystem

1. Failed case: Kernel Crash — Use-After-Free in OPP subsystem
2. Root cause: PR introduces a use-after-free bug in drivers/opp/core.c:_update_opp_table_clk(). The modified code calls dev_pm_opp_put_opp_table(opp_table) which frees the OPP table and poisons it with 0x6b6b6b6b6b6b6b6b, then returns ERR_PTR(ret) where ret contains the poisoned value. The caller dt_cpufreq_early_init() attempts to dereference this freed pointer, triggering a kernel panic at _of_add_table_indexed+0x44/0x1e8 with "Unable to handle kernel paging request at virtual address 006b6b6b6b6b6c2b".
3. Possible fix: Revert the incorrect change in drivers/opp/core.c:_update_opp_table_clk(). The original code correctly returned ERR_CAST(opp_table->clk) before freeing the table. The PR incorrectly moved dev_pm_opp_put_opp_table() before the return, creating a use-after-free. Restore the original order: call dev_err_probe(), then return ERR_CAST(opp_table->clk), then call dev_pm_opp_put_opp_table() only on the error path where the pointer is not returned to the caller.
4. Detail analysis attachment: failed_case_job225066_3_detailed.md

  Case 4: Kernel Crash — Use-after-free in OPP framework

1. Failed case: Kernel Crash — Use-after-free in OPP framework
2. Root cause: Kernel panic triggered by use-after-free bug in _of_add_table_indexed+0x44/0x1e8 during cpufreq driver probe on shikra-iqs-evk. The crash occurs when the dt_cpufreq driver attempts to add OPP tables for CPU frequency scaling; dereferencing freed memory (poison pattern 0x6b6b6b6b6b6b6b6b) causes a level 0 translation fault at virtual address 006b6b6b6b6b6c2b, leading to immediate kernel panic and preventing userspace from reaching login prompt.
3. Possible fix: Investigate and fix the OPP table lifecycle bug in the cpufreq-dt or OPP core code. The crash signature indicates a freed OPP table structure is being accessed during deferred probe of the cpufreq platform device. Check for missing reference counting, premature kfree, or race conditions in dev_pm_opp_of_cpumask_add_table and _of_add_table_indexed. As a short-term workaround, disable cpufreq-dt in the kernel config or remove the cpufreq device tree node for shikra-iqs-evk to allow boot to complete.
4. Detail analysis attachment: failed_case_job225066_4_detailed.md

Job 225067 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three driver probe failures detected: (1) regulatory.db firmware load failure (benign - optional file, cfg80211 uses built-in rules), (2) Aquantia AQR115C PHY probe failure due to missing firmware-name DT property (pre-existing board configuration issue), (3) ath11k_pci WiFi probe failure with MHI firmware load timeout -110 (pre-existing intermittent hardware/firmware issue on qcs9100-ride). None of these failures are introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: Suppress this test failure as all three probe failures are pre-existing issues unrelated to PR changes. For long-term fixes: (1) regulatory.db is benign and requires no action, (2) add firmware-name property to qcs9100-ride DT for Aquantia PHY if custom firmware is needed, (3) investigate MHI firmware load reliability on qcs9100-ride WiFi hardware (increase timeout or fix firmware/hardware initialization race).
4. Detail analysis attachment: failed_case_job225067_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 explicit synchronization after icc_set_bw() in arm_smmu_icc_enable() to ensure interconnect bandwidth is applied before SMMU register writes proceed, or move ICC path setup to an earlier initialization phase in arm_smmu_device_probe() before context bank allocation. Short-term: re-run LAVA job to confirm reproducibility; if deterministic, temporarily revert ICC voting changes and verify fault disappears.
4. Detail analysis attachment: failed_case_job225067_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no physical USB devices connected to the qcs9100-ride board's USB ports; only USB root hubs (Bus 001, 002, 003) are enumerated, indicating USB host controllers are functional but no external USB peripherals are attached to the test fixture.
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB hub with downstream devices) to one of the board's USB ports before running the USBHost test; alternatively, update the test to skip or pass when only root hubs are present if external USB device connectivity is not a requirement for this SoC/board configuration.
4. Detail analysis attachment: failed_case_job225067_3_detailed.md

  Case 4: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Ethernet driver probe succeeded but runtime interface bring-up failed due to two distinct issues: (1) end0 (23040000.ethernet) cannot attach to PHY with -EINVAL error, indicating PHY configuration or device tree mismatch; (2) end1 (23000000.ethernet) experiences repeated MAC_VLAN_Tag_Filter register access timeouts, suggesting hardware clock/power gating or register access path failure on qcs9100-ride platform.
3. Possible fix: For end0: Verify PHY device tree node configuration (phy-handle, phy-mode, MDIO bus wiring) matches hardware expectations for 23040000.ethernet on qcs9100-ride; check if PHY driver is loaded and PHY device is enumerated on MDIO bus. For end1: Investigate clock/power domain configuration for 23000000.ethernet MAC registers; verify VLAN filter register access path is not gated; check if recent DT binding changes (qcom,shikra-ethqos addition in PR) introduced clock or power-domain dependency changes that are not met on qcs9100-ride.
4. Detail analysis attachment: failed_case_job225067_4_detailed.md

  Case 5: WiFi Driver Probe Failure — MHI BHI Firmware Load Timeout

1. Failed case: WiFi Driver Probe Failure — MHI BHI Firmware Load Timeout
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because MHI (Modem Host Interface) could not load the WiFi firmware image over BHI (Boot Host Interface) within the expected timeout period on qcs9100-ride (SA8775P) platform with QCA6698AQ hw2.1 WiFi chip; the failure is introduced by the tech/bus/pci/mhi topic branch merge in PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: Revert or debug the tech/bus/pci/mhi topic branch changes affecting BHI firmware loading; specifically investigate MHI BHI timeout handling, firmware download state machine, and power sequencing for PCIe WiFi devices on SA8775P platforms; if the timeout is too aggressive, increase the BHI image load timeout in drivers/bus/mhi/host/boot.c.
4. Detail analysis attachment: failed_case_job225067_5_detailed.md

  Case 6: ** WiFi_OnOff — Driver Probe Failure (MHI Firmware Load Timeout)

1. Failed case: ** WiFi_OnOff — Driver Probe Failure (MHI Firmware Load Timeout)
2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the MHI bus could not load the WiFi firmware image over BHI within 20 seconds. The PR merges topic branch tech/bus/pci/mhi which introduced MHI subsystem changes that regressed the BHI firmware load handshake for qca6698aq WiFi chip on qcs9100-ride platform.
3. Possible fix: Revert or fix the MHI topic branch changes that affect BHI firmware loading timing/handshake. Specifically investigate MHI BHI timeout values, interrupt handling, and state machine transitions introduced in tech/bus/pci/mhi for compatibility with qca6698aq on SA8775P/qcs9100 platforms.
4. Detail analysis attachment: failed_case_job225067_6_detailed.md

  Case 7: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on qcs9100-ride (LeMans) because the platform does not support EL2/HYP mode — the kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running with virtualization extensions enabled or the bootloader/firmware did not configure EL2 properly.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression. The qcs9100-ride target does not support KVM virtualization in its current firmware/bootloader configuration. To enable KVM: (1) verify the SoC supports ARMv8 virtualization extensions, (2) ensure the bootloader (ABL/XBL) boots the kernel at EL2 or enables EL2 access, (3) if the platform genuinely lacks virtualization support, mark the KVM tests as "skip" for this target in the LAVA test definition.
4. Detail analysis attachment: failed_case_job225067_7_detailed.md

  Case 8: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed at boot because the qcs9100-ride (LeMans) platform did not boot in EL2 (hypervisor mode); kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform boot-mode issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (the PR contains no KVM or virtualization code changes). The board must be configured to boot in EL2 mode via bootloader/firmware settings, or the test should be marked as expected-fail/skip for platforms that do not support EL2 boot (qcs9100-ride currently boots in EL1).
4. Detail analysis attachment: failed_case_job225067_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a bug — it is the expected behavior when Gunyah hypervisor is running. To enable KVM on this platform, either: (1) boot without the Gunyah hypervisor (if supported by the platform firmware), or (2) use a nested virtualization configuration if Gunyah supports exposing virtual EL2 to Linux (requires Gunyah hypervisor support). For CI purposes, mark KVM tests as "expected skip" on qcs9100-ride when Gunyah is present, or exclude this platform from KVM test runs.
4. Detail analysis attachment: failed_case_job225067_9_detailed.md

  Case 10: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed at boot because HYP (EL2 hypervisor) mode is not available on qcs9100-ride platform — kernel logged "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. If KVM support is required on qcs9100-ride, verify: (1) the SoC supports virtualization extensions (EL2), (2) the bootloader/firmware enables EL2 mode, and (3) the device tree does not explicitly disable KVM. If the platform genuinely lacks EL2 support, mark KVM tests as expected-fail or skip them for this target in the LAVA job definition.
4. Detail analysis attachment: failed_case_job225067_10_detailed.md

Job 225068 | SoC kaanapali-mtp

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

Failed test cases in LAVA job 225068 (SoC: kaanapali-mtp).

  Case 1: PCIe

1. Failed case: PCIe
2. Root cause: PCIe test expects enumerated PCIe endpoint devices (checks for "Capabilities:" string from lspci output), but kaanapali-mtp board has no PCIe devices physically connected despite PCIe controller successfully probing and link training completing (Gen.3 x2 link up at 5.932s). Test also reports "DT node is not present" and "Driver is not loaded" warnings, indicating the test script's device detection logic does not recognize the successfully initialized PCIe root complex at 1c00000.pcie.
3. Possible fix: This is a test infrastructure issue, not a kernel regression. The PR introduces no PCIe-related code changes for kaanapali. Fix options: (1) Update the PCIe test script to distinguish between "PCIe controller not functional" vs "no endpoint devices connected" and mark the latter as SKIP rather than FAIL when the root complex is operational. (2) Connect a PCIe endpoint device (e.g., NVMe, WiFi card) to the kaanapali-mtp test fixture. (3) Mark this test as expected-fail or skip for kaanapali-mtp in the LAVA job definition until hardware is available.
4. Detail analysis attachment: failed_case_job225068_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no physical USB device connected to kaanapali-mtp USB host port during test execution; kernel USB subsystem initialized correctly (dwc3_qcom loaded, USB controller at a600000.usb probed successfully), but test expects at least one USB device to be enumerated.
3. Possible fix: Connect a USB device (e.g., USB flash drive, USB keyboard, or USB hub) to the kaanapali-mtp board's USB host port before running the USBHost test; alternatively, update the test to skip or pass when no USB devices are present if USB host functionality is not a validation requirement for this PR.
4. Detail analysis attachment: failed_case_job225068_2_detailed.md

  Case 3: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Bluetooth HCI command 0xfc00 (QCA vendor-specific version read) times out repeatedly with -ETIMEDOUT (-110), preventing firmware download and Bluetooth stack initialization on kaanapali-mtp (WCN7850 controller).
3. Possible fix: Investigate whether PR#1085 Bluetooth changes (QCC2072 support additions in drivers/bluetooth/hci_qca.c) inadvertently affect WCN7850 initialization timing or command handling; verify WCN7850 firmware (qca/hmtbtfw20.tlv) is present and accessible; check for power sequencing or clock/regulator issues specific to kaanapali-mtp that may cause HCI transport layer timeouts.
4. Detail analysis attachment: failed_case_job225068_3_detailed.md

  Case 4: BT_ON_OFF

1. Failed case: BT_ON_OFF
2. Root cause: Bluetooth firmware initialization repeatedly fails with timeout (-ETIMEDOUT) when reading QCA version information from the QCA6390 Bluetooth controller on kaanapali-mtp; the hci0 adapter never acquires a valid BD address, preventing Bluetooth runtime from becoming operational.
3. Possible fix: Investigate QCA6390 Bluetooth controller power sequencing and UART communication path on kaanapali-mtp; verify that the pwrseq_qcom_wcn power sequencer is correctly enabling BT_EN and providing stable clocks before firmware download; check for conflicts with concurrent DPU (display) activity that may be starving the Bluetooth UART or causing system-wide timing issues; if the issue is PR-introduced, bisect the DRM/MSM display changes in this PR to identify any resource contention or power management regressions affecting the Bluetooth subsystem.
4. Detail analysis attachment: failed_case_job225068_4_detailed.md

  Case 5: Test Timeout — DPU Encoder Frame Done Timeout (Display Subsystem Regression)

1. Failed case: Test Timeout — DPU Encoder Frame Done Timeout (Display Subsystem Regression)
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 introduces changes to dpu_encoder_get_intf() that add stream_id matching logic (cnt++ == stream_id), causing the DPU encoder (enc35) to fail wait_for_idle operations with -ETIMEDOUT (-110) starting at 6.6 seconds into boot and persisting throughout the 40-minute test run, ultimately causing LAVA test-shell timeout on kaanapali-mtp.
3. Possible fix: Revert or fix the stream_id matching logic in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:dpu_encoder_get_intf() — the new condition && cnt++ == stream_id appears to prevent correct interface selection for kaanapali-mtp's display configuration, causing encoder initialization to fail and frame done callbacks to never complete.
4. Detail analysis attachment: failed_case_job225068_5_detailed.md

  Case 6: lava-test-shell timeout

1. Failed case: lava-test-shell timeout
2. Root cause: LAVA test timed out after 2400 seconds due to persistent DRM/MSM display subsystem errors on kaanapali-mtp — DSI link clock configuration failed with -EINVAL at boot, causing continuous DPU encoder frame done timeouts (enc35) and vblank wait timeouts that prevented test completion.
3. Possible fix: Investigate PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 DRM/MSM changes for kaanapali-mtp (SM8650) display initialization regression — specifically DSI pixel clock rate setting in dsi_link_clk_set_rate_6g() and DPU encoder frame completion signaling for encoder ID 35; revert or fix the clock configuration logic that returns -EINVAL during msm_dsi_host_power_on().
4. Detail analysis attachment: failed_case_job225068_6_detailed.md

  Case 7: lava-test-retry — Test timeout caused by continuous DPU encoder failures

1. Failed case: lava-test-retry — Test timeout caused by continuous DPU encoder failures
2. Root cause: PR introduces DPU encoder regression on kaanapali-mtp causing DSI link clock initialization failure (-EINVAL) at boot, leading to continuous DPU encoder frame timeout errors (30,242 occurrences) that prevent test completion within the 2400-second LAVA timeout.
3. Possible fix: Revert or fix the dpu_encoder_get_intf() changes in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c that modify interface selection logic by adding stream_id matching — the new logic incorrectly selects the display interface for kaanapali-mtp's DSI panel, causing clock rate setting to fail with -EINVAL.
4. Detail analysis attachment: failed_case_job225068_7_detailed.md

  Case 8: LAVA Test Timeout — lava-test-shell exceeded 2400s limit

1. Failed case: LAVA Test Timeout — lava-test-shell exceeded 2400s limit
2. Root cause: The LAVA test suite timed out after 2400 seconds while running the BT_SCAN test following a failed BT_ON_OFF test. The timeout is a LAVA infrastructure limit, not a kernel crash. The system was making forward progress (kernel scheduler, interrupts, and test execution continued) but the test suite did not complete within the allocated time window. Contributing factor: continuous DPU encoder errors (dpu_encoder_phys_cmd_prepare_for_kickoff failed wait_for_idle: id:35 ret:-110) from early boot may have degraded system performance.
3. Possible fix: Re-trigger the LAVA job with an increased test timeout (from 2400s to 3600s or 4800s) in the LAVA job definition. If the timeout recurs, investigate why BT_SCAN hangs: check Bluetooth firmware loading, bluetoothd service status, and whether the DPU display errors are blocking system resources. The DPU encoder timeout errors should be investigated separately as they indicate a display subsystem issue unrelated to the test timeout.
4. Detail analysis attachment: failed_case_job225068_8_detailed.md

Job 225069 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two benign probe/firmware errors detected during boot on hamoa-evk: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16), likely due to resource conflict or the device being claimed by another driver/interface; (2) regulatory.db firmware file missing (-ENOENT, -2), a known non-critical issue when the regulatory database is compiled into the kernel or not required for the wireless configuration.
3. Possible fix: These are pre-existing platform-specific issues unrelated to PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes (which add documentation, device tree bindings, and a new mutually-exclusive TEE driver). The qseecom probe failure may indicate the platform uses QCOMTEE instead of QSEECOM for UEFI secure app access. The regulatory.db failure is benign if CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n or the database is built-in. To suppress these known benign failures in CI, update the Probe_Failure_Check test to exclude: (a) qcom_qseecom_uefisecapp probe failures on platforms without RPMB-in-SPI-NOR, and (b) regulatory.db firmware load failures when cfg80211 loads successfully.
4. Detail analysis attachment: failed_case_job225069_1_detailed.md

  Case 2: ** smmu (test validation failure — not a kernel crash)

1. Failed case: ** smmu (test validation failure — not a kernel crash)
2. Root cause: ** The SMMU test on hamoa-evk (x7181) expects the video codec device (aa00000.video-codec) to be attached to an IOMMU group for memory protection, but the device is not attached. The video codec driver (qcom-iris) probed successfully and the device is functional (firmware loaded, no runtime errors), but the IOMMU subsystem did not attach it to a group. This indicates the device tree for hamoa-evk does not specify an iommus property for the video codec node, or the test expectation is incorrect for this platform.
3. Possible fix: Verify the device tree source for hamoa-evk (arch/arm64/boot/dts/qcom/x7181-*.dts*) and confirm whether the video codec node (video-codec@aa00000) includes an iommus property pointing to the SMMU. If missing, add the property following the pattern used by other protected masters (UFS at group 3, GPU at group 14, Display at group 11, USB at groups 6-10) on this platform. If the video codec on hamoa-evk is intentionally not IOMMU-protected due to hardware or firmware limitations, update the test to exclude this device from the critical master check on this SoC.
4. Detail analysis attachment: failed_case_job225069_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because hypervisor (EL2) mode is not available on the hamoa-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot, causing /dev/kvm device node creation to be skipped.
3. Possible fix: This is a test expectation mismatch, not a kernel regression. The hamoa-evk platform does not support KVM/virtualization (no EL2 hypervisor mode available). Either: (1) exclude KVM tests from the hamoa-evk test suite, or (2) if KVM support is expected on this platform, investigate the bootloader/firmware configuration to ensure the CPU is booted at EL2 and hypervisor mode is enabled.
4. Detail analysis attachment: failed_case_job225069_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM Driver Initialization Failure

1. Failed case: KVM_EL2_DTB — KVM Driver Initialization Failure
2. Root cause: KVM driver reports "HYP mode not available" because the hamoa-iot-evk platform firmware/bootloader has not enabled EL2 (Hypervisor Exception Level) access, preventing KVM from initializing and creating /dev/kvm. This is a platform configuration limitation, not a kernel regression.
3. Possible fix: This is a known platform limitation for hamoa-iot-evk in non-EL2 boot mode. To enable KVM: (1) Use the hamoa-iot-evk-el2.dtb variant which configures EL2 boot, or (2) Update bootloader/firmware to enable EL2 access before kernel boot. For CI: mark KVM tests as expected-fail for hamoa-iot-evk base configuration, or configure LAVA job to use the -el2 DTB variant when testing KVM functionality.
4. Detail analysis attachment: failed_case_job225069_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed with "HYP mode not available" because hamoa-evk boots under Gunyah hypervisor at EL1, preventing access to EL2/HYP mode required for KVM operation.
3. Possible fix: This is expected behavior, not a bug. Either: (1) exclude KVM tests from hamoa-evk LAVA jobs when running under hypervisor, or (2) use a non-virtualized boot configuration (without Gunyah) if KVM testing is required on this platform.
4. Detail analysis attachment: failed_case_job225069_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests — Test Infrastructure Issue (KVM unavailable on platform)

1. Failed case: 0_qcom-next-ci-premerge-tests — Test Infrastructure Issue (KVM unavailable on platform)
2. Root cause: The hamoa-evk platform does not support ARM EL2/HYP mode, as evidenced by kernel message "[3.211969] kvm [1]: HYP mode not available" during boot. This causes all three KVM test cases (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail because /dev/kvm cannot be created without hypervisor support. This is a hardware/firmware platform limitation, not a kernel regression.
3. Possible fix: Exclude KVM tests from the hamoa-evk test suite, as this platform does not have EL2/HYP mode support required for KVM functionality. The PR patch contains no KVM-related changes and does not introduce this issue.
4. Detail analysis attachment: failed_case_job225069_6_detailed.md

[qcomlnxci]

Test jobs on 84c4976

• multimedia Job 227840 on glymur-crd
• multimedia Job 227839 on hamoa-iot-evk
• multimedia Job 227829 on kaanapali-mtp
• multimedia Job 227835 on lemans-evk
• multimedia Job 227836 on monaco-evk
• multimedia Job 227834 on purwa-iot-evk
• multimedia Job 227830 on qcs615-ride
• multimedia Job 227831 on qcs6490-rb3gen2
• multimedia Job 227828 on qcs8300-ride
• multimedia Job 227837 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227833 on shikra-iqs-evk
• multimedia Job 227832 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 84c4976

• multimedia Job 227840 on glymur-crd
• multimedia Job 227839 on hamoa-iot-evk
• multimedia Job 227829 on kaanapali-mtp
• multimedia Job 227835 on lemans-evk
• multimedia Job 227836 on monaco-evk
• multimedia Job 227834 on purwa-iot-evk
• multimedia Job 227892 on qcs615-ride
• multimedia Job 227831 on qcs6490-rb3gen2
• multimedia Job 227828 on qcs8300-ride
• multimedia Job 227837 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227833 on shikra-iqs-evk
• multimedia Job 227832 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 912d106

• multimedia Job 227919 on glymur-crd
• multimedia Job 227914 on hamoa-iot-evk
• multimedia Job 227915 on kaanapali-mtp
• multimedia Job 227912 on lemans-evk
• multimedia Job 227916 on monaco-evk
• multimedia Job 227911 on purwa-iot-evk
• multimedia Job 227913 on qcs615-ride
• multimedia Job 227910 on qcs6490-rb3gen2
• multimedia Job 227918 on qcs8300-ride
• multimedia Job 227920 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227917 on shikra-iqs-evk
• multimedia Job 227909 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 064621d

• multimedia Job 228564 on glymur-crd
• multimedia Job 228558 on hamoa-iot-evk
• multimedia Job 228559 on kaanapali-mtp
• multimedia Job 228562 on lemans-evk
• multimedia Job 228556 on monaco-evk
• multimedia Job 228560 on purwa-iot-evk
• multimedia Job 228561 on qcs615-ride
• multimedia Job 228557 on qcs6490-rb3gen2
• multimedia Job 228566 on qcs8300-ride
• multimedia Job 228563 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 228567 on shikra-iqs-evk
• multimedia Job 228565 on sm8750-mtp

[qcomlnxci]

Test Matrix

Test Case	glymur-crd-multimedia	hamoa-iot-evk-multimedia	kaanapali-mtp-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	sm8750-mtp-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	⚠️ skip	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
USBHost	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	❌ Fail	⚠️ skip
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
WiFi_OnOff	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	❌ Fail
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ 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	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass
watchdog	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1085

Job 228556 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — WiFi Driver Probe Failure

1. Failed case: Probe_Failure_Check — WiFi Driver Probe Failure
2. Root cause: WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory on Monaco EVK. The ath11k_pci driver cannot initialize the WCN6855 WiFi hardware without this board-specific firmware, causing probe to timeout with error -110 (ETIMEDOUT). This is a pre-existing infrastructure issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085, which only adds device tree bindings and documentation.
3. Possible fix: Add the missing Monaco-specific WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/) in the Monaco EVK build configuration. Verify the firmware is sourced from the correct linux-firmware repository or vendor firmware package for Monaco platform.
4. Detail analysis attachment: failed_case_job228556_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 an iommus property to the parent iris: video-codec@aa00000 node in arch/arm64/boot/dts/qcom/monaco.dtsi (or qcs8300.dtsi if monaco inherits from it). The property should reference the appropriate SMMU stream IDs for the video codec hardware. Alternatively, if the video codec driver is designed to use only child-node iommus (as in the newer Iris video codec architecture), update the SMMU test logic to recognize this pattern and check child nodes when the parent is a video codec device.
4. Detail analysis attachment: failed_case_job228556_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci firmware dependency

1. Failed case: WiFi Driver Probe Failure — ath11k_pci firmware dependency
2. Root cause: ath11k_pci probe failed with error -110 (ETIMEDOUT) on Monaco EVK because MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (Direct firmware load failed with error -2 / ENOENT).
3. Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/), or if the firmware path has changed, update the driver's firmware path table to match the available firmware location in the rootfs.
4. Detail analysis attachment: failed_case_job228556_3_detailed.md

  Case 4: ** WiFi_OnOff — Driver Probe Failure

1. Failed case: ** WiFi_OnOff — Driver Probe Failure
2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT because the required WCN6855 firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) is missing from the rootfs /lib/firmware/ directory. MHI power-up timed out waiting for the chip to respond after firmware load failure.
3. Possible fix: Add the missing WCN6855 firmware files to the Yocto image recipe for monaco-evk. Ensure linux-firmware-ath11k or equivalent package includes ath11k/WCN6855/hw2.1/nfa765/amss.bin and related firmware blobs. Rebuild the rootfs and re-test.
4. Detail analysis attachment: failed_case_job228556_4_detailed.md

  Case 5: 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) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI initialization to timeout during probe.
3. Possible fix: Add the missing ath11k firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image, or if the firmware path has changed in the PR, update the driver's firmware request path to match the available firmware location.
4. Detail analysis attachment: failed_case_job228556_5_detailed.md

Job 228557 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test flagged benign firmware load failures (regulatory.db for WiFi and modem.mbn for non-autoboot modem) that do not affect system functionality; WiFi tests passed and modem is correctly offline as a non-autoboot processor on qcs6490-rb3gen2.
3. Possible fix: Suppress these known-benign firmware load failures in the Probe_Failure_Check test: (1) regulatory.db is optional and WiFi functional tests pass, (2) modem.mbn failure is expected for non-autoboot modem configuration where state=offline is valid.
4. Detail analysis attachment: failed_case_job228557_1_detailed.md

  Case 2: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: qcs6490-rb3gen2 (Kodiak) platform does not boot in EL2 (hypervisor) mode by default; KVM requires EL2 support which is unavailable when the base device tree is used without the kodiak-el2.dtso overlay.
3. Possible fix: Apply the kodiak-el2.dtso device tree overlay during boot to enable EL2 mode, or mark KVM tests as expected-to-skip for qcs6490-rb3gen2 when running without the EL2 overlay.
4. Detail analysis attachment: failed_case_job228557_2_detailed.md

  Case 3: ** KVM_EL2_DTB — Platform does not support ARM EL2 (Hypervisor mode)

1. Failed case: ** KVM_EL2_DTB — Platform does not support ARM EL2 (Hypervisor mode)
2. Root cause: ** qcs6490-rb3gen2 platform does not provide EL2 (Hypervisor mode) to Linux; KVM initialization prints "HYP mode not available" and skips device creation, causing /dev/kvm to be absent and all KVM tests to fail. This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Exclude KVM tests from LAVA job definition for rb3gen2/Kodiak platform, or update test runner to skip KVM tests gracefully when /dev/kvm is not present. Long-term: work with firmware team to enable EL2 passthrough if hardware supports it.
4. Detail analysis attachment: failed_case_job228557_3_detailed.md

  Case 4: ** KVM_Infra — KVM Host Initialization Failure (HYP mode unavailable)

1. Failed case: ** KVM_Infra — KVM Host Initialization Failure (HYP mode unavailable)
2. Root cause: ** The qcs6490-rb3gen2 platform runs under the Gunyah Type-1 hypervisor which occupies EL2 (HYP mode). KVM requires exclusive EL2 access to function as a Type-2 hypervisor. When KVM initialization code detects EL2 is already claimed by Gunyah, it correctly fails with "HYP mode not available" and does not create /dev/kvm. This is expected architectural behavior, not a bug.
3. Possible fix: Update the LAVA KVM test suite to detect hypervisor presence (check for "Hypervisor cold boot, version: gunyah" in dmesg) and skip KVM tests with result=SKIP instead of result=FAIL, with message "KVM not applicable on Gunyah platforms (EL2 unavailable)". This is a test infrastructure fix, not a kernel fix.
4. Detail analysis attachment: failed_case_job228557_4_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the overall test definition as failed because 4 individual test cases failed (Probe_Failure_Check, KVM_Driver, KVM_EL2_DTB, KVM_Infra), even though the test runner completed successfully and the failures are pre-existing platform issues unrelated to the PR changes (documentation/binding updates only).
3. Possible fix: The PR itself is not the cause. The genuine failures are: (1) Probe_Failure_Check failed due to missing firmware files (regulatory.db, modem.mbn) - these are expected on this platform configuration and should be added to the known-benign suppression list or the firmware files should be provided in the rootfs; (2) KVM tests failed because /dev/kvm is not present - KVM is not enabled/functional on this qcs6490-rb3gen2 platform configuration, these tests should be skipped for this target or KVM support should be enabled in the kernel config and device tree.
4. Detail analysis attachment: failed_case_job228557_5_detailed.md

Job 228558 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: qcom_tee_uefisecapp driver probe fails with -EBUSY because efivars are already registered by another driver (likely the generic EFI runtime services driver), creating a resource conflict during boot on hamoa-evk.
3. Possible fix: Add mutual exclusion logic to prevent duplicate efivars registration — either make efivars_register() idempotent with a check-and-skip path, or add a DT/Kconfig option to select which driver should register efivars on Qualcomm platforms with TEE-based UEFI variable storage.
4. Detail analysis attachment: failed_case_job228558_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The PR adds a new iris video-codec device node at aa00000.video-codec for the hamoa-evk (glymur) platform without an iommus property at the top-level device node. The SMMU test correctly detects that this critical video master lacks IOMMU group attachment, which is required for DMA protection on Qualcomm platforms.
3. Possible fix: Add an iommus property to the top-level iris: video-codec@aa00000 device node in the hamoa-evk device tree, following the pattern used by other critical masters (UFS, GPU, USB, Display) which all have IOMMU group attachments. The child nodes (iris_non_pixel and pixel) already have iommus properties, but the parent device node also requires one for proper SMMU protection.
4. Detail analysis attachment: failed_case_job228558_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the ARM CPU is not running in EL2 (hypervisor) mode on the hamoa-evk platform. The kernel explicitly reports "HYP mode not available" during KVM driver initialization. The test is using the base hamoa-iot-evk.dtb without the EL2 device tree overlay, so virtualization extensions are not enabled by the bootloader/firmware.
3. Possible fix: Use the EL2-enabled device tree variant for this platform. The LAVA job definition should flash and boot hamoa-iot-evk-el2.dtb (base DTB + x1-el2.dtbo overlay) instead of the base hamoa-iot-evk.dtb. Alternatively, if KVM support is not required for this test configuration, mark KVM tests as expected-to-skip for non-EL2 builds.
4. Detail analysis attachment: failed_case_job228558_3_detailed.md

  Case 4: KVM Driver Probe Failure — /dev/kvm not available (HYP mode not available)

1. Failed case: KVM Driver Probe Failure — /dev/kvm not available (HYP mode not available)
2. Root cause: The hamoa-evk board is running in EL1 mode (not EL2/hypervisor mode) because the base device tree hamoa-iot-evk.dtb is loaded instead of the EL2-enabled variant hamoa-iot-evk-el2.dtb. KVM requires ARM EL2 (HYP mode) to function; the kernel correctly detects HYP mode is unavailable and skips KVM initialization, resulting in no /dev/kvm device node.
3. Possible fix: Update the LAVA job definition to use the EL2-enabled device tree hamoa-iot-evk-el2.dtb (which applies the x1-el2.dtbo overlay) when running KVM/virtualization tests on hamoa-evk. Alternatively, skip KVM tests on non-EL2 configurations or add a test prerequisite check for EL2 availability before running KVM test cases.
4. Detail analysis attachment: failed_case_job228558_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available on the Hamoa IoT EVK platform — kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware does not provide EL2 virtualization support required for KVM operation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The Hamoa IoT EVK does not support EL2/HYP mode required for KVM. Either: (1) exclude KVM tests from the Hamoa test suite, or (2) run KVM tests only on platforms with EL2 support (e.g., RB5, SA8775P), or (3) if EL2 support is expected on Hamoa, verify bootloader/TZ firmware configuration enables EL2 and is not forcing the kernel to boot at EL1.
4. Detail analysis attachment: failed_case_job228558_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because the platform is not running in EL2 (hypervisor mode). The kernel message "kvm [1]: HYP mode not available" at boot indicates the bootloader/firmware did not enter the kernel at EL2, which is required for ARM64 KVM/virtualization support on hamoa-evk.
3. Possible fix: This is a platform/firmware/bootloader configuration issue, not a kernel regression. The hamoa-evk board must be configured to boot the kernel at EL2 to enable KVM. Verify bootloader configuration (e.g., ABL/UEFI) ensures EL2 entry, or check if the board/SoC supports virtualization extensions and EL2 boot mode. If the board does not support EL2 boot, mark KVM tests as expected-fail for this platform.
4. Detail analysis attachment: failed_case_job228558_6_detailed.md

Job 228559 | SoC kaanapali-mtp

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

Failed test cases in LAVA job 228559 (SoC: kaanapali-mtp).

  Case 1: PCIe

1. Failed case: PCIe
2. Root cause: PCIe endpoint device 0x17cb:0x110e (Qualcomm WiFi controller, class 0x028000) is enumerated successfully but has no kernel driver bound because no driver (ath12k_pci, ath11k_pci, or other) includes this device ID in its pci_device_id table. This is a pre-existing platform configuration issue, not a PR-introduced regression.
3. Possible fix: Add device ID 0x17cb:0x110e to the appropriate WiFi driver's PCI device ID table (likely ath12k_pci or ath11k_pci based on vendor ID and device class), or mark this test as expected-fail/skip for kaanapali-mtp until the device is supported upstream.
4. Detail analysis attachment: failed_case_job228559_1_detailed.md

  Case 2: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Bluetooth firmware download repeatedly fails with HCI command timeout (-110 ETIMEDOUT) during TLV segment transmission to WCN7850 controller; the hci0 adapter never completes initialization and remains in DOWN state with invalid BD address (00:00:00:00:00:00).
3. Possible fix: This is a hardware communication failure between the AP and the WCN7850 Bluetooth controller over UART. Verify: (1) UART pinmux/pinctrl configuration for the serial@1994000 node in kaanapali DT, (2) WCN7850 power sequencing (enable-gpios, regulators), (3) firmware file integrity (/lib/firmware/qca/hmtbtfw20.tlv), (4) check for concurrent DPU display subsystem errors (27K+ dpu_encoder errors flooding the log) that may indicate broader platform instability or interrupt storm affecting UART communication.
4. Detail analysis attachment: failed_case_job228559_2_detailed.md

  Case 3: BT_ON_OFF

1. Failed case: BT_ON_OFF
2. Root cause: Bluetooth adapter hci0 failed to obtain a valid BD address after 40 seconds and 2 controlled recovery attempts due to repeated command timeouts (-110 / ETIMEDOUT) during QCA firmware download (qca/hmtbtfw20.tlv) and version information reads, indicating the Bluetooth controller is not responding to HCI commands over the UART transport.
3. Possible fix: This is a hardware/firmware communication failure, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR contains no Bluetooth driver changes. Recommended actions: (1) Verify the Bluetooth hardware is properly powered and the UART connection is functional on the kaanapali-mtp board; (2) Check if the QCA Bluetooth firmware files (qca/hmtbtfw20.tlv) are present and valid in the rootfs; (3) Re-trigger the test on a different kaanapali-mtp board to rule out board-specific hardware failure; (4) If the issue persists across multiple boards, investigate potential power sequencing or clock configuration issues for the Bluetooth subsystem on kaanapali-mtp.
4. Detail analysis attachment: failed_case_job228559_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 suite timed out after 2400 seconds due to continuous DRM/DPU display subsystem failures (vblank wait timeouts and DPU encoder wait_for_idle failures with -ETIMEDOUT) starting from early boot and persisting throughout the entire test run, preventing normal test execution and causing the Bluetooth ON/OFF test to fail and the suite to exceed its timeout limit.
3. Possible fix: Investigate the DRM/DPU display driver regression introduced by this PR — the continuous "dpu_encoder_phys_cmd_prepare_for_kickoff: failed wait_for_idle: id:35 ret:-110 pp:0" and "vblank wait timed out on crtc 0" errors indicate the display hardware is not responding to commands. Check if the PR modifies any display-related device tree bindings, clock configurations, or MDSS/DPU driver code for kaanapali-mtp (SM8650). If no display changes are present in the PR, this may be a pre-existing platform issue that needs separate investigation.
4. Detail analysis attachment: failed_case_job228559_4_detailed.md

  Case 5: lava-test-shell timeout (DRM/DPU display driver hang)

1. Failed case: lava-test-shell timeout (DRM/DPU display driver hang)
2. Root cause: DPU encoder (enc35) continuously fails to complete frame rendering with "failed wait_for_idle: id:35 ret:-110 pp:0" and "frame done timeout" errors, flooding the console and preventing test execution from completing within the 2400-second timeout. The PR modifies dpu_encoder_get_intf() to add stream_id matching logic, which may cause incorrect interface selection or initialization for the kaanapali-mtp display hardware.
3. Possible fix: Revert or fix the dpu_encoder_get_intf() changes in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c. The new stream_id matching logic (cnt++ == stream_id) may be selecting the wrong hardware interface or failing to match any interface when stream_id is non-zero, causing the encoder to operate with an improperly configured or NULL interface pointer. Verify that disp_info->stream_id is correctly initialized for single-stream (non-MST) displays on kaanapali-mtp.
4. Detail analysis attachment: failed_case_job228559_5_detailed.md

  Case 6: ** LAVA Test Timeout — DPU Hardware Hang (lava-test-retry)

1. Failed case: ** LAVA Test Timeout — DPU Hardware Hang (lava-test-retry)
2. Root cause: ** The kaanapali-mtp board's DPU encoder (id:35) entered a persistent hardware timeout state starting at kernel boot (6.085s) and continuing for the entire 40-minute test duration (2441.777s), generating 27,352 repeated errors: [drm:dpu_encoder_phys_cmd_prepare_for_kickoff [msm]] *ERROR* failed wait_for_idle: id:35 ret:-110 pp:0 and [drm:dpu_encoder_frame_done_timeout:2731] [dpu error]enc35 frame done timeout. The display hardware failed to acknowledge frame completion interrupts, causing the DRM subsystem to spin in timeout loops. This prevented the LAVA test suite (qcom-next-ci-premerge-tests) from making progress, triggering the LAVA infrastructure's 2400-second test timeout.
3. Possible fix: This is a hardware-level display subsystem failure specific to kaanapali-mtp. The PR introduces display bridge driver changes (lontium-lt9611c, aux-hpd-bridge, lt9211) and DT binding updates for MSM display controllers. Recommended actions: (1) Immediate: Re-trigger the CI job on a different kaanapali-mtp board to rule out board-specific hardware fault. (2) Short-term: If failure reproduces, bisect the PR's display-related commits (drivers/gpu/drm/bridge/, Documentation/devicetree/bindings/display/msm/) to identify which change breaks DPU encoder frame completion on kaanapali. (3) Proper fix: Add DPU encoder initialization checks and frame-done timeout recovery logic to prevent infinite error loops; ensure display bridge HPD (hot-plug detect) changes in aux-hpd-bridge.c do not break MSM DPU interrupt delivery on kaanapali SoC.
4. Detail analysis attachment: failed_case_job228559_6_detailed.md

  Case 7: Test Timeout — Bluetooth firmware loading failure causing test suite timeout

1. Failed case: Test Timeout — Bluetooth firmware loading failure causing test suite timeout
2. Root cause: Bluetooth firmware loading repeatedly fails with HCI command timeout (0xfc00 tx timeout -110) when attempting to download qca/hmtbtfw20.tlv, preventing BT_ON_OFF and BT_SCAN tests from completing; LAVA test shell timed out after 2400 seconds waiting for Bluetooth recovery to succeed.
3. Possible fix: Investigate the Bluetooth driver changes in pr.patch (btqca.c, btqca.h, hci_qca.c) for regressions in firmware loading path; specifically review the qca_combine_nvm_calib() function addition and any changes to TLV segment transmission logic; verify firmware file qca/hmtbtfw20.tlv is present and accessible on the kaanapali-mtp target; if PR changes are root cause, revert or fix the firmware loading regression before merge.
4. Detail analysis attachment: failed_case_job228559_7_detailed.md

Job 228560 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform-specific probe failures on purwa-evk (IQ-X5121): (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource conflict, (2) two qcom-pcie controllers fail with -ENODATA because PCIe PHY init sequences are unavailable for this SoC, (3) regulatory.db firmware missing (benign), and (4) video codec aa00000.video-codec missing IOMMU group attachment in DT/driver configuration.
3. Possible fix: These are known platform bring-up issues for purwa-evk, not regressions from PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. Suppress this test case for purwa-evk until: (1) TrustZone firmware/driver initialization order is fixed for qseecom, (2) PCIe PHY init sequences are added to the PHY driver for this SoC variant, and (3) video codec IOMMU binding is added to the device tree. The PR can proceed to merge as it does not introduce these failures.
4. Detail analysis attachment: failed_case_job228560_1_detailed.md

  Case 2: smmu — Video codec IOMMU group attachment missing

1. Failed case: smmu — Video codec IOMMU group attachment missing
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 adds a new video codec device node (iris: video-codec@aa00000) to the purwa-evk (glymur SoC) device tree but omits the mandatory iommus property, causing the video codec to not be attached to any IOMMU group. The SMMU test detected this as a critical security/functionality violation: "Critical master is missing iommu_group attachment, Video aa00000.video-codec".
3. Possible fix: Add the missing iommus property to the iris: video-codec@aa00000 node in the purwa/glymur device tree file. Based on the binding documentation in the PR (qcom,sm8450-videocc.yaml example shows iommus = <&apps_smmu 0x800 0x2>), add an appropriate iommus entry for the video codec device referencing the correct SMMU instance and stream IDs for the purwa platform.
4. Detail analysis attachment: failed_case_job228560_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on purwa-evk because the platform is running under Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode. Kernel message: kvm [1]: HYP mode not available at boot time 2.925286s.
3. Possible fix: This is not a bug or PR-introduced regression. The KVM_Driver test should be skipped on platforms running under Gunyah hypervisor. Add platform detection logic to the test suite to skip KVM tests when Gunyah is detected (check for "Gunyah based bootup" or reserved memory region "gunyah-hyp@80000000" in boot log).
4. Detail analysis attachment: failed_case_job228560_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 (gunyah-mobile-ad1fb25c6) has taken control of EL2 (HYP mode) during boot, preventing KVM from accessing the required privilege level; kernel logs show "kvm [1]: HYP mode not available" at boot time, causing /dev/kvm device node creation to fail.
3. Possible fix: This is expected behavior on platforms with a hypervisor present. To enable KVM testing: (1) disable the Gunyah hypervisor in the boot configuration, OR (2) configure KVM to run as a nested hypervisor under Gunyah (requires CONFIG_KVM_NESTED=y and hypervisor support for nested virtualization), OR (3) mark KVM tests as "skip" for purwa-evk in the LAVA test definition since this platform is designed to run with Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job228560_4_detailed.md

  Case 5: KVM_Infra — Platform Hardware Limitation (No Virtualization Support)

1. Failed case: KVM_Infra — Platform Hardware Limitation (No Virtualization Support)
2. Root cause: The Purwa IoT EVK SoC does not support ARM Virtualization Extensions (EL2/HYP mode), which is a mandatory hardware prerequisite for KVM. The kernel message kvm [1]: HYP mode not available at boot confirms the CPU does not provide EL2 exception level, preventing KVM initialization and /dev/kvm device node creation.
3. Possible fix: Exclude KVM tests from the LAVA test suite for purwa-evk and other platforms without ARM Virtualization Extensions. Add a platform capability check in the CI job definition to skip virtualization tests when CONFIG_KVM=y but HYP mode is unavailable. This is not a kernel bug or PR-introduced regression—it is expected behavior on non-virtualization-capable hardware.
4. Detail analysis attachment: failed_case_job228560_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because HYP (Hypervisor) mode is not available on the Purwa IoT EVK platform — kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware does not support EL2 virtualization, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform limitation, not a PR-introduced regression. The Purwa IoT EVK does not support KVM/virtualization in its current firmware/hardware configuration. Either: (1) exclude KVM tests from the Purwa EVK test plan, or (2) update the test to skip gracefully when HYP mode is unavailable, or (3) enable virtualization support in the platform firmware if the hardware supports it.
4. Detail analysis attachment: failed_case_job228560_6_detailed.md

Job 228561 | SoC qcs615-ride

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

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

  Case 1: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The SMMU test validation expects video codec child devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be individually attached to IOMMU groups, but only the parent device (aa00000.video-codec) is attached to IOMMU group 6. This is a test expectation mismatch, not a kernel crash or SMMU hardware failure. The kernel successfully initialized SMMU (24 IOMMU groups created), attached all critical masters including the parent video codec device, and reported no SMMU/IOMMU errors in dmesg.
3. Possible fix: Update the SMMU test validation logic to accept parent-only IOMMU group attachment for video codec devices on qcs615-ride, or modify the video codec driver/device tree to explicitly attach child devices to IOMMU groups if per-subdevice isolation is required. This is not a PR-introduced regression—the PR changes PCIe GPIO configuration, PSCI reboot modes, and QSPI flash, none of which affect video codec IOMMU attachment.
4. Detail analysis attachment: failed_case_job228561_1_detailed.md

  Case 2: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Bluetooth WCN6855 chip on qcs615-ride board fails to respond to HCI command 0xfc00 (QCA version query) over UART, resulting in repeated command timeouts (-ETIMEDOUT/-110). This is a hardware communication failure between the kernel Bluetooth driver and the Bluetooth controller, not a software regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: This is a pre-existing board/firmware/infrastructure issue, not introduced by the PR. The PR modifies Bluetooth drivers to add QCC2072 support, but all changes are properly guarded with if (soc_type == QCA_QCC2072) checks and do not affect the WCN6855 code path. Recommended actions: (1) Verify Bluetooth hardware power sequencing and UART wiring on qcs615-ride board; (2) Check if Bluetooth firmware files are present and correct for WCN6855; (3) Verify UART configuration (baudrate, flow control) matches hardware expectations; (4) Test Bluetooth on qcs615-ride with a known-good kernel baseline to confirm this is not a board-specific hardware failure.
4. Detail analysis attachment: failed_case_job228561_2_detailed.md

  Case 3: BT_ON_OFF

1. Failed case: BT_ON_OFF
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Investigate WCN6855 hardware communication path on qcs615-ride: (1) verify UART serial@a8c000 (ttyHS1) pinctrl configuration, baud rate, and flow control settings in device tree match WCN6855 requirements; (2) confirm WCN6855 power sequencing (regulators, enable GPIOs, clocks) is correct and the chip is powered before UART communication begins; (3) check for UART signal integrity issues or hardware faults on the qcs615-ride board; (4) verify the btqca driver and hci_uart modules are using the correct protocol and timing for WCN6855; (5) cross-reference with known-good qcs615-ride Bluetooth configurations to identify any missing DT properties or regulator dependencies.
4. Detail analysis attachment: failed_case_job228561_3_detailed.md

  Case 4: ** Bluetooth Driver Initialization Failure — BT_SCAN

1. Failed case: ** Bluetooth Driver Initialization Failure — BT_SCAN
2. Root cause: ** Bluetooth HCI command 0xfc00 (QCA version read) times out repeatedly with error -110 (ETIMEDOUT), preventing WCN6855 Bluetooth controller initialization on qcs615-ride. The failure occurs at the earliest driver-firmware handshake stage. PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 modifies core Bluetooth QCA driver code paths (hci_qca.c, btqca.c) including new calibration logic, device tree parsing (of_graph.h), and QCC2072 chip support. These changes likely introduce a regression affecting WCN6855 initialization sequence, power sequencing, or UART communication path on qcs615-ride platform.
3. Possible fix: Revert or isolate the PR changes to QCA Bluetooth driver initialization paths. Specifically: (1) Verify that the new qca_combine_nvm_calib() function does not break WCN6855 calibration file loading. (2) Ensure the new of_graph.h include and any associated device tree parsing does not affect WCN6855 probe sequence. (3) Confirm that QCC2072 case additions do not alter default behavior for WCN6855. (4) Test on qcs615-ride hardware to reproduce and validate the fix. If the issue persists, add debug logging to hci_qca.c around UART communication and power sequencing to identify the exact failure point.
4. Detail analysis attachment: failed_case_job228561_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update LAVA test suite to skip KVM tests on Gunyah-based platforms by detecting hypervisor presence (dmesg | grep "Hypervisor cold boot, version: gunyah") and exiting with SKIP status before attempting KVM device node validation. Alternatively, enable nested virtualization in Gunyah firmware if supported, or maintain separate test configurations for Gunyah vs bare-metal QCS615.
4. Detail analysis attachment: failed_case_job228561_5_detailed.md

  Case 6: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** Platform does not support EL2 (Hypervisor mode). The qcs615-ride board (Qualcomm QCS615 SoC) does not expose EL2 to the Linux kernel, causing KVM initialization to fail with "HYP mode not available" (line 2780 in lava_job_228561.log). As a result, /dev/kvm is not created, and the KVM_EL2_DTB test fails. This is a pre-existing platform limitation specific to qcs615-ride, not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: Update the LAVA test runner script for KVM tests to check dmesg for "HYP mode not available" before execution. If found, emit RESULT=SKIP with message "KVM not supported on this platform (HYP mode not available)" instead of RESULT=FAIL. Alternatively, exclude KVM tests from the qcs615-ride test suite entirely via the LAVA job definition, as this platform does not support virtualization.
4. Detail analysis attachment: failed_case_job228561_6_detailed.md

  Case 7: KVM Infrastructure Test Failure — /dev/kvm device unavailable

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm device unavailable
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available to the Linux kernel. The QCS615-ride platform is running the Gunyah hypervisor (version gunyah-cdfb73831), which occupies EL2, preventing KVM from claiming the hypervisor privilege level required for virtualization support.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The KVM tests should be skipped on QCS615-ride when Gunyah hypervisor is present, or the test suite should detect "HYP mode not available" and mark the test as SKIP rather than FAIL. To enable KVM on this platform, the firmware would need to be reconfigured to boot Linux at EL2 without an intermediate hypervisor, which is a board-level change outside the scope of kernel patches.
4. Detail analysis attachment: failed_case_job228561_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available on qcs615-ride platform when booted with standard qcs615-ride.dtb; 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: This is a pre-existing platform limitation, not a PR-introduced regression. The PR changes (PCIe GPIO refactoring, PSCI reboot modes, QSPI flash enablement) do not affect KVM/EL2 availability. To enable KVM on qcs615-ride, boot with the qcs615-ride-el2.dtb (EL2-enabled device tree overlay) instead of the standard qcs615-ride.dtb, or mark KVM tests as expected-fail/skip for non-EL2 platform configurations.
4. Detail analysis attachment: failed_case_job228561_8_detailed.md

Job 228562 | SoC lemans-evk

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

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

  Case 1: System Hang — login-action timeout (userspace boot stall)

1. Failed case: System Hang — login-action timeout (userspace boot stall)
2. Root cause: PR introduces a serial console bandwidth configuration regression in drivers/tty/serial/qcom_geni_serial.c that causes the system to hang after console handoff from bootconsole to ttyMSM0 at ~3.2s; kernel boots successfully but userspace init stalls after systemd-udevd starts, with no console output for 9+ minutes until LAVA timeout.
3. Possible fix: Revert the serial driver bandwidth change in geni_serial_set_rate() (commit modifying avg_bw_core calculation from GENI_DEFAULT_BW to CORE_2X_19_2_MHZ for baud ≤ 115200) or investigate why the new bandwidth value causes console/system hang on lemans-evk platform.
4. Detail analysis attachment: failed_case_job228562_1_detailed.md

  Case 2: System Hang During Boot — PCIe probe hang

1. Failed case: System Hang During Boot — PCIe probe hang
2. Root cause: System completely stopped producing console output at 4.49 seconds into boot during PCIe controller probe (qcom-pcie 1c10000.pcie and 1c00000.pcie), immediately after systemd-udevd started. No kernel panic, oops, or crash signature present — the system simply froze with no further serial output. The PR introduces PCIe driver changes including a new cgc_dis_workaround and modifications to child node parsing logic (for_each_available_child_of_node_scoped with added of_node_is_type check), which may trigger a deadlock, infinite loop, or hardware access hang during PCIe initialization on lemans-evk.
3. Possible fix: Revert the PCIe driver changes in drivers/pci/controller/dwc/pcie-qcom.c (specifically the cgc_dis_workaround logic and the child node parsing changes) and re-test. If the issue persists, add debug instrumentation to qcom_pcie_parse_perst() and qcom_pcie_post_init_2_7_0() to identify the exact hang point. Check if the new of_node_is_type() filter is incorrectly skipping required child nodes or if the cgc_dis_workaround register access is causing a bus hang on lemans hardware.
4. Detail analysis attachment: failed_case_job228562_2_detailed.md

  Case 3: Board Hang — Complete system freeze during userspace initialization

1. Failed case: Board Hang — Complete system freeze during userspace initialization
2. Root cause: System stopped making forward progress at ~4.49 seconds into boot (after systemd-udevd start, during PCIe driver probe) with no console output, no crash signature, and no login prompt; LAVA login-action timed out after 185 seconds waiting for prompt that never appeared; consistent with complete system hang where kernel/userspace wedged without triggering panic or watchdog.
3. Possible fix: This is a silent hang during boot on lemans-evk that requires hardware-level debug (SDI/JTAG) to capture CPU state at hang time. Short-term: re-trigger the CI job to confirm reproducibility; if reproducible, enable early_printk, initcall_debug, and ignore_loglevel kernel parameters to identify the last successful operation before hang. Long-term: capture SDI dump or use JTAG to determine which CPU(s) are stuck, what locks they hold, and whether the hang is in PCIe probe (last visible activity), interrupt routing, or a deadlock in device initialization.
4. Detail analysis attachment: failed_case_job228562_3_detailed.md

  Case 4: Boot Hang — System Unresponsive After Kernel Init

1. Failed case: Boot Hang — System Unresponsive After Kernel Init
2. Root cause: The lemans-evk board hung during boot after kernel initialization completed and systemd-udevd started (last kernel message at 4.49s showing PCIe driver activity); the system never reached a login prompt despite three LAVA retry attempts totaling ~10 minutes, indicating a complete loss of forward progress in the boot sequence with no kernel crash signature present.
3. Possible fix: This is a genuine boot hang requiring kernel-level investigation. First, enable early console and increase kernel log verbosity (loglevel=8 earlyprintk) to capture where the boot process stalls. Check if the hang is reproducible across multiple boots. If reproducible, bisect the PR commits to identify the change that introduced the hang. The PR contains extensive device tree and driver changes that may have introduced a boot-time deadlock, missing device initialization, or driver probe hang on lemans-evk.
4. Detail analysis attachment: failed_case_job228562_4_detailed.md

Job 228563 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing platform-specific probe failures unrelated to PR changes: (1) regulatory.db firmware file missing from rootfs (benign - cfg80211 falls back to compiled-in regulatory rules); (2) Aquantia AQR115C PHY probe failure due to missing or malformed firmware-name device tree property (error -22 = -EINVAL), preventing PHY initialization on the qcs9100-ride platform's second Ethernet interface (stmmac-0:08).
3. Possible fix: For the Aquantia PHY failure: verify the qcs9100-ride device tree includes a valid firmware-name property in the PHY node at MDIO address 0x08 under the stmmac Ethernet controller, or confirm the PHY hardware revision does not require firmware and remove the driver's firmware-name requirement check. For regulatory.db: optionally add the regulatory.db firmware file to the rootfs (non-critical - WiFi functional tests passed, indicating compiled-in regulatory data is sufficient).
4. Detail analysis attachment: failed_case_job228563_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device node (aa00000.video-codec) in the qcs9100-ride device tree is missing the required iommus property, causing the SMMU test to fail when validating that all critical masters are attached to IOMMU groups.
3. Possible fix: Add the iommus property to the video codec device node in the qcs9100/sa8775p (lemans) device tree. The PR adds video codec support to glymur.dtsi but qcs9100 is based on sa8775p/lemans, not glymur, so the video codec node on qcs9100 remains without IOMMU binding.
4. Detail analysis attachment: failed_case_job228563_2_detailed.md

  Case 3: Ethernet_Basic_Validation — Driver Probe/Runtime Failure

1. Failed case: Ethernet_Basic_Validation — Driver Probe/Runtime Failure
2. Root cause: end0 (23040000.ethernet) fails to attach to PHY with -EINVAL error during interface bring-up; end1 (23000000.ethernet) experiences MAC register access timeouts but is ultimately skipped due to missing physical link. The PR introduces RGMII_ID mode handling changes that do not affect this SGMII-based platform, indicating this is a pre-existing platform/infrastructure issue, not a PR-introduced regression.
3. Possible fix: Verify PHY device tree configuration for end0 (23040000.ethernet) — check phy-handle phandle validity, PHY address on MDIO bus, and PHY driver probe status. For end1, verify physical Ethernet cable connection to the board. This is a board/lab infrastructure issue, not a kernel regression introduced by this PR.
4. Detail analysis attachment: failed_case_job228563_3_detailed.md

  Case 4: KVM_Driver — /dev/kvm not available (HYP mode not available)

1. Failed case: KVM_Driver — /dev/kvm not available (HYP mode not available)
2. Root cause: The qcs9100-ride platform boots Linux at EL1 (non-HYP mode) rather than EL2, preventing KVM initialization. The kernel message kvm [1]: HYP mode not available indicates the ARM KVM driver detected it is not running at Exception Level 2 (hypervisor mode), which is a mandatory prerequisite for KVM functionality. This is a platform/firmware configuration issue, not a kernel regression introduced by the PR.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The qcs9100-ride board's bootloader/firmware does not support booting Linux in EL2 mode. To enable KVM on this platform: (1) update the bootloader/firmware to boot Linux at EL2 instead of EL1, or (2) exclude KVM tests from the qcs9100-ride test suite as this platform does not support virtualization in its current firmware configuration.
4. Detail analysis attachment: failed_case_job228563_4_detailed.md

  Case 5: ** KVM Driver Initialization Failure — HYP mode not available

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** The qcs9100-ride platform boots Linux at EL1 (Exception Level 1) instead of EL2 (hypervisor mode), preventing KVM from accessing ARM virtualization extensions. The kernel message kvm [1]: HYP mode not available indicates KVM detected it cannot operate without EL2 access, resulting in no /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on qcs9100-ride: (1) Configure the bootloader (ABL/XBL) to boot Linux at EL2 instead of EL1, or (2) If a proprietary hypervisor is present at EL2, KVM cannot be used in this configuration. Verify the platform's intended virtualization architecture with the board vendor. If KVM support is not intended for this platform, mark these tests as expected-to-skip in the CI configuration.
4. Detail analysis attachment: failed_case_job228563_5_detailed.md

  Case 6: KVM_Infra (Platform Configuration Issue — KVM and Gunyah Mutually Exclusive)

1. Failed case: KVM_Infra (Platform Configuration Issue — KVM and Gunyah Mutually Exclusive)
2. Root cause: KVM cannot initialize because Gunyah hypervisor is running and has exclusive control of ARM EL2 (HYP mode). KVM initialization detects "HYP mode not available" and exits without creating /dev/kvm. This is expected behavior when both KVM (CONFIG_KVM=y) and Gunyah hypervisor are enabled on qcs9100-ride — they are mutually exclusive as both require EL2.
3. Possible fix: This is not a bug introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (PR contains only documentation and DT binding changes, no KVM/hypervisor code). This is a platform configuration decision. To enable KVM tests: (1) disable Gunyah hypervisor in the build configuration, or (2) mark KVM tests as "not applicable" for qcs9100-ride when Gunyah is enabled, or (3) use a different test image without Gunyah for KVM validation.
4. Detail analysis attachment: failed_case_job228563_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs9100-ride because the platform is running under Gunyah hypervisor (nested virtualization not supported). Boot log shows "kvm [1]: HYP mode not available" and "Hypervisor cold boot, version: gunyah-cdfb73831". CONFIG_KVM is enabled but /dev/kvm device node is not created because KVM initialization fails when HYP/EL2 is already claimed by another hypervisor.
3. Possible fix: This is a test environment configuration issue, not a kernel regression. Either: (1) Run KVM tests only on bare-metal configurations without Gunyah hypervisor, or (2) Skip KVM tests when hypervisor presence is detected, or (3) Use a different test platform that boots without a hypervisor for KVM validation.
4. Detail analysis attachment: failed_case_job228563_7_detailed.md

Job 228564 | SoC glymur-crd

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

Failed test cases in LAVA job 228564 (SoC: glymur-crd).

  Case 1: Probe_Failure_Check — regulatory.db firmware load failure

1. Failed case: Probe_Failure_Check — 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 pre-existing infrastructure/rootfs issue, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR contains no changes to wireless regulatory code, cfg80211, or firmware loading paths. The regulatory.db file is missing from the target rootfs /lib/firmware/ directory.
3. Possible fix: Add the wireless-regdb package (containing regulatory.db and regulatory.db.p7s) to the Yocto image recipe or rootfs build configuration. For immediate CI unblocking, suppress this known benign failure in the Probe_Failure_Check test script by filtering out "regulatory.db" firmware load errors, as WiFi functional tests (WiFi_Firmware_Driver and WiFi_OnOff) both passed, confirming WiFi hardware and driver are working correctly despite the missing regulatory database.
4. Detail analysis attachment: failed_case_job228564_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on glymur-crd is missing IOMMU group attachment due to absent or incorrect iommus property in the device tree node, preventing SMMU protection for this critical DMA master.
3. Possible fix: Add the iommus property to the video codec device tree node in arch/arm64/boot/dts/qcom/glymur.dtsi or the appropriate glymur-crd DTS file, referencing the correct SMMU phandle and stream ID for the video codec hardware block.
4. Detail analysis attachment: failed_case_job228564_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test framework issue — the test runner's result_parse.sh script found leftover .res files (CPU_affinity.res, Freq_Scaling.res, irq.res, smmu.res) after all tests had already completed and been reported to LAVA, causing LAVA to mark the test run as "unfinished" even though all tests executed successfully.
3. Possible fix: This is a test framework bug, not a kernel regression. The .res files should be cleaned up after being processed by send-to-lava.sh. Modify the test runner to delete .res files after successful reporting, or modify result_parse.sh to ignore .res files that have already been reported to LAVA. Re-run the CI job to verify the fix.
4. Detail analysis attachment: failed_case_job228564_3_detailed.md

Job 228565 | SoC sm8750-mtp

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

Failed test cases in LAVA job 228565 (SoC: sm8750-mtp).

  Case 1: Probe_Failure_Check — ath12k WiFi7 PCIe driver probe failure

1. Failed case: Probe_Failure_Check — ath12k WiFi7 PCIe driver probe failure
2. Root cause: ath12k_wifi7_pci driver probe failed with -ETIMEDOUT (-110) on sm8750-mtp during MHI (Modem Host Interface) initialization; MHI failed to load firmware image over BHI (Boot Host Interface) with error -5 (likely -EIO), causing the WiFi PCIe device at 0000:01:00.0 to fail power-up and core initialization
3. Possible fix: Investigate MHI/BHI firmware loading path in the PR's ath12k driver changes (drivers/net/wireless/ath/ath12k/); verify firmware files are present and accessible; check if PR introduced timing changes or power sequencing issues in ath12k_wifi7_pci probe path; validate PCIe link state and MHI state machine transitions during probe; if firmware is missing, ensure ath12k WiFi7 firmware is included in the rootfs image
4. Detail analysis attachment: failed_case_job228565_1_detailed.md

  Case 2: PCIe

1. Failed case: PCIe
2. Root cause: PCIe endpoint device 0000:01:00.0 (Qualcomm device ID 0x17cb:0x1107, class 0x028000 - Network controller) enumerated successfully but has no kernel driver bound to it, causing the test's driver binding validation to fail. The PCIe controller and link are functional (Gen.2 x2 link up, no AER errors), but the endpoint device remains in "driver=unbound" state because no in-tree driver claims this device ID.
3. Possible fix: This is not a PR-introduced regression - the PR contains only documentation and device tree binding changes with no PCIe driver modifications. The failure indicates either: (1) the required driver for device 0x17cb:0x1107 is not enabled in the kernel config, (2) the driver module is not loaded, or (3) no upstream driver exists for this device. Verify kernel config includes the appropriate driver (likely ath11k or qcnfa765 for this Qualcomm wireless device), ensure the module is loaded at test time, or update the test expectations if this device is not expected to have a driver on sm8750-mtp.
4. Detail analysis attachment: failed_case_job228565_2_detailed.md

  Case 3: WiFi_Firmware_Driver — ath12k WiFi7 PCIe driver probe failure

1. Failed case: WiFi_Firmware_Driver — ath12k WiFi7 PCIe driver probe failure
2. Root cause: ath12k_wifi7_pci driver probe failed with -ETIMEDOUT (-110) during MHI (Modem Host Interface) power-up sequence; MHI subsystem failed to load firmware image over BHI (Boot Host Interface) with error -EIO (-5), indicating the WiFi firmware did not respond within the expected timeout window during PCIe device initialization on SM8750 MTP.
3. Possible fix: This is a pre-existing hardware/firmware initialization issue unrelated to the PR changes (PR only removes panic_handler, does not modify probe/power-up paths); verify WiFi firmware files are present in /lib/firmware/ath12k/, check PCIe link training completed successfully, confirm power sequencing and clocks for the WiFi PCIe endpoint are stable, and if issue persists increase MHI BHI timeout or investigate PCIe/power domain initialization order on SM8750.
4. Detail analysis attachment: failed_case_job228565_3_detailed.md

  Case 4: ** WiFi Driver Probe Failure — ath12k_wifi7_pci probe failed with error -110

1. Failed case: ** WiFi Driver Probe Failure — ath12k_wifi7_pci probe failed with error -110
2. Root cause: ** ath12k WiFi7 PCIe driver probe fails with -ETIMEDOUT during MHI (Modem Host Interface) power-up on sm8750-mtp; MHI Boot Host Interface (BHI) image load returns error -5, preventing MHI state transition to POWER_ON and causing overall probe timeout.
3. Possible fix: Verify ath12k WiFi7 firmware files are present in /lib/firmware/ath12k/ for the sm8750 platform; if missing, add the required firmware binaries to the rootfs. If firmware is present, check that power domains, clocks, and regulators required by the PCIe WiFi device are correctly defined in the sm8750-mtp device tree and that the MDSS power domain changes in this PR do not conflict with WiFi power sequencing.
4. Detail analysis attachment: failed_case_job228565_4_detailed.md

  Case 5: KVM_Driver (Test Environment Misconfiguration)

1. Failed case: KVM_Driver (Test Environment Misconfiguration)
2. Root cause: Test attempts to validate KVM on a platform running Gunyah hypervisor. ARM64 architecture allows only one hypervisor at EL2; Gunyah is active at EL2, preventing KVM initialization. /dev/kvm cannot exist in this configuration.
3. Possible fix: Update LAVA test job definition to skip KVM tests when Gunyah hypervisor is detected. Add pre-test check: if dmesg | grep -q "Gunyah.*Hypervisor"; then skip KVM_Driver, KVM_EL2_DTB, KVM_Infra tests; fi
4. Detail analysis attachment: failed_case_job228565_5_detailed.md

  Case 6: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM driver failed to initialize because the kernel is running as a guest under Gunyah hypervisor (version gunyah-mobile-80d668e8f), which does not expose EL2 virtualization extensions to the guest OS, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform configuration limitation, not a kernel regression. To enable KVM testing on sm8750-mtp: (1) boot the kernel directly on bare metal without Gunyah hypervisor, OR (2) configure Gunyah to expose nested virtualization support (NV/VHE) to the guest if supported by the hypervisor version, OR (3) exclude KVM tests from the CI test suite for Gunyah-based boot configurations.
4. Detail analysis attachment: failed_case_job228565_6_detailed.md

  Case 7: KVM_Infra — KVM Infrastructure Test Failure

1. Failed case: KVM_Infra — KVM Infrastructure Test Failure
2. Root cause: KVM cannot initialize because CPUs are running at EL1 under the Gunyah hypervisor (which occupies EL2). ARM64 KVM requires CPUs to run at EL2 to provide virtualization support; when a hypervisor like Gunyah is already present, Linux runs as a guest at EL1 and cannot access EL2 privileges needed for KVM operation. CONFIG_KVM is enabled but /dev/kvm device node is never created because kvm_init() silently fails or skips initialization when EL2 is unavailable.
3. Possible fix: Exclude KVM tests from the LAVA test suite for sm8750-mtp when Gunyah hypervisor is enabled in the device tree, or boot the kernel without Gunyah (remove gunyah-hyp DT node and boot at EL2) if KVM functionality is required for testing. This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
4. Detail analysis attachment: failed_case_job228565_7_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: DRM/MSM display driver regression causing continuous timeout errors in dpu_encoder_phys_cmd_prepare_for_kickoff (error -110 ETIMEDOUT, 8389 occurrences) for encoder id:35, preventing the DPU command-mode encoder from completing frame kickoff operations on sm8750-mtp, resulting in LAVA marking the test run as incomplete due to excessive error logging.
3. Possible fix: Review and revert the DPU encoder changes in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c from this PR; the encoder wait_for_idle timeout logic appears broken for command-mode displays on sm8750, likely due to incorrect timing parameters, missing hardware initialization, or a race condition in the encoder state machine introduced by the PR's display subsystem refactoring.
4. Detail analysis attachment: failed_case_job228565_8_detailed.md

Job 228566 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing board/infra issue unrelated to PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes. Verify PCIe slot hardware presence, PHY power/clock configuration, and reset sequencing on the qcs8300-ride test board. If the slot is unpopulated or the endpoint is known-bad, suppress this test case for qcs8300-ride or mark the board for hardware debug.
4. Detail analysis attachment: failed_case_job228566_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 despite being present and functional in the system; the device tree for qcs8300 is missing the required iommus property for the video codec node, causing the SMMU driver to skip IOMMU group assignment during device probe.
3. Possible fix: Add the missing iommus property to the video codec device tree node in arch/arm64/boot/dts/qcom/qcs8300.dtsi (or the appropriate base dtsi file) to bind the video codec to an SMMU context bank, following the pattern used by other critical masters like GPU (3d00000.gpu), Display (ae00000.display-subsystem), and USB controllers.
4. Detail analysis attachment: failed_case_job228566_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver cannot initialize because the platform is running Gunyah hypervisor. KVM and Gunyah are mutually exclusive hypervisors - when Gunyah is active at EL2, KVM cannot take control of the virtualization extensions, preventing /dev/kvm device node creation. The kernel has CONFIG_KVM=y and CONFIG_VIRTUALIZATION=y enabled, but KVM initialization is silently skipped at boot because the CPU is already running under a hypervisor (Gunyah).
3. Possible fix: This is not a kernel bug or PR-introduced regression. The test failure is expected on qcs8300-ride (Monaco) platform which uses Gunyah hypervisor by design. Either: (1) exclude KVM tests from the test suite for Gunyah-based platforms (qcs8300-ride, and any other Monaco/Gunyah targets), or (2) add a platform-specific gate in the KVM test script to skip execution when Gunyah is detected (check for "Gunyah" in dmesg or /proc/device-tree/hypervisor/compatible).
4. Detail analysis attachment: failed_case_job228566_3_detailed.md

  Case 4: KVM_EL2_DTB — /dev/kvm device node unavailable

1. Failed case: KVM_EL2_DTB — /dev/kvm device node unavailable
2. Root cause: KVM is configured (CONFIG_KVM=y) but cannot initialize because the system is running under the Gunyah hypervisor (gunyah-cdfb73831), which occupies EL2 and prevents KVM from accessing the required virtualization extensions; /dev/kvm device node creation fails silently during KVM ARM initialization when EL2 is already claimed by another hypervisor.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. On qcs8300-ride (Monaco) with Gunyah hypervisor, KVM tests are expected to fail. Either: (1) skip KVM tests on Gunyah-enabled platforms in CI, or (2) use a non-Gunyah firmware build if KVM functionality is required for testing, or (3) mark KVM tests as expected-fail on qcs8300-ride with Gunyah.
4. Detail analysis attachment: failed_case_job228566_4_detailed.md

  Case 5: KVM_Infra — KVM device node unavailable (not a crash or build load failure)

1. Failed case: KVM_Infra — KVM device node unavailable (not a crash or build load failure)
2. Root cause: QCS8300 Ride platform is running as a guest VM under the Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-cdfb73831" and "arch_timer: cp15 timer running at 19.20MHz (virt)"), which prevents nested virtualization. KVM requires EL2 (hypervisor mode) access to create /dev/kvm, but when Linux runs as a guest under Gunyah, it operates at EL1 and cannot initialize KVM even though CONFIG_KVM=y is enabled in the kernel configuration.
3. Possible fix: This is a platform architecture limitation, not a kernel bug. The KVM test suite should be skipped on qcs8300-ride targets that boot under Gunyah hypervisor. Add a platform-specific test gate in the LAVA test definition to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when Gunyah hypervisor is detected (check for "Hypervisor cold boot, version: gunyah" in dmesg or /proc/device-tree/hypervisor/compatible containing "gunyah").
4. Detail analysis attachment: failed_case_job228566_5_detailed.md

  Case 6: ** KVM_Infra — /dev/kvm not available (nested virtualization limitation)

1. Failed case: ** KVM_Infra — /dev/kvm not available (nested virtualization limitation)
2. Root cause: ** The qcs8300-ride target is running under the Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-cdfb73831"). KVM requires direct EL2 (hypervisor mode) access to initialize, which is not available when the Linux kernel runs as a guest under another hypervisor. The KVM driver detects the absence of EL2 and silently skips initialization, resulting in no /dev/kvm device node. This is expected behavior for nested virtualization scenarios and is not a kernel bug or PR-introduced regression.
3. Possible fix: Exclude KVM tests from the LAVA test suite for qcs8300-ride (and any other Gunyah-based targets) by adding a platform-specific test filter in the CI job definition. KVM functionality cannot be enabled on this platform without removing the Gunyah hypervisor layer, which would require a fundamental platform reconfiguration (bare-metal boot instead of hypervisor-based boot). If KVM testing is required, use a bare-metal qcs8300 target without Gunyah.
4. Detail analysis attachment: failed_case_job228566_6_detailed.md

Job 228567 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test script incorrectly assumes 8 CPUs exist and attempts to parse timer interrupt counts for CPUs 4-7 from /proc/interrupts, but the shikra-iqs-evk board only has 4 CPUs (0-3). The script's line 75 bash integer comparison fails when it reads string values ("GICv3", "Level", "arch_timer") instead of numeric interrupt counts for the non-existent CPUs.
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 before attempting to validate timer interrupts, rather than hardcoding an assumption of 8 CPUs.
4. Detail analysis attachment: failed_case_job228567_1_detailed.md

  Case 2: ** Probe_Failure_Check — Multiple driver probe failures detected

1. Failed case: ** Probe_Failure_Check — Multiple driver probe failures detected
2. Root cause: ** Seven probe failures detected on shikra-iqs-evk: PCIe controller timeout (-110), CoreSight ETM configuration errors (-22), missing regulatory.db firmware (-2), cpufreq-dt duplicate registration (-17), and four deferred probe entries (I2C device 3-0010, sound card, va_macro codec, MMC 4784000) that remain unresolved at test time.
3. Possible fix: The probe failures are pre-existing platform issues not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (which contains only audio/coresight/AEST documentation and binding changes). PCIe -110 indicates link training timeout (hardware/board issue); ETM -22 suggests missing DT properties; regulatory.db -2 is expected (benign); cpufreq-dt -17 is a known duplicate registration race. The deferred probe entries require investigation of their provider drivers (I2C codec driver, sound card dependencies, clock providers for va_macro and MMC). Recommended action: Mark this test case as a known baseline failure for shikra-iqs-evk until the platform DT and hardware configuration are corrected; PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 should not be blocked by these pre-existing issues.
4. Detail analysis attachment: failed_case_job228567_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe PHY initialization timeout during kernel boot on shikra-iqs-evk — the qcom-qmp-pcie-phy driver at 45ee000.phy failed to initialize within the expected timeout period, causing the qcom-pcie controller at 45e8000.pcie to abort probe with -ETIMEDOUT (-110), leaving no PCIe devices enumerated for the test to validate.
3. Possible fix: This is a pre-existing platform/hardware issue unrelated to PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (the PR contains no PCIe, PHY, or shikra device-tree changes). The failure is reproducible on shikra-iqs-evk baseline and indicates either: (1) missing/incorrect PHY clocks or regulators in the device tree, (2) PHY firmware/calibration data not loaded, or (3) hardware signal integrity issue. To resolve: verify the shikra-iqs-evk device tree includes correct vdda/vddpe-3v3 regulator bindings for the PCIe controller, confirm PHY clocks are enabled and stable, and check for any board-level PCIe signal integrity issues (e.g., M.2 slot not populated, PCIe lanes not connected).
4. Detail analysis attachment: failed_case_job228567_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB DWC3 child node missing from device tree — PR#1085 adds USB wrapper nodes (usb@4e00000, usb@4c00000) with compatible = "qcom,shikra-dwc3", "qcom,snps-dwc3" but omits the required DWC3 child node (dwc3@<address>), preventing the DWC3 core driver from probing and exposing USB root hubs.
3. Possible fix: Add the missing DWC3 child node under each USB wrapper node in arch/arm64/boot/dts/qcom/shikra.dtsi following the qcom,snps-dwc3 binding requirements (see Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml); the child node must have compatible = "snps,dwc3", reg = <address size>, and inherit PHY/interrupt/power properties from the parent.
4. Detail analysis attachment: failed_case_job228567_4_detailed.md

  Case 5: BT_SCAN (suppressed — known benign)

1. Failed case: BT_SCAN (suppressed — known benign)
2. Root cause: Test infrastructure false positive. The BT_SCAN test failed to discover nearby Bluetooth devices during its scan window, but this is a known benign failure on shikra-iqs-evk when BT_ON_OFF passes. The Bluetooth stack is fully functional (BT_FW_KMD_Service passed, BT_ON_OFF passed), proving firmware loaded and the controller can power on/off correctly. The scan failure is likely due to environmental factors (no discoverable BT devices in range, RF shielding in lab, or timing sensitivity in the test harness) rather than a kernel regression.
3. Possible fix: No kernel fix required. This failure is suppressed per Rule 3 in lava-known-benign-failures.md. If BT_SCAN reliability is critical, improve test infrastructure by: (1) deploying a known-good BT beacon device in the LAVA lab within RF range of shikra-iqs-evk, or (2) extending the scan window and retry logic in the test harness.
4. Detail analysis attachment: failed_case_job228567_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because HYP (EL2 Hypervisor) mode is not available on the Shikra IQS EVK platform. The kernel message kvm [1]: HYP mode not available indicates the CPU is not running at or does not support Exception Level 2, which is required for ARM64 KVM virtualization.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. If KVM support is required on Shikra IQS EVK: (1) verify the SoC supports EL2 in hardware specifications, (2) ensure bootloader/firmware enables EL2 before booting Linux (check ABL/UEFI configuration), (3) confirm the platform is not already running under a hypervisor that has claimed EL2. If the platform fundamentally does not support virtualization, mark KVM tests as "not applicable" for this board in the CI test matrix.
4. Detail analysis attachment: failed_case_job228567_6_detailed.md

  Case 7: Kernel Crash — synchronous external abort in qcom_rng driver causing system reboot and subsequent KVM test infrastructure failure

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver causing system reboot and subsequent KVM test infrastructure failure
2. Root cause: Hardware access fault (synchronous external abort) in qcom_rng_read() at offset +0xbc when reading from HWRNG MMIO registers during qcom_hwrng test execution. The fault indicates the HWRNG hardware block was not accessible (powered down, clocked off, or MMIO mapping invalid), causing a fatal exception and kernel panic. After system reboot, KVM infrastructure failed to initialize, preventing /dev/kvm device node creation and causing KVM_EL2_DTB test to fail.
3. Possible fix: Investigate qcom_rng driver power/clock dependencies on Shikra platform. Verify HWRNG device tree node includes all required clocks, regulators, and power domains. Add runtime PM calls or explicit clock/regulator enable before MMIO access in qcom_rng_read(). For immediate mitigation, disable qcom_hwrng test or mark it as expected-fail until driver is fixed. The KVM_EL2_DTB failure is a cascading symptom and will resolve once the qcom_rng crash is fixed.
4. Detail analysis attachment: failed_case_job228567_7_detailed.md

  Case 8: KVM_Infra — Platform Limitation (HYP mode unavailable)

1. Failed case: KVM_Infra — Platform Limitation (HYP mode unavailable)
2. Root cause: KVM cannot initialize on Shikra IQS EVK because EL2 (HYP mode) is not available on this platform. The kernel message kvm [1]: HYP mode not available at boot time (timestamp 2.082735) indicates the hardware/firmware does not provide virtualization support. CONFIG_KVM is enabled but the KVM subsystem cannot create /dev/kvm without EL2 access.
3. Possible fix: This is a platform/hardware limitation, not a kernel bug. The Shikra IQS EVK board does not support KVM virtualization. The KVM test suite should be skipped on platforms without EL2 support, or the test should be updated to report SKIP instead of FAIL when HYP mode is unavailable. No kernel code change is required. To enable KVM on this platform, the bootloader/firmware must be configured to boot Linux at EL1 with EL2 available (not trapped or disabled).
4. Detail analysis attachment: failed_case_job228567_8_detailed.md