[Salendarsingh Gaud (sgaud-quic)]

Name SHA Commits

tech/bsp/clk 443bd58 9
tech/bsp/devfreq 7acfd26 8
tech/bsp/ec c46f06d 2
tech/bsp/interconnect 81fc6e2 1
tech/bsp/sched 40b3c1f 2
tech/security/firmware-smc 503110b 11
tech/bsp/soc-infra 76d8086 33
tech/bus/pci/all 29bb333 38
tech/bus/usb/all dd0f225 51
tech/debug/hwtracing f7bba91 20
tech/pmic/all d517c3e 23
tech/mem/all 5d786d3 8
tech/mm/audio/all f084244 41
tech/mm/camss b64ca4b 33
tech/mm/drm 5681492 91
tech/mm/fastrpc e808ccd 9
tech/mm/video 1e05914 45
tech/net/ath 76d931c 9
tech/net/eth 4d55657 18
tech/net/bluetooth 1ec6c24 11
tech/pm/power 29c839e 13
tech/pm/thermal 000ea55 4
tech/security/crypto 973a381 27
tech/security/optee-next 6c04332 2
tech/storage/all 5929ee0 7
tech/all/dt/qcs6490 04fd975 20
tech/all/dt/qcs9100 d0291c6 20
tech/all/dt/qcs8300 b132d5e 26
tech/all/dt/qcs615 dbe132c 16
tech/all/dt/eliza 8b9d593 9
tech/all/dt/hamoa 41f3035 29
tech/all/dt/glymur dbd0f70 31
tech/all/dt/kaanapali 328e630 19
tech/all/dt/pakala b19aeb8 10
tech/all/hawi f7bc734 16
tech/all/maili a636cc5 17
tech/all/shikra 60c8bf4 71
tech/all/config 5d707d0 91
tech/overlay/dt 7f71952 102
tech/all/workaround 8d89b91 7
tech/noup/debug/all 42fa88a 38
tech/hwe/unoq 9b67cf2 3
early/hwe/nord fcf1215 89

[qlijarvis]

🔨 Build Failure Analysis — PR #1414

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

#	Error	File:Line	PR-introduced?	Root Cause
1	'struct eusb2_repeater' has no member named 'base'	drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c:231	Yes	PR adds code accessing rptr->base field that doesn't exist in struct eusb2_repeater. The same error appears in 12 commits within the PR.

Verdict

1 unique compilation error introduced by this PR. The error occurs in both standard and RT kernel builds, blocking all compilation.

📎 Detailed analysis: Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #1414

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

#	Error	File:Line	PR-introduced?	Root Cause
1	'struct eusb2_repeater' has no member named 'base'	drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c:231	Yes	PR adds code accessing rptr->base but struct eusb2_repeater does not have a base member

Verdict

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

📎 Detailed analysis: Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #1414

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

#	Error	File:Line	PR-introduced?	Root Cause
1	incompatible pointer type for .set_fmt	drivers/media/platform/qcom/camss/ope/core.c:2940	Yes	Function ope_proc_set_fmt missing required const struct v4l2_subdev_client_info * parameter
2	incompatible pointer type for .get_selection	drivers/media/platform/qcom/camss/ope/core.c:2942	Yes	Function ope_proc_get_selection missing required const struct v4l2_subdev_client_info * parameter
3	incompatible pointer type for .set_selection	drivers/media/platform/qcom/camss/ope/core.c:2943	Yes	Function ope_proc_set_selection missing required const struct v4l2_subdev_client_info * parameter
4	incompatible pointer type for .set_fmt	drivers/media/platform/qcom/camss/ope/core.c:3012	Yes	Function ope_disp_set_fmt missing required const struct v4l2_subdev_client_info * parameter

Verdict

All 4 errors are introduced by this PR. The new file drivers/media/platform/qcom/camss/ope/core.c uses an outdated V4L2 subdev API signature that is incompatible with the current kernel.

📎 Detailed analysis: Full report

[qlijarvis]

🔨 Build Failure Analysis — PR #1414

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

#	Error	File:Line	PR-introduced?	Root Cause
1	Incompatible function pointer type for .set_fmt	drivers/media/platform/qcom/camss/ope/core.c:2940	Yes	Function ope_proc_set_fmt missing required const struct v4l2_subdev_client_info * parameter
2	Incompatible function pointer type for .get_selection	drivers/media/platform/qcom/camss/ope/core.c:2942	Yes	Function ope_proc_get_selection missing required const struct v4l2_subdev_client_info * parameter
3	Incompatible function pointer type for .set_selection	drivers/media/platform/qcom/camss/ope/core.c:2943	Yes	Function ope_proc_set_selection missing required const struct v4l2_subdev_client_info * parameter
4	Incompatible function pointer type for .set_fmt	drivers/media/platform/qcom/camss/ope/core.c:3012	Yes	Function ope_disp_set_fmt missing required const struct v4l2_subdev_client_info * parameter

Verdict

All 4 compilation errors are introduced by this PR. The new OPE driver uses an outdated v4l2_subdev API signature.

📎 Detailed analysis: Full report

[qcomlnxci]

Test Matrix

Test Case	kbdev-glymur-crd-multimedia	kbdev-hamoa-iot-evk-multimedia	kbdev-kaanapali-mtp-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia	kbdev-sm8750-mtp-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ 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	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	◻️	❌ 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	✅ 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	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail
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 d7a1466

• multimedia Job 268534 on glymur-crd
• multimedia Job 268541 on hamoa-iot-evk
• multimedia Job 268539 on kaanapali-mtp
• multimedia Job 268531 on lemans-evk
• multimedia Job 268538 on monaco-evk
• multimedia Job 268533 on purwa-iot-evk
• multimedia Job 268537 on qcs615-ride
• multimedia Job 268529 on qcs6490-rb3gen2
• multimedia Job 268540 on qcs8300-ride
• multimedia Job 268532 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 268535 on shikra-iqs-evk
• multimedia Job 268530 on sm8750-mtp

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1414

Job 268529 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Missing Firmware Files

1. Failed case: Probe_Failure_Check — Missing Firmware Files
2. Root cause: Two firmware files are missing from the rootfs: regulatory.db (for cfg80211 wireless regulatory database) and renesas_usb_fw.mem (for Renesas xHCI PCIe USB controller). Both drivers fail probe with -ENOENT (-2), but these are non-critical optional peripherals that do not affect core platform functionality on qcs6490-rb3gen2.
3. Possible fix: Add the missing firmware files to the rootfs image: install wireless-regdb package (provides /lib/firmware/regulatory.db) and linux-firmware package (provides /lib/firmware/renesas_usb_fw.mem). Alternatively, if these peripherals are not used on this board, suppress these specific probe failures in the Probe_Failure_Check test filter list.
4. Detail analysis attachment: failed_case_job268529_1_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA infrastructure marked the test run as "unfinished" despite successful completion of all test cases; the test runner exited normally with <LAVA_TEST_RUNNER EXIT> but LAVA's test-shell action did not recognize the completion signal correctly, triggering a false failure.
3. Possible fix: Re-trigger the CI job; this is a known LAVA test harness synchronization issue where the test-shell action times out or misses the completion signal even though all tests ran to completion — the underlying kernel and tests are healthy.
4. Detail analysis attachment: failed_case_job268529_2_detailed.md

Job 268530 | SoC sm8750-mtp

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

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

  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: Disable one of the two mutually exclusive drivers in the kernel configuration. For sm8750-mtp, either set CONFIG_QCOM_QSEECOM_UEFISECAPP=n (to use the new TEE-based driver) or set CONFIG_QCOM_TEE_UEFISECAPP=n (to keep the existing QSEECOM driver). The choice depends on which secure world interface (QSEECOM vs TEE/QTEE) is supported by the platform firmware.
4. Detail analysis attachment: failed_case_job268530_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The PR introduces a new video-codec device node (iris: video-codec@aa00000) in the sm8750 (eliza) device tree with iommus = <&apps_smmu 0x1940 0x0> property, but the device is not being attached to an IOMMU group at runtime. The smmu test explicitly checks that critical master devices (GPU, USB, Display, Video) are protected by IOMMU groups, and fails when it detects aa00000.video-codec is missing IOMMU group attachment despite having an iommus property in the device tree.
3. Possible fix: Add the missing IOMMU group attachment for the video-codec device by ensuring the SMMU driver properly processes the iommus property during device probe. Verify that CONFIG_ARM_SMMU and CONFIG_IOMMU_API are enabled (they are), and check whether the video-codec driver probe sequence is completing before the SMMU attachment occurs. If the video-codec driver is not yet merged or is failing to probe, the IOMMU attachment will not occur. Alternatively, if this is expected behavior for this PR stage (video-codec DT node added before driver), update the smmu test to exclude aa00000.video-codec from the critical master check until the driver is merged.
4. Detail analysis attachment: failed_case_job268530_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe endpoint device 0000:01:00.0 (Qualcomm WCN7850 WLAN, VID:DID=0x17cb:0x110e) is enumerated on the PCIe bus with link up (Gen 3 x2) but no kernel driver is bound to it. The test expects all PCIe devices to have drivers bound. This is a pre-existing platform configuration issue where either the device ID is not in the ath12k_pci driver's supported device table, or the driver probe is failing silently. The PR modifies ath12k ASPM handling and QRTR node filtering but does not introduce this binding failure.
3. Possible fix: This is not a PR-introduced regression. The failure is due to missing driver support or configuration for device 0x17cb:0x110e on sm8750-mtp. To resolve: (1) Verify the ath12k_pci driver includes PCI_DEVICE(0x17cb, 0x110e) in its pci_device_id table; (2) Check kernel logs for ath12k probe errors using dmesg | grep -i "ath12k.*probe\|ath12k.*error"; (3) If the device ID is missing, add it to drivers/net/wireless/ath/ath12k/pci.c; (4) If probe is failing, investigate QRTR node ID filtering changes in this PR's qmi.c modifications. The test can be re-run after verifying ath12k driver configuration for sm8750 platform.
4. Detail analysis attachment: failed_case_job268530_3_detailed.md

  Case 4: ** BT_FW_KMD_Service

1. Failed case: ** BT_FW_KMD_Service
2. Root cause: ** Bluetooth firmware download failure on SM8750-MTP WCN7850 controller — repeated UART frame reassembly errors (-EILSEQ) followed by command timeout (-ETIMEDOUT) during TLV segment transmission. PR 1414 modifies btqca.c firmware loading logic (adds qca_combine_nvm_calib function), likely introducing a timing or data corruption issue that breaks UART communication with the WCN7850 hardware during firmware download.
3. Possible fix: Revert or debug the qca_combine_nvm_calib changes in PR 1414's btqca.c modifications. Verify that the new calibration data combining logic does not corrupt firmware payloads or introduce timing violations on UART-based Qualcomm Bluetooth controllers (WCN7850). Test with and without the PR on SM8750-MTP to confirm regression.
4. Detail analysis attachment: failed_case_job268530_4_detailed.md

  Case 5: BT_ON_OFF

1. Failed case: BT_ON_OFF
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a known intermittent hardware/firmware communication issue on sm8750-mtp WCN7850. Recommended actions: (1) Re-trigger the CI job to verify if the failure is transient; (2) If persistent, verify firmware file qca/hmtbtfw20.tlv integrity and version compatibility with WCN7850 controller version 0x02000200; (3) Check UART14 signal integrity, baud rate configuration (currently 3.2Mbps), and power supply stability for WCN7850 regulators during firmware download; (4) If issue persists across multiple runs, escalate to Qualcomm Bluetooth firmware team with full kernel log and controller version details for firmware/hardware investigation.
4. Detail analysis attachment: failed_case_job268530_5_detailed.md

  Case 6: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth firmware download failure on sm8750-mtp WCN7850 — repeated HCI frame reassembly errors (EILSEQ -84) during firmware TLV segment transfer, followed by command timeout (ETIMEDOUT -110), preventing hci0 from obtaining a valid BD address and becoming operational.
3. Possible fix: Investigate PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 Bluetooth driver changes in drivers/bluetooth/btqca.c, drivers/bluetooth/hci_qca.c, and drivers/bluetooth/hci_serdev.c — the PR modifies QCA firmware loading logic (new qca_combine_nvm_calib function) which may introduce frame assembly or timing issues during TLV download on WCN7850 hardware; verify firmware file integrity and UART flow control settings; if PR changes are root cause, revert or fix the firmware download sequence to handle WCN7850 frame timing correctly.
4. Detail analysis attachment: failed_case_job268530_6_detailed.md

  Case 7: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the SM8750-MTP platform — kernel message at boot: kvm [1]: HYP mode not available.
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.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. The SM8750-MTP board is not configured to boot Linux at EL1 with EL2 available for KVM. To enable KVM: (1) verify the bootloader (ABL/XBL) is configured to leave EL2 accessible to Linux, (2) confirm the device tree does not disable virtualization, and (3) if the platform uses a hypervisor (e.g., Gunyah), ensure it exposes nested virtualization support. If KVM is not a requirement for SM8750-MTP CI validation, mark this test as expected-fail or skip for this platform.
4. Detail analysis attachment: failed_case_job268530_7_detailed.md

  Case 8: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed because the sm8750-mtp platform is running under the Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is already occupied by Gunyah.
3. Possible fix: This is expected behavior on sm8750-mtp with Gunyah hypervisor enabled. The test should be skipped on platforms where a Type-1 hypervisor (Gunyah) is present. Add platform detection logic to skip KVM tests when "Hypervisor cold boot, version: gunyah-mobile" is detected in boot logs, or disable Gunyah in the firmware/bootloader configuration if KVM functionality is required for testing.
4. Detail analysis attachment: failed_case_job268530_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP mode (EL2) is not available on SM8750 MTP — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation; CONFIG_KVM is enabled but the platform does not support virtualization extensions or EL2 is disabled by firmware/bootloader.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. Verify that SM8750 MTP firmware supports EL2/virtualization extensions; if not, mark KVM tests as expected-fail for this platform. If EL2 should be available, check bootloader configuration (ABL/XBL) to ensure it does not disable HYP mode before handing control to the kernel.
4. Detail analysis attachment: failed_case_job268530_9_detailed.md

  Case 10: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the SM8750-MTP platform. The kernel detected at boot time (2.673603s) that EL2 is not accessible, preventing KVM from creating /dev/kvm. This is a platform firmware/bootloader configuration issue where EL2 is not enabled before Linux boots.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. Short-term: Skip KVM tests on SM8750-MTP in the LAVA test suite by adding a platform-specific test filter. Long-term: Configure the SM8750-MTP bootloader/firmware to enable EL2 mode before booting Linux, or verify if the platform hardware supports virtualization extensions and update the firmware accordingly.
4. Detail analysis attachment: failed_case_job268530_10_detailed.md

Job 268531 | SoC lemans-evk

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

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

  Case 1: login-action

1. Failed case: login-action
2. Root cause: Userspace boot hang after systemd-udevd initialization on lemans-evk; kernel booted successfully (Linux 7.4.0-rc1-01177-gd7a1466f8c32) but system stopped producing console output at ~4.4 seconds after PCIe driver probe messages, preventing login prompt from appearing.
3. Possible fix: This is likely a pre-existing platform/infra issue unrelated to the PR changes (which are primarily DT additions for RAS error nodes, IPCC mailboxes, ICE OPP table, and SDHC register updates). Re-trigger the CI job to confirm reproducibility; if persistent, investigate lemans-evk board serial console connectivity, systemd-udevd configuration, or PCIe initialization hang on this specific hardware.
4. Detail analysis attachment: failed_case_job268531_1_detailed.md

  Case 2: auto-login-action

1. Failed case: auto-login-action
2. Root cause: Userspace initialization hang on lemans-evk after kernel successfully booted to init/systemd; system stops responding after systemd-udevd starts (timestamp 3.569s) and during PCIe device probing (timestamp 4.425s), never reaching login prompt despite 3 retry attempts over ~10 minutes with no console output.
3. Possible fix: This is a userspace/init hang, not a kernel crash or PR-introduced regression. The PR contains only documentation and device tree binding changes with no driver code modifications. Recommended actions: (1) Re-trigger the LAVA job to rule out transient infrastructure issue; (2) If reproducible, investigate lemans-evk-specific userspace init scripts, udev rules, or PCIe device initialization that may be blocking boot-to-login; (3) Check if the rootfs image for lemans-evk has init system misconfigurations or missing dependencies; (4) Enable systemd debug logging (systemd.log_level=debug on kernel cmdline) to identify which service/unit is blocking.
4. Detail analysis attachment: failed_case_job268531_2_detailed.md

  Case 3: minimal-boot — Boot Hang (userspace initialization stall)

1. Failed case: minimal-boot — Boot Hang (userspace initialization stall)
2. Root cause: System hung during early userspace initialization after PCIe driver probe at ~4.4 seconds into boot; no further kernel messages or userspace progress for >10 minutes until LAVA login-action timeout. Last kernel activity: qcom-pcie driver probing 1c00000.pcie and 1c10000.pcie with dummy regulator warnings. System never reached login prompt despite kernel successfully starting /init and systemd-udevd.
3. Possible fix: This is a userspace boot hang, not a kernel crash. Investigate: (1) Check if PCIe device enumeration is blocking boot — add pci=nomsi or pcie_aspm=off to kernel cmdline to rule out PCIe link training hang; (2) Enable systemd debug (systemd.log_level=debug systemd.log_target=console) to identify which systemd unit is stalling; (3) Check if rootfs mount or device probing is stuck — verify UFS storage is accessible and rootfs integrity; (4) If lemans-evk-specific, compare DTB PCIe node configuration with known-good baseline to identify any PR-introduced DT changes affecting PCIe or boot-critical devices.
4. Detail analysis attachment: failed_case_job268531_3_detailed.md

  Case 4: System Hang — Login Timeout (Userspace Initialization Hang)

1. Failed case: System Hang — Login Timeout (Userspace Initialization Hang)
2. Root cause: System hung during userspace initialization after kernel boot completed successfully at ~4.4s; no kernel output for ~97 seconds until LAVA login timeout; last kernel message shows PCIe driver probing, then complete silence indicating userspace init process (systemd-udevd) stalled or hung without producing any console output or reaching login prompt.
3. Possible fix: This is a LAVA infrastructure/timeout issue, not a kernel regression. The kernel booted successfully but userspace failed to initialize within the LAVA timeout window. Re-trigger the LAVA job with increased login timeout (from 200s to 600s) in the job definition. If the issue persists, investigate the rootfs image for init system issues (systemd-udevd hang, missing dependencies, or slow device probing). The PR changes (ARM RAS debugfs, STP policy, and documentation) do not affect boot or init paths and are not the root cause.
4. Detail analysis attachment: failed_case_job268531_4_detailed.md

Job 268532 | SoC qcs9100-ride

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

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

  Case 1: Driver Probe Failures — Pre-existing Platform Issues

1. Failed case: Driver Probe Failures — Pre-existing Platform Issues
2. Root cause: The Probe_Failure_Check test detected four pre-existing probe failures on qcs9100-ride that are unrelated to PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414: (1) nvmem-reboot-mode deferred probe due to missing nvmem cell "reboot-mode" in device tree, (2) qcom-tee-uefisecapp probe failure with -EBUSY (-16) indicating TEE service unavailable or already claimed, (3) regulatory.db firmware missing (-ENOENT/-2) which is a known benign WiFi regulatory database issue, and (4) Aquantia AQR115C Ethernet PHY probe failure with -EINVAL (-22) due to missing or malformed "firmware-name" property in device tree. All four failures appear in the kernel boot log (lines 3658, 3759, 3828-3829) before any test execution, confirming they are boot-time issues present in the baseline kernel, not regressions introduced by this PR.
3. Possible fix: These are pre-existing platform configuration issues, not PR-introduced regressions. No action required for PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. For platform maintainers: (1) add the missing nvmem cell "reboot-mode" to the qcs9100-ride device tree to resolve the deferred probe, (2) verify TEE firmware and service availability for qcom-tee-uefisecapp, (3) optionally add regulatory.db to the firmware image (benign if absent), and (4) add or correct the "firmware-name" property for the Aquantia PHY node in the device tree. Re-run the Probe_Failure_Check test after applying these DT/firmware fixes to confirm resolution.
4. Detail analysis attachment: failed_case_job268532_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device at aa00000.video-codec exists in the device tree but is missing the iommus property, causing it to fail IOMMU group attachment validation during the SMMU test on qcs9100-ride (sa8775p-based) platform.
3. Possible fix: Add the iommus property to the video-codec@aa00000 node in the sa8775p.dtsi device tree file to attach the video codec to an IOMMU group, following the pattern used for other critical masters (UFS, Display, GPU, USB, Ethernet) that all have iommus properties and pass the test.
4. Detail analysis attachment: failed_case_job268532_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Revert or fix the dwmac-qcom-ethqos.c changes in PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 to restore compatibility with qcs9100-ride Ethernet hardware; specifically review new register definitions (RGMII_IO_MACRO_BYPASS, EMAC_WRAPPER_SGMII_PHY_CNTRL0/1_V4, EMAC_WRAPPER_USXGMII_MUX_SEL) and clock configuration changes for qcs9100 platform compatibility.
4. Detail analysis attachment: failed_case_job268532_3_detailed.md

  Case 4: KVM Driver Initialization Failure

1. Failed case: KVM Driver Initialization Failure
2. Root cause: qcs9100-ride (LeMans) platform does not support ARM EL2 (Hypervisor Exception Level), which is a mandatory hardware requirement for KVM on ARM64. KVM driver probe fails at boot with "HYP mode not available", preventing /dev/kvm device creation.
3. Possible fix: Mark KVM tests as "not applicable" or "skip" for qcs9100-ride platform in the LAVA test suite configuration. KVM cannot be enabled on this SoC due to hardware limitations - no software fix is possible.
4. Detail analysis attachment: failed_case_job268532_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM device node unavailable (platform boot mode issue)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (platform boot mode issue)
2. Root cause: The qcs9100-ride board booted at EL1 (non-hypervisor mode) instead of EL2 (hypervisor mode), causing KVM initialization to fail with "HYP mode not available" at boot time (timestamp 2.283545s), preventing /dev/kvm device node creation; this is a platform/firmware/bootloader configuration issue, not a kernel regression.
3. Possible fix: Configure the qcs9100-ride board's bootloader/firmware to boot the kernel at EL2 (hypervisor exception level) instead of EL1; verify the EFI boot entry selection mechanism is correctly switching to the el2kvm boot path, or manually select the EL2 boot option in the bootloader menu before running KVM tests.
4. Detail analysis attachment: failed_case_job268532_5_detailed.md

  Case 6: KVM Infrastructure Test Failure — /dev/kvm unavailable (HYP mode not available)

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm unavailable (HYP mode not available)
2. Root cause: The qcs9100-ride (LeMans Ride Rev3) platform booted without EL2 (hypervisor) mode available, causing KVM driver initialization to fail with "HYP mode not available" at kernel boot time (line 2.283545). CONFIG_KVM is enabled in the kernel configuration, but the ARM CPU is not running in or does not have access to EL2, preventing /dev/kvm device creation. This is a platform/firmware/bootloader configuration issue, not a kernel driver bug.
3. Possible fix: This is a pre-existing platform configuration issue, not introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 (which contains no KVM-related changes). To enable KVM on qcs9100-ride: (1) Verify the bootloader (ABL/XBL) is configured to boot Linux in EL2 or with VHE (Virtualization Host Extensions) enabled; (2) Check if the platform requires the lemans-el2.dtbo overlay to enable EL2 mode — the test used the base qcs9100-ride-r3.dtb without the -el2 variant; (3) If EL2 support is available, flash the qcs9100-ride-r3-el2.dtb (which applies lemans-el2.dtbo overlay) instead of the base DTB; (4) If the platform hardware does not support EL2/virtualization, mark KVM tests as "not applicable" for this board in the CI test matrix.
4. Detail analysis attachment: failed_case_job268532_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (EL2) mode is not available on the qcs9100-ride platform. The kernel message kvm [1]: HYP mode not available at boot time (2.28s) indicates the platform is not booting with EL2 enabled, preventing KVM infrastructure from initializing and creating /dev/kvm.
3. Possible fix: This is a platform/firmware/boot configuration issue, not a kernel regression. Verify the qcs9100-ride board's bootloader/firmware configuration to ensure EL2 mode is enabled. Check if the board is using the correct device tree blob (e.g., lemans-ride-el2.dtb if an EL2 variant exists). If the platform does not support EL2 or is intentionally booting in EL1-only mode, mark the KVM_Infra test as "not applicable" for this board in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job268532_7_detailed.md

Job 268533 | SoC purwa-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Test detects expected platform-specific probe failures on purwa-evk where certain hardware (PCIe controllers at 1bd0000/1bf8000, secure world UEFI services) is not populated or not configured, and regulatory.db firmware is intentionally absent. These are benign failures — the PCIe functional test passed, confirming no regression.
3. Possible fix: Update the Probe_Failure_Check test to include platform-specific suppression rules for purwa-evk: suppress -EBUSY from qcom_qseecom_uefisecapp/qcom-tee-uefisecapp, -ENODATA from qcom-pcie 1bd0000/1bf8000, and -ENOENT from regulatory.db firmware load. Alternatively, add a platform-specific allowlist to the test harness.
4. Detail analysis attachment: failed_case_job268533_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test expects the video-codec device (aa00000.video-codec) to be directly attached to an IOMMU group, but the new Iris video codec driver architecture (introduced in this PR) uses child devices (non-pixel and pixel) for IOMMU attachment instead of attaching the parent device directly.
3. Possible fix: Update the SMMU test to recognize the Iris video codec's child-device IOMMU attachment pattern — check for IOMMU groups on aa00000.video-codec/non-pixel and aa00000.video-codec/pixel child devices rather than requiring direct parent-device attachment.
4. Detail analysis attachment: failed_case_job268533_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on purwa-evk because the platform boots under the Gunyah hypervisor at EL2, preventing the kernel from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is already occupied by the hypervisor. This is a platform architecture limitation, not a kernel regression.
3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as expected-to-skip for purwa-evk in the LAVA test definition, or add a platform capability check that skips KVM tests when a hypervisor is detected at boot. The PR (camera/DT changes) did not introduce this issue.
4. Detail analysis attachment: failed_case_job268533_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform Architectural Limitation (EL2/HYP Mode Not Available)

1. Failed case: KVM_EL2_DTB — Platform Architectural Limitation (EL2/HYP Mode Not Available)
2. Root cause: KVM initialization failed because the Purwa IoT EVK platform is not running with EL2 (hypervisor mode) available. The kernel message kvm [1]: HYP mode not available at boot time (3.186763s) indicates the platform does not support or is not configured to expose EL2 to Linux, which is a mandatory requirement for KVM functionality.
3. Possible fix: Mark KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) as "Not Applicable" for the Purwa IoT EVK platform in the LAVA test suite configuration. Add a platform capability check to skip KVM tests on platforms without EL2 support. If EL2 support is expected on this platform, verify the bootloader/firmware configuration to ensure Linux boots at EL2 or under a hypervisor that exposes nested virtualization support.
4. Detail analysis attachment: failed_case_job268533_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP mode (EL2) is not available on Purwa IoT EVK — kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation; CONFIG_KVM is enabled but the platform does not support virtualization extensions or EL2 is disabled by firmware/bootloader.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. Verify that Purwa IoT EVK firmware supports EL2/virtualization extensions; if not, mark KVM tests as expected-fail for this platform. If EL2 should be available, check bootloader configuration (ABL/XBL/UEFI) to ensure it does not disable HYP mode before handing control to the kernel.
4. Detail analysis attachment: failed_case_job268533_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM/virtualization not available on Purwa IoT EVK platform — kernel reports "HYP mode not available" during boot, indicating the platform does not support EL2 hypervisor mode (hardware/firmware/bootloader limitation).
3. Possible fix: This is not a PR-introduced regression. The PR contains device tree and driver updates unrelated to KVM/virtualization support. The test failure is expected on platforms without EL2 support. Recommended action: Update the LAVA test job definition to skip KVM tests on purwa-iot-evk (non-EL2 variant), or use the purwa-iot-evk-el2.dtb variant if EL2 testing is required and the platform/firmware supports it.
4. Detail analysis attachment: failed_case_job268533_6_detailed.md

Job 268534 | SoC glymur-qli-crd

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Sound card driver (snd-x1e80100) has unresolved deferred probe due to missing WCD codec DAI dependency on glymur-crd platform; additionally, regulatory.db firmware file is missing (benign for non-WiFi testing). The audio probe failure may be related to PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414's LPASS audio clock controller changes for Glymur.
3. Possible fix: For the sound card issue: verify WCD codec driver is enabled in kernel config, confirm codec device tree node is present and correctly wired to the sound card node, and validate that LPASS audio clock controller changes in this PR do not break codec probe dependencies. For regulatory.db: add the file to the test rootfs or suppress this specific firmware load failure in the test framework as it does not affect core functionality.
4. Detail analysis attachment: failed_case_job268534_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: PR introduces new video-codec device tree nodes (iris: video-codec@aa00000 with compatible qcom,glymur-iris) across multiple glymur DTS files but omits the mandatory iommus property, causing the video codec device to lack IOMMU group attachment; the smmu test explicitly validates that critical masters (GPU, USB, Camera, Display, Video) are IOMMU-protected and fails when it detects aa00000.video-codec has no iommu_group.
3. Possible fix: Add the missing iommus property to all iris: video-codec@aa00000 device tree nodes in the PR; reference the appropriate SMMU phandle and stream ID for the video codec subsystem on glymur (e.g., iommus = <&apps_smmu 0x2180 0x0400>; — verify the correct stream ID from the glymur hardware specification or existing reference device trees for similar Qualcomm SoCs).
4. Detail analysis attachment: failed_case_job268534_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: it detected that the video codec device at address aa00000 is not attached to any IOMMU group, which is a hard requirement for DMA-capable devices on ARM platforms with SMMU enabled. This PR modifies glymur video codec bindings, clock configurations, and device tree nodes, and the failure indicates the video codec device is not properly integrated with the IOMMU subsystem after these changes.
3. Possible fix: Verify that the video codec device node in arch/arm64/boot/dts/qcom/glymur.dtsi includes a valid iommus property referencing the apps_smmu with correct stream IDs, and ensure the iris video driver probe sequence properly attaches to the IOMMU domain during initialization.
4. Detail analysis attachment: failed_case_job268534_3_detailed.md

Job 268535 | SoC shikra-iqs-evk

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

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

  Case 1: GIC (Test Infrastructure Bug)

1. Failed case: GIC (Test Infrastructure Bug)
2. Root cause: The GIC test script has a bash parsing error at line 75 and incorrectly assumes 8 CPUs exist on the shikra-iqs-evk platform, which only has 4 CPUs (0-3). The script attempts to parse /proc/interrupts fields (GICv3, Level, arch_timer) as integers in a bash comparison, causing "integer expected" errors for CPUs 4-7 that don't exist.
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, and fix the bash parsing logic at line 75 to correctly extract only numeric interrupt count fields from /proc/interrupts.
4. Detail analysis attachment: failed_case_job268535_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing shikra-iqs-evk platform hardware/firmware limitations — PCIe endpoint not responding (timeout -110), missing regulatory.db firmware file, TEE UEFI secure app unavailable (-EBUSY), TPM SPI device timeout, and audio subsystem deferred probe due to missing clock/DAI dependencies. None of these failures are introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 (documentation and DT binding changes only).
3. Possible fix: Mark as known platform limitation — these probe failures are expected on shikra-iqs-evk hardware configuration and do not indicate a kernel regression. Update CI test expectations to suppress these known benign failures for shikra-iqs-evk, or add hardware/firmware support for PCIe endpoint, regulatory database, TEE UEFI app, TPM device, and audio clock providers.
4. Detail analysis attachment: failed_case_job268535_2_detailed.md

  Case 3: PCIe — Driver Probe Failure (PHY initialization timeout)

1. Failed case: PCIe — Driver Probe Failure (PHY initialization timeout)
2. Root cause: PCIe PHY driver probe failed with -ETIMEDOUT during initialization on shikra-iqs-evk (QCS8300); PR#1414 adds new voltage regulators ("vdda-refgen", "refgen") to qcs8300_qmp_gen4x2_pciephy_cfg but the device tree for shikra does not provide these regulators, causing the PHY driver to fail with "supply vdda not found, using dummy regulator" warnings and ultimately timing out during PHY initialization.
3. Possible fix: Add the missing voltage regulator supplies ("vdda-refgen" and "refgen") to the PCIe PHY device tree node for shikra-iqs-evk, or revert the vreg_list change for qcs8300_qmp_gen4x2_pciephy_cfg in drivers/phy/qualcomm/phy-qcom-qmp-pcie.c if these regulators are not actually required for QCS8300 hardware.
4. Detail analysis attachment: failed_case_job268535_3_detailed.md

  Case 4: ** BT_SCAN (Test Infrastructure Failure — No Discoverable Devices)

1. Failed case: ** BT_SCAN (Test Infrastructure Failure — No Discoverable Devices)
2. Root cause: ** Bluetooth scan test failed because the LAVA lab environment has zero discoverable Bluetooth devices within RF range of the shikra-iqs-evk board. The Bluetooth stack is fully functional (BT_FW_KMD_Service and BT_ON_OFF both passed; hci0 adapter operational; scan commands execute successfully), but the test expects at least one device to be discovered and fails when the environment is device-free.
3. Possible fix: Deploy a dedicated Bluetooth LE beacon or always-on discoverable device in the LAVA lab near the shikra-iqs-evk test rack, or update the BT_SCAN test to skip gracefully (not fail) when no devices are in range by adding an environment-aware flag (e.g., BT_SCAN_REQUIRED=0 for isolated labs).
4. Detail analysis attachment: failed_case_job268535_4_detailed.md

  Case 5: ** KVM_Driver (also KVM_EL2_DTB, KVM_Infra)

1. Failed case: ** KVM_Driver (also KVM_EL2_DTB, KVM_Infra)
2. Root cause: ** KVM initialization failed with "HYP mode not available" because the Shikra IQS EVK is running the Gunyah hypervisor at EL2, preventing KVM from accessing the required hypervisor privilege level. This is a platform/firmware configuration issue, not a kernel bug.
3. Possible fix: This is not a PR-introduced regression. To enable KVM testing on Shikra IQS EVK, either: (1) reconfigure the firmware/bootloader to boot without Gunyah hypervisor, allowing KVM direct EL2 access, or (2) exclude KVM tests from the CI test suite for boards running Gunyah, as KVM and Gunyah cannot coexist (both require EL2).
4. Detail analysis attachment: failed_case_job268535_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization failed because Gunyah hypervisor is already running at EL2, preventing KVM from entering HYP mode; kernel message "kvm [1]: HYP mode not available" confirms EL2 is unavailable to KVM on Shikra IQS EVK platform.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414; Shikra IQS EVK boots with Gunyah hypervisor by default which occupies EL2 and prevents KVM from initializing; to enable KVM, either (1) boot without Gunyah hypervisor, or (2) use nested virtualization if supported, or (3) mark KVM tests as expected-fail for Gunyah-enabled Shikra configurations in the LAVA test suite.
4. Detail analysis attachment: failed_case_job268535_6_detailed.md

  Case 7: ** KVM_Infra (Test Infrastructure Configuration Issue)

1. Failed case: ** KVM_Infra (Test Infrastructure Configuration Issue)
2. Root cause: ** KVM tests fail because the Shikra IQS EVK board is booted with Gunyah hypervisor running at EL2 (EFI selection='el2gh'), preventing KVM from accessing EL2. The kernel correctly reports "HYP mode not available" during KVM initialization, and /dev/kvm device node is not created. This is expected behavior when a hypervisor is already running at EL2.
3. Possible fix: This is not a kernel bug or PR-introduced regression. To enable KVM testing on this platform, the board must be configured to boot without the Gunyah hypervisor (use EFI selection='el1' or equivalent non-hypervisor boot mode). Alternatively, exclude KVM tests from the CI test suite for boards configured with Gunyah hypervisor, as KVM and Gunyah cannot coexist (both require exclusive EL2 access).
4. Detail analysis attachment: failed_case_job268535_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because the kernel is not running in EL2 (HYP mode not available); the shikra-iqs-evk board booted at EL1, preventing KVM from creating /dev/kvm device node.
3. Possible fix: Boot the board with EL2 support enabled by applying the shikra-el2.dtso overlay (present in this PR) or configure the bootloader/firmware to enter the kernel at EL2 instead of EL1; verify with cat /proc/cpuinfo or check for "HYP mode not available" in dmesg.
4. Detail analysis attachment: failed_case_job268535_8_detailed.md

Job 268537 | SoC qcs615-ride

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

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

  Case 1: ** Probe_Failure_Check — Driver Probe Failure (New Driver Conflict)

1. Failed case: ** Probe_Failure_Check — Driver Probe Failure (New Driver Conflict)
2. Root cause: ** The new qcom-tee-uefisecapp driver introduced in PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 attempts to register as an efivars provider on qcs615-ride, but the platform already has an active efivars provider. The kernel efivars subsystem rejects the second registration with -EBUSY (error -16). This is expected behavior, not a kernel bug. The secondary regulatory.db firmware load failure (error -2) is a known benign false positive — WiFi functional tests passed.
3. Possible fix: Add platform-specific Kconfig dependency or runtime detection to prevent qcom-tee-uefisecapp from loading on platforms that already have efivars support (e.g., via qcom_qseecom_uefisecapp or EFI runtime services). Alternatively, modify the driver to detect existing efivars providers and gracefully skip registration instead of failing probe.
4. Detail analysis attachment: failed_case_job268537_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec child devices (video-decoder and video-encoder) are not registered as separate platform devices with IOMMU group attachments on qcs615-ride; the parent video-codec device is correctly attached to IOMMU group 6, but the test expects child video function devices to also have independent IOMMU group attachments, which is not the case in the current driver/DT configuration.
3. Possible fix: This is a test expectation mismatch rather than a functional regression. The venus video codec driver creates video-decoder and video-encoder as V4L2 video devices (character devices under /dev/videoN), not as separate platform devices with independent IOMMU attachments. Update the smmu test to exclude video codec child devices from the critical master check, or verify that the parent video-codec device's IOMMU attachment is sufficient for DMA protection of all video operations.
4. Detail analysis attachment: failed_case_job268537_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: QCS615 SoC does not support ARM Virtualization Extensions (EL2/HYP mode) — KVM driver correctly detected hardware limitation and reported "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: Exclude KVM tests from qcs615-ride LAVA test suite — the platform lacks hardware virtualization support and will never pass these tests. KVM tests should only run on platforms with EL2 support (e.g., qcs6490-rb3gen2-el2, which has kodiak-el2.dtbo overlay in this PR).
4. Detail analysis attachment: failed_case_job268537_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Gunyah hypervisor occupies EL2 on qcs615-ride, preventing KVM initialization; kernel correctly reports "HYP mode not available" and does not create /dev/kvm device node.
3. Possible fix: Exclude KVM tests from qcs615-ride LAVA job definition — this platform configuration does not support KVM. Alternatively, if KVM testing is required, rebuild the platform firmware without Gunyah hypervisor (not recommended for production use cases that depend on Gunyah's secure partitioning).
4. Detail analysis attachment: failed_case_job268537_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM is architecturally unavailable on qcs615-ride because the platform runs under Gunyah hypervisor which does not expose EL2 (Hypervisor mode) to the guest kernel. The kernel correctly reports "kvm [1]: HYP mode not available" during boot, preventing /dev/kvm device creation.
3. Possible fix: Skip KVM tests on platforms running under a hypervisor, or mark them as expected-fail for qcs615-ride. Add platform detection logic to the test suite to check for hypervisor presence (e.g., grep for "Hypervisor cold boot" in dmesg) before running KVM tests.
4. Detail analysis attachment: failed_case_job268537_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support KVM virtualization — QCS615 does not boot in HYP (EL2) mode, preventing KVM device node creation despite CONFIG_KVM being enabled in kernel config.
3. Possible fix: Mark KVM_Infra test as expected-fail or skip for QCS615 platform in LAVA job definition; this is a known platform limitation, not a kernel regression.
4. Detail analysis attachment: failed_case_job268537_6_detailed.md

Job 268538 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: ath11k_pci driver probe timeout (-110/ETIMEDOUT) during WiFi card initialization on monaco-evk, likely caused by PR changes to QMI node filtering logic (ath11k_hif_get_qrtr_node_id) and ASPM power management (pci_disable_link_state) that disrupt PCIe device enumeration or firmware loading timing.
3. Possible fix: Revert or debug the QMI node filtering changes in drivers/net/wireless/ath/ath11k/qmi.c:ath11k_qmi_ops_new_server() and ASPM changes in drivers/net/wireless/ath/ath11k/pci.c:ath11k_pci_aspm_disable() — verify that qrtr_host_node_id() returns valid node ID for monaco-evk's WCN6855 WiFi card and that pci_disable_link_state() does not cause PCIe link instability during probe.
4. Detail analysis attachment: failed_case_job268538_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The PR enables the iris video-codec device (status = "okay") in monaco-el2.dtso but the base iris node in monaco.dtsi (at address 0xaa00000) lacks the required iommus property for the main device, causing the SMMU test to fail when checking that critical master "Video aa00000.video-codec" is attached to an IOMMU group.
3. Possible fix: Add the missing iommus property to the iris video-codec@aa00000 node in arch/arm64/boot/dts/qcom/monaco.dtsi (around line 59530 in the patch), following the pattern used in other SoCs where the main device node has iommus for non-pixel and pixel child nodes.
4. Detail analysis attachment: failed_case_job268538_2_detailed.md

  Case 3: 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 WCN6855 firmware package to the Yocto build recipe for monaco-evk. Specifically, ensure linux-firmware-ath11k-wcn6855 (or equivalent firmware package containing ath11k/WCN6855/hw2.1/*/amss.bin) is included in the rootfs image recipe for this SoC. Verify the firmware path matches the driver's expected location by checking the ath11k_pci driver's board-specific firmware search paths for monaco/nfa765 platforms.
4. Detail analysis attachment: failed_case_job268538_3_detailed.md

  Case 4: WiFi_OnOff — ath11k_pci driver probe failure

1. Failed case: WiFi_OnOff — ath11k_pci driver probe failure
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) on monaco-evk because MHI (Modem Host Interface) power-up timed out after 1.1 seconds waiting for the WCN6855 WiFi chip firmware to respond; the MHI controller failed to transition to M0 state, and the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin was missing (error -2, ENOENT).
3. Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs under /lib/firmware/ and ensure the firmware package for WCN6855 hw2.1 nfa765 variant is included in the Yocto image recipe; if the firmware is proprietary and unavailable, use the fallback path or reconfigure the device tree to match available firmware variants.
4. Detail analysis attachment: failed_case_job268538_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 definition marked as failed due to incomplete test execution — the test runner exited normally after completing all available tests, but LAVA infrastructure marked it as "unfinished" because some individual test cases failed (WiFi probe timeout due to missing firmware, probe failure checks). The kernel booted successfully and executed 9+ minutes of tests before the test definition was marked failed.
3. Possible fix: This is not a PR-introduced regression. The WiFi probe failure (ath11k_pci 0000:01:00.0: probe with driver ath11k_pci failed with error -110) is caused by missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the test image — a pre-existing infrastructure issue unrelated to the PR's ath11k driver changes. The PR modifies ASPM handling in ath11k_pci.c but the probe never reaches that code path due to the earlier firmware load failure. To resolve: ensure the test image includes the required WCN6855 firmware files, or suppress this known firmware-missing failure in the CI configuration for monaco-evk.
4. Detail analysis attachment: failed_case_job268538_5_detailed.md

Job 268539 | SoC kaanapali-mtp

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The newly introduced qcom-tee-uefisecapp driver (added by this PR) attempts to register EFI variable operations via efivars_register() during probe, but fails with -EBUSY because EFI runtime services are already registered by the platform firmware (UEFI) at boot time (visible at timestamp 2.82s: "efivars: Registered efivars operations"). The kaanapali-mtp platform uses UEFI firmware which provides native EFI runtime variable services, making the TEE-based uefisecapp driver redundant and causing a registration conflict.
3. Possible fix: Add a pre-probe check in qcom_tee_uefisecapp_probe() to detect if EFI runtime services are already active (via efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE) or checking efi_enabled(EFI_RUNTIME_SERVICES)), and return -ENODEV with an informational message if native UEFI runtime services are present, allowing the driver to gracefully skip probe on platforms where it is not needed. Alternatively, add a Kconfig dependency or platform compatibility check to prevent the driver from being enabled on UEFI-based platforms.
4. Detail analysis attachment: failed_case_job268539_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device 2000000.video-codec is not attached to an IOMMU group because the PR introduces a new Iris video codec driver architecture where IOMMU mappings are specified in child device nodes (non-pixel, pixel, video-firmware) rather than on the parent device node, causing the SMMU test's parent-device IOMMU group check to fail.
3. Possible fix: Update the SMMU test script to recognize the new Iris video codec driver pattern where child nodes contain iommus properties instead of the parent device; alternatively, mark video codec devices using the child-node IOMMU pattern as expected exceptions in the test's critical master validation logic.
4. Detail analysis attachment: failed_case_job268539_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe endpoint device 0000:01:00.0 (Qualcomm QCN9274 WiFi, vendor 0x17cb device 0x110e) was successfully enumerated and link is up at 8.0 GT/s x2, but no kernel driver is bound to it (driver=unbound). The ath12k_pci driver that should bind to this device is either not built into the kernel image or not loaded as a module during boot.
3. Possible fix: This is a test infrastructure / kernel configuration issue, not a PR-introduced regression. The PR modifies ath12k driver code (ASPM handling changes in drivers/net/wireless/ath/ath12k/pci.c) but does not affect driver probe or device ID matching. Verify that CONFIG_ATH12K=m or CONFIG_ATH12K=y and CONFIG_ATH12K_PCI=m or CONFIG_ATH12K_PCI=y are set in the kernel config used for this LAVA job. If built as modules, ensure ath12k.ko and ath12k_pci.ko are included in the rootfs and loaded during boot (check /lib/modules// and modprobe configuration).
4. Detail analysis attachment: failed_case_job268539_3_detailed.md

  Case 4: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Bluetooth WCN7850 firmware download repeatedly times out with HCI command 0xfc00 timeout (-110 ETIMEDOUT) during TLV segment transfer of qca/hmtbtfw20.tlv, preventing firmware initialization and leaving the adapter with invalid BD address (00:00:00:00:00:00) on kaanapali-mtp platform.
3. Possible fix: Investigate UART transport reliability between AP and WCN7850 Bluetooth controller on kaanapali-mtp — verify UART pinmux/GPIO configuration in device tree, check for UART clock/power sequencing issues during Bluetooth power-on, and confirm firmware file qca/hmtbtfw20.tlv integrity in rootfs; if PR introduced changes to hci_uart/btqca drivers (hci_serdev.c flush ordering, qca_combine_nvm_calib), bisect to isolate the regression and revert or fix the problematic commit.
4. Detail analysis attachment: failed_case_job268539_4_detailed.md

  Case 5: LAVA Test Timeout — Bluetooth Firmware Load Failure Loop

1. Failed case: LAVA Test Timeout — Bluetooth Firmware Load Failure Loop
2. Root cause: The kaanapali-mtp board's WCN7850 Bluetooth controller repeatedly fails to load firmware (qca/hmtbtfw20.tlv) with command 0xfc00 tx timeout errors (-110 / ETIMEDOUT), causing the BT_FW_KMD_Service test to fail and the subsequent BT_ON_OFF test to enter an infinite recovery loop that exhausts the 40-minute LAVA test timeout. The PR introduces Bluetooth driver changes (btqca.c, hci_qca.c) including new firmware handling logic (qca_combine_nvm_calib) and QCC2072 support, which may have introduced a regression in the WCN7850 firmware download path or timing.
3. Possible fix: Revert the Bluetooth driver changes in this PR (drivers/bluetooth/btqca.c, drivers/bluetooth/hci_qca.c, drivers/bluetooth/hci_serdev.c) and re-test to confirm the baseline works. If the baseline also fails, this is a pre-existing kaanapali-mtp board/firmware issue unrelated to the PR. If the baseline passes, bisect the PR's Bluetooth commits to identify which change broke WCN7850 firmware loading, focusing on the new qca_combine_nvm_calib function and any changes to firmware request/download timing or retry logic.
4. Detail analysis attachment: failed_case_job268539_5_detailed.md

  Case 6: lava-test-shell

1. Failed case: lava-test-shell
2. Root cause: LAVA test shell timed out after 2400 seconds (40 minutes) because the BT_ON_OFF test hung waiting for Bluetooth runtime to become ready. The Bluetooth driver repeatedly failed to download firmware qca/hmtbtfw20.tlv with HCI command 0xfc00 tx timeout (error -110 ETIMEDOUT) during WCN7850 setup on kaanapali-mtp. The firmware download failure is a pre-existing hardware/firmware communication issue unrelated to the PR changes (PR adds QCC2072 support; this device is WCN7850).
3. Possible fix: Re-trigger the CI job. If the issue recurs, investigate the WCN7850 Bluetooth hardware/firmware communication path on kaanapali-mtp: check UART signal integrity, verify firmware file qca/hmtbtfw20.tlv is present and valid in the rootfs, review HCI transport layer logs for UART errors, and consider increasing HCI command timeout or adding retry logic for kaanapali-mtp platform-specific timing requirements.
4. Detail analysis attachment: failed_case_job268539_6_detailed.md

  Case 7: lava-test-retry (LAVA test timeout caused by Bluetooth firmware loading failure)

1. Failed case: lava-test-retry (LAVA test timeout caused by Bluetooth firmware loading failure)
2. Root cause: Bluetooth driver (btqca/hci_uart for WCN7850) repeatedly fails to load firmware file qca/hmtbtfw20.tlv with HCI command timeout (-110 ETIMEDOUT). The QCA controller successfully reads version information but times out when attempting to download the TLV firmware segment, exhausting all retry attempts (0, 1, 2) across multiple recovery cycles. The test framework correctly waits for Bluetooth readiness but times out after 2400 seconds when the adapter never achieves a valid BD address.
3. Possible fix: Investigate the HCI command transport path between the kernel Bluetooth driver and the WCN7850 firmware on kaanapali-mtp. The -110 (ETIMEDOUT) during "command 0xfc00 tx timeout" suggests either: (1) the UART transport is not reliably delivering commands to the Bluetooth controller, (2) the WCN7850 firmware is not responding to HCI commands within the expected timeout window, or (3) a platform-specific power/clock/pinctrl issue is preventing proper UART communication. Check UART configuration (baud rate, flow control), WCN7850 power sequencing (enable-gpios, regulators), and compare with known-working kaanapali-mtp configurations. If this is a PR-introduced regression, review any changes to WCN7850 device tree bindings, UART serdev configuration, or Bluetooth driver initialization sequence.
4. Detail analysis attachment: failed_case_job268539_7_detailed.md

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

1. Failed case: LAVA Test Infrastructure Timeout — lava-test-shell exceeded 2400s limit
2. Root cause: The BT_ON_OFF test case entered an infinite recovery loop attempting to load Bluetooth firmware (qca/hmtbtfw20.tlv) for the wcn7850 adapter on kaanapali-mtp. The Bluetooth driver repeatedly failed with "command 0xfc00 tx timeout" (-110 ETIMEDOUT) during firmware download, triggering test-level recovery attempts that never completed. The LAVA job timeout (2400s) was reached while the test was still stuck in the second recovery attempt, causing the entire job to fail.
3. Possible fix: This is a test infrastructure timeout, not a PR-introduced regression. The Bluetooth firmware loading issue is a known pre-existing platform/firmware problem on kaanapali-mtp (wcn7850 adapter). Recommended actions: (1) Increase the LAVA job timeout from 2400s to 3600s in the job definition to accommodate slow Bluetooth recovery on this platform, or (2) Configure the BT_ON_OFF test to fail-fast after the first recovery attempt instead of retrying indefinitely, or (3) Skip Bluetooth tests on kaanapali-mtp until the wcn7850 firmware loading timeout issue is resolved at the driver/firmware level.
4. Detail analysis attachment: failed_case_job268539_8_detailed.md

Job 268540 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add platform compatibility check or conditional registration logic to qcomtee_uefisecapp_probe() to gracefully handle platforms where EFI variable services are already provided by another backend (e.g., UEFI runtime services or qcom_qseecom_uefisecapp). The driver should return -ENODEV or skip registration rather than failing with -EBUSY, or use a Kconfig dependency to prevent building on incompatible platforms.
4. Detail analysis attachment: failed_case_job268540_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on qcs8300-ride is missing IOMMU group attachment because the device tree node lacks the iommus property, causing the SMMU validation test to fail when checking critical master protection.
3. Possible fix: Add the iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/qcs8300.dtsi or qcs8300-ride.dts, referencing the appropriate SMMU instance and stream IDs for the video codec hardware on this SoC.
4. Detail analysis attachment: failed_case_job268540_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 not a kernel bug or PR-introduced regression. The QCS8300/Monaco platform does not have virtualization extensions enabled in hardware/firmware. To resolve: (1) If virtualization is required, verify the platform SKU supports it and ensure bootloader/TZ firmware enables EL2 mode; (2) If virtualization is not needed on this platform, exclude KVM tests from the CI test suite for QCS8300 targets to prevent false failures.
4. Detail analysis attachment: failed_case_job268540_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: QCS8300 Ride platform booted without EL2 (Hypervisor mode) support — kernel reports "kvm [1]: HYP mode not available" at boot, preventing KVM device node creation. The platform requires the EL2-enabled device tree overlay (qcs8300-ride-el2.dtb = qcs8300-ride.dtb + monaco-el2.dtbo) to boot Linux in hypervisor mode, but the LAVA job used the standard qcs8300-ride.dtb without the EL2 overlay.
3. Possible fix: Update the LAVA job definition to flash and boot the EL2-enabled device tree blob qcs8300-ride-el2.dtb instead of qcs8300-ride.dtb. This will enable the platform to boot Linux at EL2, allowing KVM to initialize and create /dev/kvm.
4. Detail analysis attachment: failed_case_job268540_4_detailed.md

  Case 5: KVM_Infra — Test Environment Limitation (Nested Virtualization Not Supported)

1. Failed case: KVM_Infra — Test Environment Limitation (Nested Virtualization Not Supported)
2. Root cause: The qcs8300-ride target is running as a guest under Gunyah hypervisor (version gunyah-3fe287d48), which prevents KVM from initializing because nested virtualization is not supported. The kernel message kvm [1]: HYP mode not available indicates that EL2 (hypervisor mode) is not accessible to the guest kernel, causing /dev/kvm device node creation to fail.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414 (which contains only device tree and documentation changes unrelated to KVM/virtualization). The failure is expected behavior on this platform configuration. To enable KVM testing: (1) run the test on bare-metal qcs8300-ride hardware without Gunyah hypervisor, OR (2) if nested virtualization support is required, enable it in the Gunyah hypervisor configuration and ensure the guest kernel is configured with appropriate nested KVM support, OR (3) mark KVM tests as skipped/not-applicable for Gunyah-hosted test environments in the CI configuration.
4. Detail analysis attachment: failed_case_job268540_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 on the qcs8300-ride platform. The kernel boot log shows kvm [1]: HYP mode not available at boot time, indicating the platform is not running in hypervisor (EL2) mode. CONFIG_KVM is enabled in the kernel configuration, but the KVM driver cannot initialize because the hardware/firmware does not support or enable EL2 execution.
3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.4-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1414. The qcs8300-ride board does not support KVM/virtualization in its current firmware/hardware configuration. Mark the KVM_Infra and KVM_EL2_DTB tests as expected failures for this platform, or exclude them from the test suite for qcs8300-ride until EL2 support is enabled in the platform firmware/bootloader configuration.
4. Detail analysis attachment: failed_case_job268540_6_detailed.md

Job 268541 | SoC hamoa-evk

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** The PR introduces a new qcom-tee-uefisecapp driver that conflicts with the existing qcom_qseecom_uefisecapp driver for the same UEFI secure app service, causing expected -EBUSY probe failures. Additionally, a pre-existing benign regulatory.db firmware load failure (-ENOENT) is detected. These are platform-expected probe failures on hamoa-evk, not functional regressions.
3. Possible fix: Suppress these three probe failures in the Probe_Failure_Check test for hamoa-evk platform: (1) qcom_qseecom_uefisecapp -EBUSY (expected when qcom-tee-uefisecapp binds first), (2) qcom-tee-uefisecapp -EBUSY (expected when qcom_qseecom_uefisecapp binds first), and (3) regulatory.db -ENOENT (benign, cfg80211 uses built-in regulatory data). Alternatively, configure the kernel to load only one of the two UEFI secure app drivers via Kconfig or device tree to eliminate the conflict.
4. Detail analysis attachment: failed_case_job268541_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) exists in the device tree but is missing the iommus property, preventing IOMMU group attachment required for DMA protection on hamoa-evk (x7181/x1e80100-based SoC).
3. Possible fix: Add the iommus property to the video-codec@aa00000 node in the hamoa/x1e80100 device tree, referencing the appropriate SMMU instance and stream ID, following the pattern used by other critical masters (UFS, GPU, Display) that successfully attach to IOMMU groups.
4. Detail analysis attachment: failed_case_job268541_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on hamoa-evk because the Gunyah hypervisor is running at EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" indicates that KVM detected it cannot operate because another hypervisor (Gunyah) has already claimed EL2 privilege level, which is required for KVM virtualization on ARM64.
3. Possible fix: This is expected behavior on hamoa-evk with Gunyah hypervisor enabled. Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as "skip" for hamoa-evk platform in the LAVA test suite configuration, or add a platform-specific test gate that skips KVM tests when Gunyah hypervisor is detected in boot logs.
4. Detail analysis attachment: failed_case_job268541_3_detailed.md

  Case 4: KVM_EL2_DTB (Test Environment Limitation)

1. Failed case: KVM_EL2_DTB (Test Environment Limitation)
2. Root cause: Hamoa EVK platform does not boot with EL2 hypervisor mode available to Linux; KVM initialization reports "HYP mode not available" at boot, preventing /dev/kvm creation and causing all KVM tests to fail.
3. Possible fix: This is not a kernel bug. The test should be skipped on platforms without EL2/KVM support, or the Hamoa EVK firmware/bootloader configuration must be updated to boot Linux with EL2 access enabled. Add platform capability detection to the CI test suite to skip KVM tests when HYP mode is unavailable.
4. Detail analysis attachment: failed_case_job268541_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the KVM test suite to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or check /sys/hypervisor) and skip KVM tests with result=skip (not fail) when a hypervisor is already running. The test's "KVM Availability Gate" should check for hypervisor presence before attempting KVM tests.
4. Detail analysis attachment: failed_case_job268541_5_detailed.md

  Case 6: KVM_Infra — /dev/kvm device node missing

1. Failed case: KVM_Infra — /dev/kvm device node missing
2. Root cause: KVM driver initialization failed because HYP (Hypervisor) mode is not available on the hamoa-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot time, causing KVM driver to abort initialization and never create the /dev/kvm device node.
3. Possible fix: This is a platform hardware limitation, not a PR-introduced regression. The hamoa-evk SoC does not support EL2/HYP mode required for KVM virtualization. Recommended action: exclude KVM tests from the hamoa-evk CI test suite, or mark them as expected-to-skip for this platform. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job268541_6_detailed.md

[qcomlnxci]

Test Matrix

Test Case	kbdev-glymur-crd-multimedia	kbdev-hamoa-iot-evk-multimedia	kbdev-kaanapali-mtp-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia	kbdev-sm8750-mtp-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ 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	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	◻️	❌ 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	✅ 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	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail
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 d7a1466

• multimedia Job 268534 on glymur-crd
• multimedia Job 268541 on hamoa-iot-evk
• multimedia Job 268539 on kaanapali-mtp
• multimedia Job 268988 on lemans-evk
• multimedia Job 268538 on monaco-evk
• multimedia Job 268533 on purwa-iot-evk
• multimedia Job 268537 on qcs615-ride
• multimedia Job 268529 on qcs6490-rb3gen2
• multimedia Job 268540 on qcs8300-ride
• multimedia Job 268532 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 268535 on shikra-iqs-evk
• multimedia Job 268530 on sm8750-mtp

[qcomlnxci]

Test Matrix

Test Case	kbdev-glymur-crd-multimedia	kbdev-hamoa-iot-evk-multimedia	kbdev-kaanapali-mtp-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia	kbdev-sm8750-mtp-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ 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	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	◻️	❌ 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	✅ 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	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail
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 d7a1466

• multimedia Job 268534 on glymur-crd
• multimedia Job 268541 on hamoa-iot-evk
• multimedia Job 269770 on kaanapali-mtp
• multimedia Job 268988 on lemans-evk
• multimedia Job 268538 on monaco-evk
• multimedia Job 268533 on purwa-iot-evk
• multimedia Job 268537 on qcs615-ride
• multimedia Job 268529 on qcs6490-rb3gen2
• multimedia Job 268540 on qcs8300-ride
• multimedia Job 268532 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 268535 on shikra-iqs-evk
• multimedia Job 268530 on sm8750-mtp

[qcomlnxci]

Test Matrix

Test Case	kbdev-glymur-crd-multimedia	kbdev-hamoa-iot-evk-multimedia	kbdev-kaanapali-mtp-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia	kbdev-sm8750-mtp-multimedia
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_ON_OFF	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
BT_SCAN	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ 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	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
USBHost	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail
watchdog	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on d7a1466

• multimedia Job 268534 on glymur-crd
• multimedia Job 268541 on hamoa-iot-evk
• multimedia Job 269770 on kaanapali-mtp
• multimedia Job 269774 on lemans-evk
• multimedia Job 268538 on monaco-evk
• multimedia Job 268533 on purwa-iot-evk
• multimedia Job 268537 on qcs615-ride
• multimedia Job 268529 on qcs6490-rb3gen2
• multimedia Job 268540 on qcs8300-ride
• multimedia Job 268532 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 268535 on shikra-iqs-evk
• multimedia Job 268530 on sm8750-mtp