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

[Salendarsingh Gaud (sgaud-quic)]

Name SHA Commits

tech/bsp/clk 24b9b5e 32
tech/bsp/devfreq 4809534 7
tech/security/firmware-smc de7413c 6
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 39a86aa 13
tech/bus/peripherals e6f6741 8
tech/bus/pci/all 99d5cf2 45
tech/bus/pci/phy 66e44c2 14
tech/bus/usb/dwc d90fb64 4
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing a3f730f 24
tech/pmic/misc 8d60b51 22
tech/mem/iommu cdc9e80 9
tech/mm/audio/all 88b8f29 8
tech/mm/camss dffc6e9 49
tech/mm/drm 83f65e1 76
tech/mm/fastrpc bff2f47 12
tech/mm/video bdcc5c4 127
tech/mm/gpu b9f2291 12
tech/mproc/rpmsg 55dc464 1
tech/net/ath 2ac1acc 21
tech/net/bluetooth 450dc5e 7
tech/pm/power f712532 16
tech/pm/thermal d525ff9 8
tech/security/crypto 1f60c0a 23
tech/security/ice beabac0 9
tech/storage/all cef1b3c 5
tech/all/dt/qcs6490 2e92fd1 28
tech/all/dt/qcs9100 754b808 24
tech/all/dt/qcs8300 a02cf61 31
tech/all/dt/qcs615 66b7e2f 11
tech/all/dt/agatti 2ca1b63 2
tech/all/dt/eliza 5338032 25
tech/all/dt/hamoa 106f486 49
tech/all/dt/glymur c5bf216 60
tech/all/dt/kaanapali d21ef73 26
tech/all/dt/pakala 450d786 9
tech/all/config 7b48e6e 78
tech/overlay/dt b895d0e 78
tech/all/workaround 219d869 12
tech/mproc/all 104969c 2
tech/noup/debug/all e473076 29
tech/hwe/unoq a2d85fe 4
early/hwe/shikra/drivers b19d2ec 184
early/hwe/shikra/dt dd90d88 130
early/hwe/lyra 8c9d598 6

[qlijarvis]

🔨 Build Failure Analysis — PR #978

PR:#978
Build run:https://github.com/qualcomm-linux/kernel-config/actions/runs/32172413689

#	Error	File:Line	PR-introduced?	Root Cause
1	Failed to apply overlay: FDT_ERR_NOTFOUND	arch/arm64/boot/dts/qcom/talos-lyra-evk-camx.dtbo	Yes	PR adds talos-lyra-evk-camx.dtso overlay file but does not add a corresponding Makefile rule to define how to apply it. The build system attempts to automatically apply the overlay to talos-lyra-evk.dtb, but the overlay targets nodes that don't exist in that base DTB.

Verdict

1 error is introduced by this PR. The error occurs in both standard and RT kernel builds.

📎 Detailed analysis:Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #978

PR:#978
Build run:https://github.com/qualcomm-linux/kernel-config/actions/runs/32172413689

#	Error	File:Line	PR-introduced?	Root Cause
1	Failed to apply dtbo overlay	arch/arm64/boot/dts/qcom/talos-lyra-evk-camx.dtbo	No	Pre-existing Makefile rule references talos-lyra-evk-camx.dtb but the required overlay file talos-lyra-evk-camx.dtbo does not exist in the tree

Verdict

This build failure is NOT introduced by this PR. The error is caused by a pre-existing issue in the base tree where a Makefile rule references talos-lyra-evk-camx.dtb but the required overlay file talos-lyra-evk-camx.dtbo does not exist.

📎 Detailed analysis:Full report

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #978

Job 207833 | SoC kaanapali-mtp

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

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

Case 1: remoteproc

1. Failed case: remoteproc
2. Root cause: SoCCP (remoteproc0) is in "attached" state because it is a pre-booted processor that Linux attaches to (not boots), while the test expects all remoteproc instances to be in "running" state; ADSP and CDSP are Linux-booted and correctly show "running" state.
3. Possible fix: Update the remoteproc test script to recognize "attached" as a valid state for attach-mode remoteproc instances (e.g., SoCCP); modify the test to check for either "running" OR "attached" state, or maintain a per-subsystem expected-state map that accounts for SoCCP's attach-mode lifecycle.
4. Detail analysis attachment: failed_case_job207833_1_detailed.md

Case 2: PCIe

1. Failed case: PCIe
2. Root cause: Test infrastructure issue — the PCIe functional test script expects platform-specific DT nodes or lspci output patterns that are not present on kaanapali-mtp, despite PCIe hardware being fully functional (Gen.3 x2 link up, devices enumerated at 0000:00:00.0 and 0000:01:00.0).
3. Possible fix: Update the PCIe test script in qcom-linux-testkit to handle kaanapali-mtp platform correctly by either (1) adding kaanapali-specific DT node patterns to the test, or (2) making the test check for actual PCIe functionality (link status, device enumeration) rather than platform-specific DT nodes.
4. Detail analysis attachment: failed_case_job207833_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Restore dr_mode = "peripheral" in arch/arm64/boot/dts/qcom/kaanapali-mtp.dts and kaanapali-qrd.dts as a short-term fix to unblock the PR. For proper dual-role support, add usb-role-switch; property to the USB controller node and wire it to the pmic-glink connector via usb-role-switch = <&usb_role_switch_provider>; phandle, then add the role-switch provider node under pmic-glink. Verify host mode enumeration on kaanapali-mtp hardware before merging.
4. Detail analysis attachment: failed_case_job207833_3_detailed.md

Case 4: ** BT_FW_KMD_Service (Bluetooth Firmware/KMD Service Test)

1. Failed case: ** BT_FW_KMD_Service (Bluetooth Firmware/KMD Service Test)
2. Root cause: ** PR-introduced regression in Bluetooth QCA driver (drivers/bluetooth/btqca.c) breaks WCN7850 firmware download on kaanapali-mtp — HCI vendor command 0xfc00 times out during TLV segment transmission, preventing firmware file qca/hmtbtfw20.tlv from loading successfully.
3. Possible fix: Revert or fix the firmware download logic changes in drivers/bluetooth/btqca.c introduced by this PR (specifically the qca_combine_nvm_calib() function and related TLV handling modifications) to restore WCN7850 compatibility; ensure QCC2072 support additions do not alter the firmware download command sequence for existing chipsets like WCN7850.
4. Detail analysis attachment: failed_case_job207833_4_detailed.md

Case 5: WiFi_Firmware_Driver — Driver/Module Issue (ath12k_pci missing)

1. Failed case: WiFi_Firmware_Driver — Driver/Module Issue (ath12k_pci missing)
2. Root cause: The ath12k_pci kernel module is not built or not included in the kernel image. The PCIe WiFi device (17cb:110e WCN7850) is detected on the bus, but the ath12k_pci driver module that binds to it is missing from /lib/modules/7.2.0-01457-gf957a7795822/kernel/drivers/net/wireless/ath/ath12k/. CONFIG_ATH12K is enabled but CONFIG_ATH12K_PCI appears to be disabled or not built as a module, preventing the driver from probing the PCIe-attached WCN7850 WiFi hardware on kaanapali-mtp.
3. Possible fix: Enable CONFIG_ATH12K_PCI=m in the kernel configuration (arch/arm64/configs/defconfig or the relevant config fragment), rebuild the kernel, and verify that ath12k_pci.ko is present in the modules directory. The driver should then automatically probe the WCN7850 device at boot and create a WiFi interface.
4. Detail analysis attachment: failed_case_job207833_5_detailed.md

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

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** KVM driver cannot initialize because the Gunyah hypervisor is already running at EL2 (Exception Level 2), preventing KVM from obtaining the exclusive EL2 access it requires. On kaanapali-mtp, the boot firmware loads Gunyah hypervisor (version gunyah-mobile-ca9ade961) at EL2 before the Linux kernel boots, and KVM detects this condition during initialization and aborts with "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which contains no KVM-related changes). To enable KVM on kaanapali-mtp: (1) modify the boot firmware/bootloader configuration to NOT load the Gunyah hypervisor, allowing the kernel to boot directly at EL2, OR (2) use a different platform/board that does not have a hypervisor pre-loaded at EL2, OR (3) accept that KVM and Gunyah are mutually exclusive on this platform and mark KVM tests as "not applicable" for kaanapali-mtp in the CI test matrix.
4. Detail analysis attachment: failed_case_job207833_6_detailed.md

Case 7: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM cannot initialize because the CPU is running at EL1 instead of EL2. The bootloader (UEFI/XBL version 6.0.260226.BOOT.MXF_UEFI.2.5-00601-KAANAPALI-1) on kaanapali-mtp is configured to boot Linux at Exception Level 1, which prevents KVM from enabling hypervisor mode. The kernel correctly detects this condition and reports "HYP mode not available" at boot time [3.504518], resulting in /dev/kvm not being created. This is a platform configuration limitation specific to the kaanapali-mtp (SC8380XP) hardware/firmware, not a kernel bug or PR-introduced regression.
3. Possible fix: If KVM support is required on kaanapali-mtp: Coordinate with Qualcomm bootloader team to update UEFI/XBL firmware configuration to boot Linux at EL2 instead of EL1, and verify TrustZone secure monitor permits hypervisor mode operation. If KVM is not a requirement for this platform: Add platform-specific test skip logic in the LAVA job definition to exclude KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when running on kaanapali-mtp, or mark these tests as expected failures in the test framework.
4. Detail analysis attachment: failed_case_job207833_7_detailed.md

Case 8: KVM_Infra — Platform Virtualization Not Supported

1. Failed case: KVM_Infra — Platform Virtualization Not Supported
2. Root cause: The kaanapali-mtp platform does not support ARM Virtualization Extensions (EL2/HYP mode), which is required for KVM. KVM initialization fails with "HYP mode not available" at boot (timestamp 3.504518s), preventing /dev/kvm device creation.
3. Possible fix: Exclude KVM tests from the kaanapali-mtp LAVA job definition. Update the test suite configuration to skip KVM tests on platforms without EL2 support. Add a platform capability check in the test runner to automatically skip virtualization tests when /dev/kvm is unavailable due to missing hardware support (not driver failure).
4. Detail analysis attachment: failed_case_job207833_8_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present. The kernel logged "kvm [1]: HYP mode not available" at boot, indicating that EL2 (hypervisor mode) is not available on the kaanapali-mtp platform, preventing KVM initialization. This is a pre-existing platform limitation, not a PR-introduced regression—the PR contains only documentation and device tree binding changes with no KVM or virtualization code modifications.
3. Possible fix: This is not a kernel bug requiring a fix. The kaanapali-mtp board does not support EL2/HYP mode, which is a hardware/firmware limitation. The test should either be skipped on platforms without EL2 support, or the test framework should be updated to mark this as "SKIP" rather than "FAIL" when CONFIG_KVM is enabled but /dev/kvm is unavailable due to missing HYP mode. No kernel changes are needed for this PR.
4. Detail analysis attachment: failed_case_job207833_9_detailed.md

Job 207834 | SoC glymur-crd

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

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

Case 1: remoteproc

1. Failed case: remoteproc
2. Root cause: Test expectation mismatch — SoCCP remoteproc is correctly in "attached" state (early-boot processor that Linux attaches to) but the test incorrectly expects "running" state (Linux-controlled boot).
3. Possible fix: Update the remoteproc test script to accept "attached" as a valid state for remoteproc0 (soccp) on glymur-crd, since SoCCP is an early-boot RISC-V MCU that boots before Linux and is attached rather than started by the kernel.
4. Detail analysis attachment: failed_case_job207834_1_detailed.md

Case 2: Probe_Failure_Check — Deferred Probe Storm (Driver Module Issue)

1. Failed case: Probe_Failure_Check — Deferred Probe Storm (Driver Module Issue)
2. Root cause: Eight PMIC temp-alarm devices (c426000.spmi:pmic@{1,2,3,5,7}:temp-alarm@a00 and c437000.spmi:pmic@{2,3,5}:temp-alarm@a00) remain in permanent deferred probe state with "(reason unknown)" because the qcom-spmi-temp-alarm driver is not loaded or not built into the kernel. The PR introduces a new qcom-spmi-mbg-tm driver and related Kconfig options (QCOM_SPMI_MBG_TM, QCOM_SPMI_ADC_TM5_GEN3) but does not ensure the existing temp-alarm driver remains available for glymur-crd's PMIC configuration. The regulatory.db firmware load failure is a known benign issue (cfg80211 regulatory database is optional).
3. Possible fix: Verify that CONFIG_QCOM_SPMI_TEMP_ALARM is enabled in the kernel configuration for glymur-crd. If the PR intentionally replaces the old temp-alarm driver with the new MBG driver, update the glymur-crd device tree to use the new compatible string and ensure the new driver's dependencies (QCOM_SPMI_ADC5_GEN3) are met. If both drivers should coexist, ensure both CONFIG_QCOM_SPMI_TEMP_ALARM and CONFIG_QCOM_SPMI_MBG_TM are enabled and the device tree nodes use the correct compatible strings for each PMIC type.
4. Detail analysis attachment: failed_case_job207834_2_detailed.md

Case 3: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The PR introduces a new Iris video codec device node (iris: video-codec@aa00000) in arch/arm64/boot/dts/qcom/glymur.dtsi without a top-level iommus property — IOMMU bindings are present only in child nodes (non-pixel and pixel sub-nodes), causing the parent device to not be attached to any IOMMU group, which fails the LAVA SMMU test's critical master validation check.
3. Possible fix: Add a top-level iommus property to the iris: video-codec@aa00000 node in arch/arm64/boot/dts/qcom/glymur.dtsi (e.g., iommus = <&apps_smmu 0x1940 0x0>, <&apps_smmu 0x1943 0x0>, <&apps_smmu 0x1944 0x0>, <&apps_smmu 0x19e0 0x0>;) to ensure the video codec device is attached to an IOMMU group, or update the LAVA test to accept child-node-only IOMMU bindings for multi-context devices like Iris.
4. Detail analysis attachment: failed_case_job207834_3_detailed.md

Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices physically connected to the glymur-crd board's USB host ports during test execution. The USB host controller (xHCI) initialized successfully and enumerated both USB 2.0 and USB 3.0 root hubs, but the test expects at least one functional USB device beyond the root hubs to be present.
3. Possible fix: This is not a kernel regression. The test should either: (1) be marked as SKIP when no USB devices are expected in the lab setup for glymur-crd, or (2) the lab infrastructure should ensure a USB device (e.g., USB flash drive, USB keyboard) is physically connected to the board's USB port before running the test. No kernel or PR changes are required.
4. Detail analysis attachment: failed_case_job207834_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 infrastructure marked the test run as "unfinished" despite all individual test cases completing execution. The message "Marking unfinished test run as failed" at line 7303 indicates LAVA detected an unexpected test runner exit condition. Four individual test cases genuinely failed: (1) remoteproc - remoteproc0 in 'attached' state instead of expected 'running', (2) Probe_Failure_Check - deferred probe devices and regulatory.db firmware load failure, (3) smmu - video codec (aa00000.video-codec) missing iommu_group attachment, (4) USBHost - no functional USB devices detected (only hubs present).
3. Possible fix: Re-trigger the CI job to verify if the "unfinished test run" is a transient LAVA infrastructure issue. For the genuine test failures: (1) remoteproc0 'attached' state is expected behavior for certain remoteproc instances and may be a test expectation issue, not a kernel regression; (2) Probe_Failure_Check failures (deferred probes for temp-alarm devices and regulatory.db firmware) are known benign issues on this platform; (3) smmu failure for video codec missing iommu_group requires investigation of video codec driver probe sequence and DT iommus property; (4) USBHost failure requires physical USB device connection to the test board or test expectation adjustment.
4. Detail analysis attachment: failed_case_job207834_5_detailed.md

Job 207835 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test detected three firmware load failures during boot: (1) regulatory.db for cfg80211 wireless regulatory database, and (2-3) modem.mbn for remoteproc0 (modem subsystem). These are expected missing firmware files on qcs6490-rb3gen2 in the current test environment configuration — regulatory.db is optional for wireless operation (WiFi functional tests passed), and modem firmware is not provisioned in this LAVA test image (modem subsystem is not required for baseport validation).
3. Possible fix: Update the Probe_Failure_Check test script to suppress known-benign firmware load failures for qcs6490-rb3gen2: add regulatory.db and qcom/qcs6490/modem.mbn to the platform-specific firmware exclusion list, as these files are not provisioned in the test rootfs and their absence does not indicate a kernel regression (WiFi_OnOff, WiFi_Firmware_Driver, BT_ON_OFF, and BT_FW_KMD_Service all passed, confirming wireless subsystem is functional).
4. Detail analysis attachment: failed_case_job207835_1_detailed.md

Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices connected to the qcs6490-rb3gen2 board's USB host port during test execution. The USB host controller driver (dwc3-qcom) initialized successfully, USB core subsystem loaded correctly, and no kernel errors were logged. The test script enumerated USB devices and found none, which is expected behavior when no physical USB devices are attached to the host port.
3. Possible fix: This is not a kernel bug requiring a code fix. The failure is environmental. To resolve: (1) Verify the LAVA lab setup for qcs6490-rb3gen2 includes a USB device (e.g., USB flash drive, USB hub) connected to the USB host port before test execution, or (2) mark the USBHost test as SKIP for this board if USB host testing is not supported in the current lab configuration, or (3) update the test to check for USB host controller presence and capability rather than requiring enumerated devices.
4. Detail analysis attachment: failed_case_job207835_2_detailed.md

Case 3: KVM_Driver — Platform Virtualization Support Unavailable

1. Failed case: KVM_Driver — Platform Virtualization Support Unavailable
2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not support ARM virtualization extensions (EL2/Hypervisor mode). The kernel correctly detected this hardware limitation during KVM initialization with the message "kvm [1]: HYP mode not available" at boot time (3.401088s). While CONFIG_KVM is enabled in the kernel configuration, the underlying hardware does not provide the EL2 privilege level required for KVM operation, preventing the creation of /dev/kvm.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The PR adds only documentation and device tree bindings (including EL2 overlays for platforms that DO support virtualization). To resolve: (1) Skip/disable KVM tests on qcs6490-rb3gen2 in the LAVA test suite, as this platform lacks hardware virtualization support, OR (2) Mark KVM tests as expected-fail for this platform, OR (3) Use a different Qualcomm platform with ARM virtualization extensions (e.g., SA8775P, SM8550) for KVM validation.
4. Detail analysis attachment: failed_case_job207835_3_detailed.md

Case 4: ** KVM_EL2_DTB — Test Configuration Mismatch (EL1 DTB used, EL2 required)

1. Failed case: ** KVM_EL2_DTB — Test Configuration Mismatch (EL1 DTB used, EL2 required)
2. Root cause: ** The LAVA job flashed and booted the regular DTB (qcs6490-rb3gen2.dtb) which boots in EL1 mode. In EL1, KVM/HYP mode is architecturally unavailable on ARM64, causing the kernel to report kvm [1]: HYP mode not available at boot. The test KVM_EL2_DTB requires the board to boot in EL2 mode with the EL2 DTB overlay (qcs6490-rb3gen2-el2.dtb) to enable KVM support.
3. Possible fix: Update the LAVA job definition for qcs6490-rb3gen2 KVM tests to flash and boot the EL2 DTB (qcs6490-rb3gen2-el2.dtb) instead of the regular DTB. The EL2 DTB is now available in the build artifacts after this PR merges. Alternatively, create a separate LAVA device type or job template specifically for EL2/KVM testing on this platform.
4. Detail analysis attachment: failed_case_job207835_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: Exclude KVM tests from the qcs6490-rb3gen2 test suite, as this platform is configured to run Linux as a guest VM under Gunyah and does not support nested virtualization. Alternatively, if KVM testing is required, reconfigure the board to boot Linux directly at EL2 without the Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job207835_5_detailed.md

Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the Gunyah hypervisor is already running at EL2, preventing KVM from taking control of the hypervisor mode — kernel message "kvm [1]: HYP mode not available" at boot confirms this platform limitation.
3. Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression. The qcs6490-rb3gen2 board runs Gunyah hypervisor which occupies EL2, making KVM unavailable. To enable KVM testing: (1) boot without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use a different board/configuration that does not run a proprietary hypervisor at EL2.
4. Detail analysis attachment: failed_case_job207835_6_detailed.md

Job 207836 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check — Firmware Load False Positive

1. Failed case: Probe_Failure_Check — Firmware Load False Positive
2. Root cause: The Probe_Failure_Check test detected a cfg80211 regulatory database firmware load failure (Direct firmware load for regulatory.db failed with error -2) that occurred during early boot. This is a benign false positive: the cfg80211 subsystem first attempts to load an optional user-space regulatory.db file; when absent (error -2 = -ENOENT), it falls back to compiled-in X.509 certificates, which loaded successfully as evidenced by the log line "Loading compiled-in X.509 certificates for regulatory database" immediately preceding the failure. The system continued normal operation with no WiFi/wireless functionality impairment. This failure is unrelated to the PR (which contains only audio subsystem changes) and is a pre-existing platform characteristic of the qcs615-ride test image.
3. Possible fix: Suppress this specific firmware load failure pattern in the Probe_Failure_Check test logic by adding an exception for regulatory.db when the preceding log shows successful loading of compiled-in certificates. Alternatively, if strict firmware-load checking is required, add the regulatory.db file to the rootfs firmware directory (/lib/firmware/) in the test image build recipe, though this is unnecessary for functionality.
4. Detail analysis attachment: failed_case_job207836_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The smmu test expects video codec sub-devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be attached to IOMMU groups, but these sub-devices are not present in the device tree or driver implementation for qcs615-ride. The parent device aa00000.video-codec is correctly attached to IOMMU group 6, but the test's expectation for child video-decoder and video-encoder devices to have separate IOMMU group attachments is not met. This is a test expectation mismatch, not an actual SMMU or kernel regression.
3. Possible fix: Update the smmu test to exclude video codec sub-device checks for qcs615-ride, or modify the test to only verify parent video-codec device IOMMU attachment. The PR does not introduce this issue — it is a pre-existing platform-specific test configuration problem where the test expects a device topology that qcs615 does not implement.
4. Detail analysis attachment: failed_case_job207836_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: QCS615 SoC does not support ARM EL2 (Hypervisor mode), which is required for KVM virtualization. Kernel correctly detected this during initialization and reported "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as SKIP (not FAIL) for qcs615-ride in the LAVA test suite, or add a platform capability check in the test runner to skip KVM tests when EL2 is unavailable.
4. Detail analysis attachment: failed_case_job207836_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform architecture limitation, not a kernel bug. The qcs615-ride platform uses Gunyah as its hypervisor, which precludes KVM operation. To resolve: (1) Disable CONFIG_KVM in the kernel config for Gunyah-based platforms, or (2) Add KVM test skip logic in the CI test suite to skip KVM tests when running on Gunyah-based platforms (detect via /sys/hypervisor/type or boot log "Gunyah based bootup"), or (3) If nested virtualization under Gunyah is required, this needs Gunyah hypervisor support for nested EL2 virtualization (not currently available).
4. Detail analysis attachment: failed_case_job207836_4_detailed.md

Case 5: ** KVM_Infra — KVM driver initialization failure (platform configuration issue)

1. Failed case: ** KVM_Infra — KVM driver initialization failure (platform configuration issue)
2. Root cause: ** The qcs615-ride platform boots with Gunyah hypervisor occupying ARM EL2 (Hypervisor mode). KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present, resulting in "HYP mode not available" and no /dev/kvm device node creation.
3. Possible fix: Disable the KVM test suite for qcs615-ride in the LAVA job definition, as this platform is configured for Gunyah virtualization and cannot support KVM simultaneously. Alternatively, if KVM testing is required, reconfigure the platform firmware/bootloader to boot without Gunyah hypervisor (mutually exclusive choice).
4. Detail analysis attachment: failed_case_job207836_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on QCS615-Ride because Gunyah hypervisor is already running at EL2 (HYP mode), preventing KVM from accessing the required privilege level. The kernel message "kvm [1]: HYP mode not available" at boot time (3.236s) indicates KVM detected it cannot operate in this configuration. This is a platform configuration limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: This is expected behavior on platforms running Gunyah hypervisor. To enable KVM testing: (1) reconfigure the platform to boot without Gunyah hypervisor, OR (2) exclude KVM tests from the CI test suite for QCS615-Ride targets running Gunyah, OR (3) use a different target platform that does not run a hypervisor at EL2 for KVM validation.
4. Detail analysis attachment: failed_case_job207836_6_detailed.md

Job 207837 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected deferred probe entries for 8 PMIC temp-alarm devices and two known-benign probe/firmware failures (qcom_qseecom_uefisecapp -EBUSY, regulatory.db -ENOENT) that do not impact system functionality on hamoa-evk.
3. Possible fix: Suppress these known-benign failures in the Probe_Failure_Check test for hamoa-evk: (1) temp-alarm deferred probe is expected when thermal framework initializes after SPMI PMIC probes; (2) qcom_qseecom_uefisecapp -EBUSY is a known platform limitation where UEFI secure app is not available; (3) regulatory.db firmware absence is benign when WiFi/BT functional tests pass (confirmed: WiFi_OnOff, BT_ON_OFF, BT_SCAN all passed).
4. Detail analysis attachment: failed_case_job207837_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, failing the SMMU test's critical master protection validation on hamoa-evk (X1E80100 SoC).
3. Possible fix: Add the missing iommus property to the video-codec device tree node at aa00000.video-codec in the hamoa-evk DTB, referencing the appropriate SMMU instance and stream ID, following the pattern used for other critical masters (GPU, Display, UFS) on this platform.
4. Detail analysis attachment: failed_case_job207837_2_detailed.md

Case 3: KVM_Driver — Platform Configuration Incompatibility

1. Failed case: KVM_Driver — Platform Configuration Incompatibility
2. Root cause: KVM cannot initialize on hamoa-evk (IQ-X7181) because the platform runs under Gunyah hypervisor at EL2. Kernel correctly reports "kvm [1]: HYP mode not available" at boot (line 4.856151). ARM architecture allows only one hypervisor at EL2; nested virtualization is not supported on this platform.
3. Possible fix: Exclude KVM tests from hamoa-evk LAVA job definition. This is expected behavior, not a regression. KVM tests should only run on platforms without a pre-existing hypervisor (bare-metal or platforms with nested virtualization support).
4. Detail analysis attachment: failed_case_job207837_3_detailed.md

Case 4: ** KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)

1. Failed case: ** KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)
2. Root cause: ** The hamoa-evk platform does not support or enable ARM EL2 (Hypervisor Exception Level), as evidenced by the kernel message kvm [1]: HYP mode not available at boot time (4.856s). Without EL2, the KVM subsystem cannot initialize, and /dev/kvm is never created. This is a hardware/firmware limitation specific to the hamoa-evk board configuration, not a kernel regression.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. To enable KVM on hamoa-evk: (1) Verify the SoC hardware supports EL2/virtualization extensions; (2) Update the bootloader/UEFI firmware to boot the kernel at EL2 instead of EL1 (current UEFI version: BOOT.MXF_UEFI.2.5-00625-HAMOA-1); (3) If the hardware does not support EL2, mark KVM tests as "not applicable" for this platform in the CI test matrix. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job207837_4_detailed.md

Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (Hypervisor) mode (EL2) is not available on the hamoa-evk platform — the kernel logged "kvm [1]: HYP mode not available" during boot, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The hamoa-evk board does not support virtualization extensions (EL2/HYP mode). Either: (1) skip KVM tests on hamoa-evk in the CI test matrix, or (2) enable EL2 support in the platform firmware/bootloader if the SoC hardware supports it but firmware is configured to boot at EL1.
4. Detail analysis attachment: failed_case_job207837_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed due to 5 genuine individual test failures within the suite: Probe_Failure_Check (probe errors for temp-alarm devices and qseecom_uefisecapp), smmu (video codec aa00000.video-codec missing iommu_group attachment), and 3 KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra all failing because /dev/kvm device node is not present despite CONFIG_KVM being enabled).
3. Possible fix: The overall test case failure is expected LAVA behavior when individual tests fail. Address the root causes: (1) For KVM failures: investigate why /dev/kvm is not created despite CONFIG_KVM=y - check if KVM driver initialization is failing or if the platform lacks required hardware virtualization support (EL2/VHE); (2) For smmu failure: verify video codec driver IOMMU binding in device tree and ensure video codec probe completes successfully; (3) For Probe_Failure_Check: investigate temp-alarm probe deferrals and qseecom_uefisecapp -EBUSY error - these may be pre-existing platform issues unrelated to this PR.
4. Detail analysis attachment: failed_case_job207837_6_detailed.md

Job 207838 | SoC qcs9100-ride

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

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

Case 1: Kernel Crash — Watchdog Pretimeout Panic

1. Failed case: Kernel Crash — Watchdog Pretimeout Panic
2. Root cause: PR introduces CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y in kernel configuration, which triggers a kernel panic when the watchdog pretimeout event fires. The qcs9100-ride platform's watchdog pretimeout fired at 166 seconds during boot while systemd was starting services (Modem Manager, Network Manager, etc.), causing the system to panic instead of continuing operation.
3. Possible fix: Remove CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y from the kernel configuration and either set CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP=y or disable watchdog pretimeout governor entirely. Alternatively, if watchdog pretimeout panic is intentional for debugging, increase the watchdog timeout value or ensure the watchdog is properly serviced during boot.
4. Detail analysis attachment: failed_case_job207838_1_detailed.md

Case 2: Kernel Crash — Watchdog pretimeout panic during boot

1. Failed case: Kernel Crash — Watchdog pretimeout panic during boot
2. Root cause: Watchdog pretimeout panic triggered at 166 seconds after boot start on qcs9100-ride. System was stuck in idle state waiting for multiple systemd services (Modem Manager, Network Manager, Hostname Service, Avahi mDNS/DNS-SD, Bluetooth OBEX, EFI mount) that failed to complete initialization within their timeout windows. The watchdog pretimeout fired because the system was not making forward progress, with CPU0 in cpuidle_enter_state when the interrupt occurred.
3. Possible fix: This is a userspace service initialization hang, not a kernel crash introduced by the PR. The PR contains only documentation and device tree binding changes with no code modifications that would affect boot flow or watchdog behavior. Re-trigger the CI job to verify if this is a transient infrastructure issue. If the hang persists, investigate why systemd services are timing out during boot on qcs9100-ride — check for network configuration issues, missing firmware files, or hardware dependencies that prevent service initialization. Consider increasing systemd service timeouts or disabling non-critical services for CI boot testing.
4. Detail analysis attachment: failed_case_job207838_2_detailed.md

Case 3: Kernel Crash — Watchdog pretimeout panic during userspace boot hang

1. Failed case: Kernel Crash — Watchdog pretimeout panic during userspace boot hang
2. Root cause: System hang during userspace initialization at ~167 seconds after boot; multiple systemd services (Modem Manager, Network Manager, Hostname Service, Avahi, EFI mount) blocked for >1 minute, preventing forward progress; watchdog pretimeout triggered panic on CPU0 from idle state (cpuidle_enter_state), indicating the system was unable to complete boot and reach login prompt on qcs9100-ride.
3. Possible fix: Investigate why systemd services are hanging during boot — check for deadlocks in device initialization (modem, network, hostname resolution), filesystem mount issues (EFI partition mount failed with "logical sector size too small"), or missing firmware/dependencies; increase watchdog timeout temporarily to allow boot completion for debugging; check dmesg for service-specific errors before the hang; verify all required kernel drivers and firmware are present for qcs9100-ride platform services.
4. Detail analysis attachment: failed_case_job207838_3_detailed.md

Case 4: Kernel Crash — Watchdog Pretimeout Panic

1. Failed case: Kernel Crash — Watchdog Pretimeout Panic
2. Root cause: Watchdog bark (pretimeout) triggered a kernel panic while the system was idle in cpuidle. The watchdog pretimeout event fired on CPU0 at 166.954682 seconds after boot, indicating the watchdog was not being serviced (pet) for an extended period, causing the pretimeout governor to panic the system. The system successfully booted, reached userspace, started systemd services, but then hung or became unresponsive during idle, preventing the watchdog from being pet.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR changes (which are primarily audio/sound subsystem and device tree additions). The watchdog timeout configuration may be too aggressive for this qcs9100-ride platform, or there is a latent bug causing the system to hang during idle. Short-term mitigation: increase the watchdog timeout value in the device tree or kernel command line, or disable the watchdog pretimeout panic governor. Proper fix: investigate why the system became unresponsive during idle — check cpuidle driver behavior, interrupt delivery, and scheduler activity on qcs9100-ride. Enable ftrace or add debug instrumentation to capture the system state before the watchdog fires.
4. Detail analysis attachment: failed_case_job207838_4_detailed.md

Job 207839 | SoC sm8750-mtp

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

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

Case 1: ** Probe_Failure_Check (suppressed — known benign)

1. Failed case: ** Probe_Failure_Check (suppressed — known benign)
2. Root cause: ** The Probe_Failure_Check test detected two firmware load failures (bluetooth qca/hmtnv20.b2c and regulatory regulatory.db) during early boot, but both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming firmware loaded correctly at runtime. This is a known false positive caused by the test probing firmware state before drivers fully initialize.
3. Possible fix: No action required. This is a known benign test infrastructure issue covered by suppression rules 2 and 3 in lava-known-benign-failures.md. The functional tests confirm the kernel is working correctly on sm8750-mtp.
4. Detail analysis attachment: failed_case_job207839_1_detailed.md

Case 2: ** PCIe (Test Infrastructure Issue - Not a Kernel Bug)

1. Failed case: ** PCIe (Test Infrastructure Issue - Not a Kernel Bug)
2. Root cause: ** The PCIe test script's validation logic does not match the sm8750-mtp hardware configuration. The kernel PCIe subsystem is fully functional (driver loaded at qcom-pcie 1c00000.pcie, link established as PCIe Gen.2 x2 link up at 10.321s, devices enumerated: Root Port 0000:00:00.0 [17cb:011c] and Endpoint 0000:01:00.0 [17cb:1107], IOMMU integration successful), but the test script's checks for DT node presence, lspci "Capabilities:" string, and driver load state fail due to test implementation assumptions that don't align with this platform's actual configuration.
3. Possible fix: Update the PCIe test script in qcom-linux-testkit (Runner/suites/Kernel/Baseport/PCIe/run.sh) to correctly detect PCIe functionality on sm8750-mtp by: (1) adjusting DT node path checks to search for qcom,.*-pcie compatible strings under /proc/device-tree/soc*/pcie*/ rather than hardcoded paths, (2) updating lspci parsing to use lspci -v for capabilities detection, and (3) verifying driver load by checking /sys/bus/platform/drivers/qcom-pcie/*/ for bound devices rather than relying on module load state (driver may be built-in on sm8750).
4. Detail analysis attachment: failed_case_job207839_2_detailed.md

Case 3: ** USBHost (Test Infrastructure / Hardware Availability Issue)

1. Failed case: ** USBHost (Test Infrastructure / Hardware Availability Issue)
2. Root cause: ** The sm8750-mtp board in the LAVA lab does not have any USB host peripherals (keyboard, mouse, storage device, or hub) physically connected to its USB host port. The USBHost test checks for enumerated USB devices via lsusb or /sys/bus/usb/devices and fails when none are found. The USB host controller driver (dwc3-qcom for device a600000.usb) initialized successfully and the device was added to IOMMU group 4, but no external USB devices are plugged in.
3. Possible fix: This is not a kernel bug. To make the USBHost test pass, physically connect a USB peripheral (e.g., USB storage device, keyboard, or hub) to the USB host port on the sm8750-mtp board in the LAVA lab. Alternatively, mark the USBHost test as SKIP (not FAIL) for sm8750-mtp if USB host hardware is intentionally not available on this board variant, or update the test to distinguish between "driver not loaded" (genuine failure) and "no devices connected" (expected for boards without USB host peripherals).
4. Detail analysis attachment: failed_case_job207839_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM device node /dev/kvm is not available because the kernel is running at EL1 (guest mode) under the Gunyah hypervisor on SM8750-MTP, not at EL2 (hypervisor mode) which is required for KVM functionality. Nested virtualization is not supported in this configuration.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The failure is expected behavior on SM8750-MTP which runs under Gunyah hypervisor. To enable KVM testing: (1) boot the kernel directly at EL2 without a hypervisor, or (2) use a platform that supports nested virtualization, or (3) exclude KVM tests from the SM8750-MTP test suite as they are not applicable to this hypervisor-based platform configuration.
4. Detail analysis attachment: failed_case_job207839_4_detailed.md

Case 5: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM cannot initialize on sm8750-mtp because the system is running under the Gunyah hypervisor, which occupies EL2 (the hypervisor privilege level required by KVM). Linux is running at EL1 as a guest VM, and KVM requires exclusive EL2 access to create the /dev/kvm device node. This is an architectural constraint, not a kernel bug.
3. Possible fix: Add a pre-test check in the KVM test suite to skip KVM tests when Gunyah hypervisor is detected (check for "gunyah" in dmesg or device tree). Long-term: maintain separate test configurations for sm8750-mtp — one with Gunyah (skip KVM tests) and one bare-metal (run KVM tests) — or disable Gunyah in bootloader for platforms where KVM testing is required.
4. Detail analysis attachment: failed_case_job207839_5_detailed.md

Case 6: KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)

1. Failed case: KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)
2. Root cause: KVM cannot initialize on SM8750-MTP because Gunyah hypervisor is already running at EL2; KVM requires exclusive EL2 access and cannot coexist with another hypervisor on ARM64 architecture.
3. Possible fix: This is not a kernel regression but an expected architectural limitation. To enable KVM testing on SM8750-MTP, boot the system without Gunyah hypervisor (requires firmware/bootloader configuration change to disable Gunyah and allow Linux to run at EL2). Alternatively, skip KVM tests on platforms configured with Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job207839_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on SM8750-MTP because Gunyah hypervisor (Type-1) is already running at EL2, preventing KVM (Type-2) from accessing virtualization extensions. CONFIG_KVM is enabled but /dev/kvm device node is never created because the KVM driver detects it cannot operate under an existing hypervisor.
3. Possible fix: This is expected behavior, not a bug. To enable KVM testing on SM8750-MTP: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) use a different test platform without Gunyah, or (3) mark KVM tests as "skip" for SM8750-MTP in the LAVA job definition since this platform is configured for Gunyah-based virtualization, not KVM-based virtualization.
4. Detail analysis attachment: failed_case_job207839_7_detailed.md

Job 207840 | SoC monaco-evk

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

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

Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** WiFi driver (ath11k_pci) probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the Monaco EVK test rootfs (error -2: ENOENT). The MHI bus cannot power up the WCN6855 WiFi chip without firmware, causing the probe sequence to timeout. This is a pre-existing test infrastructure issue, not a PR-introduced regression — the PR contains only documentation and device tree binding changes with no driver code modifications.
3. Possible fix: Update the Monaco EVK test rootfs to include the WCN6855 nfa765 variant firmware files. Install ath11k/WCN6855/hw2.1/nfa765/amss.bin (and associated .mdt/.b* files) into /lib/firmware/ in the test image. Verify the linux-firmware-ath11k package in the Yocto build recipe includes the nfa765 board variant. After updating the rootfs, reflash Monaco EVK and re-run the test — WiFi probe should succeed and Probe_Failure_Check should pass.
4. Detail analysis attachment: failed_case_job207840_1_detailed.md

Case 2: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow

1. Failed case: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow
2. Root cause: SMMU 15200000.iommu experienced an unhandled context fault (fsr=0x402, iova=0x40100000, fsynr=0x130011) indicating a translation fault during a write operation to an unmapped or incorrectly mapped IOVA, immediately followed by a Runtime PM usage count underflow error suggesting improper power management reference counting in the SMMU driver or client device during the fault handling path on monaco-evk.
3. Possible fix: This is a pre-existing platform/driver issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only adds SMMU compatible strings for new SoCs). The failure occurs during fastrpc compute-cb device probe when ADSP remoteproc is initializing. Immediate action: suppress this known monaco-evk SMMU fault in CI test expectations. Long-term fix: investigate SMMU context bank 0 mapping for fastrpc compute-cb@3 device at probe time, verify IOMMU domain attachment sequence and IOVA allocation correctness, and audit Runtime PM get/put pairing in arm-smmu driver fault handler and fastrpc driver probe path.
4. Detail analysis attachment: failed_case_job207840_2_detailed.md

Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The monaco-evk board's USB ports are configured in USB gadget (device) mode, not USB host mode. The test expects to enumerate USB host devices (via lsusb or similar), but no USB devices are physically connected to the board's USB host ports, or the ports are operating in gadget mode. Evidence: systemd reached "Hardware activated USB gadget" target (line showing USB gadget activation), and the test immediately reports "No USB devices found" without any USB host controller enumeration messages.
3. Possible fix: This is a test infrastructure issue, not a PR-introduced kernel bug. The PR does not modify USB host drivers or device tree USB configuration for monaco. To resolve: (1) verify the monaco-evk board has USB devices physically connected to its USB host ports in the LAVA lab, (2) confirm the device tree configures the USB ports in host mode (not gadget/OTG mode), or (3) mark this test as "not applicable" for monaco-evk if the board does not support USB host mode in the current lab configuration.
4. Detail analysis attachment: failed_case_job207840_3_detailed.md

Case 4: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing nfa765 firmware files to the rootfs build. The firmware directory /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ must be populated with amss.bin and other required firmware blobs. This is a build/packaging issue, not a kernel code regression — the PR correctly maps monaco-evk to nfa765 firmware, but the firmware files are not included in the Yocto/distro image.
4. Detail analysis attachment: failed_case_job207840_4_detailed.md

Case 5: WiFi_OnOff — ath11k_pci probe failure

1. Failed case: WiFi_OnOff — ath11k_pci probe failure
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 power-up timeout during WiFi device initialization.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory /lib/firmware/. This is a rootfs/build configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
4. Detail analysis attachment: failed_case_job207840_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: The overall LAVA test definition failed because multiple individual test cases failed within it. The primary root cause is PR-introduced: the ath11k driver probe fails with -ETIMEDOUT because the PR changes the firmware path for monaco-evk to use "nfa765" firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin), but this firmware file is not present in the rootfs. Additionally, the PR's SMMU driver changes introducing interconnect bandwidth voting cause a Runtime PM usage count underflow and SMMU context fault at iova=0x40100000.
3. Possible fix: Revert the ath11k firmware path change for monaco-evk in drivers/net/wireless/ath/ath11k/core.c (line 1054) back to the default firmware path, OR ensure the nfa765 firmware files are included in the rootfs image. For the SMMU issue, review the arm_smmu_icc_enable/disable implementation in drivers/iommu/arm/arm-smmu/arm-smmu.c to ensure proper PM reference counting balance when interconnect bandwidth voting is enabled/disabled.
4. Detail analysis attachment: failed_case_job207840_6_detailed.md

Job 207841 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected deferred probe devices (4 SPMI PMIC temp-alarm devices at c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) during boot; however, BT_ON_OFF and WiFi_OnOff functional tests both passed, confirming that Bluetooth and WiFi firmware loaded correctly at runtime and the devices are fully functional.
3. Possible fix: The firmware load failures are known benign false positives (suppression Rule 3 applies: BT ON/OFF passed). The deferred probe warnings for temp-alarm devices indicate a missing dependency (likely IIO thermal channel provider not yet probed); this is a pre-existing platform issue unrelated to the PR changes (PR touches audio/coresight/DT bindings but not thermal alarm drivers). No action required for this PR; the test should be updated to suppress firmware false positives when functional tests pass, and to allow deferred probe for temp-alarm devices on lemans-evk.
4. Detail analysis attachment: failed_case_job207841_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The PR introduces a new video-codec@aa00000 device node in glymur.dtsi (used by lemans-evk) with iommus properties only on child nodes (non-pixel, pixel), but the parent platform device itself lacks an iommus property, causing the device to not be attached to any IOMMU group. The smmu test validates that critical masters have IOMMU protection and correctly flags this as a configuration error.
3. Possible fix: Add an iommus property to the parent video-codec@aa00000 device node in arch/arm64/boot/dts/qcom/glymur.dtsi, or if the device is intentionally using child-node-only IOMMU mappings (common for video codecs with separate pixel/non-pixel contexts), update the smmu test to recognize this pattern and check child node IOMMU attachments instead of expecting a parent-level attachment.
4. Detail analysis attachment: failed_case_job207841_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 suite completed with 2 genuine test case failures (Probe_Failure_Check and smmu) that are pre-existing platform issues unrelated to the PR changes, which contain only documentation and device tree binding updates with no functional code modifications.
3. Possible fix: These failures are not PR-introduced regressions. The PR can proceed to merge. For the underlying issues: (1) Probe_Failure_Check: investigate temp-alarm deferred probe on PMICs and missing firmware files (regulatory.db, bluetooth firmware); (2) smmu: investigate why video codec device aa00000.video-codec is not attached to an IOMMU group on lemans-evk.
4. Detail analysis attachment: failed_case_job207841_3_detailed.md

Job 207842 | SoC qcs8300-ride

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

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

Case 1: Hung Task Deadlock — UFS devfreq rwsem writer starvation

1. Failed case: Hung Task Deadlock — UFS devfreq rwsem writer starvation
2. Root cause: Rwsem deadlock between UFS devfreq scaling (writer) and qtee_supplicant BSG I/O (reader) on qcs8300-ride. The devfreq_monitor worker (kworker/u34:4:244) attempts to acquire the UFS host write lock via ufshcd_devfreq_scale → down_write, but qtee_supplicant:2555 holds a read lock on the same rwsem while blocked in blk_execute_rq → wait_for_completion_io_timeout waiting for a UFS BSG ioctl to complete. Multiple writeback workers are also blocked waiting for block I/O tags (blk_mq_get_tag), creating cascading I/O stalls. The system cannot make forward progress, preventing login prompt from appearing.
3. Possible fix: This is a pre-existing kernel issue unrelated to the PR (which only fixes DT binding YAML syntax). The deadlock is caused by a known UFS driver locking issue where devfreq scaling and BSG I/O paths contend on the host rwsem. Workaround: disable UFS devfreq (echo userspace > /sys/class/devfreq/*/governor) or apply upstream UFS locking fixes that separate devfreq and I/O paths. The PR changes (documentation-only) do not introduce or fix this issue.
4. Detail analysis attachment: failed_case_job207842_1_detailed.md

Case 2: auto-login-action

1. Failed case: auto-login-action
2. Root cause: Kernel booted successfully but userspace failed to reach login prompt due to filesystem I/O hang — multiple tasks (systemd-timesyn, jbd2/sdf1-8) blocked for >122 seconds waiting on ext4 journal operations on the rootfs partition (/dev/sdf1), preventing system initialization from completing.
3. Possible fix: This is a pre-existing kernel/storage stack issue unrelated to the PR (PR contains only documentation and device tree binding changes, no storage/filesystem code). Re-trigger the LAVA job; if the hang recurs, investigate UFS driver or ext4/jbd2 journal commit path on qcs8300-ride — check for known issues with KIOXIA THGJFGT0T25BAZZA UFS device on this platform, verify UFS firmware version, and consider enabling additional debug (hung_task_panic, jbd2 debug) to capture the exact I/O stall point.
4. Detail analysis attachment: failed_case_job207842_2_detailed.md

Case 3: minimal-boot

1. Failed case: minimal-boot
2. Root cause: Storage I/O subsystem deadlock — UFS device became unresponsive causing multiple kernel worker threads (writeback, devfreq, block layer) to block indefinitely waiting for I/O completion; qtee_supplicant (TrustZone userspace daemon) blocked on UFS BSG ioctl while holding a read lock needed by devfreq worker, creating a cascading deadlock that prevented login prompt from appearing within the 168-second LAVA timeout.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR changes (audio subsystem modifications). Re-trigger the CI job; if the hang recurs, investigate UFS driver stability on qcs8300-ride — check for missing firmware, UFS controller initialization issues, or TrustZone/UFS interaction bugs. Consider increasing the LAVA login timeout from 168s to 300s as a temporary mitigation to allow slower boot scenarios to complete.
4. Detail analysis attachment: failed_case_job207842_3_detailed.md

Case 4: Login Timeout — System Hang (UFS I/O Deadlock)

1. Failed case: Login Timeout — System Hang (UFS I/O Deadlock)
2. Root cause: Kernel booted successfully but userspace hung during init due to a UFS storage I/O deadlock involving qtee_supplicant blocking on UFS BSG requests while multiple writeback workers are blocked waiting for storage I/O completion, preventing the system from reaching a login prompt.
3. Possible fix: This is a kernel-level UFS driver or TrustZone interaction issue causing I/O stalls on qcs8300-ride. Investigate the UFS driver's interaction with qtee_supplicant (TrustZone secure storage operations) and the devfreq scaling path that is blocked on rwsem. Check if PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 introduces any clock/power-domain changes affecting UFS PHY or controller initialization that could cause I/O timeouts. Re-run the test with UFS debug enabled (CONFIG_SCSI_UFS_QCOM_DEBUG=y) and collect full dmesg showing UFS command timeouts and hung task backtraces.
4. Detail analysis attachment: failed_case_job207842_4_detailed.md

Job 207843 | SoC shikra-iqs-evk

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

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

Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test script assumes 8 CPUs and attempts to parse timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform only has 4 CPUs (CPU0-CPU3), causing bash integer comparison errors and false test failures for non-existent CPUs.
3. Possible fix: Update the GIC test script (/lava-207843/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an assumption of 8 CPUs, and only validate timer counts for CPUs that actually exist on the platform.
4. Detail analysis attachment: failed_case_job207843_1_detailed.md

Case 2: remoteproc

1. Failed case: remoteproc
2. Root cause: Modem remoteproc (remoteproc0) enabled in device tree but not configured for auto-boot; firmware path set to qcom/shikra/cqs/qdsp6sw.mbn but remoteproc subsystem never attempts to power up the modem, leaving it in "offline" state.
3. Possible fix: Add missing device tree property to trigger auto-boot for modem remoteproc, or verify that the modem firmware file exists at the specified path and that all required dependencies (clocks, regulators, memory regions) are properly configured in the shikra-iqs-evk device tree.
4. Detail analysis attachment: failed_case_job207843_2_detailed.md

Case 3: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the audiocorecc DT node to arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts with correct reg, clocks, and compatible string per the new binding. Remove or prevent cpufreq-dt instantiation on shikra (check DT cpufreq node and platform code) since shikra uses qcom,shikra-cpufreq-rimps.
4. Detail analysis attachment: failed_case_job207843_3_detailed.md

Case 4: PCIe

1. Failed case: PCIe
2. Root cause: PCIe controller driver not probing on shikra-iqs-evk — test reports "DT node is not present" and "Driver is not loaded". Kernel sync_state messages reference PCIe device at 45e8000.pcie, but no driver probe occurs. This is a pre-existing platform limitation, not a PR-introduced regression (PR only adds DT binding documentation, not driver or DT node).
3. Possible fix: This is not a kernel bug requiring a fix. The PCIe test failure is expected on shikra-iqs-evk until: (1) PCIe driver support for qcom,shikra-pcie compatible is added to pcie-qcom.c, (2) PCIe DT node is added and enabled in shikra-iqs-evk.dts, and (3) board hardware supports PCIe. Mark this test as expected-fail or skip for shikra-iqs-evk in CI configuration until PCIe enablement is complete.
4. Detail analysis attachment: failed_case_job207843_4_detailed.md

Case 5: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (dwc3_qcom/xhci) did not probe or initialize during boot on shikra-iqs-evk, resulting in no USB devices being enumerated when the test ran; this is a hardware/infrastructure/configuration issue, not a kernel crash or PR-introduced regression.
3. Possible fix: Verify USB host controller driver is enabled in kernel config (CONFIG_USB_DWC3_QCOM, CONFIG_USB_XHCI_HCD); check device tree for usb@4e00000 node status and dependencies (clocks, regulators, PHYs); verify physical USB hardware is connected to the test board; if driver is present but not probing, check dmesg for deferred probe or missing dependency errors; re-run test with USB device physically connected to the board's USB host port.
4. Detail analysis attachment: failed_case_job207843_5_detailed.md

Case 6: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** KVM driver initialization failed because ARM Hypervisor (EL2) mode is not available on the Shikra IQS EVK platform. The bootloader/firmware does not enable EL2 for Linux, preventing KVM from creating the /dev/kvm device node. This is a platform limitation, not a kernel bug or a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
3. Possible fix: Mark the KVM_Driver test as "skip" or "expected to fail" on Shikra IQS EVK in the LAVA test definition, since the platform does not support KVM. Alternatively, contact the Qualcomm platform team to request a firmware update that enables EL2 for Linux on this SoC.
4. Detail analysis attachment: failed_case_job207843_6_detailed.md

Case 7: KVM_EL2_DTB — /dev/kvm unavailable (KVM initialization failed)

1. Failed case: KVM_EL2_DTB — /dev/kvm unavailable (KVM initialization failed)
2. Root cause: KVM failed to initialize during boot because HYP (Hypervisor/EL2) mode is not available on the Shikra IQS EVK platform. Boot log shows "kvm [1]: HYP mode not available" at timestamp 3.394310s, preventing /dev/kvm device node creation. This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
3. Possible fix: This is not a PR-introduced regression. The Shikra IQS EVK platform does not support KVM/virtualization in its current firmware/bootloader configuration. To enable KVM: (1) verify the platform supports EL2/HYP mode in hardware, (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 instead of EL1, (3) if the platform fundamentally lacks EL2 support, mark KVM tests as "skip" for this SoC in the CI test matrix rather than "fail".
4. Detail analysis attachment: failed_case_job207843_7_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xb8/0x210 when attempting to read from the hardware RNG device registers. The abort occurred during a memory-mapped I/O read operation (ldr w26, [x28, #0] - instruction b940039a), indicating the hardware RNG block is either not powered/clocked correctly, not present, or the MMIO mapping is incorrect for the Shikra IQS EVK platform.
3. Possible fix: Verify the qcom_rng device tree node for Shikra IQS EVK: confirm the reg property points to the correct MMIO base address for the PRNG hardware block on this SoC, ensure required clocks (core, iface) and power domains are specified and functional, and check that the hardware block is not disabled or gated. If the hardware RNG is not present or functional on Shikra IQS EVK, disable the qcom_rng driver for this platform or mark the DT node as status = "disabled".
4. Detail analysis attachment: failed_case_job207843_8_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The PR introduces a new RNG device tree node (rng@4454000) for Shikra with compatible string qcom,shikra-trng, but the qcom_rng driver attempts to access hardware registers that are either not powered, not clocked, or mapped to an invalid/inaccessible address, resulting in a synchronous external abort (bus error) when the qcom_hwrng test reads from /dev/hwrng.
3. Possible fix: The RNG device node added in the PR is missing required properties (clocks, power-domains, or interconnects) that must be enabled before the hardware can be accessed. Add the missing clock, power-domain, and/or interconnect references to the rng@4454000 node in arch/arm64/boot/dts/qcom/shikra-*.dtsi, following the pattern used in other Qualcomm SoC device trees (e.g., sc7280, sm8450). Verify the correct register base address (0x04454000) matches the hardware documentation for Shikra.
4. Detail analysis attachment: failed_case_job207843_9_detailed.md

Case 10: Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at qcom_rng_read+0xb8/0x210 when attempting to read from the TRNG hardware registers. The PR adds shikra-trng DT binding support, but the hardware MMIO region is either not powered, not clocked, or the base address is incorrect for the shikra-iqs-evk platform, causing the CPU to fault when the driver attempts MMIO read access.
3. Possible fix: Verify the TRNG MMIO base address (0x4454000 per the PR patch) matches the shikra-iqs-evk hardware specification and is correctly mapped in the device tree. Ensure the TRNG hardware block has its clocks enabled and power domain active before the driver probe. Add runtime PM or explicit clock/regulator enablement in the qcom_rng driver probe path for shikra. If the MMIO address is wrong, correct it in arch/arm64/boot/dts/qcom/shikra-*.dts.
4. Detail analysis attachment: failed_case_job207843_10_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware bus access fault (synchronous external abort 0x96000010) in qcom_rng_read() at offset +0xb8 when accessing MMIO register during /dev/hwrng read operation. The qcom_hwrng test triggered a read from /dev/hwrng which caused the qcom_rng driver to access an invalid or unpowered hardware register address, resulting in a fatal bus error and kernel panic on shikra-iqs-evk.
3. Possible fix: Verify the TRNG hardware register base address and clock/power domain configuration in the shikra device tree. The PR adds "qcom,shikra-trng" compatible string support — ensure the DT node at rng@4454000 has correct reg property, required clocks are enabled, and the TRNG power domain is active before driver probe. If the hardware block is not present or powered on shikra-iqs-evk, mark the DT node as status = "disabled" or add runtime power management checks in the driver probe path.
4. Detail analysis attachment: failed_case_job207843_11_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The PR adds a new RNG device node (rng@4454000) for Shikra, but the hardware block is not accessible. When the qcom_hwrng test attempts to read from /dev/hwrng, the driver tries to access the RNG hardware registers and triggers a synchronous external abort at qcom_rng_read+0xb8. This indicates the hardware block is either unpowered, unclocked, at the wrong address, or missing required DT dependencies (clocks, power-domains, interconnects).
3. Possible fix: Add the missing clock, power-domain, and interconnect properties to the rng device tree node in arch/arm64/boot/dts/qcom/shikra.dtsi. Reference the upstream qcom,prng.yaml binding schema and other working SoC examples (e.g., sm8450, sm8550) to identify required properties: clocks, clock-names, power-domains, and interconnects. Verify the MMIO address 0x4454000 is correct from Shikra hardware documentation. After fixing the DT, rebuild the DTB and re-test on Shikra hardware.
4. Detail analysis attachment: failed_case_job207843_12_detailed.md

Job 207844 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test flagged expected platform-specific probe failures and missing optional firmware files as errors; none are PR-introduced regressions - qcom-pcie link training failures occur when no PCIe endpoints are present (hardware-dependent), qcom_qseecom_uefisecapp probe failure is a TrustZone configuration issue, and video codec firmware files are not included in the test rootfs image.
3. Possible fix: Suppress known benign probe failures in the Probe_Failure_Check test for purwa-evk platform: PCIe probe failures with -ENODATA when no endpoints present, qcom_qseecom_uefisecapp -EBUSY errors, and missing optional firmware files (regulatory.db, vpu30_p1_s7.mbn); alternatively, update test to distinguish between critical probe failures (that break functionality) and expected platform-specific failures.
4. Detail analysis attachment: failed_case_job207844_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is missing IOMMU group attachment on purwa-evk platform — the device is present in the device tree but not attached to any IOMMU group, causing the SMMU validation test to fail when checking critical DMA master protection.
3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in the purwa platform DTS file to bind the video codec to an IOMMU group, following the pattern used for other critical masters (GPU, UFS, USB) which successfully show IOMMU group attachments in the test log.
4. Detail analysis attachment: failed_case_job207844_2_detailed.md

Case 3: ** KVM_Driver (Platform Configuration Issue — Gunyah Hypervisor Present)

1. Failed case: ** KVM_Driver (Platform Configuration Issue — Gunyah Hypervisor Present)
2. Root cause: ** KVM cannot initialize on purwa-evk because the Gunyah hypervisor has claimed EL2 (ARM hypervisor exception level) at boot. KVM requires exclusive access to EL2 to create and manage virtual machines, but Gunyah is already running at EL2. The kernel correctly detects this condition and prints "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm from being created.
3. Possible fix: This is not a bug requiring a code fix. This is a platform configuration decision. To enable KVM on purwa-evk, the Gunyah hypervisor must be disabled in the boot firmware/bootloader configuration. Specifically, remove or disable hypvm.mbn from the flash image (spinor/hypvm.mbn). Alternatively, exclude KVM tests from the test suite for platforms that run Gunyah, as KVM and Gunyah are mutually exclusive.
4. Detail analysis attachment: failed_case_job207844_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the kernel is running at EL1 (Exception Level 1) instead of EL2, which is required for KVM/hypervisor functionality. The system boots under the Gunyah hypervisor ("Gunyah based bootup" in UEFI logs), which runs at EL2 and launches the kernel at EL1, preventing KVM from accessing EL2 (HYP mode). The kernel reports "kvm [1]: HYP mode not available" at boot, and consequently /dev/kvm is never created.
3. Possible fix: This is not a PR-introduced regression—the PR contains no KVM, virtualization, or EL2-related changes (only device tree interconnect updates, AEST debugfs, and STP policy documentation). The failure is a platform configuration issue specific to purwa-evk running under Gunyah hypervisor. To enable KVM on this platform, either: (1) boot the kernel directly at EL2 without Gunyah (requires bootloader/firmware changes to disable Gunyah and boot kernel at EL2), or (2) use nested virtualization if Gunyah supports it (requires Gunyah hypervisor configuration changes). For CI purposes, suppress this test on purwa-evk when Gunyah is enabled, or run it only on platforms that boot the kernel at EL2.
4. Detail analysis attachment: failed_case_job207844_4_detailed.md

Case 5: KVM_Infra — Platform EL2 Unavailable

1. Failed case: KVM_Infra — Platform EL2 Unavailable
2. Root cause: The purwa-evk platform firmware boots Linux at EL1 (kernel mode) instead of EL2 (hypervisor mode), preventing KVM from initializing. KVM on ARM64 requires the CPU to run at EL2 to provide virtualization support. Evidence: kernel log line 3189 shows "kvm [1]: HYP mode not available"; CONFIG_KVM is enabled (line 6667) but /dev/kvm is not created (line 6674) because KVM's is_hyp_mode_available() check fails at EL1.
3. Possible fix: This is a platform/firmware limitation, not a PR-introduced regression (PR 978 contains no KVM, boot, or EL2 code changes). Short-term: Mark KVM tests as skip/expected-fail for purwa-evk in the LAVA job definition to prevent false CI failures. Long-term: Update purwa-evk bootloader/firmware (ABL/UEFI) to hand off to Linux at EL2 instead of EL1; coordinate with Qualcomm BSP team. Verify fix by confirming "kvm [1]: Hyp mode initialized successfully" in dmesg and /dev/kvm device node creation.
4. Detail analysis attachment: failed_case_job207844_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the Purwa IoT EVK platform. The kernel message kvm [1]: HYP mode not available at boot time (4.7s) indicates the CPU is not running with EL2 enabled or the platform firmware/bootloader did not preserve EL2 mode for the kernel.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR does not modify KVM or ARM virtualization code. To enable KVM on Purwa EVK: (1) verify the SoC supports virtualization extensions (ARMv8.0-A with VHE or later), (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 (not EL1), and (3) if using Gunyah hypervisor (reserved memory regions present in DT), ensure it's configured to allow KVM in the primary VM. If KVM is not a requirement for this platform, mark the KVM tests as expected-to-skip for Purwa EVK in the CI configuration.
4. Detail analysis attachment: failed_case_job207844_6_detailed.md

[qcomlnxci]

Test jobs on 01f6a0f

• multimedia Job 208285 on glymur-crd
• multimedia Job 208290 on hamoa-iot-evk
• multimedia Job 208288 on kaanapali-mtp
• multimedia Job 208289 on lemans-evk
• multimedia Job 208287 on monaco-evk
• multimedia Job 208284 on purwa-iot-evk
• multimedia Job 208291 on qcs615-ride
• multimedia Job 208286 on qcs6490-rb3gen2
• multimedia Job 208280 on qcs8300-ride
• multimedia Job 208281 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 208283 on shikra-iqs-evk
• multimedia Job 208282 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	⚠️ skip	⚠️ skip	✅ Pass
BT_FW_KMD_Service	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
CPUFreq_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️	◻️	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail
OpenCV	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	◻️	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
USBHost	❌ Fail	◻️	❌ Fail	✅ Pass	❌ Fail	◻️	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
WiFi_OnOff	✅ Pass	◻️	⚠️ skip	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
adsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️	◻️	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
hotplug	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass
rngtest	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	◻️	✅ 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

[qcomlnxci]

Test jobs on 01f6a0f

• multimedia Job 208285 on glymur-crd
• multimedia Job 210661 on hamoa-iot-evk
• multimedia Job 208288 on kaanapali-mtp
• multimedia Job 208289 on lemans-evk
• multimedia Job 208287 on monaco-evk
• multimedia Job 210658 on purwa-iot-evk
• multimedia Job 210659 on qcs615-ride
• multimedia Job 208286 on qcs6490-rb3gen2
• multimedia Job 208280 on qcs8300-ride
• multimedia Job 208281 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 210660 on shikra-iqs-evk
• multimedia Job 208282 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	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	◻️	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ 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	◻️	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	◻️	✅ 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	✅ Pass	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail
OpenCV	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ 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	❌ Fail	◻️	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
WiFi_OnOff	✅ Pass	◻️	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
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	✅ Pass	✅ 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	◻️	✅ 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	◻️	✅ 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

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #978

Job 208048 | SoC qcs615-ride

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

Failed test cases in LAVA job 208048 (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: Suppress this specific failure pattern in the Probe_Failure_Check test by adding a filter rule to exclude "faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2" from the probe failure detection logic, as this is a known benign condition when CONFIG_CFG80211_INTERNAL_REGDB is enabled (which it is on qcs615-ride).
4. Detail analysis attachment: failed_case_job208048_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the smmu test script to recognize that Venus video codec implementations on qcs615 use a unified parent device model where the parent device's IOMMU group attachment (aa00000.video-codec → group 6) provides protection for all video encode/decode operations. The test should not expect separate IOMMU group entries for video-decoder and video-encoder child nodes on platforms using this architecture.
4. Detail analysis attachment: failed_case_job208048_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is an expected platform limitation, not a regression. To enable KVM testing: (1) reconfigure the platform to boot Linux directly at EL2 without Gunyah, or (2) exclude KVM tests from the CI test plan for Gunyah-enabled platforms like QCS615 Ride, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job208048_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for qcs615-ride and other platforms without EL2 support. Add a platform capability check in the LAVA job definition to skip virtualization tests when the target SoC does not support EL2. This is not a kernel bug or PR regression — it is an expected platform limitation.
4. Detail analysis attachment: failed_case_job208048_4_detailed.md

Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 SoC does not support ARM Virtualization Extensions (EL2/HYP mode), which is a mandatory hardware prerequisite for KVM; kernel message kvm [1]: HYP mode not available confirms EL2 is unavailable on this platform.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. Disable KVM tests for QCS615 in the LAVA test suite configuration, or exclude QCS615 from KVM test runs by adding a platform capability check in the test runner that skips KVM tests when /sys/firmware/devicetree/base/compatible contains qcom,qcs615.
4. Detail analysis attachment: failed_case_job208048_5_detailed.md

Case 6: ** KVM_Infra

1. Failed case: ** KVM_Infra
2. Root cause: ** The qcs615-ride platform does not support ARM virtualization extensions (EL2/HYP mode). The kernel message kvm [1]: HYP mode not available at boot time (timestamp [3.232486]) indicates the hardware does not provide the necessary virtualization support. CONFIG_KVM is enabled in the kernel config, but /dev/kvm cannot be created because the underlying hardware capability is absent.
3. Possible fix: Mark KVM tests as "skip" (not "fail") for qcs615-ride in the LAVA test plan, or add a platform capability check to the test suite that skips KVM tests when HYP mode is unavailable. This is not a kernel bug or PR-introduced regression — it is expected behavior for platforms without virtualization extensions.
4. Detail analysis attachment: failed_case_job208048_6_detailed.md

Job 208049 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check — PMIC temp-alarm deferred probe (pre-existing infrastructure issue)

1. Failed case: Probe_Failure_Check — PMIC temp-alarm deferred probe (pre-existing infrastructure issue)
2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state with "reason unknown" on lemans-evk. The qcom-spmi-temp-alarm driver depends on IIO channels from the SPMI ADC driver; the deferred probe indicates the required IIO channel provider is not available or not properly registered at probe time. This is a pre-existing platform/DT configuration issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978, which adds new thermal monitoring drivers (MBG-TM, ADC-TM5-Gen3) but does not modify the existing temp-alarm driver or its IIO ADC dependencies.
3. Possible fix: This is a pre-existing infrastructure issue on lemans-evk, not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR adds new thermal drivers but does not break existing temp-alarm functionality. To resolve: (1) verify the lemans-evk device tree includes proper IIO ADC channel definitions for temp-alarm nodes; (2) confirm CONFIG_QCOM_SPMI_ADC5 or equivalent IIO ADC driver is enabled and probing successfully; (3) check dmesg for IIO ADC probe failures or missing channel registrations; (4) if this is a known lemans-evk limitation, add a suppression rule to the Probe_Failure_Check test for lemans-evk temp-alarm deferred probes. The bluetooth firmware load failures should be suppressed per lava-known-benign-failures.md Rule 3 (BT_ON_OFF test passed).
4. Detail analysis attachment: failed_case_job208049_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on lemans-evk is not attached to any IOMMU group, failing the SMMU test's critical master protection check.
3. Possible fix: Add IOMMU binding for the video-codec device node in the lemans device tree (arch/arm64/boot/dts/qcom/lemans*.dtsi) by adding an iommus property referencing the appropriate SMMU instance and stream ID.
4. Detail analysis attachment: failed_case_job208049_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA framework marked the test run as "unfinished" despite lava_test_shell completing and LAVA_TEST_RUNNER EXIT signal being received. This is a LAVA infrastructure state-tracking issue, not a kernel regression. All individual test cases completed execution (47 tests: 44 passed, 2 failed, 1 skipped), but LAVA's test-shell completion detector flagged the run as incomplete.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate LAVA dispatcher logs for the specific completion condition that was not met. This is not a kernel bug — the two genuine test failures (Probe_Failure_Check: deferred probe warnings; smmu: video codec iommu_group missing) are unrelated to the overall test definition failure and should be triaged separately.
4. Detail analysis attachment: failed_case_job208049_3_detailed.md

Job 208050 | SoC purwa-evk

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

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

Case 1: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The http-download action timed out after 2397 seconds while downloading a 1049 MB build artifact from AWS S3. Network transfer speed degraded progressively from ~10 MB/s to ~0.22 MB/s, causing the download to stall at 45% completion. The configured timeout of 40 minutes was insufficient for the degraded network conditions. Error: "http-download timed out after 2397 seconds".
3. Possible fix: Re-trigger the CI job to retry with potentially better network conditions. If the issue recurs, increase the http-download timeout from 2397s (40min) to 6000s (100min) and the download-retry block timeout from 2400s to 6000s in the LAVA job definition. Additionally, configure download-retry attempts from 1 to 3 to allow automatic recovery from transient network issues. Investigate LAVA worker network path to AWS S3 us-west-2 for bandwidth constraints or routing issues.
4. Detail analysis attachment: failed_case_job208050_1_detailed.md

Case 2: Build Load Failure — HTTP download timeout

1. Failed case: Build Load Failure — HTTP download timeout
2. Root cause: Result: Build Load Failure. The LAVA dispatcher's HTTP download of the 1049 MB boot image from S3 timed out after 2397 seconds at 45% completion (472 MB transferred). Network transfer speed degraded to ~200 KB/s (normal S3 downloads should achieve several MB/s), indicating network congestion or connectivity issues between the LAVA worker and AWS S3 us-west-2 region.
3. Possible fix: Re-trigger the CI job to retry with a fresh network path. If the issue recurs, increase the http-download timeout from the current 2397s (~40min) to 3600s (60min) in the LAVA job definition's download-retry action block, and investigate network path quality between the LAVA worker and S3 (check for bandwidth throttling, routing issues, or worker-side network saturation).
4. Detail analysis attachment: failed_case_job208050_2_detailed.md

Case 3: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The LAVA dispatcher's HTTP download of the 1049 MB boot artifact from AWS S3 timed out after 2397 seconds at 45% completion (472 MB transferred) due to extremely slow network transfer rate (~197 KB/s, expected 5-50 MB/s), exceeding the configured http-download timeout of 39m57s.
3. Possible fix: Re-trigger the CI job to retry with normal network conditions. If the issue recurs, increase the http-download timeout from 2397s (39m57s) to 7200s (2 hours) and the download-retry block timeout from 2399s to 7200s in the LAVA job definition to accommodate large artifacts (>1 GB) on slow network paths. Investigate LAVA worker network connectivity to AWS S3 us-west-2 region and check for bandwidth throttling or routing issues.
4. Detail analysis attachment: failed_case_job208050_3_detailed.md

Case 4: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The http-download action timed out after 2397 seconds while downloading a 1049 MB build artifact from S3, reaching only 45% (472 MB) completion at an effective transfer rate of ~197 KB/s, which was insufficient to complete within the configured 39m57s timeout window.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, investigate network path between LAVA worker (172.19.0.4) and S3 (qli-prd-kernel-gh-artifacts.s3.us-west-2.amazonaws.com) for bandwidth constraints or throttling, and increase the http-download timeout from 2397s (00:39:57) to at least 7200s (02:00:00) and the download-retry block timeout from 00:40:00 to 02:05:00 in the LAVA job definition to accommodate the 1 GB+ artifact size.
4. Detail analysis attachment: failed_case_job208050_4_detailed.md

Job 208051 | SoC shikra-iqs-evk

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

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

Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test assumes 8 CPUs are present but shikra-iqs-evk has only 4 CPUs (CPU0-CPU3), causing the script to fail when checking timer counts for non-existent CPUs 4-7.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding CPU count assumptions, or skip validation for CPUs that are not present in /proc/interrupts.
4. Detail analysis attachment: failed_case_job208051_1_detailed.md

Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected persistent deferred probe entries (sound/snd-sc8280xp audio codec waiting for CPU DAI, va_macro codec waiting for mclk clock, I2C device 3-0010) and two benign probe failures (regulatory.db firmware missing -ENOENT, cpufreq-dt -EEXIST duplicate registration) that are pre-existing platform issues unrelated to PR978 changes.
3. Possible fix: The deferred probe entries are expected on shikra-iqs-evk when audio subsystem dependencies (CPU DAI name resolution, mclk clock provider) are not yet available; the regulatory.db firmware absence is a known userspace packaging issue; the cpufreq-dt -EEXIST is harmless (driver already registered). Suppress these known-benign patterns in the Probe_Failure_Check test configuration for shikra-iqs-evk, or adjust test thresholds to ignore deferred probes that do not block critical functionality.
4. Detail analysis attachment: failed_case_job208051_2_detailed.md

Case 3: PCIe

1. Failed case: PCIe
2. Root cause: Device tree compatible string mismatch — the shikra.dtsi defines the PCIe node with compatible = "qcom,pcie-shikra" but the pcie-qcom.c driver expects compatible = "qcom,shikra-pcie", preventing driver probe and leaving the PCIe controller uninitialized on shikra-iqs-evk.
3. Possible fix: Change the compatible string in arch/arm64/boot/dts/qcom/shikra.dtsi from compatible = "qcom,pcie-shikra"; to compatible = "qcom,shikra-pcie"; to match the driver's of_device_id table entry and the binding document (Documentation/devicetree/bindings/pci/qcom,shikra-pcie.yaml).
4. Detail analysis attachment: failed_case_job208051_3_detailed.md

Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controller remained in gadget mode and did not switch to host mode; no USB host controller driver (xhci-hcd) probe messages found in kernel log, and test script found zero enumerated USB devices.
3. Possible fix: Verify USB hardware setup on shikra-iqs-evk board — ensure a USB device is physically connected to the USB host port and that the port is configured for host mode (not gadget/peripheral mode). If hardware is correct, investigate USB role-switching logic in dwc3-qcom driver changes introduced by this PR, specifically the new uses_eusb2_phy field and role-switching code paths.
4. Detail analysis attachment: failed_case_job208051_4_detailed.md

Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Test environment issue — Bluetooth scan completed successfully (controller powered on, discovery started and stopped cleanly) but no nearby Bluetooth devices were available to discover in the LAVA lab environment during the scan window.
3. Possible fix: This is not a kernel regression. The BT_ON_OFF test passed, confirming Bluetooth stack is functional. The BT_SCAN failure is due to absence of discoverable Bluetooth devices in the test environment. Recommended actions: (1) verify test lab has Bluetooth beacon/device configured for scan tests, (2) if beacon exists, check its power/pairing state, (3) consider extending scan timeout or retry count in test script.
4. Detail analysis attachment: failed_case_job208051_5_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_rng driver crashes with a synchronous external abort when attempting to read from the hardware RNG MMIO registers at address 0x04454000. This indicates the RNG hardware block is either not powered, not clocked, or the MMIO region is not accessible on the Shikra IQS EVK platform. The PR adds the RNG device tree node (rng@4454000) but does not include required dependencies (clocks, power-domains, or interconnects) that are necessary for the hardware block to be accessible.
3. Possible fix: Add the missing clock, power-domain, and interconnect properties to the rng@4454000 device tree node in the Shikra DTS files. Reference similar Qualcomm SoC RNG nodes (e.g., SM8450, SM8550) to identify the required clocks, clock-names, power-domains, and interconnects properties. Ensure the RNG hardware block is properly powered and clocked before the driver attempts MMIO access.
4. Detail analysis attachment: failed_case_job208051_6_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access failure in qcom_rng driver when reading RNG hardware registers at offset 0x0 (instruction b940039a = ldr w26, [x28]). The synchronous external abort (ESR 0x96000010) indicates the hardware did not respond to the MMIO read, likely due to the RNG hardware block being unpowered, unclocked, or in reset state on the Shikra IQS EVK platform.
3. Possible fix: Add proper power domain, clock, and reset dependencies to the qcom_rng device tree node for Shikra (SM8750). Verify that the RNG hardware block is powered and clocked before driver probe. If the hardware is not functional on this platform, disable the qcom_rng driver in the device tree or kernel config for Shikra until hardware support is confirmed.
4. Detail analysis attachment: failed_case_job208051_7_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault (synchronous external abort) in qcom_rng_read+0xb8 when the qcom_hwrng test attempted to read from /dev/hwrng. The fault occurred at instruction b940039a (32-bit load from register x28+0x38), indicating the MMIO register mapped for the hardware RNG is either not powered, not clocked, or the mapping is invalid on shikra-iqs-evk. The KVM_Infra test failure (missing /dev/kvm device node) is unrelated — it's a test infrastructure issue where CONFIG_KVM is enabled but the KVM device node was not created, likely because KVM initialization failed silently or the platform does not support virtualization at EL2.
3. Possible fix: For the kernel crash: Investigate why the qcom_rng MMIO region is not accessible on shikra-iqs-evk — verify the device tree node for qcom,prng has correct reg/clocks/power-domain properties, confirm the RNG hardware block is powered and clocked during the test, and check if runtime PM is suspending the device prematurely. Add error handling in qcom_rng_read to detect and report MMIO access failures gracefully instead of crashing. For the KVM_Infra test: Check dmesg for KVM initialization errors (search for "kvm" or "KVM" early in boot log) — if KVM failed to initialize due to missing hypervisor support or EL2 unavailability on this SoC, either disable CONFIG_KVM for shikra or mark the KVM tests as expected-fail/skip for this platform.
4. Detail analysis attachment: failed_case_job208051_8_detailed.md

Case 9: Kernel Crash — Synchronous External Abort in qcom_rng Driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng Driver
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 adds incomplete device tree node for Shikra RNG hardware at 0x4454000 (missing required clock and power domain properties). When qcom_hwrng test attempts to read from /dev/hwrng, the qcom_rng driver accesses unpowered/unclocked hardware registers, triggering a synchronous external abort at qcom_rng_read+0xb8 and causing kernel panic.
3. Possible fix: Add required clock and power domain properties to the rng@4454000 DT node in arch/arm64/boot/dts/qcom/shikra*.dtsi. Reference similar SoC RNG nodes (e.g., sm8450, sm8550) for the correct clock bindings ("core" clock from gcc) and power-domains property. Alternatively, remove the incomplete rng node from this PR and submit it separately once the full hardware integration is validated.
4. Detail analysis attachment: failed_case_job208051_9_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault in qcom_rng_read() at offset +0xb8 when reading from MMIO register (instruction b940039a = ldr w26, [x28, #0]). The synchronous external abort (SError 0x96000010) indicates the hardware did not respond to the MMIO read, likely because the RNG hardware block was not powered, clocked, or accessible at the time of access. This is a pre-existing hardware/platform issue on shikra-iqs-evk, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only adds DT binding documentation for "qcom,shikra-trng").
3. Possible fix: Verify that the qcom_rng driver probe sequence on shikra correctly enables all required clocks, regulators, and power domains before attempting MMIO access. Add runtime PM calls or explicit clock/regulator enable in the driver probe path if missing. Check the shikra device tree to ensure the RNG node has correct clocks, clock-names, and *-supply properties. As a short-term mitigation, disable the qcom_hwrng test on shikra-iqs-evk until the platform power/clock configuration is fixed.
4. Detail analysis attachment: failed_case_job208051_10_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** Hardware access fault (synchronous external abort) in qcom_rng_read+0xb8/0x210 at kernel timestamp 817.873s during qcom_hwrng test execution. The driver attempted to read from a hardware RNG register that either: (1) was not clocked/powered, (2) had incorrect MMIO mapping, or (3) the hardware block was in an inaccessible state. After the panic, the board rebooted into ramdump/EDL mode and never returned, causing the LAVA test suite to timeout after 40 minutes.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (PR contains only documentation and device tree binding changes, no qcom_rng driver modifications). Immediate mitigation: Skip the qcom_hwrng test in the CI test plan for shikra-iqs-evk until the root cause is fixed. Proper fix: Investigate qcom_rng driver probe sequence and clock/power dependencies on shikra platform — ensure RNG hardware block is properly initialized before the hwrng test runs. Check device tree for correct qcom,rng node configuration (clocks, power-domains, reg addresses). If the issue is reproducible, add runtime PM or clock enable checks in qcom_rng_read before accessing hardware registers.
4. Detail analysis attachment: failed_case_job208051_11_detailed.md

Case 12: Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: Hardware bus error (synchronous external abort) when qcom_rng driver attempted to read hardware register during /dev/hwrng access on shikra-iqs-evk; indicates qcom_rng hardware block is not accessible (likely unpowered, ungated, or incorrectly mapped for this platform).
3. Possible fix: Verify qcom_rng device tree node for shikra-iqs-evk: confirm reg property matches hardware address map, ensure required clocks/power-domains are specified and functional, add runtime PM support if missing, or disable qcom_rng node in DT if hardware is not present/functional on this board variant.
4. Detail analysis attachment: failed_case_job208051_12_detailed.md

Job 208052 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check — Firmware Load Failures (Non-Critical)

1. Failed case: Probe_Failure_Check — Firmware Load Failures (Non-Critical)
2. Root cause: The Probe_Failure_Check test detected three firmware load failures during boot: (1) regulatory.db for cfg80211/wireless regulatory database (error -2 / ENOENT), and (2-3) qcom/qcs6490/modem.mbn for remoteproc0 modem subsystem (error -2 / ENOENT). These are expected, non-critical failures on qcs6490-rb3gen2: regulatory.db is an optional wireless regulatory database that falls back to built-in rules when absent, and modem.mbn is not provisioned in the test filesystem because modem functionality is not required for this CI validation run. All functional remoteproc tests (cdsp_remoteproc, adsp_remoteproc, wpss_remoteproc) passed, confirming the remoteproc subsystem is healthy.
3. Possible fix: Suppress these known benign firmware load failures in the Probe_Failure_Check test by adding an allowlist for: (1) "regulatory.db" (cfg80211 optional regulatory database), and (2) "qcom/qcs6490/modem.mbn" (modem firmware not required for CI). Alternatively, if modem testing is desired, provision the modem firmware files in /lib/firmware/qcom/qcs6490/ in the test rootfs. The PR does not introduce this issue — it is a pre-existing test configuration gap.
4. Detail analysis attachment: failed_case_job208052_1_detailed.md

Case 2: USBHost

1. Failed case: USBHost
2. Root cause: PR-introduced bug in drivers/usb/dwc3/dwc3-qcom.c — the new dwc3_qcom_set_swnode() function attempts to create a managed software_node on every probe attempt, causing sysfs "duplicate filename" errors during deferred probe retries, which prevents the dwc3_qcom driver from successfully probing and initializing the USB host controller on qcs6490-rb3gen2.
3. Possible fix: Modify dwc3_qcom_set_swnode() to check if the software_node already exists before attempting to create it, or use device_add_software_node() instead of device_create_managed_software_node() with proper cleanup, or move the software_node creation to a location that is only called once per device (not on every probe retry).
4. Detail analysis attachment: failed_case_job208052_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the platform is already running under Gunyah hypervisor (EL2 occupied); nested virtualization is not supported, resulting in "HYP mode not available" and missing /dev/kvm device node.
3. Possible fix: This is a platform limitation, not a PR-introduced regression. KVM tests should be skipped on qcs6490-rb3gen2 (and similar Gunyah-based platforms) in the LAVA test suite, or the test should be updated to detect hypervisor presence and report SKIP instead of FAIL when EL2 is already occupied by a hypervisor.
4. Detail analysis attachment: failed_case_job208052_3_detailed.md

Case 4: KVM_EL2_DTB — KVM device node unavailable (not a crash or build failure)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (not a crash or build failure)
2. Root cause: The qcs6490-rb3gen2 board booted with base DTB (qcs6490-rb3gen2.dtb) in EL1 mode instead of EL2 mode. Kernel message at boot: kvm [1]: HYP mode not available (line 2851). KVM requires EL2 (hypervisor exception level) to function; when unavailable, KVM initialization exits early and does not create /dev/kvm. This is expected kernel behavior, not a bug. The PR adds EL2 support via kodiak-el2.dtbo overlay, but the LAVA test configuration did not use the EL2-enabled DTB (qcs6490-rb3gen2-el2.dtb).
3. Possible fix: Update the LAVA job definition to flash and boot with the EL2-enabled DTB: use qcs6490-rb3gen2-el2.dtb (which applies kodiak-el2.dtbo overlay) instead of the base qcs6490-rb3gen2.dtb. Verify the bootloader is configured to boot the kernel in EL2 mode. If the bootloader does not support EL2 boot, this is a platform limitation and the KVM tests should be marked as expected-fail or skipped for non-EL2 configurations.
4. Detail analysis attachment: failed_case_job208052_4_detailed.md

Case 5: KVM Infrastructure Unavailable — Platform Does Not Support EL2/HYP Mode

1. Failed case: KVM Infrastructure Unavailable — Platform Does Not Support EL2/HYP Mode
2. Root cause: The qcs6490-rb3gen2 platform does not provide EL2 (Hypervisor Exception Level) access to the Linux kernel. KVM driver initialization detects this at boot and reports "HYP mode not available", preventing creation of /dev/kvm. This is a platform/firmware limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced failure. No kernel fix is required. To enable KVM on this platform: (1) verify the SoC supports EL2 in hardware, (2) configure the bootloader/firmware (ABL/UEFI) to boot Linux at EL2 or enable EL2 access from EL1, (3) if running under a hypervisor, enable nested virtualization support. If the platform fundamentally does not support EL2, mark KVM tests as "not applicable" for this board in the CI test matrix.
4. Detail analysis attachment: failed_case_job208052_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present; kernel reports "HYP mode not available" during KVM initialization, indicating the platform is running under a hypervisor (Gunyah) that does not expose EL2/HYP mode to the kernel, preventing KVM from creating the device node.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The qcs6490-rb3gen2 board is running under Gunyah hypervisor which reserves EL2 for itself. To enable KVM testing: (1) boot without hypervisor, or (2) use a nested virtualization-capable hypervisor configuration, or (3) exclude KVM tests from the CI plan for hypervisor-enabled builds.
4. Detail analysis attachment: failed_case_job208052_6_detailed.md

Job 208053 | SoC glymur-crd

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

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

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: (1) For temp-alarm deferred probe: Verify thermal zone provider (qcom-spmi-temp-alarm driver) dependencies are met in device tree - check that io-channels ADC references are valid and ADC driver probes successfully. (2) For regulatory.db: Install wireless-regdb package in rootfs or add regulatory.db to /lib/firmware/. Both issues are pre-existing infrastructure/configuration problems, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
4. Detail analysis attachment: failed_case_job208053_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device at address aa00000.video-codec exists in the device tree but failed to probe successfully, resulting in no IOMMU group attachment. The SMMU test validates that critical DMA masters (GPU, USB, Camera, Display, Video) are protected by IOMMU groups; the video codec device is present in the device tree but did not bind to its driver, leaving it without IOMMU protection.
3. Possible fix: Investigate why the video codec driver (qcom-iris or qcom-venus) failed to probe on glymur-crd. Check kernel logs for probe deferral reasons (missing clocks, power domains, or firmware). If the driver is not enabled in the kernel config, enable CONFIG_VIDEO_QCOM_IRIS or CONFIG_VIDEO_QCOM_VENUS. If the device tree node is incomplete or incorrect for glymur, verify the compatible string, reg address, clocks, power-domains, and iommus properties match the hardware specification and driver requirements.
4. Detail analysis attachment: failed_case_job208053_2_detailed.md

Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** Test infrastructure issue — the USBHost test expects a physical USB device (e.g., USB flash drive, keyboard, or mouse) to be connected to the glymur-crd board's USB host port, but none is present. The USB host controller (xHCI) initialized successfully and both USB 2.0 and USB 3.0 root hubs are correctly enumerated, indicating the kernel USB subsystem is functioning normally.
3. Possible fix: Connect a physical USB device to the glymur-crd board's USB host port before running the test suite, or update the test to skip/pass when no external USB devices are present (since USB host controller functionality is verified by successful root hub enumeration). This is not a kernel bug or PR-introduced regression.
4. Detail analysis attachment: failed_case_job208053_3_detailed.md

Case 4: LAVA Test Framework Issue — Missing ENDRUN Signal

1. Failed case: LAVA Test Framework Issue — Missing ENDRUN Signal
2. Root cause: The LAVA test runner emitted <LAVA_SIGNAL_STARTRUN> at the beginning of the test suite but failed to emit the required <LAVA_SIGNAL_ENDRUN> signal before exiting with <LAVA_TEST_RUNNER EXIT>, causing LAVA to mark the test run as "unfinished" despite all individual test cases completing successfully.
3. Possible fix: This is a test infrastructure bug in the qcom-linux-testkit test runner script, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The test definition's run script at Runner/plans/qcom-next-ci-premerge.yaml or the lava-test-runner wrapper must be fixed to emit <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests 208053_1.1.3.1> before the <LAVA_TEST_RUNNER EXIT> signal. Re-run the CI job after fixing the test runner script in the qcom-linux-testkit repository.
4. Detail analysis attachment: failed_case_job208053_4_detailed.md

Job 208054 | SoC kaanapali-mtp

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

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

Case 1: ** PCIe

1. Failed case: ** PCIe
2. Root cause: ** Test infrastructure false positive — PCIe test script validation logic is incorrect for kaanapali-mtp platform. The script checks for DT node paths, lspci output format, and driver load status using methods that don't match this platform's configuration, despite PCIe hardware being fully functional (Gen.3 x2 link up, root port and endpoint device enumerated successfully).
3. Possible fix: Update the PCIe test script (Runner/suites/Kernel/Baseport/PCIe/run.sh) to correctly validate PCIe on kaanapali-mtp by: (1) checking kernel dmesg for "PCIe.*link up" instead of relying on DT node path matching, (2) verifying PCI device enumeration via /sys/bus/pci/devices/ instead of lspci output parsing, (3) confirming driver binding via /sys/bus/platform/drivers/qcom-pcie/ directory presence.
4. Detail analysis attachment: failed_case_job208054_1_detailed.md

Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB controller (a600000.usb) is configured in gadget mode instead of host mode due to dr_mode mismatch, preventing USB host functionality and device enumeration on kaanapali-mtp.
3. Possible fix: Update the device tree for kaanapali-mtp to set dr_mode="host" or dr_mode="otg" in the USB controller node (a600000.usb) to enable USB host functionality; alternatively, verify that the PR changes did not inadvertently modify USB controller configuration for this platform.
4. Detail analysis attachment: failed_case_job208054_2_detailed.md

Case 3: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: WCN7850 Bluetooth controller on kaanapali-mtp fails to respond to HCI command 0xfc00 during firmware download (hmtbtfw20.tlv), resulting in -ETIMEDOUT (-110) across all retry attempts; BD address remains invalid (00:00:00:00:00:00) and controller never initializes.
3. Possible fix: This is a pre-existing hardware/platform issue unrelated to PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only adds QCC2072 support). Recommended actions: (1) Verify UART connection and power sequencing for WCN7850 on kaanapali-mtp; (2) Check if firmware file qca/hmtbtfw20.tlv is present and valid in rootfs; (3) Test with a known-good kaanapali-mtp board to isolate hardware vs. configuration issue; (4) If reproducible across boards, investigate UART flow control settings and WCN7850 power-on timing in device tree.
4. Detail analysis attachment: failed_case_job208054_3_detailed.md

Case 4: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: PR removes the wifi@0 device tree node from &pcie4_port0 in arch/arm64/boot/dts/qcom/kaanapali-mtp.dts (lines 22877-22893 of pr.patch), preventing the ath12k_pci driver from binding to the WCN7850 PCIe WiFi device (PCI ID 17cb:110e) despite successful PCIe enumeration.
3. Possible fix: Restore the wifi@0 device tree node under &pcie4_port0 in kaanapali-mtp.dts with the complete regulator supply bindings (vddaon, vddwlcx, vddwlmx, vddrfacmn, vddrfa0p8, vddrfa1p2, vddrfa1p8, vddpcie0p9, vddpcie1p8) that were removed, or verify the node was intentionally moved to a different location in the device tree and ensure that location is included in the kaanapali-mtp DTB.
4. Detail analysis attachment: failed_case_job208054_4_detailed.md

Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because HYP (EL2) mode is not available to the Linux kernel — the Gunyah hypervisor has already claimed EL2 during early boot (log shows "Hypervisor cold boot, version: gunyah-mobile-ca9ade961"), preventing KVM from accessing the required privilege level to create /dev/kvm.
3. Possible fix: This is an expected architectural limitation on kaanapali-mtp when running under the Gunyah hypervisor. The KVM_Driver test should be skipped or marked as "not applicable" for platforms where a Type-1 hypervisor (Gunyah) is present. To enable KVM functionality, the system would need to boot without the Gunyah hypervisor, which may not be feasible depending on platform requirements. Recommended action: Update the LAVA test suite to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor/type) and skip KVM tests when a Type-1 hypervisor is active.
4. Detail analysis attachment: failed_case_job208054_5_detailed.md

Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization fails because the kaanapali-mtp platform is running Gunyah hypervisor which owns EL2 (hypervisor mode), leaving Linux at EL1 without direct EL2 access required for KVM to initialize; kernel logs show kvm [1]: HYP mode not available at boot.
3. Possible fix: This is an expected platform limitation, not a kernel bug. KVM cannot run on platforms where a Type-1 hypervisor (Gunyah) owns EL2. To enable KVM testing: (1) use a platform configuration without Gunyah hypervisor, or (2) mark KVM tests as "skip" for kaanapali-mtp in the LAVA test definition, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job208054_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on kaanapali-mtp because the platform runs under Gunyah hypervisor which does not expose EL2 (HYP mode) to the guest kernel; kernel correctly reports "kvm [1]: HYP mode not available" and skips KVM initialization, resulting in /dev/kvm not being created.
3. Possible fix: Exclude KVM tests from the kaanapali-mtp test suite in LAVA job definitions, as this platform architecture (Gunyah-based virtualization) does not support nested KVM; alternatively, run KVM tests only on bare-metal platforms or platforms with nested virtualization support.
4. Detail analysis attachment: failed_case_job208054_7_detailed.md

Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed with "HYP mode not available" at boot — the ARM EL2 (hypervisor) exception level is not accessible to the kernel on this kaanapali-mtp platform, preventing KVM driver from creating /dev/kvm.
3. Possible fix: This is a platform firmware/bootloader configuration issue, not a kernel regression. Verify that the kaanapali-mtp firmware boots the kernel at EL1 with EL2 accessible (HCR_EL2.E2H or virtualization extensions enabled). If EL2 is intentionally disabled on this platform, mark KVM tests as expected-to-skip in the LAVA job definition for kaanapali-mtp.
4. Detail analysis attachment: failed_case_job208054_8_detailed.md

Job 208055 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two benign probe failures and eight deferred probes for SPMI temp-alarm devices on hamoa-evk. The qcom_qseecom_uefisecapp probe failure (error -16, EBUSY) indicates the UEFI secure app is not available in the TrustZone environment on this platform. The regulatory.db firmware load failure (error -2, ENOENT) is a known benign false positive when the wireless regulatory database is not required or is built into the kernel. The eight deferred temp-alarm probes are waiting for the qcom-spmi-temp-alarm driver dependency (likely thermal zone registration), which is a transient condition that typically resolves after boot completes.
3. Possible fix: Suppress these known benign failures in the Probe_Failure_Check test for hamoa-evk. Add qcom_qseecom_uefisecapp (error -16) and regulatory.db (error -2) to the test's benign failure allowlist. The deferred temp-alarm probes should be excluded from failure detection as they represent normal deferred probe behavior, not permanent failures. If temp-alarm functionality is critical, verify that the qcom-spmi-temp-alarm driver and thermal subsystem are properly configured in the kernel config and device tree.
4. Detail analysis attachment: failed_case_job208055_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on hamoa-evk platform, failing the SMMU test's critical master protection check.
3. Possible fix: Add IOMMU binding for the video codec device node in the hamoa (x1e80100) device tree. Verify that the video-codec@aa00000 node includes an iommus property referencing the appropriate SMMU instance, similar to other critical masters (GPU, Display, USB, UFS) that passed the test.
4. Detail analysis attachment: failed_case_job208055_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the hamoa-evk platform is running with the Gunyah hypervisor already occupying EL2 (hypervisor mode), preventing KVM from accessing the required privilege level. The kernel log shows "kvm [1]: HYP mode not available" at boot time, which is the expected behavior when a hypervisor is already present.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM test suite should be skipped on platforms configured with Gunyah hypervisor, or the test should be updated to detect hypervisor presence and report SKIP instead of FAIL. To enable KVM on this platform, the system would need to be reconfigured to boot without the Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job208055_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver cannot initialize because HYP mode (EL2) is not available — Gunyah hypervisor is already running at EL2 on hamoa-evk platform, preventing KVM from accessing EL2 which it requires for virtualization support.
3. Possible fix: This is not a PR-introduced regression but a platform limitation. KVM and Gunyah cannot coexist as both require exclusive EL2 access. To enable KVM tests on hamoa-evk: (1) disable Gunyah hypervisor in bootloader/firmware configuration, or (2) exclude KVM tests from hamoa-evk CI runs as this platform is configured for Gunyah-based virtualization, not KVM-based virtualization.
4. Detail analysis attachment: failed_case_job208055_4_detailed.md

Case 5: KVM_Infra — KVM driver initialization failure

1. Failed case: KVM_Infra — KVM driver initialization failure
2. Root cause: KVM driver failed to initialize because the system is running under the Gunyah hypervisor in a mode that does not expose EL2 (HYP mode) to the guest kernel, preventing KVM from creating the /dev/kvm device node. The kernel message "kvm [1]: HYP mode not available" at boot time (line 2946 in dmesg) indicates that CONFIG_KVM is enabled but the CPU is not running at EL2 or the hypervisor has not delegated virtualization extensions to this VM.
3. Possible fix: This is not a PR-introduced regression — the PR contains device tree, documentation, and driver changes unrelated to KVM/virtualization. The hamoa-evk platform is running under the Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-mobile-c487961e9" at boot), which does not currently support nested virtualization (exposing VHE/nVHE to guest VMs). To enable KVM on this platform, either: (1) configure the Gunyah hypervisor to expose EL2 virtualization extensions to the PVM (requires hypervisor configuration changes and is not currently supported on hamoa-evk), or (2) exclude KVM-dependent tests from the hamoa-evk test suite, as this platform is not intended to support nested virtualization.
4. Detail analysis attachment: failed_case_job208055_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed due to 5 genuine sub-test failures: (1) Probe_Failure_Check failed due to qcom_qseecom_uefisecapp probe error -16 and regulatory.db firmware load error -2; (2) smmu test failed because Video codec (aa00000.video-codec) is missing IOMMU group attachment; (3) KVM_Driver, KVM_EL2_DTB, and KVM_Infra all failed because /dev/kvm device node is not present despite CONFIG_KVM being enabled.
3. Possible fix: (1) For Probe_Failure_Check: investigate qcom_qseecom_uefisecapp driver probe failure (error -16 = -EBUSY) and ensure regulatory.db firmware file is present in the rootfs; (2) For smmu: add IOMMU binding for video-codec device (aa00000.video-codec) in the hamoa-evk device tree; (3) For KVM failures: ensure KVM driver initialization completes successfully and creates /dev/kvm device node — check dmesg for KVM initialization errors and verify all KVM dependencies (hypervisor support, EL2 mode) are properly configured for hamoa-evk platform.
4. Detail analysis attachment: failed_case_job208055_6_detailed.md

Job 208056 | SoC monaco-evk

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

Failed test cases in LAVA job 208056 (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) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ directory, causing MHI transport initialization to time out during WiFi chipset power-up on monaco-evk (iq-8275-evk) with WCN6855 hardware.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — this is a firmware packaging issue in the Yocto/build recipe, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
4. Detail analysis attachment: failed_case_job208056_1_detailed.md

Case 2: ** SMMU Fault — Video Codec Missing IOMMU Attachment

1. Failed case: ** SMMU Fault — Video Codec Missing IOMMU Attachment
2. Root cause: ** The video codec device (aa00000.video-codec) on monaco-evk is missing its IOMMU binding in the device tree, causing an SMMU Stage 1 translation fault (FSR=0x402, IOVA=0x40100000) and Runtime PM usage count underflow when the device attempts DMA access during boot.
3. Possible fix: Add the missing iommus property to the video codec device tree node in arch/arm64/boot/dts/qcom/monaco-evk.dts, specifying the correct Stream ID and mask for the apps_smmu controller (consult monaco SoC hardware documentation for the correct SID value, typically in the range 0x800-0x1000 for video subsystems).
4. Detail analysis attachment: failed_case_job208056_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Monaco EVK board USB ports are configured in device/gadget mode (systemd reached "Hardware activated USB gadget" target), not host mode. No USB host devices are physically connected to the board's USB ports, and no USB host controller driver probe messages appear in the kernel log. The test expects enumeration of external USB devices connected to the board's USB host ports.
3. Possible fix: This is a test infrastructure issue, not a kernel regression. The PR patch (documentation and device tree bindings) does not modify USB drivers or configuration. To resolve: (1) verify Monaco EVK hardware has USB host ports with external USB devices physically connected (keyboard, mouse, flash drive, etc.), (2) verify the device tree configures the USB controller in host or OTG mode (dr_mode property), not peripheral-only mode, (3) if the board lacks USB host capability or external devices, mark this test as "skip" or "not applicable" for Monaco EVK in the LAVA test suite.
4. Detail analysis attachment: failed_case_job208056_3_detailed.md

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

1. Failed case: ** WiFi Driver Probe Failure — Missing Board-Specific Firmware
2. Root cause: ** ath11k_pci driver probe fails with -ETIMEDOUT because the required WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ tree. The Monaco EVK board configuration specifies a board-specific firmware subdirectory (nfa765/) that is not populated in the test image, causing MHI firmware load to fail with -ENOENT, which cascades to MHI power-up timeout (-110) and ultimately probe failure.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware package for Monaco EVK builds. If the nfa765/ variant does not exist, create a symlink from ath11k/WCN6855/hw2.1/nfa765/ → ath11k/WCN6855/hw2.1/ or update the Monaco device tree to remove the board-specific firmware path override and use the standard WCN6855 firmware location.
4. Detail analysis attachment: failed_case_job208056_4_detailed.md

Case 5: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Install the nfa765 firmware variant to /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ in the CI rootfs image, or revert the firmware path mapping for monaco-evk in drivers/net/wireless/ath/ath11k/core.c if the nfa765 variant is not yet available for this platform.
4. Detail analysis attachment: failed_case_job208056_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure marked test run as failed ("Marking unfinished test run as failed") despite successful test completion. The underlying genuine test failures are: (1) ath11k_pci WiFi driver probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2 ENOENT), causing -110 ETIMEDOUT probe failure; (2) SMMU context fault at iova=0x40100000 with Runtime PM usage count underflow; (3) USBHost test failure due to no USB devices connected (test environment issue). The PR changes only device tree files for Monaco platform and does not modify WiFi drivers or firmware packaging.
3. Possible fix: Re-trigger the CI job with a rootfs image that includes the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in /lib/firmware/. If the firmware is intentionally excluded for Monaco EVK, update the test suite to skip WiFi tests on this platform. For the LAVA "unfinished test run" error, investigate LAVA job definition timeout settings and test runner exit signal handling.
4. Detail analysis attachment: failed_case_job208056_6_detailed.md

Job 208057 | SoC sm8750-mtp

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two benign firmware load failures during boot: regulatory.db (cfg80211 wireless regulatory database) and qca/hmtnv20.b2c (Bluetooth NVM config file). Both are optional files with fallback mechanisms — cfg80211 falls back to built-in regulatory rules, and Bluetooth falls back to qca/hmtnv20.bin (which loaded successfully). The Probe_Failure_Check test flagged these as failures, but both WiFi (WiFi_OnOff PASS) and Bluetooth (BT_ON_OFF PASS) functional tests passed, confirming the drivers are fully operational.
3. Possible fix: Suppress these two firmware load errors in the Probe_Failure_Check test logic by adding them to the known-benign firmware failure list. Alternatively, package the optional firmware files (regulatory.db and qca/hmtnv20.b2c) in the rootfs to eliminate the warnings. No kernel or driver fix is required — this is a test false positive.
4. Detail analysis attachment: failed_case_job208057_1_detailed.md

Case 2: PCIe

1. Failed case: PCIe
2. Root cause: Test infrastructure issue — PCIe controller (qcom-pcie 1c00000.pcie) probed successfully and PCIe Gen.2 x2 link is up with WiFi 7 device (ath12k_wifi7_pci 0000:01:00.0) enumerated, but the test script reports "DT node is not present", "Capabilities: missing", and "Driver is not loaded". The test is checking for a specific PCIe endpoint device, DT node, or driver module that is not present or not configured on sm8750-mtp, despite the PCIe subsystem functioning correctly. This is a pre-existing platform configuration gap, not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which adds camera subsystem support, not PCIe changes).
3. Possible fix: Update the PCIe test script to either (1) skip the test on sm8750-mtp if the expected PCIe endpoint hardware is not present on this board variant, or (2) adjust the test expectations to match the actual sm8750-mtp PCIe configuration (WiFi 7 endpoint only, no additional PCIe devices). Alternatively, if a specific PCIe endpoint device is expected, add the corresponding DT node and driver configuration to sm8750-mtp.dts.
4. Detail analysis attachment: failed_case_job208057_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — the USBHost test expects physical USB devices to be connected to the USB host port on the sm8750-mtp board, but no USB devices are present in the LAVA lab environment. The kernel USB subsystem initialized successfully (USB device a600000.usb added to IOMMU group 4), but the test fails because it cannot enumerate any connected USB peripherals.
3. Possible fix: This is not a kernel regression. The test failure is expected when no USB devices are physically connected. To resolve: (1) connect a USB device (e.g., USB flash drive, keyboard, or hub) to the USB host port on the sm8750-mtp board in the LAVA lab, or (2) mark this test as SKIP when no USB devices are expected to be present, similar to how the Ethernet test is skipped when no Ethernet interfaces are detected.
4. Detail analysis attachment: failed_case_job208057_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize because the kernel is running as a guest under the Gunyah hypervisor (nested virtualization not supported). Evidence: Hypervisor boot message "gunyah-mobile-1dda77727 prod" at boot, CONFIG_KVM enabled but /dev/kvm device node not created, no KVM initialization messages in dmesg.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. Either: (1) Run KVM tests on bare-metal (non-virtualized) SM8750-MTP hardware, or (2) Enable nested virtualization support in the Gunyah hypervisor configuration if the feature is available, or (3) Skip KVM tests when running under a hypervisor by detecting virtualization at test runtime.
4. Detail analysis attachment: failed_case_job208057_4_detailed.md

Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on SM8750 MTP because the Gunyah hypervisor is already running at EL2; only one hypervisor can control EL2 at a time, and KVM requires exclusive EL2 access to create /dev/kvm.
3. Possible fix: This is expected behavior, not a failure. To enable KVM testing, boot the platform without Gunyah (disable Gunyah in bootloader/firmware configuration), or mark KVM tests as "skip" for Gunyah-enabled platforms in the CI test matrix.
4. Detail analysis attachment: failed_case_job208057_5_detailed.md

Case 6: KVM_Infra — /dev/kvm device node not present

1. Failed case: KVM_Infra — /dev/kvm device node not present
2. Root cause: KVM subsystem did not initialize because the SM8750 MTP platform is running under the Gunyah hypervisor (reserved memory region gunyah-hyp@80000000 present in device tree). When a Type-1 hypervisor like Gunyah is active, KVM (a Type-2 hypervisor) cannot initialize as it requires exclusive access to EL2 virtualization extensions. CONFIG_KVM is enabled in the kernel config, but the KVM driver never probes or creates /dev/kvm because the CPU is already running in a virtualized context.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (the patch touches only documentation, device tree bindings for various SoCs, and driver code unrelated to KVM/virtualization). The failure is expected platform behavior for SM8750 MTP when Gunyah is enabled. To enable KVM testing on this platform: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) use a different test platform that boots Linux directly at EL2 without a Type-1 hypervisor, or (3) mark KVM tests as expected-to-skip on SM8750 MTP in the LAVA test definition when Gunyah is detected.
4. Detail analysis attachment: failed_case_job208057_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: The SM8750-MTP target is running as a guest under the Gunyah hypervisor in protected mode (evidenced by pvmfw@824a0000 reserved memory and "arm-pv: using stolen time PV" message). KVM cannot initialize in nested virtualization scenarios because /dev/kvm device node creation is blocked when the kernel detects it is running under a hypervisor. CONFIG_KVM is enabled but KVM subsystem does not create /dev/kvm when running as a guest.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. To enable KVM testing on SM8750-MTP, the target must boot in bare-metal mode (without Gunyah hypervisor). Update the LAVA job definition or board configuration to boot the kernel directly on hardware rather than as a protected VM guest. Alternatively, exclude KVM tests from the test suite for targets configured to run under Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job208057_7_detailed.md

Job 208058 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two probe/firmware errors detected: (1) qcom-pcie 1c10000.pci probe failed with -ETIMEDOUT due to PCIe PHY initialization timeout on qcs8300-ride platform - a pre-existing hardware/platform issue unrelated to this PR's documentation and binding changes; (2) regulatory.db firmware load failure - a known benign error where cfg80211 falls back to built-in certificates.
3. Possible fix: For PCIe: Investigate qcs8300-ride board-specific PCIe PHY power sequencing, clock configuration, or hardware connectivity for the 1c10000.pci controller; this is a platform bring-up issue, not a kernel regression. For regulatory.db: No action required - this is expected behavior when the optional regulatory.db file is not present; the system uses built-in X.509 certificates successfully (confirmed by "Loaded X.509 cert" messages in log).
4. Detail analysis attachment: failed_case_job208058_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The video-codec device at aa00000.video-codec is missing IOMMU group attachment because the PR adds a new video-codec@aa00000 device tree node for qcs8300 without an iommus property on the parent node — only child nodes (non-pixel and pixel) have iommus properties, leaving the parent platform device unprotected by the SMMU.
3. Possible fix: Add an iommus property to the parent video-codec@aa00000 device tree node in the qcs8300 DTS, or mark the device as dma-coherent if SMMU protection is not required, or update the SMMU test to skip checking parent nodes when child nodes have IOMMU mappings.
4. Detail analysis attachment: failed_case_job208058_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller initialized successfully but reports zero ports available ("USB0 root hub has no ports" at kernel boot). This is a hardware/device-tree configuration issue where the xHCI controller at 0x0a400000 is enabled but has no downstream ports configured in the device tree, preventing enumeration of any USB devices beyond the root hub.
3. Possible fix: This is a pre-existing hardware/board configuration limitation on qcs8300-ride, not introduced by this PR (PR changes only PCIe PHY regulators and eMMC CQE support). The test expectation should be adjusted to SKIP for qcs8300-ride until USB host ports are physically wired and configured in the device tree, or the board should be equipped with a USB hub/device on the available port.
4. Detail analysis attachment: failed_case_job208058_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: qcs8300-ride platform boots under Gunyah hypervisor (EL2), preventing KVM initialization. Linux runs as a guest (EL1) and cannot access hypervisor mode required for KVM. Log evidence: "Hypervisor cold boot, version: gunyah-1cb9db980" and "gunyah-md-region" reserved memory. CONFIG_KVM=y but /dev/kvm not created because KVM requires EL2 access unavailable to guest OS.
3. Possible fix: This is expected platform behavior, not a regression. The KVM_Driver test should be skipped on qcs8300-ride (and other Gunyah-based platforms) or the test should detect hypervisor presence and skip gracefully. Update LAVA test definition to exclude KVM tests for qcs8300-ride, or modify KVM_Driver test to check for hypervisor presence (/sys/hypervisor/type or dmesg) and report SKIP instead of FAIL.
4. Detail analysis attachment: failed_case_job208058_4_detailed.md

Case 5: KVM_EL2_DTB — KVM device node unavailable (platform configuration incompatibility)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (platform configuration incompatibility)
2. Root cause: QCS8300 Ride platform is configured with Gunyah hypervisor running at EL2 (Exception Level 2). KVM requires exclusive access to EL2 to provide virtualization support, but Gunyah already occupies EL2. ARM architecture does not support nested virtualization in this configuration, so KVM initialization is silently skipped during boot, resulting in /dev/kvm device node never being created.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The test suite expects KVM functionality on a platform where KVM cannot run due to Gunyah hypervisor presence. Fix: Either (1) disable KVM tests on Gunyah-enabled platforms in the LAVA test definition, or (2) use a non-Gunyah firmware build if KVM testing is required, or (3) mark KVM tests as expected-to-skip on qcs8300-ride when Gunyah is active.
4. Detail analysis attachment: failed_case_job208058_5_detailed.md

Case 6: KVM Infrastructure Test Failure — Nested Virtualization Not Supported

1. Failed case: KVM Infrastructure Test Failure — Nested Virtualization Not Supported
2. Root cause: QCS8300 Ride platform runs as a Primary VM under Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-1cb9db980" and "arm-pv: using stolen time PV"). KVM requires EL2 access to initialize; when running as a guest, EL2 is owned by Gunyah. Without nested virtualization support enabled in Gunyah for this platform, KVM cannot initialize and /dev/kvm is never created. This is a platform configuration limitation, not a kernel bug.
3. Possible fix: This is not a PR-introduced regression (PR touches documentation/DT bindings, not KVM). To enable KVM on this platform: (1) verify Gunyah hypervisor version supports nested virtualization for QCS8300, (2) enable nested virtualization in Gunyah configuration for the PVM, (3) rebuild and reflash hypervisor firmware, or (4) mark KVM tests as "not applicable" for QCS8300 Ride in CI when running under Gunyah, as nested virtualization may not be a supported use case for this automotive platform.
4. Detail analysis attachment: failed_case_job208058_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver failed to initialize on QCS8300 platform — CONFIG_KVM is enabled but /dev/kvm device node was not created, indicating KVM did not probe successfully at runtime, likely due to missing EL2/virtualization support or platform-specific KVM initialization failure.
3. Possible fix: Verify QCS8300 hardware supports ARM virtualization extensions (EL2); check for missing KVM initialization messages in dmesg; if platform doesn't support KVM, disable CONFIG_KVM in the kernel config or mark KVM tests as expected-fail for this SoC; if KVM should be supported, investigate why kvm_arch_init() or kvm_init() failed during boot.
4. Detail analysis attachment: failed_case_job208058_7_detailed.md

Job 208059 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check — Deferred Probe and Probe Failures

1. Failed case: Probe_Failure_Check — Deferred Probe and Probe Failures
2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state with "reason unknown", and two genuine probe failures: (1) regulatory.db firmware missing (-ENOENT) for cfg80211 wireless regulatory database, and (2) Aquantia AQR115C Ethernet PHY probe failure (-EINVAL) due to missing firmware-name property in device tree.
3. Possible fix: The deferred temp-alarm probes and both probe failures are pre-existing platform/configuration issues not introduced by this PR. For temp-alarm: investigate missing IIO ADC dependency (likely qcom-spmi-adc driver not loaded or DT thermal-zone linkage missing). For regulatory.db: install linux-firmware package or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB. For Aquantia PHY: add firmware-name property to the PHY node in qcs9100-ride device tree or provide the firmware file.
4. Detail analysis attachment: failed_case_job208059_1_detailed.md

Case 2: ** smmu (IOMMU group attachment validation failure)

1. Failed case: ** smmu (IOMMU group attachment validation failure)
2. Root cause: ** The video codec device node (aa00000.video-codec) added in this PR is missing the required top-level iommus property in the device tree. The SMMU test validates that critical masters (USB, Display, Video) are attached to IOMMU groups for memory protection. The video codec node only defines iommus properties in its child nodes (non-pixel and pixel), but the parent device itself has no IOMMU attachment, causing the test to fail.
3. Possible fix: Add the iommus property to the top-level iris: video-codec@aa00000 device node in arch/arm64/boot/dts/qcom/glymur.dtsi. Reference similar video codec nodes in other Qualcomm SoCs (e.g., arch/arm64/boot/dts/qcom/sc7180.dtsi line 2390: iommus = <&apps_smmu 0x0c00 0x60>;) to determine the correct SMMU stream ID (SID) for the qcs9100 video codec, then add the property before the child node definitions.
4. Detail analysis attachment: failed_case_job208059_2_detailed.md

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

1. Failed case: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)
2. Root cause: ** The USBHost test expects external USB devices (e.g., USB flash drive, keyboard, mouse) to be physically connected to the qcs9100-ride board's USB ports. Only USB root hubs (Bus 001/002/003 Device 001) are enumerated, indicating no USB peripherals are plugged into the board. The kernel USB subsystem is functioning correctly — all xhci-hcd host controllers initialized successfully, USB core drivers registered, and root hubs detected. This is a test environment/hardware setup issue, not a kernel regression.
3. Possible fix: Ensure USB test devices (USB flash drive, keyboard, or mouse) are physically connected to the qcs9100-ride board's USB ports before running the USBHost test. If the test is intended to validate only USB host controller initialization (not peripheral detection), update the test script to pass when root hubs are detected and functional, similar to how the Ethernet test skips when no cable is connected.
4. Detail analysis attachment: failed_case_job208059_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 definition marked as failed because 3 individual test cases within the test suite failed (Probe_Failure_Check, smmu, USBHost), causing LAVA to mark the overall test definition as "unfinished" despite the test runner completing successfully.
3. Possible fix: This is not a genuine failure of the test definition itself — the kernel booted successfully, all tests executed, and the test runner completed normally. The "unfinished test run" error is LAVA's way of propagating individual test failures to the test definition level. Review the 3 individual test failures (Probe_Failure_Check, smmu, USBHost) separately to determine if they are PR-introduced regressions or pre-existing issues.
4. Detail analysis attachment: failed_case_job208059_4_detailed.md

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #978

Job 208280 | SoC qcs8300-ride

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

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

Case 1: ** Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)

1. Failed case: ** Probe_Failure_Check — Driver Probe Failures (Pre-existing Platform Issues)
2. Root cause: ** PCIe endpoint device not present, not powered, or link training timeout
3. Possible fix: These are not PR-introduced regressions. Recommended actions: (1) Add firmware-name = "..."; property to Aquantia PHY DT node in qcs8300-ride device tree; (2) Either install PCIe endpoint hardware or mark PCIe controller as status = "disabled" in DT if not used on this board variant; (3) Include wireless-regdb package in rootfs build or suppress regulatory.db check if WiFi is not required. The PR can proceed; these failures are baseline platform issues.
4. Detail analysis attachment: failed_case_job208280_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The qcs8300 video-codec device (aa00000.video-codec) is not attached to an IOMMU group because the PR introduces a new Iris video codec driver that uses child-node IOMMU bindings (non-pixel and pixel sub-devices) instead of parent-level iommus property, causing the SMMU test's critical-master check to fail when it expects the parent device to have direct IOMMU group attachment.
3. Possible fix: Update the SMMU test script to recognize the Iris video codec's child-node IOMMU binding pattern and verify IOMMU protection via child devices (iris_non_pixel and pixel nodes) rather than requiring parent-level attachment, or add a parent-level iommus property to the video-codec node for backward compatibility with existing test infrastructure.
4. Detail analysis attachment: failed_case_job208280_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (xHCI) initialized with zero ports on USB0 root hub, preventing enumeration of any USB devices beyond the root hub itself; kernel message "xhci-hcd xhci-hcd.1.auto: USB0 root hub has no ports" at boot indicates hardware/DT configuration issue where the xHCI controller's port count is incorrectly reported as zero.
3. Possible fix: Verify and correct the USB DT node configuration for qcs8300-ride in the device tree; ensure the xHCI controller's port configuration properties (num-ports, port mappings, PHY bindings) are correctly specified; if the PR touches USB PHY or dwc3-qcom driver code (as indicated by changes to drivers/usb/dwc3/dwc3-qcom.c, drivers/phy/qualcomm/phy-qcom-qmp-usbc.c, drivers/phy/qualcomm/phy-qcom-qusb2.c), review those changes for regressions in port enumeration logic or PHY initialization that could cause the controller to report zero ports.
4. Detail analysis attachment: failed_case_job208280_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: /dev/kvm device node not created because KVM driver failed to initialize — ARM virtualization extensions (VHE/nVHE) are not available or kernel is not running at EL2, preventing KVM from creating the character device. CONFIG_KVM is enabled but no KVM initialization messages appear in dmesg, indicating silent initialization failure typical of missing hardware virtualization support or incorrect boot exception level on qcs8300-ride.
3. Possible fix: Verify that the qcs8300-ride platform's bootloader (ABL/XBL) boots Linux at EL2 (hypervisor mode) and that the SoC supports ARM virtualization extensions. If the platform does not support KVM (common for automotive SoCs without virtualization), mark KVM tests as "not applicable" for this target in the CI test matrix. If virtualization is expected, check bootloader configuration and device tree for hypervisor/EL2 setup, and confirm CPU feature registers (ID_AA64PFR0_EL1) indicate EL2 support.
4. Detail analysis attachment: failed_case_job208280_4_detailed.md

Case 5: KVM_EL2_DTB — KVM device node unavailable (expected behavior under Gunyah hypervisor)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (expected behavior under Gunyah hypervisor)
2. Root cause: The qcs8300-ride target is running under the Gunyah hypervisor (EL2 already occupied), which prevents KVM from initializing. KVM requires EL2 to function and cannot run nested under another hypervisor. The kernel has CONFIG_KVM=y but the KVM subsystem does not create /dev/kvm because it detects it's running as a guest (no access to EL2).
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which contains audio/STP/AEST documentation changes unrelated to virtualization). This is expected platform behavior for qcs8300-ride running under Gunyah. To enable KVM testing: (1) boot the target without Gunyah hypervisor (bare-metal mode), or (2) use a platform that supports nested virtualization, or (3) mark KVM tests as "skip" for Gunyah-enabled platforms in the CI test matrix.
4. Detail analysis attachment: failed_case_job208280_5_detailed.md

Case 6: KVM_Infra — KVM driver not initialized (CONFIG_KVM enabled but /dev/kvm absent)

1. Failed case: KVM_Infra — KVM driver not initialized (CONFIG_KVM enabled but /dev/kvm absent)
2. Root cause: KVM driver (kvm.ko / kvm-arm.ko) did not initialize during boot despite CONFIG_KVM=y; system is running as a guest under Gunyah hypervisor which prevents nested virtualization — KVM requires EL2 access but the kernel is running at EL1 under the hypervisor, so KVM initialization is silently skipped.
3. Possible fix: This is expected behavior on qcs8300-ride when running under Gunyah hypervisor — KVM cannot function as a nested hypervisor in this configuration. Either: (1) skip KVM tests on this platform/configuration, or (2) boot without the Gunyah hypervisor (bare-metal) if KVM functionality is required, or (3) add a test precondition check for hypervisor presence before running KVM tests.
4. Detail analysis attachment: failed_case_job208280_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: /dev/kvm device node not created because KVM driver failed to initialize on qcs8300-ride platform (Monaco target). CONFIG_KVM is enabled but no KVM initialization messages appear in dmesg, indicating the platform does not support KVM virtualization or the hypervisor/firmware configuration prevents KVM from running at EL2.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR does not modify KVM code or platform configuration. Mark KVM tests as expected failures for qcs8300-ride platform, or investigate platform firmware/hypervisor configuration to enable EL2 virtualization support if required.
4. Detail analysis attachment: failed_case_job208280_7_detailed.md

Job 208281 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing hardware/firmware configuration issues on qcs9100-ride: (1) Aquantia AQR115C Ethernet PHY probe fails with -EINVAL (-22) due to missing firmware-name DT property; (2) regulatory.db firmware file missing from rootfs (benign - WiFi/BT functional). Four SPMI temp-alarm devices remain in deferred probe due to missing thermal zone dependencies (pre-existing platform issue, not PR-introduced).
3. Possible fix: For Aquantia PHY: Add firmware-name property to the PHY node in qcs9100-ride.dts or mark the property as optional in the driver. For regulatory.db: Install wireless-regdb package in rootfs (or suppress as known benign since WiFi/BT work). For temp-alarm deferred probes: Investigate missing thermal zone configuration for qcs9100 PMICs - likely requires thermal zone DT nodes or driver updates to resolve dependencies.
4. Detail analysis attachment: failed_case_job208281_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 adds a new video codec device node (iris: video-codec@aa00000) in the device tree without the required iommus property, causing the SMMU test to fail because this critical master device is not attached to any IOMMU group.
3. Possible fix: Add the iommus property to the iris: video-codec@aa00000 device node in the device tree. Based on similar Qualcomm video codec implementations, the property should specify the appropriate SMMU stream IDs for the video hardware, e.g., iommus = <&apps_smmu 0x2180 0x20>; (exact stream IDs should be verified from hardware documentation for sa8775p/glymur).
4. Detail analysis attachment: failed_case_job208281_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel issue requiring a code fix. To resolve: (1) Connect at least one functional USB device (e.g., USB flash drive, keyboard, or mouse) to the qcs9100-ride board's USB ports before running the test, OR (2) Mark this test as "skip" or "expected-fail" in the LAVA job definition for boards in the lab that do not have USB peripherals connected, OR (3) Update the test to distinguish between "USB subsystem broken" (kernel bug) vs "no devices connected" (infrastructure/environment issue) and report the latter as a warning rather than a failure.
4. Detail analysis attachment: failed_case_job208281_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 framework issue — the test runner script emitted <LAVA_SIGNAL_STARTRUN> but failed to emit the required <LAVA_SIGNAL_ENDRUN> completion signal, causing LAVA dispatcher to mark the test run as "unfinished" despite all individual test cases passing successfully.
3. Possible fix: Re-trigger the CI job; if the issue recurs, inspect the test runner script (/lava-208281/0/tests/0_qcom-next-ci-premerge-tests/run.sh or Runner/utils/result_parse.sh) to ensure it emits <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests 208281_1.1.3.1> after completing all tests and before exiting.
4. Detail analysis attachment: failed_case_job208281_4_detailed.md

Job 208282 | SoC sm8750-mtp

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

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

Case 1: Probe_Failure_Check — Benign Firmware Load False Positives

1. Failed case: Probe_Failure_Check — Benign Firmware Load False Positives
2. Root cause: The Probe_Failure_Check test detected two firmware load errors (qca/hmtnv20.b2c for Bluetooth and regulatory.db for WiFi regulatory) during early boot on sm8750-mtp. However, both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming that Bluetooth and WiFi firmware loaded successfully at runtime. These are known false positives caused by the test probing firmware state before the drivers have fully initialized.
3. Possible fix: Suppress these failures per LAVA Known Benign Failure Suppression Rules 2 and 3. No kernel or PR changes required. Consider updating the Probe_Failure_Check test to exclude firmware load errors when corresponding functional tests pass, or to run after driver initialization completes.
4. Detail analysis attachment: failed_case_job208282_1_detailed.md

Case 2: PCIe

1. Failed case: PCIe
2. Root cause: PCIe is not enabled or fully configured in the sm8750-mtp device tree; the test expects functional PCIe hardware but the platform either has PCIe disabled (status = "disabled" in DT) or lacks the necessary board-level configuration (regulators, clocks, PHY) to bring up the PCIe controller.
3. Possible fix: If PCIe hardware is present on sm8750-mtp: enable the pcie0 node in arch/arm64/boot/dts/qcom/sm8750-mtp.dts by adding &pcie0 { status = "okay"; ... } with proper regulator/clock/PHY bindings. If PCIe is not expected on this board variant: mark the PCIe test as SKIP for sm8750-mtp in the LAVA test definition or add sm8750-mtp to the PCIe test's board exclusion list.
4. Detail analysis attachment: failed_case_job208282_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: No USB devices enumerated on sm8750-mtp platform; PMIC GLINK device link creation failed with USB controller (a600000.usb), error code 0x180 (DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME), indicating USB role switching infrastructure is not fully functional, preventing USB host mode operation or device detection.
3. Possible fix: This is a test environment/platform configuration issue, not a PR-introduced kernel regression. The PR touches USB driver code (dwc3-qcom.c, USB PHY drivers, USB typec) but does not introduce code that would prevent USB enumeration. Recommended actions: (1) Verify USB host hardware is physically connected to the sm8750-mtp board's USB port; (2) Check if the board's USB port is configured for host mode vs device mode in the device tree; (3) Investigate why PMIC GLINK fails to create device link with USB controller - this may require PMIC GLINK/UCSI firmware or device tree fixes specific to sm8750; (4) If sm8750-mtp USB host is not yet supported in this kernel version, mark the USBHost test as SKIP for this platform until USB host support is enabled.
4. Detail analysis attachment: failed_case_job208282_3_detailed.md

Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM failed to initialize because the SM8750-MTP platform is running under the Gunyah hypervisor, which prevents KVM from creating the /dev/kvm device node. Nested virtualization (running KVM inside a hypervisor) is not supported on this ARM platform configuration.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The test should be skipped on platforms running under Gunyah hypervisor. Add a pre-test check to detect Gunyah hypervisor presence (check for "gunyah-hyp" in /proc/device-tree/reserved-memory or dmesg) and skip KVM tests when detected, or reconfigure the platform to boot without Gunyah if KVM testing is required.
4. Detail analysis attachment: failed_case_job208282_4_detailed.md

Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization failed because the kernel is running as a guest under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-mobile-1dda77727"), which prevents KVM from accessing EL2 and creating the /dev/kvm device node. CONFIG_KVM is enabled but the driver cannot initialize in nested virtualization context.
3. Possible fix: This is not a PR-introduced regression — it is an expected platform configuration limitation. The SM8750-MTP board runs under Gunyah hypervisor by default, which prevents KVM from initializing. To enable KVM testing: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) mark KVM tests as "skip" for SM8750-MTP in the LAVA test definition when Gunyah is present, or (3) add a pre-test check that detects hypervisor presence and skips KVM tests automatically.
4. Detail analysis attachment: failed_case_job208282_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on SM8750 MTP because the Gunyah hypervisor is already running and has taken control of EL2 (Exception Level 2). Only one hypervisor can control EL2 at a time, creating a fundamental architectural conflict. CONFIG_KVM is enabled in the kernel configuration, but /dev/kvm device node is not created because KVM initialization is blocked by the presence of Gunyah.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR modifies documentation, device tree bindings, and various drivers unrelated to KVM or virtualization infrastructure. To enable KVM on this platform, either: (1) disable Gunyah hypervisor in the firmware/bootloader configuration and reboot, or (2) accept that KVM tests will fail on platforms configured to run Gunyah, and mark KVM tests as "not applicable" for Gunyah-enabled platforms in the CI test matrix.
4. Detail analysis attachment: failed_case_job208282_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM failed to initialize on SM8750-MTP because the platform is running under Gunyah hypervisor, which prevents KVM from creating /dev/kvm. CONFIG_KVM is enabled but KVM ARM initialization silently fails when a Type-1 hypervisor (Gunyah) is already running at EL2, as KVM requires exclusive EL2 access.
3. Possible fix: This is expected behavior on SM8750-MTP with Gunyah hypervisor — KVM and Gunyah cannot coexist. Either: (1) Skip KVM tests on Gunyah-enabled platforms by adding a platform exclusion rule to the LAVA job definition, or (2) If KVM testing is required, use a build/platform configuration without Gunyah hypervisor (requires firmware changes to disable Gunyah at boot).
4. Detail analysis attachment: failed_case_job208282_7_detailed.md

Job 208283 | SoC shikra-iqs-evk

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

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

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

1. Failed case: GIC (Test Script Bug — Not a Kernel Issue)
2. Root cause: The GIC test script incorrectly assumes 8 CPUs and attempts to parse timer interrupt counts for CPUs 4-7 from /proc/interrupts, but the shikra-iqs-evk platform has only 4 CPUs (0-3), causing bash integer comparison errors when the script reads non-numeric fields ("GICv3", "Level", "arch_timer") beyond the 4th counter.
3. Possible fix: Update the GIC test script (Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding an 8-CPU assumption, and only validate timer counts for CPUs that actually exist on the target platform.
4. Detail analysis attachment: failed_case_job208283_1_detailed.md

Case 2: Probe_Failure_Check — Deferred probe not resolved (driver dependency failure)

1. Failed case: Probe_Failure_Check — Deferred probe not resolved (driver dependency failure)
2. Root cause: Audio codec (va_macro at a078000) and sound card (snd-sc8280xp) fail to probe due to missing "Audio ref clock source" (third clock input) in audiocorecc DT node — the clock phandle is set to <0> (null) instead of a valid clock provider, causing AUDIO_CORE_CC_TX_MCLK_CLK lookup to fail with "unable to get mclk clock".
3. Possible fix: Add the missing audio reference clock phandle as the third clock input to the audiocorecc node in arch/arm64/boot/dts/qcom/shikra.dtsi (replace <0> with the correct audio ref clock provider phandle, likely from an external audio oscillator or LPASS clock source defined elsewhere in the DT).
4. Detail analysis attachment: failed_case_job208283_2_detailed.md

Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe driver fails to bind to the device tree node due to a compatible string mismatch — the DT binding and driver match table specify "qcom,shikra-pcie" but the actual device tree node in arch/arm64/boot/dts/qcom/shikra.dtsi uses "qcom,pcie-shikra" (reversed order), preventing driver probe and causing the test to report "DT node is not present", "Driver is not loaded", and "Capabilities: is missing".
3. Possible fix: Change the compatible string in arch/arm64/boot/dts/qcom/shikra.dtsi from compatible = "qcom,pcie-shikra"; to compatible = "qcom,shikra-pcie"; to match the driver's of_device_id table entry and DT binding specification.
4. Detail analysis attachment: failed_case_job208283_3_detailed.md

Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure failure — no USB host devices physically connected to the shikra-iqs-evk board's USB host port during test execution.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The failure is due to missing test hardware (no USB device plugged into the USB host port). To resolve: (1) Verify USB host port hardware connectivity on the shikra-iqs-evk test fixture, (2) Connect a USB device (e.g., USB flash drive, keyboard, or hub) to the USB host port before running the USBHost test, or (3) Mark USBHost as a manual/conditional test that requires specific hardware setup and skip it in automated CI when hardware is not available.
4. Detail analysis attachment: failed_case_job208283_4_detailed.md

Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth scan failure (no devices discovered after 3 attempts) occurring concurrently with continuous regulator voltage range errors from pm8150_l2 (l2: unsupportable voltage range: 3500000-3296000uV). The PR introduces a DTS configuration for shikra-iqs-evk where pm8150_l2 regulator max voltage is set to 3300000uV, but the SD card controller (sdhc_2) vqmmc supply attempts to request 3500000uV, exceeding the configured maximum. This regulator constraint violation floods the kernel log and may degrade system performance or power management, indirectly impacting Bluetooth scan reliability on the shikra-iqs-evk platform.
3. Possible fix: Correct the pm8150_l2 regulator-max-microvolt in arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi from 3300000 to at least 3500000 to accommodate the SD card controller's voltage requirements, or adjust the sdhc_2 vqmmc voltage request to stay within the 1650000-3300000uV range. Verify the hardware datasheet for pm8150_l2's actual supported voltage range and align DTS configuration accordingly.
4. Detail analysis attachment: failed_case_job208283_5_detailed.md

Case 6: KVM_Driver — Driver Initialization Failure

1. Failed case: KVM_Driver — Driver Initialization Failure
2. Root cause: KVM driver initialization failed because the Shikra IQS EVK platform does not support HYP (EL2) mode, as indicated by kernel message "kvm [1]: HYP mode not available" at boot; CONFIG_KVM is enabled but /dev/kvm device node was not created because the ARM KVM driver detected the platform lacks EL2 virtualization support.
3. Possible fix: This is a platform/firmware limitation, not a kernel bug. To enable KVM on Shikra: (1) Verify the SoC SKU supports virtualization (not fused off), (2) Update bootloader (ABL/XBL) to enable EL2 and boot kernel at EL2, (3) Verify TrustZone configuration allows EL2 access. If virtualization is not required for this platform, mark KVM tests as "not applicable" for Shikra IQS EVK in the CI test matrix.
4. Detail analysis attachment: failed_case_job208283_6_detailed.md

Case 7: ** Kernel Crash — Synchronous External Abort (hardware bus fault)

1. Failed case: ** Kernel Crash — Synchronous External Abort (hardware bus fault)
2. Root cause: ** The qcom_rng driver triggered a synchronous external abort (hardware bus fault) at offset +0xb8 in qcom_rng_read when attempting to read from the RNG hardware MMIO registers during the qcom_hwrng test. This is a platform-specific hardware access failure on Shikra IQS EVK, unrelated to the KVM_EL2_DTB test failure (which is expected since this platform does not support KVM/HYP mode). The PR modifies only documentation and DT bindings and does not touch qcom_rng or any runtime driver code.
3. Possible fix: This is a pre-existing platform/firmware issue, not a PR regression. Investigate Shikra IQS EVK device tree for qcom_rng node: verify MMIO address range, clock/regulator dependencies, and power domain configuration. Check if the RNG hardware block is properly powered and clocked on this platform. If the RNG is not functional on Shikra IQS EVK, disable the qcom_hwrng test for this platform or mark it as expected-fail until the hardware access issue is resolved.
4. Detail analysis attachment: failed_case_job208283_7_detailed.md

Case 8: ** Kernel Crash — Synchronous External Abort in qcom_rng Driver (Hardware Access Fault)

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng Driver (Hardware Access Fault)
2. Root cause: ** The qcom_hwrng test triggered a synchronous external abort when the qcom_rng driver attempted to read from the hardware RNG MMIO registers at address 0xffff800082f03004. The abort indicates the RNG hardware block is not accessible, likely because: (1) the device power domain is not enabled, (2) the device clock is not running, (3) the device is held in reset, or (4) the MMIO address mapping in the device tree is incorrect for the Shikra IQS EVK platform. The repeated regulator voltage range warnings (l2: unsupportable voltage range: 3500000-3296000uV) throughout the boot log suggest broader power management configuration issues on this board. This is a pre-existing platform issue, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which does not touch qcom_rng or related code).
3. Possible fix: This is a board/platform configuration issue, not a kernel regression. Recommended actions: (1) Verify the qcom_rng device tree node for Shikra IQS EVK includes correct clocks, clock-names, power-domains, and reg (MMIO base address) properties. (2) Confirm the RNG power domain and clocks are enabled before the driver probes by checking genpd_summary and clk_summary debugfs outputs. (3) If the RNG hardware is not present or not functional on this board variant, disable the qcom_rng driver in the defconfig or mark the DT node as status = "disabled" for Shikra IQS EVK. (4) Investigate and fix the regulator voltage range warnings (l2: unsupportable voltage range) which may be related to the RNG power domain issue. (5) For CI purposes, either fix the board configuration or exclude the qcom_hwrng test from the Shikra IQS EVK test suite until the hardware issue is resolved.
4. Detail analysis attachment: failed_case_job208283_8_detailed.md

Case 9: Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: The qcom_rng driver triggered a synchronous external abort at PC qcom_rng_read+0xb8 when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The abort indicates the driver attempted to access an unmapped, unpowered, or clock-gated hardware RNG register on the Shikra IQS EVK platform. After the panic, the system correctly entered warm reset/ramdump mode per the configured reboot=panic_warm and qcom_scm.download_mode=1 kernel parameters, but LAVA timed out waiting for the board to complete ramdump collection and reboot.
3. Possible fix: This is a pre-existing platform/driver issue, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only adds device tree bindings and documentation). Short-term: disable the qcom_hwrng test for Shikra IQS EVK in the LAVA test definition until the RNG hardware/driver issue is resolved. Long-term: investigate why the RNG hardware registers are not accessible on Shikra — verify clock/power domain configuration in the device tree, confirm the RNG hardware block is present and functional on this SoC variant, and add proper error handling in qcom_rng_read to gracefully fail instead of crashing when hardware access fails.
4. Detail analysis attachment: failed_case_job208283_9_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware register access fault in qcom_rng_read() at address 0x4454000 on shikra-iqs-evk; PR adds shikra-trng DT node at reg=<0x04454000 0x1000> but the hardware block is either not powered, not clocked, or the register address is incorrect for this SoC, causing a bus fault when the qcom_hwrng test attempts to read entropy.
3. Possible fix: Verify the RNG hardware block base address (0x04454000) is correct for Shikra SoC by cross-referencing the hardware register specification; ensure the RNG block has required clock and power domain dependencies declared in the DT node (clocks, power-domains properties); if the address is correct, add runtime PM support or explicit clock/regulator enable in the qcom_rng driver probe path before accessing registers; if the address is wrong, correct it in arch/arm64/boot/dts/qcom/shikra-*.dtsi.
4. Detail analysis attachment: failed_case_job208283_10_detailed.md

Case 11: Kernel Crash — Synchronous External Abort (Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (Hardware Access Fault)
2. Root cause: The PR adds a new RNG device tree node for shikra at address 0x04454000, but when the qcom_rng driver attempts to read hardware registers during the qcom_hwrng test, a synchronous external abort occurs at qcom_rng_read+0xb8, indicating the hardware block is either unpowered, unclocked, or the register address is incorrect for the shikra-iqs-evk platform.
3. Possible fix: Verify the RNG hardware register base address (0x04454000) is correct for shikra-iqs-evk by cross-referencing with the SoC hardware manual; add missing clock and power-domain properties to the rng DT node (the current PR patch shows only compatible and reg properties with no clocks or power-domains); ensure the RNG hardware block is enabled and clocked before driver probe by adding required clocks, clock-names, and power-domains properties following the pattern used in other Qualcomm SoC RNG nodes.
4. Detail analysis attachment: failed_case_job208283_11_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_rng driver crashes with a synchronous external abort when attempting to read TRNG hardware registers on shikra-iqs-evk. The PR adds shikra-trng device tree support, but the hardware access fails at the bus level, indicating missing power/clock dependencies or incorrect register mapping for this board variant.
3. Possible fix: Review and correct the shikra-trng device tree node in the PR: verify the reg property matches the hardware documentation for QCM2290/shikra, add all required clocks/power-domains/regulators per the qcom,prng.yaml binding, and ensure the TRNG hardware block is properly enabled and accessible on the shikra-iqs-evk board. If the TRNG hardware is not present or not functional on this board variant, mark the device node as status = "disabled" in the board-specific DTS.
4. Detail analysis attachment: failed_case_job208283_12_detailed.md

Job 208284 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected 10 probe/firmware errors on purwa-evk: PCIe controllers failed due to missing PHY init sequences for this SoC (-ENODATA), QSEECOM failed with -EBUSY (TZ resource conflict), video codec firmware missing from rootfs (-ENOENT), and 7 PMIC temp-alarm devices remain in deferred probe (non-critical).
3. Possible fix: These are pre-existing platform issues unrelated to the PR (which contains only documentation changes). For PCIe: add purwa-specific PHY init sequences to qcom-qmp-pcie-phy driver or DT. For video codec: add vpu30_p1_s7.mbn firmware to rootfs /lib/firmware/qcom/vpu/. For QSEECOM: investigate TZ app load ordering. Deferred temp-alarms are benign and can be ignored.
4. Detail analysis attachment: failed_case_job208284_1_detailed.md

Case 2: ** smmu

1. Failed case: ** smmu
2. Root cause: ** Video codec device aa00000.video-codec is not attached to any IOMMU group on purwa-evk (X1E80100 SoC), causing the SMMU test to fail its critical master protection validation.
3. Possible fix: Add the missing iommus property to the video codec device tree node for purwa-evk/X1E80100. The device should be assigned to an IOMMU group similar to other critical masters (GPU, Display, Camera, USB, UFS). Verify the device tree includes iommus = <&apps_smmu [stream_id] [flags]>; in the aa00000.video-codec node.
4. Detail analysis attachment: failed_case_job208284_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM requires ARM EL2 (Hypervisor mode) support to create the /dev/kvm device node. The purwa-evk platform does not provide EL2 capability, causing KVM initialization to fail with "HYP mode not available" during boot. This is a platform hardware limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Skip KVM tests on purwa-evk platform in the LAVA test suite configuration, as this platform does not support virtualization. Add a platform capability check to the test runner that excludes KVM tests when EL2 is unavailable. Alternatively, run KVM tests only on platforms with confirmed EL2 support (e.g., rb3gen2, kodiak).
4. Detail analysis attachment: failed_case_job208284_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Platform hardware/firmware limitation — purwa-evk boots without EL2 (Hypervisor) mode enabled, preventing KVM initialization. Kernel message at boot: "kvm [1]: HYP mode not available" (line 2619). CONFIG_KVM is enabled but /dev/kvm device node is not created because KVM driver exits early when HYP mode is unavailable.
3. Possible fix: This is NOT a PR-introduced regression. Mark KVM tests as SKIP on purwa-evk (non-EL2 variant) in CI configuration, OR update CI to flash EL2-enabled firmware and use purwa-iot-evk-el2.dtb for KVM test runs. The PR adds EL2 device tree overlays but does not modify the base platform configuration or KVM driver code.
4. Detail analysis attachment: failed_case_job208284_4_detailed.md

Case 5: KVM Infrastructure Test — Expected Failure (Nested Virtualization Not Supported)

1. Failed case: KVM Infrastructure Test — Expected Failure (Nested Virtualization Not Supported)
2. Root cause: KVM cannot initialize on purwa-evk because the system is running as a guest under the Gunyah hypervisor ("Hypervisor cold boot, version: gunyah-mobile-c487961e9"), which means EL2/HYP mode is not available to the guest kernel. The kernel correctly reports "kvm [1]: HYP mode not available" and does not create /dev/kvm.
3. Possible fix: Exclude KVM tests from the purwa-evk test suite, as this platform runs under Gunyah hypervisor and does not support nested virtualization. Alternatively, add a pre-flight check in the test harness to skip KVM tests when a hypervisor is detected (check for "Hypervisor cold boot" in boot logs or reserved memory regions like "gunyah-hyp@80000000").
4. Detail analysis attachment: failed_case_job208284_5_detailed.md

Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the Purwa IoT EVK platform — 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 hardware/firmware limitation, not a PR-introduced regression. The Purwa IoT EVK does not support EL2 virtualization mode. Either: (1) exclude KVM tests from the Purwa EVK test suite, or (2) verify that the platform firmware/bootloader is configured to boot the kernel in EL2 mode (check bootloader configuration and ensure the kernel is booted with appropriate EL2 entry point).
4. Detail analysis attachment: failed_case_job208284_6_detailed.md

Job 208285 | SoC glymur-crd

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test infrastructure false positive — the test flags 8 PMIC temp-alarm devices in deferred probe state (expected behavior while waiting for thermal zone dependencies) and 1 benign firmware load failure from faux_driver (test/dummy driver) for regulatory.db, which does not impact actual wireless functionality (WiFi_OnOff and BT_ON_OFF tests both passed).
3. Possible fix: Refine Probe_Failure_Check test logic to exclude known-benign deferred probe patterns (PMIC temp-alarm devices commonly defer until thermal zones initialize) and filter out faux_driver firmware errors (test driver artifacts). Alternatively, verify that temp-alarm devices eventually probe successfully after thermal subsystem initialization completes, rather than checking at a fixed early boot checkpoint.
4. Detail analysis attachment: failed_case_job208285_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The new IRIS video codec driver (aa00000.video-codec) introduced in this PR uses child device nodes (non-pixel, pixel) for IOMMU attachment instead of attaching the parent platform device directly to an IOMMU group, causing the SMMU validation test to fail when checking for critical master IOMMU protection on glymur-crd.
3. Possible fix: Update the SMMU test script to recognize the IRIS video codec's child-node IOMMU attachment pattern by checking for iommus properties in child nodes (non-pixel/pixel) when the parent aa00000.video-codec device is not directly attached to an IOMMU group, or add an iommus property to the parent iris node in the device tree if the hardware supports it.
4. Detail analysis attachment: failed_case_job208285_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue - no USB peripheral devices physically connected to the glymur-crd board's USB ports; only USB 2.0 and USB 3.0 root hubs are enumerated (Bus 001 Device 001: ID 1d6b:0002, Bus 002 Device 001: ID 1d6b:0003), indicating USB host controllers are functional but no test devices are attached.
3. Possible fix: Connect a USB peripheral device (e.g., USB flash drive, USB keyboard, or USB mouse) to one of the glymur-crd board's USB ports before running the USBHost test; alternatively, mark this test as SKIP when no USB test devices are available in the LAVA lab setup, or update the test to verify USB controller functionality without requiring physical devices.
4. Detail analysis attachment: failed_case_job208285_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Infrastructure Issue)
2. Root cause: LAVA test harness incorrectly marked the test case as "unfinished" and failed it despite the test runner completing normally with <LAVA_TEST_RUNNER EXIT>. All individual tests executed and reported results, but LAVA's dispatcher failed to recognize the test run as complete. This is a LAVA infrastructure/configuration issue, not a kernel regression. The test suite itself had 3 genuine test failures (Probe_Failure_Check, smmu, USBHost) but these are unrelated to the LAVA "unfinished" marking.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate the LAVA job definition for incorrect test completion detection patterns or timeout configurations. The LAVA dispatcher may be expecting a different completion signal than what the test runner provides. Check the lava-test-shell action configuration and ensure the test definition's completion criteria match what the test runner emits.
4. Detail analysis attachment: failed_case_job208285_4_detailed.md

Job 208286 | SoC qcs6490-rb3gen2

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

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

Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script parsing bug — the GIC test script at line 75 attempts integer comparison on a string field ("GICv3") from /proc/interrupts, causing the test to incorrectly report CPUs 6-7 as failed when those CPUs are offline and have no interrupt counters in /proc/interrupts.
3. Possible fix: Update the GIC test script to skip CPUs that are not online (check /sys/devices/system/cpu/cpu*/online before testing) or fix the awk/parsing logic at line 75 to correctly extract only numeric interrupt count fields, ignoring the "GICv3" controller name column.
4. Detail analysis attachment: failed_case_job208286_1_detailed.md

Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Refine the Probe_Failure_Check test to suppress known-benign firmware load failures: (1) regulatory.db when cfg80211 loads compiled-in certificates successfully, (2) renesas_usb_fw.mem when the PCIe device is optional and not critical, (3) modem.mbn when the remoteproc is non-autoboot and intentionally offline. Alternatively, add these firmware files to the test rootfs if they are intended to be present.
4. Detail analysis attachment: failed_case_job208286_2_detailed.md

Case 3: Freq_Scaling — Test Logic Error (CPU Topology Mismatch)

1. Failed case: Freq_Scaling — Test Logic Error (CPU Topology Mismatch)
2. Root cause: The Freq_Scaling test script expects 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 only has 7 working CPUs. CPU7 failed to boot during kernel initialization with error "psci: failed to boot CPU7 (-22)" and "CPU7: failed to boot: -22". The test passed checks for cpu0-cpu6 cpufreq interfaces but then failed with message "CPUFreq interface not found. Test Failed" because it attempted to check cpu7 which does not exist on this platform.
3. Possible fix: Update the Freq_Scaling test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /sys/devices/system/cpu/present instead of hardcoding an expected CPU count. The test should iterate only over CPUs that are actually present and online on the target platform. Example: Replace hardcoded loop for cpu in {0..7} with dynamic detection: for cpu in $(cat /sys/devices/system/cpu/present | tr ',' ' ' | tr '-' ' ').
4. Detail analysis attachment: failed_case_job208286_3_detailed.md

Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices physically connected to the qcs6490-rb3gen2 board's USB host port during test execution; the xHCI PCIe controller (Renesas 0001:04:00.0) failed to probe due to missing firmware (renesas_usb_fw.mem), preventing enumeration of any PCIe-attached USB devices.
3. Possible fix: This is not a PR-introduced regression. The test expects external USB devices to be connected to the board's USB host port. Either: (1) connect a USB device (e.g., USB flash drive, keyboard, or hub) to the board's USB host port before running the test, or (2) mark this test as SKIP when no USB host hardware is available in the LAVA lab setup, or (3) provide the missing Renesas USB firmware file (renesas_usb_fw.mem) in the rootfs at /lib/firmware/ to enable the PCIe xHCI controller.
4. Detail analysis attachment: failed_case_job208286_4_detailed.md

Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver cannot initialize because the kernel is running as a guest under the Gunyah hypervisor (Type-1 hypervisor at EL2), which prevents the kernel from accessing HYP mode (EL2) required for KVM operation. The kernel log shows "kvm [1]: HYP mode not available" during boot, and consequently /dev/kvm device node is never created.
3. Possible fix: This is expected behavior on qcs6490-rb3gen2 when running under Gunyah hypervisor. The KVM_Driver test should be skipped or marked as N/A for platforms running under a Type-1 hypervisor. Update the test suite to detect hypervisor presence (check for "Hypervisor cold boot" or gunyah in boot logs) and skip KVM tests when running as a guest VM.
4. Detail analysis attachment: failed_case_job208286_5_detailed.md

Case 6: KVM_EL2_DTB — KVM/Virtualization Driver Initialization Failure

1. Failed case: KVM_EL2_DTB — KVM/Virtualization Driver Initialization Failure
2. Root cause: KVM driver initialization failed during kernel boot because HYP mode (EL2 exception level) is not available on qcs6490-rb3gen2. The kernel message kvm [1]: HYP mode not available at boot time (line 2848) indicates the CPU is not running at EL2 or the bootloader/firmware did not configure EL2 properly, preventing KVM from creating the /dev/kvm device node required by all three KVM test cases.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which contains only documentation and GPU virtualization config changes unrelated to KVM/ARM EL2 setup). Verify that the qcs6490-rb3gen2 bootloader/firmware is configured to boot the kernel at EL2 or with VHE (Virtualization Host Extensions) enabled. If KVM support is not expected on this platform, mark these KVM test cases as "skip" for qcs6490-rb3gen2 in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job208286_6_detailed.md

Case 7: KVM_Infra (test infrastructure issue — platform does not support virtualization)

1. Failed case: KVM_Infra (test infrastructure issue — platform does not support virtualization)
2. Root cause: qcs6490-rb3gen2 SoC lacks ARM EL2 (Hypervisor) support; KVM driver initialization aborted with "HYP mode not available" during boot, preventing /dev/kvm creation.
3. Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test suite, or add a platform capability check to skip KVM tests when EL2 is not available. This is not a kernel bug — the platform hardware does not support virtualization.
4. Detail analysis attachment: failed_case_job208286_7_detailed.md

Case 8: KVM Test Failures — /dev/kvm not available

1. Failed case: KVM Test Failures — /dev/kvm not available
2. Root cause: KVM initialization failed because HYP (EL2) mode is not available on qcs6490-rb3gen2; 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 platform limitation, not a PR-introduced regression. The qcs6490-rb3gen2 board does not support EL2/HYP mode required for KVM. Either: (1) skip KVM tests on this platform in the CI job definition, or (2) if EL2 support is expected, verify bootloader/firmware configuration enables EL2 and check device tree hyp reserved memory region is correctly configured.
4. Detail analysis attachment: failed_case_job208286_8_detailed.md

Job 208287 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k probe timeout

1. Failed case: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k probe timeout
2. Root cause: The Probe_Failure_Check test detected five probe/firmware errors: (1) regulatory.db firmware missing (-ENOENT), (2-3) Bluetooth firmware files (wcnhpbtfw21.tlv, hpbtfw21.tlv) missing (-ENOENT), (4) ath11k WiFi firmware (amss.bin) missing (-ENOENT), and (5) ath11k_pci probe timeout (-ETIMEDOUT). The Bluetooth firmware failures are known benign (BT_ON_OFF test passed, confirming Bluetooth is functional). The WiFi firmware failure and ath11k probe timeout are genuine failures — WiFi_OnOff test also failed, confirming WiFi is non-functional on monaco-evk. The root cause is that the ath11k WiFi driver failed to load firmware for the WCN6855 hw2.1 chip with board variant "nfa765", causing the PCI probe to time out waiting for the MHI subsystem to initialize.
3. Possible fix: This is a pre-existing platform/firmware packaging issue, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR changes audio (sc8280xp.c, qdsp6/topology.c, sdw.c) and does not touch WiFi, ath11k, or firmware paths. The monaco-evk board image is missing the required WiFi firmware file /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin. To fix: (1) add the missing firmware file to the rootfs firmware directory, or (2) if "nfa765" is an incorrect board variant for monaco-evk, update the device tree qcom,ath11k-calibration-variant property to match the available firmware board directory (e.g., remove the variant or use a standard one like "qcom,wcn6855-hw2.1"). The Bluetooth and regulatory.db firmware warnings are cosmetic and do not affect functionality.
4. Detail analysis attachment: failed_case_job208287_1_detailed.md

Case 2: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow

1. Failed case: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow
2. Root cause: SMMU 15200000.iommu reported an unhandled Stage-1 translation fault (FSR=0x402 TF, IOVA=0x40100000, S1CBNDX=5, WNR) immediately followed by "Runtime PM usage count underflow!" during fastrpc compute-cb device attachment at boot on monaco-evk, indicating a Runtime PM reference counting bug in the SMMU driver that causes premature power-down attempts during active fault handling.
3. Possible fix: Apply the upstream fix for arm-smmu Runtime PM usage count underflow (check drivers/iommu/arm/arm-smmu/arm-smmu.c for pm_runtime_get/put balance in fault handler paths); verify the SMMU driver correctly holds a PM reference during fault handling and device attachment; if the issue persists, enable CONFIG_IOMMU_TLBSYNC_DEBUG and CONFIG_ARM_SMMU_TESTBUS_DUMP to capture detailed SMMU state at fault time.
4. Detail analysis attachment: failed_case_job208287_2_detailed.md

Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no USB devices physically connected to the monaco-evk USB host ports during test execution. The USB host controllers (a400000.usb and a600000.usb) are present, correctly initialized, and IOMMU-protected, but the test expects at least one USB device to be enumerated and fails when none are found.
3. Possible fix: This is not a kernel bug. Verify the monaco-evk lab setup: ensure a USB device (e.g., USB flash drive, keyboard, or hub) is physically connected to one of the board's USB host ports before running the USBHost test. If the board's USB ports are intended to operate in device/gadget mode only, update the test suite to skip USBHost on monaco-evk or mark it as expected-fail for this platform.
4. Detail analysis attachment: failed_case_job208287_3_detailed.md

Case 4: ** WiFi Driver Probe Failure — Firmware Missing

1. Failed case: ** WiFi Driver Probe Failure — Firmware Missing
2. Root cause: ** ath11k_pci driver probe fails with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ directory. MHI bus cannot power up the WCN6855 WiFi chip without firmware, causing the probe sequence to time out. This is a pre-existing firmware packaging issue in the LAVA test image, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only refactors device tree files and does not touch WiFi driver, PCIe, or firmware paths).
3. Possible fix: Add the linux-firmware-ath11k package (or equivalent vendor firmware package containing WCN6855/hw2.1/nfa765 variant) to the Yocto/buildroot image recipe used for monaco-evk LAVA testing. Specifically, ensure /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are present in the rootfs. Re-trigger the LAVA job after updating the image. If the firmware is proprietary and not yet available in the build, coordinate with the WiFi firmware team to stage the correct firmware version for QCS8300/monaco-evk.
4. Detail analysis attachment: failed_case_job208287_4_detailed.md

Case 5: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Revert the monaco-evk entry from ath11k_core_usecase_firmware_table in drivers/net/wireless/ath/ath11k/core.c to restore the default firmware path. In parallel, add the missing ath11k/WCN6855/hw2.1/nfa765/amss.bin firmware file to the Yocto/meta-qcom firmware package recipe, then re-apply the firmware table change in a subsequent PR once the firmware is confirmed present in the build image.
4. Detail analysis attachment: failed_case_job208287_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the test definition as failed because 5 individual test cases failed: (1) ath11k_pci WiFi driver probe timeout (error -110/ETIMEDOUT) causing WiFi_OnOff, WiFi_Firmware_Driver, and Probe_Failure_Check failures; (2) SMMU context fault (fsr=0x402, iova=0x40100000) and runtime PM usage count underflow in arm-smmu 15200000.iommu; (3) USBHost test failure due to no USB devices enumerated. The kernel booted successfully on monaco-evk, but PR changes to SMMU interconnect bandwidth management (arm-smmu.c) and ath11k firmware table reordering (core.c) likely introduced regressions.
3. Possible fix: Revert or fix the SMMU interconnect bandwidth changes in drivers/iommu/arm/arm-smmu/arm-smmu.c that introduced icc_enable/icc_disable calls - the runtime PM usage count underflow suggests improper power management sequencing. Investigate the ath11k_pci probe timeout on monaco-evk with the reordered firmware table - verify the nfa765 firmware path is correct and accessible, and check if the firmware table reordering changed the probe sequence timing. The USBHost failure may be a pre-existing board configuration issue (no USB device physically connected) rather than a PR-introduced regression.
4. Detail analysis attachment: failed_case_job208287_6_detailed.md

Job 208288 | SoC kaanapali-mtp

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

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

Case 1: PCIe Test Infrastructure Issue (Not a Kernel Regression)

1. Failed case: PCIe Test Infrastructure Issue (Not a Kernel Regression)
2. Root cause: The PCIe test script failed to detect the PCIe controller and endpoint device despite both being successfully initialized and operational in the kernel. The kernel log shows PCIe link is up (Gen.3 x2), root port enumerated (pci 0000:00:00.0), and endpoint device detected (pci 0000:01:00.0). The test script reports "DT node is not present", "Capabilities: is missing", and "Driver is not loaded", but these checks are incorrect or incompatible with the kaanapali-mtp (SM8750) platform's PCIe configuration.
3. Possible fix: Update the PCIe test script to correctly detect PCIe functionality on kaanapali-mtp platform. The test should check for enumerated PCI devices via lspci or /sys/bus/pci/devices/ rather than relying on platform-specific DT node paths or driver module names that may vary across SoCs. This is a test infrastructure issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
4. Detail analysis attachment: failed_case_job208288_1_detailed.md

Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB controller forced to gadget-only mode due to configuration mismatch detected by dwc3-qcom driver; device tree changes in PR removed explicit dr_mode = "peripheral" override but driver logic enforces gadget mode when detecting incompatible configuration, preventing USB host controller (xhci-hcd) from probing and enumerating USB devices on kaanapali-mtp.
3. Possible fix: Investigate why dwc3-qcom driver reports "Configuration mismatch. dr_mode forced to gadget" at probe time; verify device tree dr_mode property is correctly set to "host" or "otg" for kaanapali-mtp USB node at a600000.usb; if hardware supports host mode, ensure PHY configuration, Type-C connector role, and PMIC-glink configuration align with host/OTG operation; if this is a board-specific limitation (e.g., Type-C port wired for device-only), update test expectations to skip USBHost on kaanapali-mtp.
4. Detail analysis attachment: failed_case_job208288_2_detailed.md

Case 3: BT_FW_KMD_Service — Bluetooth Firmware Load Failure

1. Failed case: BT_FW_KMD_Service — Bluetooth Firmware Load Failure
2. Root cause: Bluetooth HCI command timeout (0xfc00) during firmware download to WCN7850 controller. The btqca driver repeatedly fails to send TLV segments to the Bluetooth controller with error -110 (ETIMEDOUT), preventing successful firmware load of qca/hmtbtfw20.tlv. This is a hardware communication timeout between the kernel driver and the Bluetooth controller over UART, not a missing firmware file issue.
3. Possible fix: This is a pre-existing hardware/firmware communication issue on kaanapali-mtp, not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR adds QCC2072 Bluetooth support and NVM calibration combining logic but does not modify WCN7850 firmware loading paths or timeout handling. Recommended actions: (1) Verify UART configuration and pinctrl settings for the Bluetooth UART interface in the kaanapali-mtp device tree; (2) Check if WCN7850 power sequencing (regulators, enable GPIOs) is correct and stable; (3) Increase HCI command timeout if the hardware requires longer response times; (4) Check for hardware-level signal integrity issues on the UART lines.
4. Detail analysis attachment: failed_case_job208288_3_detailed.md

Case 4: WiFi_Firmware_Driver — Missing ath12k PCI/AHB Driver Modules

1. Failed case: WiFi_Firmware_Driver — Missing ath12k PCI/AHB Driver Modules
2. Root cause: The ath12k_pci and ath12k_ahb kernel modules are not present in the kernel build for kaanapali-mtp (WCN7850 WiFi 7 platform). The test detects ath12k firmware files (/lib/firmware/ath12k/WCN7850/hw2.0/amss.bin) and successfully loads the ath12k_wifi7 and ath12k core modules, but the critical bus-specific driver modules (ath12k_pci for PCIe-attached WCN7850, ath12k_ahb for AHB-attached variants) are missing. Without these modules, the ath12k driver cannot bind to the PCI device (17cb:110e detected at 0000:01:00.0), firmware cannot be loaded, and no WiFi interface is created.
3. Possible fix: Enable CONFIG_ATH12K_PCI=m and CONFIG_ATH12K_AHB=m in the kernel configuration for kaanapali-mtp builds. Verify that drivers/net/wireless/ath/ath12k/pci.c and ahb.c are compiled as modules and included in the rootfs module directory. Rebuild the kernel image and rootfs, then re-run the LAVA job to confirm ath12k_pci probes the WCN7850 device and firmware loads successfully.
4. Detail analysis attachment: failed_case_job208288_4_detailed.md

Case 5: KVM Driver Initialization Failure — Platform Configuration Limitation

1. Failed case: KVM Driver Initialization Failure — Platform Configuration Limitation
2. Root cause: KVM driver initialization failed with "HYP mode not available" because the kaanapali-mtp platform is running with Gunyah hypervisor at EL2, preventing Linux kernel from accessing hypervisor mode required for KVM virtualization.
3. Possible fix: This is not a bug or regression. The test expectation is incorrect for this platform configuration. Either: (1) Skip KVM tests on platforms running under Gunyah hypervisor, or (2) Configure the platform to boot Linux at EL2 without Gunyah if KVM support is required.
4. Detail analysis attachment: failed_case_job208288_5_detailed.md

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

1. Failed case: KVM Driver Initialization Failure — HYP mode not available
2. Root cause: KVM driver cannot initialize because the Kaanapali MTP platform boots with a Gunyah hypervisor already running at EL2, preventing the Linux kernel from accessing EL2/HYP mode required for KVM operation. This is a platform configuration issue, not a kernel regression.
3. Possible fix: This is not a bug — it is expected behavior for Kaanapali MTP in its default Gunyah hypervisor configuration. KVM tests should be skipped on platforms that boot with a hypervisor at EL2. To enable KVM on this platform, reconfigure the boot flow to boot Linux directly at EL2 without the Gunyah hypervisor, or use a platform configuration that supports nested virtualization.
4. Detail analysis attachment: failed_case_job208288_6_detailed.md

Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM on this platform, boot without the Gunyah hypervisor by using a non-EL2 device tree blob (use kaanapali-mtp.dtb instead of kaanapali-mtp-el2.dtb). If both Gunyah virtualization and KVM are required, they cannot coexist on the same boot — choose one based on the use case (Gunyah for production VM workloads, KVM for development/testing).
4. Detail analysis attachment: failed_case_job208288_7_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM testing on Kaanapali MTP: (1) disable the Gunyah hypervisor in the firmware/bootloader configuration, OR (2) use a different test platform that boots Linux directly at EL2 without a hypervisor, OR (3) exclude KVM tests from the CI job definition for platforms running Gunyah. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job208288_8_detailed.md

Job 208289 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Verify the lemans (SA9075) device tree includes the required thermal zone provider nodes for PMIC temp-alarm devices. Check if qcom,spmi-temp-alarm driver dependencies (thermal framework, IPA thermal zones, or PMIC thermal bindings) are correctly defined in arch/arm64/boot/dts/qcom/sa9075*.dtsi. If the provider is present but failing to probe, enable CONFIG_THERMAL_DEBUGFS and check /sys/kernel/debug/thermal/ for thermal zone registration failures. For the firmware failures, suppress them in CI — they are known benign (WiFi/BT functional tests passed).
4. Detail analysis attachment: failed_case_job208289_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test expects a video codec device at address aa00000.video-codec to be attached to an IOMMU group, but this device is either not present in the device tree for lemans-evk, or the video codec driver (qcom-iris or venus) failed to probe, leaving the device unattached to any IOMMU group.
3. Possible fix: Verify whether the lemans-evk device tree includes a video codec node at address 0xaa00000; if absent, either add the DT node or update the SMMU test's critical-master list to exclude video codec for lemans-evk; if present, investigate why the video codec driver did not probe (check for missing clocks, regulators, firmware, or driver config).
4. Detail analysis attachment: failed_case_job208289_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the test suite as failed because the test runner exited without completing all expected tests; two individual tests failed: (1) smmu test detected video codec device (aa00000.video-codec) missing IOMMU group attachment, indicating the video codec driver did not properly attach to SMMU on lemans-evk; (2) Probe_Failure_Check detected multiple device probe failures including PMIC temp-alarm devices and firmware load failures.
3. Possible fix: For the video codec IOMMU issue: verify the video codec device tree node includes proper iommus property and that the Venus/video codec driver probe sequence correctly attaches to IOMMU on lemans-evk; check if PR changes to video codec bindings or driver affect IOMMU attachment. For probe failures: temp-alarm and firmware issues are likely pre-existing platform issues unrelated to this PR; verify by checking if these failures exist on baseline qcom-next without the PR.
4. Detail analysis attachment: failed_case_job208289_3_detailed.md

Job 208290 | SoC hamoa-evk

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

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

Case 1: ** Probe_Failure_Check — Deferred Probe Timeout Issue

1. Failed case: ** Probe_Failure_Check — Deferred Probe Timeout Issue
2. Root cause: ** PR introduces a hardcoded 15-second deferred probe timeout in drivers/base/dd.c (replacing CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT), which is insufficient for hamoa-evk platform where temp-alarm device dependencies (thermal/IIO/PMIC subsystems) require >15 seconds to initialize, leaving 8 temp-alarm devices permanently deferred.
3. Possible fix: Revert the hardcoded timeout change in drivers/base/dd.c and restore the original CONFIG_DRIVER_DEFERRED_PROBE_TIMEOUT behavior, or increase the hardcoded value to at least 30-60 seconds to accommodate slower platform initialization on Qualcomm SoCs with complex PMIC/thermal subsystems.
4. Detail analysis attachment: failed_case_job208290_1_detailed.md

Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on hamoa-evk is missing IOMMU group attachment, violating the platform security requirement that all critical DMA masters must be protected by SMMU.
3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/x7181.dtsi (or the appropriate hamoa DT include) to attach it to the SMMU, following the pattern used by other critical masters (UFS, GPU, USB) which all successfully show IOMMU group attachment.
4. Detail analysis attachment: failed_case_job208290_2_detailed.md

Case 3: ** KVM_Driver (Platform Capability Limitation)

1. Failed case: ** KVM_Driver (Platform Capability Limitation)
2. Root cause: ** The Hamoa (X7181) SoC does not support ARM EL2 (Hypervisor) mode, which is required for KVM virtualization. The kernel message "kvm [1]: HYP mode not available" at boot time indicates the CPU lacks virtualization extensions or EL2 is disabled at the firmware/bootloader level. CONFIG_KVM is enabled in the kernel configuration, but the hardware platform cannot provide the required EL2 execution mode, preventing /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR-introduced regression - it's a hardware platform limitation. The KVM_Driver test should be excluded from the test suite for Hamoa EVK boards, or the test should be updated to skip gracefully when HYP mode is unavailable. If KVM support is required for this platform, verify with Qualcomm whether: (1) the SoC supports EL2 but firmware/bootloader disables it (check ABL/UEFI settings), or (2) the SoC variant lacks virtualization extensions entirely. For CI purposes, add Hamoa EVK to the KVM test exclusion list.
4. Detail analysis attachment: failed_case_job208290_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization failed because the platform does not support EL2 hypervisor mode — kernel log shows kvm [1]: HYP mode not available at boot, preventing /dev/kvm device node creation; this is a pre-existing platform limitation on hamoa-iot-evk base DTB (non-EL2 configuration), not introduced by the PR.
3. Possible fix: This is not a regression — the test is expected to fail on hamoa-iot-evk base DTB because KVM requires EL2 hypervisor support which is only available when booting with the EL2-enabled DTB overlay (hamoa-iot-evk-el2.dtb). To enable KVM on hamoa, the LAVA job definition must be updated to use hamoa-iot-evk-el2.dtb (base DTB + x1-el2.dtbo overlay) instead of the base hamoa-iot-evk.dtb. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job208290_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: Exclude KVM tests from the hamoa-evk LAVA test suite, as this platform does not support virtualization. Update test runner to skip KVM tests gracefully when /dev/kvm is absent rather than failing. If KVM support is required, verify bootloader/firmware configuration enables EL2, or use a different platform with virtualization support (e.g., rb5, sm8450-hdk).
4. Detail analysis attachment: failed_case_job208290_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure marked the test definition as failed because some individual test cases within the suite failed (KVM_Driver, KVM_EL2_DTB, KVM_Infra failed due to missing /dev/kvm device node; Probe_Failure_Check and smmu also failed), triggering LAVA's "Marking unfinished test run as failed" behavior even though the test runner completed normally.
3. Possible fix: This is expected LAVA behavior when individual tests fail within a suite — the overall test definition inherits the failure status. The genuine failures to address are: (1) KVM tests failing because /dev/kvm is not present (CONFIG_KVM is enabled but the device node is not created — likely a KVM module loading or initialization issue on hamoa-evk), (2) Probe_Failure_Check and smmu test failures. Re-run the job after investigating why /dev/kvm is not being created despite CONFIG_KVM being enabled.
4. Detail analysis attachment: failed_case_job208290_6_detailed.md

Job 208291 | SoC qcs615-ride

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

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

Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** The wireless regulatory database firmware file (regulatory.db) is missing from the root filesystem at /lib/firmware/regulatory.db. The cfg80211 subsystem attempts to load this file during initialization and fails with -ENOENT (error -2, file not found). However, the kernel has compiled-in X.509 certificates as a fallback, and the wireless subsystem (ath11k QCA6698) continues to function correctly. This is a root filesystem packaging issue on qcs615-ride, not a kernel regression. The failure is not introduced by PR 978, which contains no changes to cfg80211, wireless regulatory code, or firmware loading infrastructure.
3. Possible fix: Add the wireless-regdb firmware file to the qcs615-ride root filesystem image. For Yocto/OE builds, include wireless-regdb in IMAGE_INSTALL. For Debian/Ubuntu images, install the wireless-regdb package. Alternatively, update the Probe_Failure_Check test to suppress this specific benign failure, as the kernel's built-in regulatory certificates provide a working fallback and wireless functionality is not impacted.
4. Detail analysis attachment: failed_case_job208291_1_detailed.md

Case 2: smmu — Video codec child device IOMMU attachment failure

1. Failed case: smmu — Video codec child device IOMMU attachment failure
2. Root cause: The video codec driver at aa00000.video-codec successfully probed and attached to IOMMU group 6, but its expected child devices (video-decoder and video-encoder) were not created or did not attach to IOMMU groups. The test expects these child devices to have independent IOMMU group attachments for memory isolation, but they are missing from /sys/kernel/iommu_groups enumeration.
3. Possible fix: Verify that the video codec driver (likely qcom-venus or iris driver) is correctly instantiating video-decoder and video-encoder child platform devices with proper IOMMU bindings in the device tree. Check if the PR introduced changes to the video-codec@aa00000 node in qcs615-ride.dts that removed or modified the video-decoder/video-encoder child node definitions or their iommus properties. If child nodes are present in DT, verify the driver's probe logic creates the child devices and that the IOMMU framework attaches them.
4. Detail analysis attachment: failed_case_job208291_2_detailed.md

Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Skip KVM tests on QCS615 targets in the CI test matrix by adding a platform check in the test runner: if grep -q "QCS615" /proc/device-tree/model; then echo "SKIP: KVM not supported on QCS615 (boots at EL1)"; exit 0; fi. This is not a kernel bug or PR-introduced regression - QCS615 does not support KVM in its current firmware configuration. Alternative long-term fix: Request Qualcomm firmware update to boot kernel at EL2 (may not be possible due to product segmentation).
4. Detail analysis attachment: failed_case_job208291_3_detailed.md

Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a PR-introduced regression. The PR adds EL2 DTB build targets and overlays but does not modify KVM driver code or boot flow. The LAVA job must be configured to flash and boot the EL2-enabled device tree (qcs615-ride-el2.dtb with talos-el2.dtbo overlay) instead of the standard qcs615-ride.dtb. Update the LAVA job definition to use the -el2 DTB variant for qcs615-ride when KVM tests are included in the test suite.
4. Detail analysis attachment: failed_case_job208291_4_detailed.md

Case 5: KVM_Infra (test infrastructure failure, not a kernel crash)

1. Failed case: KVM_Infra (test infrastructure failure, not a kernel crash)
2. Root cause: KVM cannot initialize on QCS615 because the Gunyah hypervisor is already running at EL2. ARM architecture allows only one hypervisor at EL2; KVM correctly detects "HYP mode not available" and exits cleanly without creating /dev/kvm.
3. Possible fix: This is expected behavior, not a bug. To enable KVM testing on QCS615: (1) disable Gunyah in the firmware/bootloader configuration, or (2) exclude KVM tests from the QCS615 test suite, or (3) use a different platform without Gunyah for KVM validation.
4. Detail analysis attachment: failed_case_job208291_5_detailed.md

Case 6: ** KVM_Infra

1. Failed case: ** KVM_Infra
2. Root cause: ** QCS615 SoC does not support ARM Virtualization Extensions (EL2/HYP mode). The kernel correctly detects this at boot time and logs kvm [1]: HYP mode not available, preventing /dev/kvm device creation. This is a hardware/firmware platform limitation, not a kernel regression.
3. Possible fix: This is expected behavior on QCS615. To resolve: (1) Skip KVM tests on platforms without virtualization support by adding a platform capability check in the LAVA job definition, or (2) Use a different SoC with ARM Virtualization Extensions support (e.g., SM8450, SM8550) for KVM testing. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job208291_6_detailed.md

[qcomlnxci]

Test jobs on e812d7f

• multimedia Job 212504 on glymur-crd
• multimedia Job 212500 on hamoa-iot-evk
• multimedia Job 212499 on kaanapali-mtp
• multimedia Job 212498 on lemans-evk
• multimedia Job 212497 on monaco-evk
• multimedia Job 212507 on purwa-iot-evk
• multimedia Job 212502 on qcs615-ride
• multimedia Job 212506 on qcs6490-rb3gen2
• multimedia Job 212505 on qcs8300-ride
• multimedia Job 212501 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212508 on shikra-iqs-evk
• multimedia Job 212503 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	⚠️ skip	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ 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	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ 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	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ 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	❌ Fail	◻️	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ 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	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️	⚠️ 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	◻️	◻️	✅ 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	❌ Fail	✅ Pass	❌ 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

[qcomlnxci]

Test jobs on e812d7f

• multimedia Job 212504 on glymur-crd
• multimedia Job 212500 on hamoa-iot-evk
• multimedia Job 212499 on kaanapali-mtp
• multimedia Job 212498 on lemans-evk
• multimedia Job 212497 on monaco-evk
• multimedia Job 212507 on purwa-iot-evk
• multimedia Job 212502 on qcs615-ride
• multimedia Job 212506 on qcs6490-rb3gen2
• multimedia Job 212505 on qcs8300-ride
• multimedia Job 213264 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212508 on shikra-iqs-evk
• multimedia Job 212503 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	⚠️ skip	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ 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	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ 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	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ 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	❌ Fail	◻️	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ 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	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️	⚠️ 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	◻️	◻️	✅ 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	❌ Fail	✅ Pass	❌ 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

[qcomlnxci]

Test jobs on e812d7f

• multimedia Job 212504 on glymur-crd
• multimedia Job 212500 on hamoa-iot-evk
• multimedia Job 212499 on kaanapali-mtp
• multimedia Job 212498 on lemans-evk
• multimedia Job 212497 on monaco-evk
• multimedia Job 212507 on purwa-iot-evk
• multimedia Job 212502 on qcs615-ride
• multimedia Job 212506 on qcs6490-rb3gen2
• multimedia Job 212505 on qcs8300-ride
• multimedia Job 213592 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212508 on shikra-iqs-evk
• multimedia Job 212503 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	⚠️ skip	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ 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	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ 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	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ 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	❌ Fail	◻️	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ 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	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️	⚠️ 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	◻️	◻️	✅ 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	❌ Fail	✅ Pass	❌ 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

[qcomlnxci]

Test jobs on e812d7f

• multimedia Job 212504 on glymur-crd
• multimedia Job 212500 on hamoa-iot-evk
• multimedia Job 212499 on kaanapali-mtp
• multimedia Job 212498 on lemans-evk
• multimedia Job 212497 on monaco-evk
• multimedia Job 212507 on purwa-iot-evk
• multimedia Job 212502 on qcs615-ride
• multimedia Job 212506 on qcs6490-rb3gen2
• multimedia Job 212505 on qcs8300-ride
• multimedia Job 214235 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212508 on shikra-iqs-evk
• multimedia Job 212503 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	⚠️ skip	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ 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	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ 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	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ 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	❌ Fail	◻️	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ 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	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️	⚠️ 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	◻️	◻️	✅ 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	❌ Fail	✅ Pass	❌ 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

[qcomlnxci]

Test jobs on e812d7f

• multimedia Job 214259 on glymur-crd
• multimedia Job 214264 on hamoa-iot-evk
• multimedia Job 214263 on kaanapali-mtp
• multimedia Job 214257 on lemans-evk
• multimedia Job 214254 on monaco-evk
• multimedia Job 214262 on purwa-iot-evk
• multimedia Job 214260 on qcs615-ride
• multimedia Job 214265 on qcs6490-rb3gen2
• multimedia Job 214261 on qcs8300-ride
• multimedia Job 214256 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 214258 on shikra-iqs-evk
• multimedia Job 214255 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	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ 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	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
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	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ 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	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ 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	✅ Pass	⚠️ skip	◻️
USBHost	❌ Fail	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	◻️
adsp_remoteproc	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️
cdsp_remoteproc	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ 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	✅ 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	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ 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	◻️

[qcomlnxci]

Test jobs on 415646a

• multimedia Job 214291 on glymur-crd
• multimedia Job 214293 on hamoa-iot-evk
• multimedia Job 214299 on kaanapali-mtp
• multimedia Job 214292 on lemans-evk
• multimedia Job 214300 on monaco-evk
• multimedia Job 214302 on purwa-iot-evk
• multimedia Job 214295 on qcs615-ride
• multimedia Job 214298 on qcs6490-rb3gen2
• multimedia Job 214294 on qcs8300-ride
• multimedia Job 214296 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 214301 on shikra-iqs-evk
• multimedia Job 214297 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	⚠️ skip	✅ Pass	◻️	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	⚠️ skip
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	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ 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	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	◻️	✅ 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	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ 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	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	⚠️ skip	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ 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
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	◻️	✅ 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	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass