Qcom next staging 7.2 rc7 glymur display

[Salendarsingh Gaud (sgaud-quic)]

Below changes are picked for Glymur release :

qualcomm-linux/kernel-topics@7b48e6e
qualcomm-linux/kernel-topics@83f65e1

[qcomlnxci]

Test jobs on fa6c906

• multimedia Job 207652 on glymur-crd
• multimedia Job 207655 on hamoa-iot-evk
• multimedia Job 207658 on kaanapali-mtp
• multimedia Job 207657 on lemans-evk
• multimedia Job 207663 on monaco-evk
• multimedia Job 207654 on purwa-iot-evk
• multimedia Job 207660 on qcs615-ride
• multimedia Job 207659 on qcs6490-rb3gen2
• multimedia Job 207656 on qcs8300-ride
• multimedia Job 207661 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 207653 on shikra-iqs-evk
• multimedia Job 207662 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	◻️	◻️	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	◻️	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	◻️	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
Ethernet	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	◻️	◻️	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ 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	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	❌ 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	✅ Pass	◻️	◻️	✅ Pass
USBHost	❌ Fail	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	❌ Fail	❌ Fail	◻️	◻️	❌ Fail
WiFi_Firmware_Driver	✅ Pass	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
WiFi_OnOff	✅ Pass	❌ Fail	⚠️ skip	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	◻️	◻️	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
remoteproc	❌ Fail	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	◻️	◻️	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	◻️	✅ Pass

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #973

Job 207652 | SoC glymur-crd

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

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

  Case 1: remoteproc — Test Expectation Mismatch (Not a Kernel Issue)

1. Failed case: remoteproc — Test Expectation Mismatch (Not a Kernel Issue)
2. Root cause: The test incorrectly expects remoteproc0 (soccp) to be in "running" state, but SoCCP is an early-boot remoteproc that Linux attaches to (state: "attached") rather than boots. Both "running" and "attached" are valid operational states in the remoteproc framework.
3. Possible fix: Update the remoteproc test script to accept "attached" as a valid operational state for remoteprocs that support early-boot attach mode. Modify the test to check for (state == "running" OR state == "attached") instead of requiring state == "running" for all remoteprocs.
4. Detail analysis attachment: failed_case_job207652_1_detailed.md

  Case 2: ** Probe_Failure_Check — Deferred Probe Loop (8 SPMI PMIC temp-alarm devices)

1. Failed case: ** Probe_Failure_Check — Deferred Probe Loop (8 SPMI PMIC temp-alarm devices)
2. Root cause: ** The qcom-spmi-temp-alarm driver is not available in the kernel (not built-in, not loaded as module, or CONFIG disabled).
3. Possible fix: Enable CONFIG_THERMAL_QCOM_SPMI_TEMP_ALARM=y in the kernel configuration for glymur-crd CI builds. Rebuild and reflash the kernel. Verify driver probes successfully by checking dmesg for qcom-spmi-temp-alarm registration messages and confirming /sys/kernel/debug/devices_deferred no longer lists temp-alarm devices after boot.
4. Detail analysis attachment: failed_case_job207652_2_detailed.md

  Case 3: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) added by PR without top-level iommus property in device tree, causing SMMU test to fail when checking for IOMMU group attachment of critical master devices.
3. Possible fix: Add iommus property to the top-level video-codec@aa00000 node in arch/arm64/boot/dts/qcom/glymur.dtsi, following the pattern used by other critical masters (GPU, USB, Camera, Display) which all have iommus at the device level, not just in subnodes.
4. Detail analysis attachment: failed_case_job207652_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure configuration issue — the USBHost test expects a physical USB device (keyboard, mouse, storage, etc.) to be connected to the glymur-crd board's USB port, but only USB 2.0 and USB 3.0 root hubs are present (no external devices connected). The USB host controller (xHCI) initialized successfully and is fully functional.
3. Possible fix: Connect a physical USB device (e.g., USB flash drive, keyboard, or mouse) to the glymur-crd board in the LAVA lab before running the test, or update the test script to skip USBHost when no external USB device is available (treat as configuration-dependent test similar to Ethernet).
4. Detail analysis attachment: failed_case_job207652_4_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test suite marked as failed due to four sub-test failures (remoteproc, Probe_Failure_Check, smmu, USBHost) that occurred during functional validation after successful kernel boot; these are test validation failures, not kernel crashes or build load failures.
3. Possible fix: Review and address each individual test failure: (1) remoteproc0 state is 'attached' instead of 'running' - investigate why remoteproc0 did not transition to running state; (2) Probe_Failure_Check detected deferred probe devices (temp-alarm nodes) and regulatory.db firmware load failure - verify these are expected for glymur-crd platform; (3) smmu test failed because video codec (aa00000.video-codec) is missing IOMMU group attachment - check device tree IOMMU bindings for video codec node; (4) USBHost test found only USB hubs, no functional devices - verify USB device connectivity in test setup.
4. Detail analysis attachment: failed_case_job207652_5_detailed.md

Job 207653 | SoC shikra-iqs-evk

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

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

  Case 1: GIC (Test Infrastructure Bug — Script Parsing Error)

1. Failed case: GIC (Test Infrastructure Bug — Script Parsing Error)
2. Root cause: The GIC test script (run.sh line 75) attempts to parse /proc/interrupts to extract timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform only has 4 CPUs (0-3). The script encounters a bash integer comparison error when parsing the interrupt line "11: 25339 35737 30348 18084 GICv3 19 Level arch_timer" because it expects only numeric fields but receives the string "GICv3" in the interrupt controller name column.
3. Possible fix: Update the GIC test script to: (1) dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding CPU count expectations, (2) fix the /proc/interrupts parsing logic at line 75 to correctly handle non-numeric fields (interrupt controller name, trigger type) by using proper field extraction (e.g., awk '{print $2, $3, $4, $5}' to extract only the per-CPU count columns), and (3) skip validation for CPUs that are not present on the platform.
4. Detail analysis attachment: failed_case_job207653_1_detailed.md

  Case 2: Remoteproc — Modem subsystem not auto-started

1. Failed case: Remoteproc — Modem subsystem not auto-started
2. Root cause: remoteproc0 (modem/qdsp6sw.mbn) registered as "available" at boot but was never automatically powered up, remaining in "offline" state; cdsp (remoteproc1) and lpaicp (remoteproc2) were auto-started successfully, indicating platform-specific or policy-driven selective boot behavior for shikra-iqs-evk where modem auto-start is intentionally disabled or requires manual trigger.
3. Possible fix: This is expected behavior for shikra-iqs-evk platform — modem subsystem requires manual start via echo start > /sys/class/remoteproc/remoteproc0/state or userspace policy configuration; if auto-start is required, verify device-tree qcom,auto-boot property is set for the modem remoteproc node, or update test expectations to reflect platform-specific boot policy.
4. Detail analysis attachment: failed_case_job207653_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: Suppress known false positives in Probe_Failure_Check test: (1) cpufreq-dt error -17 on SCMI platforms, (2) regulatory.db -ENOENT, (3) audio subsystem deferred probes on shikra-iqs-evk if audio is non-critical for CI; alternatively, delay test execution to allow deferred probes more time to resolve.
4. Detail analysis attachment: failed_case_job207653_3_detailed.md

  Case 4: PCIe

1. Failed case: PCIe
2. Root cause: PCIe driver for compatible string "qcom,pcie-shikra" is not present in the kernel; the PR adds device tree nodes and bindings but the corresponding PCIe host controller driver has not been merged or enabled in the kernel build.
3. Possible fix: Add and enable the Qualcomm Shikra PCIe host controller driver (drivers/pci/controller/dwc/pcie-qcom-shikra.c or similar) that matches the "qcom,pcie-shikra" compatible string, or temporarily disable the PCIe node in the device tree by setting status = "disabled" in shikra-iqs-evk.dts until the driver is available.
4. Detail analysis attachment: failed_case_job207653_4_detailed.md

  Case 5: USBHost

1. Failed case: USBHost
2. Root cause: USB controller on shikra-iqs-evk is configured in gadget/peripheral mode (for serial console), but the USBHost test expects host mode to enumerate external USB devices; test infrastructure does not match hardware configuration.
3. Possible fix: Either (1) configure the shikra-iqs-evk USB controller DT node with dr_mode = "host" or dr_mode = "otg" and ensure a USB hub/device is physically connected to the host port, or (2) skip the USBHost test on boards where USB is dedicated to gadget mode for console/debug, or (3) add a second USB controller node configured for host mode if the hardware supports it.
4. Detail analysis attachment: failed_case_job207653_5_detailed.md

  Case 6: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth scan test failed because no discoverable Bluetooth devices are present in the LAVA test environment; the Bluetooth controller is functional (BT_ON_OFF passed, controller powered on successfully, discovery started/stopped correctly), but the test expects to find at least one nearby Bluetooth device to validate scan functionality.
3. Possible fix: This is a test environment configuration issue, not a kernel regression. The test should either: (1) be updated to skip when no reference Bluetooth device is available in the lab, or (2) the LAVA lab should provision a reference Bluetooth beacon/device near the shikra-iqs-evk board to enable scan validation. No kernel fix is required.
4. Detail analysis attachment: failed_case_job207653_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 fault in qcom_rng_read() at PC offset +0xb8 when reading from the hardware RNG register during the qcom_hwrng test. The synchronous external abort (ESR 0x96000010) indicates the CPU attempted to read from an unmapped, unpowered, or clock-gated hardware address, causing a bus-level fault. This is a pre-existing hardware/platform issue on shikra-iqs-evk, not introduced by PR Qcom next staging 7.2 rc7 glymur display #973 (which only modifies documentation and DT bindings unrelated to qcom_rng).
3. Possible fix: This is NOT a PR-introduced regression. The qcom_hwrng test should be marked as a known failure or skipped on shikra-iqs-evk until the platform's RNG hardware configuration (clocks, power domains, IOMMU mappings) is corrected. To debug: verify qcom_rng DT node has correct clocks/power-domains, check if RNG block is powered and clocked during the test, and confirm SMMU/IOMMU mappings for the RNG register range. Re-trigger the CI job to confirm this is reproducible and not a transient hardware glitch.
4. Detail analysis attachment: failed_case_job207653_7_detailed.md

  Case 8: 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 crashed with a synchronous external abort (0x96000010) at PC qcom_rng_read+0xb8 while reading hardware RNG registers during the qcom_hwrng test. This indicates the driver attempted to access an unmapped, unpowered, or incorrectly configured MMIO region for the Shikra TRNG hardware. The PR adds shikra-trng device tree support but the runtime hardware access fails, suggesting missing clock/regulator enablement, incorrect MMIO address mapping, or hardware not ready when accessed.
3. Possible fix: Verify the shikra-trng device tree node has correct reg address (0x4454000 per PR), required clocks are defined and enabled before register access, and power domains/regulators are properly sequenced in the qcom_rng probe path. Add runtime PM calls or explicit clock/regulator enable before the first MMIO read in qcom_rng_read(). Cross-check the MMIO address against Shikra hardware documentation and confirm it matches the actual SoC memory map.
4. Detail analysis attachment: failed_case_job207653_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: Kernel panic triggered by synchronous external abort at PC qcom_rng_read+0xb8 in the qcom_rng driver while a dd process (PID 10206) was reading from /dev/hwrng. The abort indicates a hardware bus error when the driver attempted to read from the RNG hardware register, suggesting the RNG hardware block was not properly powered/clocked or the MMIO mapping became invalid on the shikra-iqs-evk platform.
3. Possible fix: Investigate qcom_rng driver power/clock dependencies and MMIO region validity on shikra (QCM2290). Verify that the RNG device tree node includes correct power-domain, clock, and reg properties. Add runtime PM and clock enable checks before register access in qcom_rng_read(). If the issue is platform-specific, consider disabling the qcom_rng driver for shikra-iqs-evk until hardware dependencies are resolved, or add a platform quirk to handle the power sequencing correctly.
4. Detail analysis attachment: failed_case_job207653_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: Synchronous external abort (0x96000010) in qcom_rng_read+0xb8/0x210 when the qcom_hwrng test attempted to read entropy from /dev/hwrng on shikra-iqs-evk; the hardware RNG register access faulted, causing a kernel panic that prevented test completion and triggered the 2400-second LAVA timeout.
3. Possible fix: Investigate qcom_rng driver hardware register mapping for shikra (QCM2290/QCM6490 family) — verify PRNG base address, clock/power domain dependencies, and whether the RNG block requires explicit enablement on this SoC; add runtime PM or clock gating checks before register access; if the RNG hardware is not present or not functional on shikra-iqs-evk, mark the test as SKIP for this platform or disable the qcom_rng driver in the device tree.
4. Detail analysis attachment: failed_case_job207653_10_detailed.md

Job 207654 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Multiple probe and firmware load failures detected on purwa-evk (iq-x5121-evk): (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) indicating secure app already loaded or resource conflict; (2) two PCIe controllers (1bd0000, 1bf8000) failed with -ENODATA (-61) indicating missing/unavailable PCIe endpoints or link training failure; (3) regulatory.db firmware missing (-ENOENT, -2) which is benign for WiFi operation; (4) video codec (qcom-iris) firmware vpu30_p1_s7.mbn missing (-ENOENT, -2) causing video codec to fail probe and remain without IOMMU group attachment; (5) seven PMIC temp-alarm devices remain in deferred probe state. These are platform-specific hardware/firmware availability issues, not PR-introduced regressions.
3. Possible fix: These failures are expected on purwa-evk and do not indicate kernel regressions: (1) qcom_qseecom_uefisecapp -EBUSY is normal when secure app is pre-loaded by firmware; (2) PCIe -ENODATA is expected when no PCIe cards are installed; (3) regulatory.db is optional and WiFi functions without it; (4) video codec firmware vpu30_p1_s7.mbn must be added to rootfs /lib/firmware/qcom/vpu/ to enable video decode/encode; (5) PMIC temp-alarm deferred probe is benign if thermal monitoring is not critical. To resolve: add missing video firmware to the test image, or suppress these known-benign failures in the Probe_Failure_Check test logic for purwa-evk.
4. Detail analysis attachment: failed_case_job207654_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the iommus property to the video-codec@aa00000 device tree node in the purwa SoC device tree file (arch/arm64/boot/dts/qcom/x5121.dtsi or equivalent) to bind the Venus video codec to an IOMMU group, following the pattern used in other Qualcomm SoCs (e.g., iommus = <&apps_smmu 0x2180 0x20>;).
4. Detail analysis attachment: failed_case_job207654_2_detailed.md

  Case 3: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath12k WiFi driver QMI DMA allocation failure (7274496 bytes, type 1) during firmware load on purwa-evk platform — likely caused by insufficient contiguous DMA memory or CMA pool exhaustion, potentially exacerbated by PR Qcom next staging 7.2 rc7 glymur display #973's extensive addition of dma-coherent properties to device tree nodes which may have altered DMA memory allocation patterns or increased contention for DMA-capable memory regions.
3. Possible fix: Increase the CMA pool size in the device tree reserved-memory node for purwa-evk, or adjust the DMA memory allocation strategy for the ath12k_wifi7_pci driver; verify that the PR's dma-coherent property additions to multiple device tree nodes (BAM DMA, audio DMA, GPI DMA controllers) have not inadvertently reduced available CMA memory for WiFi; if the issue persists, revert the dma-coherent changes for non-critical devices or implement a dedicated reserved-memory pool for WiFi QMI firmware buffers.
4. Detail analysis attachment: failed_case_job207654_3_detailed.md

  Case 4: WiFi_OnOff — WiFi driver probe warning (non-fatal)

1. Failed case: WiFi_OnOff — WiFi driver probe warning (non-fatal)
2. Root cause: ath12k_wifi7_pci driver on purwa-evk (WCN7850 hw2.0) logged "qmi dma allocation failed (7274496 B type 1), will try later with small size" during initial probe at boot, but the driver successfully recovered by retrying with a smaller allocation size and completed initialization (firmware loaded, interface operational).
3. Possible fix: This is a known benign warning — the driver implements fallback logic and successfully initializes despite the initial allocation failure. The WiFi_OnOff test should suppress this specific warning pattern when the driver subsequently completes probe successfully (firmware version logged, interface renamed to wlP4p1s0). If the warning must be eliminated, investigate CMA/DMA heap sizing for purwa-evk or adjust the initial QMI DMA allocation request size in the ath12k_wifi7 driver.
4. Detail analysis attachment: failed_case_job207654_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel bug. To enable KVM on purwa-evk, the bootloader/firmware must be configured to boot the kernel in EL2 mode. If the hardware supports virtualization extensions, update the bootloader (ABL/UEFI) configuration to enter the kernel at EL2. If the hardware doesn't support EL2, KVM cannot be enabled and this test should be excluded from the purwa-evk test suite.
4. Detail analysis attachment: failed_case_job207654_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on purwa-evk because the platform is running under the Gunyah hypervisor (gunyah-mobile-c487961e9), which occupies EL2 and prevents KVM from accessing HYP mode; kernel reports "kvm [1]: HYP mode not available" at boot.
3. Possible fix: Exclude KVM test cases (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for purwa-evk and other platforms running under Gunyah hypervisor, as nested virtualization is not supported; alternatively, configure the platform to boot without Gunyah if KVM testing is required.
4. Detail analysis attachment: failed_case_job207654_6_detailed.md

  Case 7: KVM Infrastructure Test Failure — KVM unavailable due to Gunyah hypervisor at EL2

1. Failed case: KVM Infrastructure Test Failure — KVM unavailable due to Gunyah hypervisor at EL2
2. Root cause: KVM cannot initialize because Gunyah hypervisor is running at EL2, preventing Linux KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" indicates that the ARM virtualization extensions (EL2) are already claimed by the Gunyah hypervisor running on purwa-evk, making /dev/kvm unavailable despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform configuration constraint, not a PR-introduced regression. On purwa-evk with Gunyah hypervisor, KVM tests should be skipped or the test suite should be updated to detect Gunyah presence and mark KVM tests as "not applicable" rather than "fail". To enable KVM, the platform would need to boot without the Gunyah hypervisor, which requires bootloader/firmware configuration changes outside the scope of kernel patches.
4. Detail analysis attachment: failed_case_job207654_7_detailed.md

  Case 8: KVM_Driver, KVM_EL2_DTB, KVM_Infra (Test Infrastructure Limitation)

1. Failed case: KVM_Driver, KVM_EL2_DTB, KVM_Infra (Test Infrastructure Limitation)
2. Root cause: KVM cannot initialize because Gunyah hypervisor is already running at EL2 on purwa-evk platform; ARM architecture allows only one hypervisor at EL2, and KVM requires exclusive EL2 access to create /dev/kvm.
3. Possible fix: This is not a kernel regression or bug. The test failures are expected on platforms running Gunyah hypervisor. To enable KVM testing: (1) disable Gunyah hypervisor in the boot configuration, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms like purwa-evk, or (3) use a different test platform without Gunyah for KVM validation.
4. Detail analysis attachment: failed_case_job207654_8_detailed.md

Job 207655 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Eight SPMI PMIC temp-alarm devices (pmic@1 through pmic@9, excluding pmic@0 and pmic@7) are stuck in deferred probe because they depend on io-channels from pmk8550_vadc ADC driver, which has not successfully probed; additionally, two benign probe failures exist: qcom_qseecom_uefisecapp probe failed with -EBUSY (device busy, expected when secure app not available) and regulatory.db firmware missing (non-critical WiFi regulatory database).
3. Possible fix: Verify that the pmk8550_vadc ADC driver (qcom,spmi-adc5-gen3) is enabled in the kernel config and that the ADC device node at c42d000.spmi:pmic@0:adc@9000 is present and correctly configured in the device tree; check boot logs for any ADC probe failures or missing dependencies (clocks, regulators, interrupts); if ADC probe is failing, resolve its dependencies first to unblock the temp-alarm devices.
4. Detail analysis attachment: failed_case_job207655_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 required iommus property, preventing IOMMU group attachment; the SMMU test validation logic correctly detected this critical master is not protected by SMMU.
3. Possible fix: Add the missing iommus property to the video-codec@aa00000 node in the x1e80100 (hamoa) device tree file (arch/arm64/boot/dts/qcom/x1e80100.dtsi or board-specific overlay) to bind the video codec to the appropriate SMMU context bank; reference similar Qualcomm SoCs for the correct SMMU stream ID values.
4. Detail analysis attachment: failed_case_job207655_2_detailed.md

  Case 3: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath12k_wifi7_pci driver encounters a QMI DMA allocation failure (7274496 bytes, type 1) during probe on hamoa-evk, but successfully recovers by retrying with a smaller size and completes initialization — WiFi interface (wlP4p1s0) is created and firmware loads successfully. The test framework incorrectly flags this as a failure because it detects the error message in dmesg without verifying the driver's successful recovery.
3. Possible fix: Update the WiFi_Firmware_Driver test script to check for successful driver recovery after DMA allocation warnings — verify that the WiFi interface is created (wlP4p1s0/wlan0 present) and firmware version is logged before marking the test as failed. The current test only pattern-matches error strings without validating final driver state.
4. Detail analysis attachment: failed_case_job207655_3_detailed.md

  Case 4: WiFi_OnOff — Test Infrastructure False Positive

1. Failed case: WiFi_OnOff — Test Infrastructure False Positive
2. Root cause: Test case detects transient WiFi driver DMA allocation warning ("qmi dma allocation failed (7274496 B type 1), will try later with small size") as a failure, but the driver successfully recovered with a smaller allocation size and the WiFi interface became fully operational (wlP4p1s0 created at boot time 12.410137s).
3. Possible fix: Update the WiFi_OnOff test case logic to distinguish between fatal probe failures (driver never recovers, no interface created) and transient warnings with successful recovery (driver retries and succeeds, interface operational). The test should only fail if the WiFi interface is not present or non-functional after boot completes.
4. Detail analysis attachment: failed_case_job207655_4_detailed.md

  Case 5: ** KVM_Driver — Platform Boot Configuration Issue (Kernel Booted at EL1, Not EL2)

1. Failed case: ** KVM_Driver — Platform Boot Configuration Issue (Kernel Booted at EL1, Not EL2)
2. Root cause: ** The hamoa-evk bootloader (UEFI 6.0.260507.BOOT.MXF_UEFI.2.5-00625-HAMOA-1) started the Linux kernel at Exception Level 1 (EL1) instead of Exception Level 2 (EL2). KVM requires the kernel to boot at EL2 to provide ARM virtualization extensions. The kernel correctly detected this condition at boot time ([4.860364] kvm [1]: HYP mode not available) and disabled KVM, causing /dev/kvm to not be created.
3. Possible fix: Configure the hamoa-evk UEFI bootloader to start the Linux kernel at EL2 instead of EL1. This requires updating the UEFI boot configuration or boot stub to enter the kernel at EL2. If the platform firmware does not support booting at EL2, KVM cannot be enabled on this platform and the KVM tests should be excluded from the hamoa-evk test suite.
4. Detail analysis attachment: failed_case_job207655_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: The hamoa-evk platform firmware/bootloader is not booting Linux at EL2 (hypervisor exception level), preventing KVM driver initialization. The CPU hardware supports EL2 features (HCRX_EL2, Enhanced Virtualization Traps detected), but the boot chain does not grant EL2 access to Linux. This is a pre-existing platform configuration issue, not introduced by PR Qcom next staging 7.2 rc7 glymur display #973.
3. Possible fix: This is not a PR-introduced regression and does not require PR changes. To enable KVM on hamoa-evk: (1) Update the bootloader/firmware to boot Linux at EL2 instead of EL1, or (2) Use the hamoa-iot-evk-el2.dtb overlay (x1-el2.dtbo) which is designed for EL2 boot configurations, or (3) Mark KVM tests as expected-fail for hamoa-evk in the LAVA test definition until firmware is updated to support EL2 boot.
4. Detail analysis attachment: failed_case_job207655_6_detailed.md

  Case 7: KVM Infrastructure Test Failure — KVM/Gunyah Hypervisor Conflict

1. Failed case: KVM Infrastructure Test Failure — KVM/Gunyah Hypervisor Conflict
2. Root cause: Gunyah hypervisor is running at EL2 (detected at boot: "Hypervisor cold boot, version: gunyah-mobile-c487961e9"), preventing KVM from accessing HYP mode. KVM requires exclusive EL2 access but cannot claim it when another hypervisor is already present. The kernel reports "kvm [1]: HYP mode not available" and /dev/kvm is never created, causing all KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The hamoa-evk board is configured to boot with Gunyah hypervisor firmware, which is incompatible with KVM host functionality. To enable KVM testing on this platform: (1) Flash a non-Gunyah firmware build that boots Linux directly at EL1 without a hypervisor at EL2, OR (2) Exclude hamoa-evk from KVM test jobs in the CI configuration, as this platform is intended for Gunyah guest VM testing, not KVM host testing. The PR does not introduce this issue — it's a pre-existing platform/test-matrix mismatch.
4. Detail analysis attachment: failed_case_job207655_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM is not available on Hamoa EVK because the platform does not support HYP mode (EL2 virtualization extensions); kernel reports "kvm [1]: HYP mode not available" at boot.
3. Possible fix: Mark KVM tests as expected-to-skip for Hamoa EVK in the LAVA job definition, or exclude Hamoa from KVM test runs; this is a hardware/platform limitation, not a kernel regression.
4. Detail analysis attachment: failed_case_job207655_8_detailed.md

Job 207656 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: PCIe controller at 1c10000.pci probe timeout (-ETIMEDOUT) and regulatory.db firmware load failure (-ENOENT) on qcs8300-ride; these are pre-existing platform/infrastructure issues not introduced by PR Qcom next staging 7.2 rc7 glymur display #973 (which contains only audio/coresight/AEST/display bridge changes unrelated to PCIe or wireless regulatory database).
3. Possible fix: For PCIe timeout: verify PCIe hardware presence, power rails, and clocks on qcs8300-ride board; if hardware is absent or non-functional, suppress this probe failure in the test or mark as expected for this platform configuration. For regulatory.db: install wireless-regdb package in rootfs or suppress this benign firmware load failure (regulatory framework falls back to built-in database).
4. Detail analysis attachment: failed_case_job207656_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) added by PR Qcom next staging 7.2 rc7 glymur display #973 is missing the iommus property in its device tree node, preventing IOMMU group attachment required for DMA protection on qcs8300-ride.
3. Possible fix: Add iommus property to the iris: video-codec@aa00000 device tree node in the PR patch, referencing the appropriate SMMU stream IDs for the video codec hardware on qcs8300.
4. Detail analysis attachment: failed_case_job207656_2_detailed.md

  Case 3: ** USBHost (Hardware/Infrastructure Issue — Not a Kernel Regression)

1. Failed case: ** USBHost (Hardware/Infrastructure Issue — Not a Kernel Regression)
2. Root cause: ** USB host controller (xhci-hcd at 0x0a400000) initialized successfully but reports "USB0 root hub has no ports". The test expects functional USB devices but only detects the root hub (Bus 001 Device 001: ID 1d6b:0002). This indicates the qcs8300-ride board either has no USB host ports physically wired/enabled, the device tree does not describe USB port nodes, or no USB devices are connected in the LAVA lab.
3. Possible fix: Verify qcs8300-ride board hardware in the LAVA lab — confirm USB host ports are present and a USB device (flash drive, keyboard) is physically connected. If the board has no USB host capability, mark this test as "not applicable" for qcs8300-ride. This is NOT a PR Qcom next staging 7.2 rc7 glymur display #973 regression; the PR touches USB bindings documentation and dwc3-qcom driver refactoring but does not modify qcs8300-ride device tree or disable USB ports.
4. Detail analysis attachment: failed_case_job207656_3_detailed.md

  Case 4: ** BT_FW_KMD_Service — Bluetooth Firmware/Driver Initialization Failure

1. Failed case: ** BT_FW_KMD_Service — Bluetooth Firmware/Driver Initialization Failure
2. Root cause: ** Bluetooth HCI device never created on qcs8300-ride; firmware load never attempted despite correct device tree node (qcom,wcn6855-bt at /soc@0/geniqup@9c0000/serial@988000/bluetooth) and loaded kernel drivers (bluetooth, hci_uart, btqca). No firmware files found under /lib/firmware/qca/ or other standard paths, and no kernel log evidence of firmware download attempt (missing "setup on UART is completed", "using rampatch file", "using NVM file" markers). The btqca driver probe likely failed silently due to missing firmware files, or firmware request failed without detailed logging.
3. Possible fix: Verify WCN6855 Bluetooth firmware files (msbtfw*.bin, msnv*.bin or cmbtfw*.bin, cmnv*.bin) are present in the rootfs under /lib/firmware/qca/. If missing, add to the Yocto image recipe: IMAGE_INSTALL:append = " linux-firmware-qca" and rebuild the image. If files are present, enable btqca dynamic debug (echo 'module btqca +p' > /sys/kernel/debug/dynamic_debug/control) and reproduce to capture detailed probe and firmware-load logs, then check for silent probe failures or firmware request errors.
4. Detail analysis attachment: failed_case_job207656_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is expected behavior for the qcs8300-ride platform configuration. To enable KVM testing: (1) reconfigure the platform to boot Linux at EL2 without Gunyah, or (2) exclude KVM tests from the qcs8300-ride test suite, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job207656_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the system is running as a guest under the Gunyah hypervisor (version gunyah-1cb9db980), which occupies EL2. KVM requires direct access to EL2 (hypervisor mode) to create the /dev/kvm device node, but when the kernel runs as a guest VM at EL1, EL2 is not available to it.
3. Possible fix: This is not a PR-introduced regression. The test expectation is incorrect for this platform configuration. Either: (1) Skip KVM tests on qcs8300-ride when running under Gunyah hypervisor, or (2) Use a bare-metal (non-virtualized) boot configuration for qcs8300-ride if KVM testing is required. The test should check for hypervisor presence (/sys/hypervisor/type or paravirt detection) and skip gracefully.
4. Detail analysis attachment: failed_case_job207656_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM kernel module (kvm.ko or kvm-arm.ko) failed to load or initialize, preventing creation of the /dev/kvm device node despite CONFIG_KVM being enabled in the kernel configuration.
3. Possible fix: This is a pre-existing platform/kernel configuration issue unrelated to PR Qcom next staging 7.2 rc7 glymur display #973. The QCS8300 (Monaco) platform requires KVM to be built as a module and loaded at runtime, or requires additional platform-specific KVM enablement (hypervisor support, EL2 mode configuration). Verify: (1) KVM module is present in the rootfs and loaded via modprobe/systemd, (2) the platform firmware/bootloader enables EL2/hypervisor mode, (3) check dmesg for KVM initialization errors during early boot. If KVM support is not yet enabled for QCS8300, this test should be skipped for this platform until KVM enablement work is complete.
4. Detail analysis attachment: failed_case_job207656_7_detailed.md

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

1. Failed case: KVM Test Failure — /dev/kvm not available
2. Root cause: QCS8300 (Monaco) platform does not support KVM/virtualization at EL2; CONFIG_KVM is enabled in the kernel config but the KVM subsystem fails to initialize at boot because the hardware/firmware does not provide the required virtualization extensions or EL2 access, resulting in no /dev/kvm device node creation.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (the PR contains no KVM-related changes). Mark KVM tests as "not applicable" or "skip" for qcs8300-ride in the LAVA test definition, or add a platform-specific gate that skips KVM tests when running on Monaco/QCS8300 targets that lack virtualization support.
4. Detail analysis attachment: failed_case_job207656_8_detailed.md

Job 207657 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Deferred Probe Failure (PMIC temp-alarm devices)

1. Failed case: Probe_Failure_Check — Deferred Probe Failure (PMIC temp-alarm devices)
2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state on lemans-evk, indicating the qpnp-temp-alarm driver or its thermal zone dependency failed to resolve, likely due to missing thermal zone configuration in device tree or driver not loaded.
3. Possible fix: Verify qpnp-temp-alarm driver (CONFIG_QCOM_SPMI_TEMP_ALARM) is enabled and built-in (not module); check lemans-evk device tree for correct thermal-zones node with references to these PMIC temp-alarm devices; if thermal zones are missing, add them following qcom,spmi-temp-alarm.yaml binding; if driver is modular, ensure it loads before thermal framework initialization.
4. Detail analysis attachment: failed_case_job207657_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is missing IOMMU group attachment — the device tree node for the Iris video codec added by this PR does not include the required iommus property, causing the SMMU validation test to fail when checking that critical DMA-capable masters are protected by IOMMU.
3. Possible fix: Add the iommus property to the video codec device tree node in the relevant DTS/DTSI file (glymur.dtsi or lemans.dtsi) to attach the video codec to an appropriate IOMMU group, following the pattern used by other critical masters (UFS, Ethernet, GPU, USB, Display) which all have iommus = <&apps_smmu ...> properties.
4. Detail analysis attachment: failed_case_job207657_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 infrastructure issue — test runner completed normally and signaled <LAVA_TEST_RUNNER EXIT>, but LAVA dispatcher marked the test definition as failed with "Marking unfinished test run as failed". The kernel booted successfully (Linux version 7.2.0-rc7-01513-gfa6c90600f67 present), and 46 out of 48 test cases completed (44 passed, 2 failed: Probe_Failure_Check and smmu). This is not a build load failure, kernel crash, or genuine test regression — it is a LAVA test harness synchronization issue where the dispatcher did not receive expected completion signals despite the test runner exiting cleanly.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate the LAVA test definition for missing or malformed result signals in the test runner exit path. The two failed test cases (Probe_Failure_Check and smmu) should be analyzed separately as they may represent genuine test failures unrelated to the LAVA infrastructure issue.
4. Detail analysis attachment: failed_case_job207657_3_detailed.md

Job 207658 | SoC kaanapali-mtp

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

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

  Case 1: ** Remoteproc State Expectation Mismatch — Test Infrastructure Gap

1. Failed case: ** Remoteproc State Expectation Mismatch — Test Infrastructure Gap
2. Root cause: ** The remoteproc test expects all remoteprocs to be in "running" state, but remoteproc0 (soccp) is correctly in "attached" state because it is a late-attach remoteproc that was already started by the bootloader. The PR introduces soccp-pas support for kaanapali-mtp, adding a new remoteproc device that operates in attach mode, but the test infrastructure was not updated to handle this valid state.
3. Possible fix: Update the remoteproc test script to accept "attached" as a valid state for remoteproc0 (soccp) on kaanapali-mtp and other platforms where soccp is pre-started by firmware. The test should check that soccp is in "attached" state (not "running") and that other remoteprocs (adsp, cdsp) are in "running" state as expected.
4. Detail analysis attachment: failed_case_job207658_1_detailed.md

  Case 2: PCIe

1. Failed case: PCIe
2. Root cause: Test infrastructure issue — PCIe hardware is functional (link up Gen.3 x2, devices enumerated at 0000:00:00.0 and 0000:01:00.0), but test script validation logic fails because: (1) DT node pattern check doesn't match kaanapali-mtp's PCIe node structure, (2) lspci "Capabilities:" output check fails (tool may be missing or output format unexpected), (3) driver loaded check uses wrong pattern (qcom-pcie driver IS loaded and functional). This is not a kernel functional regression; PCIe subsystem works correctly.
3. Possible fix: Update the PCIe test script for kaanapali-mtp platform: (1) adjust DT node search pattern to match /soc@0/pcie@1c00000, (2) verify lspci tool is installed in test rootfs and update output parsing logic, (3) fix driver detection to check for qcom-pcie module or verify via /sys/bus/pci/devices presence instead of incorrect driver name pattern.
4. Detail analysis attachment: failed_case_job207658_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: USB controller (a600000.usb) forced into gadget mode due to device tree configuration mismatch; kernel log shows "Configuration mismatch. dr_mode forced to gadget" preventing USB host functionality and device enumeration on kaanapali-mtp.
3. Possible fix: The PR removes dr_mode = "peripheral" from board DTS files but the base kaanapali.dtsi likely still defines dr_mode = "gadget" or the dwc3-qcom driver defaults to gadget mode; verify the base dtsi defines dr_mode = "host" or dr_mode = "otg" for the USB controller node to enable host mode functionality.
4. Detail analysis attachment: failed_case_job207658_3_detailed.md

  Case 4: ** BT_FW_KMD_Service

1. Failed case: ** BT_FW_KMD_Service
2. Root cause: ** Bluetooth firmware loading timeout on kaanapali-mtp (WCN7850 chip) — HCI command 0xfc00 (TLV segment transfer) times out with error -110 (ETIMEDOUT) during qca/hmtbtfw20.tlv firmware download, preventing controller initialization. The failure occurs after successful hardware detection and version read, indicating a communication breakdown during firmware transfer. PR Qcom next staging 7.2 rc7 glymur display #973 modifies drivers/bluetooth/btqca.c firmware download flow, likely introducing a regression affecting WCN7850 despite QCC2072-specific conditionals.
3. Possible fix: Revert or isolate the firmware download flow changes in drivers/bluetooth/btqca.c introduced by PR Qcom next staging 7.2 rc7 glymur display #973, specifically reviewing the qca_download_firmware() function for unintended side effects on non-QCC2072 chips. Verify that memory allocation/deallocation, error handling, and timing in the firmware transfer path remain unchanged for WCN7850. Test firmware loading on kaanapali-mtp with and without the PR changes to confirm regression.
4. Detail analysis attachment: failed_case_job207658_4_detailed.md

  Case 5: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: The ath12k_pci and ath12k_ahb kernel modules are not built or included in the kernel image for kaanapali-mtp (WCN7850 WiFi 7 platform). The PCI device (17cb:110e) is successfully enumerated on the PCIe bus at 1c00000.pcie, but no driver binds to it because the required ath12k_pci module is missing from /lib/modules/7.2.0-rc7-01513-gfa6c90600f67/kernel/drivers/net/wireless/ath/ath12k/.
3. Possible fix: Enable CONFIG_ATH12K_PCI=m (or =y) in the kernel configuration for kaanapali-mtp builds. The WCN7850 WiFi device on this platform requires the ath12k_pci driver to bind to the PCIe-attached WiFi hardware. Verify the fix by confirming ath12k_pci.ko is present in the modules directory and that dmesg shows "ath12k_pci" probe messages after boot.
4. Detail analysis attachment: failed_case_job207658_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize because Linux is running at EL1 under the Gunyah hypervisor (running at EL2). KVM requires the kernel to run at EL2 to provide hypervisor functionality, but EL2 is already occupied by Gunyah. This is a platform configuration issue, not a kernel bug.
3. Possible fix: This is not a bug to fix - it's expected behavior. KVM and Gunyah hypervisor are mutually exclusive. To enable KVM testing on kaanapali-mtp, the platform must be configured to boot Linux directly at EL2 without the Gunyah hypervisor. Alternatively, update the test suite to skip KVM tests when a hypervisor is detected (check for EL1 boot or hypervisor presence in dmesg).
4. Detail analysis attachment: failed_case_job207658_6_detailed.md

  Case 7: KVM_EL2_DTB — KVM Device Node Not Available

1. Failed case: KVM_EL2_DTB — KVM Device Node Not Available
2. Root cause: KVM driver initialization failed because HYP (EL2) mode is not available on this platform. The kaanapali-mtp board is running with Gunyah hypervisor, which means Linux is executing as a guest VM at EL1, not at EL2. KVM requires direct access to EL2 to create and manage virtual machines, which is not possible when Linux itself is running as a guest under another hypervisor.
3. Possible fix: This is a test environment configuration issue, not a PR-introduced regression. The KVM tests should be skipped or marked as "not applicable" for platforms running under a hypervisor. To enable KVM functionality, the board would need to boot Linux directly at EL2 without the Gunyah hypervisor, or use nested virtualization if supported. For CI purposes, add a platform capability check to skip KVM tests on hypervisor-hosted configurations.
4. Detail analysis attachment: failed_case_job207658_7_detailed.md

  Case 8: KVM_Infra (and KVM_Driver, KVM_EL2_DTB)

1. Failed case: KVM_Infra (and KVM_Driver, KVM_EL2_DTB)
2. Root cause: KVM tests fail because kaanapali-mtp platform does not support ARM virtualization extensions (EL2/HYP mode); kernel logs show "kvm [1]: HYP mode not available" at boot, and all three KVM test cases (KVM_Driver, KVM_EL2_DTB, KVM_Infra) report "/dev/kvm is not available" despite CONFIG_KVM being enabled in the kernel configuration.
3. Possible fix: Exclude KVM tests from the kaanapali-mtp LAVA test suite, as this platform does not have hardware virtualization support; alternatively, mark these tests as "expected to skip" for platforms without EL2 capability by checking for HYP mode availability before running KVM tests.
4. Detail analysis attachment: failed_case_job207658_8_detailed.md

  Case 9: 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: Suppress KVM tests on Qualcomm platforms with Gunyah hypervisor (Kaanapali, Glymur, Hamoa families). Add platform detection logic to the LAVA test suite: if Gunyah hypervisor is detected in boot logs (grep "Hypervisor cold boot, version: gunyah"), skip KVM tests with result=skip and reason="Platform runs Gunyah hypervisor — KVM unavailable by design". Alternatively, if KVM support is required, boot the platform without Gunyah (requires firmware/bootloader configuration change to disable hypervisor, which may break secure VM features).
4. Detail analysis attachment: failed_case_job207658_9_detailed.md

Job 207659 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test case detected three firmware load failures during boot: regulatory.db (cfg80211), renesas_usb_fw.mem (xhci-pci-renesas), and modem.mbn (remoteproc0). All three are benign, platform-expected failures not introduced by PR Qcom next staging 7.2 rc7 glymur display #973. Modem is intentionally disabled on qcs6490-rb3gen2 ("Skipping modem subsystem on Kodiak platform"), regulatory.db is optional (WiFi functional without it), and the Renesas USB controller firmware may not be required for this board variant.
3. Possible fix: Update the Probe_Failure_Check test to suppress these three known-benign firmware load failures for qcs6490-rb3gen2 platform. Add platform-specific exclusion rules: (1) modem.mbn for qcs6490 (modem not supported), (2) regulatory.db (optional cfg80211 file), (3) renesas_usb_fw.mem (optional PCIe USB controller). Alternatively, package these firmware files in the rootfs if the hardware is present and should be functional.
4. Detail analysis attachment: failed_case_job207659_1_detailed.md

  Case 2: USBHost — Test Infrastructure Limitation (No External USB Devices Connected)

1. Failed case: USBHost — Test Infrastructure Limitation (No External USB Devices Connected)
2. Root cause: The USBHost test expects external USB devices to be physically connected to the qcs6490-rb3gen2 board's USB host ports for enumeration. The test failure "No USB devices found" indicates no external USB devices (hubs, storage, peripherals) are connected to the board in the LAVA lab setup. The on-SoC USB controller (a600000.usb) is present and added to IOMMU group 8, but the PCIe-attached Renesas xHCI controller (0001:04:00.0) failed to probe due to missing firmware (renesas_usb_fw.mem, error -2). However, the primary cause of test failure is the absence of any enumerated USB devices on the bus, not a kernel driver regression.
3. Possible fix: This is a test environment configuration issue, not a kernel bug introduced by PR Qcom next staging 7.2 rc7 glymur display #973. The PR contains USB-related changes (dwc3-qcom driver updates, USB PHY bindings, USB connector bindings) but none that would prevent USB host enumeration. To resolve: (1) Connect a USB device (hub, storage, or keyboard) to the board's USB host port in the LAVA lab setup, or (2) Mark this test as SKIP when no external USB hardware is available, or (3) Modify the test to verify USB controller presence and readiness instead of requiring enumerated devices. The Renesas xHCI firmware issue is a separate pre-existing problem (missing firmware file in rootfs) and does not affect the on-SoC USB controller.
4. Detail analysis attachment: failed_case_job207659_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: Suppress KVM tests on Gunyah-enabled platforms. Add platform detection in the test suite: check for Gunyah hypervisor presence (dmesg | grep "Hypervisor cold boot") and skip KVM tests with message "KVM not available on Gunyah-enabled platform (architectural conflict)". This is not a PR-introduced regression but a pre-existing platform configuration where qcs6490-rb3gen2 runs Gunyah virtualization, making KVM unavailable by design.
4. Detail analysis attachment: failed_case_job207659_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM unavailable (expected: system running under Gunyah hypervisor)

1. Failed case: KVM_EL2_DTB — KVM unavailable (expected: system running under Gunyah hypervisor)
2. Root cause: The qcs6490-rb3gen2 board is running as a guest under the Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-1cb9db980 perf" and kernel message "kvm [1]: HYP mode not available"). When Linux runs as a guest VM under a hypervisor, the CPU is not in EL2/HYP mode, so KVM cannot initialize and /dev/kvm is not created. This is expected architectural behavior, not a kernel defect.
3. Possible fix: This is not a kernel bug. The KVM_EL2_DTB test should be skipped or marked as "not applicable" when the target is running under a hypervisor. To enable KVM on this platform, the system must boot without a hypervisor (bare-metal EL2 mode). The PR changes (adding EL2 device tree overlays for qcs6490-rb3gen2) are unrelated to this test failure — the failure occurs because the LAVA job flashed a Gunyah-based image, not because of the PR's device tree changes.
4. Detail analysis attachment: failed_case_job207659_4_detailed.md

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

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** The qcs6490-rb3gen2 (Kodiak) platform bootloader does not boot the kernel in ARM EL2 (Hypervisor) mode, which is required for KVM virtualization support. The KVM driver detects this at initialization and exits cleanly with "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on this board: (1) Update the bootloader (ABL/UEFI) configuration to boot the kernel in EL2 mode, OR (2) If the platform does not support EL2 (TrustZone restrictions or hardware limitations), disable CONFIG_KVM in the kernel config for this target to avoid false test failures, OR (3) Mark KVM tests as "expected skip" for qcs6490-rb3gen2 in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job207659_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM device node /dev/kvm not created despite CONFIG_KVM=y — KVM driver did not initialize or create the character device, likely due to missing KVM ARM host support (CONFIG_KVM_ARM_HOST not enabled) or EL2/VHE not available on qcs6490-rb3gen2 platform.
3. Possible fix: Enable CONFIG_KVM_ARM_HOST in kernel config if the platform supports EL2/VHE; if the SoC does not support virtualization extensions, mark KVM tests as expected-fail or skip them in the LAVA job definition for qcs6490-rb3gen2.
4. Detail analysis attachment: failed_case_job207659_6_detailed.md

Job 207660 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — regulatory.db firmware load failure

1. Failed case: Probe_Failure_Check — regulatory.db firmware load failure
2. Root cause: The cfg80211 wireless regulatory subsystem failed to load the regulatory.db firmware file (error -2: ENOENT) during boot. This is a known benign failure on qcs615-ride because the regulatory database is compiled into the kernel via X.509 certificates (evidenced by "Loading compiled-in X.509 certificates for regulatory database" and successful cert loading). WiFi functionality is unaffected — WiFi_Firmware_Driver and WiFi_OnOff tests both passed, confirming ath11k driver loaded successfully and WiFi interface (wlp1s0) is operational.
3. Possible fix: This is a false positive test failure. The Probe_Failure_Check test should be updated to exclude regulatory.db firmware load failures when CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y and compiled-in X.509 regulatory certificates are present. No kernel or PR changes required — this is a test infrastructure issue. The PR (which adds AEST/STP documentation and device tree changes) is not related to this failure.
4. Detail analysis attachment: failed_case_job207660_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expects child video codec devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be independently attached to IOMMU groups, but the qcom-venus driver on qcs615-ride creates only the parent device (aa00000.video-codec) which is correctly attached to IOMMU group 6. The child devices are logical software constructs (V4L2 video nodes) that do not require separate IOMMU group attachments.
3. Possible fix: Update the SMMU test expectations for qcs615-ride to reflect the correct video codec driver architecture where only the parent platform device requires IOMMU attachment. The test should verify that aa00000.video-codec is attached (which passes) and should not expect separate IOMMU attachments for the logical video-decoder/video-encoder child devices.
4. Detail analysis attachment: failed_case_job207660_2_detailed.md

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

1. Failed case: KVM_Driver — /dev/kvm unavailable (HYP mode not available)
2. Root cause: KVM driver initialization failed because the system is running under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-1cb9db980 perf"), which reserves EL2 (HYP mode) for itself. The kernel KVM driver logged "kvm [1]: HYP mode not available" during early boot, preventing /dev/kvm creation. This is a platform configuration issue specific to qcs615-ride running in virtualized mode, not a kernel regression introduced by the PR.
3. Possible fix: This is expected behavior on qcs615-ride when booted with Gunyah hypervisor active. To enable KVM testing: (1) boot the kernel in non-virtualized mode (disable Gunyah in bootloader/firmware configuration), or (2) skip KVM tests on this platform configuration, or (3) use nested virtualization if supported by the Gunyah hypervisor version. The PR does not introduce this failure — it is a pre-existing platform/test-environment mismatch.
4. Detail analysis attachment: failed_case_job207660_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 bug requiring a fix - it is the correct behavior for the platform configuration. To enable KVM testing on QCS615: (1) Use a non-virtualized boot configuration without Gunyah hypervisor, OR (2) Skip KVM tests on Gunyah-enabled platforms by adding a platform-specific test filter in the LAVA job definition that excludes Virtualization/KVM test suite when Gunyah is detected at boot.
4. Detail analysis attachment: failed_case_job207660_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: qcs615-ride platform does not support ARM EL2 (hypervisor mode), which is a mandatory hardware prerequisite for KVM on ARM64; kernel correctly detects missing HYP mode and fails KVM initialization with "HYP mode not available" at boot.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. To enable KVM testing: (1) use a platform with EL2 support (e.g., rb5, rb3gen2, sa8775p), or (2) exclude KVM tests from qcs615-ride CI jobs, or (3) if EL2 is expected to be available, verify bootloader/firmware configuration enables EL2 and does not trap to EL1.
4. Detail analysis attachment: failed_case_job207660_5_detailed.md

  Case 6: KVM_EL2_DTB (and KVM_Infra)

1. Failed case: KVM_EL2_DTB (and KVM_Infra)
2. Root cause: QCS615 Ride platform does not support KVM virtualization — kernel reports "HYP mode not available" during boot, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The test should be skipped on QCS615 or the platform should be configured with hypervisor support if available. No kernel fix required.
4. Detail analysis attachment: failed_case_job207660_6_detailed.md

Job 207661 | SoC qcs9100-ride

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

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

  Case 1: login-action

1. Failed case: login-action
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the interconnects property to the SMMU node at 15000000.iommu in the qcs9100/lemans device tree, specifying the interconnect path to the SMMU register space, and ensure the interconnect driver votes for bandwidth before SMMU probe attempts register access.
4. Detail analysis attachment: failed_case_job207661_1_detailed.md

  Case 2: Kernel Crash — Synchronous External Abort during SMMU S2CR register write

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU S2CR register write
2. Root cause: The PR introduces interconnect bandwidth voting for SMMU register access (arm_smmu_icc_enable) but the qcs9100-ride device tree does not include the required interconnect path property. When the SMMU driver attempts to write to S2CR registers at probe time without an active interconnect vote, the hardware blocks the access, triggering a synchronous external abort at qcom_smmu_write_s2cr+0x84.
3. Possible fix: Add the missing interconnects property to the SMMU node in arch/arm64/boot/dts/qcom/qcs9100-ride.dts, referencing the appropriate interconnect path to the SMMU register space. The binding requires this property for SoCs where SMMU registers are only accessible after bandwidth vote. If the interconnect provider is not yet available for qcs9100, the driver's arm_smmu_icc_get() should be updated to treat -EPROBE_DEFER gracefully and defer probe until the interconnect is ready.
4. Detail analysis attachment: failed_case_job207661_2_detailed.md

  Case 3: Kernel Crash — Synchronous External Abort during SMMU Initialization

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU Initialization
2. Root cause: The kernel panicked with a synchronous external abort (hardware fault) at PC qcom_smmu_write_s2cr+0x84/0x138 during SMMU (15000000.iommu) probe and S2CR register write. The fault occurred when the SMMU driver attempted to write to an SMMU hardware register that either does not exist, is not accessible, or is powered down on the qcs9100-ride platform. This is a hardware access fault, not a software bug in the PR changes.
3. Possible fix: Verify that the SMMU hardware at address 0x15000000 is correctly powered and clocked on qcs9100-ride. Check the device tree for this SoC to ensure the SMMU node has correct power-domain, clock, and register range properties. If the hardware is not present or not accessible on this board variant, the SMMU node should be disabled in the qcs9100-ride device tree with status = "disabled";. This is a platform-specific hardware configuration issue, not introduced by PR Qcom next staging 7.2 rc7 glymur display #973.
4. Detail analysis attachment: failed_case_job207661_3_detailed.md

  Case 4: Kernel Crash — Synchronous External Abort during SMMU S2CR register write

1. Failed case: Kernel Crash — Synchronous External Abort during SMMU S2CR register write
2. Root cause: Hardware access fault (synchronous external abort ESR 0x96000010) when writing to SMMU S2CR register at offset 0xc28 during SMMU device probe on qcs9100-ride; the SMMU register space at physical address corresponding to ffff800084500000 + 0xc28 is either not mapped, not powered, or not accessible at this boot stage
3. Possible fix: Verify SMMU power domain and interconnect dependencies are satisfied before SMMU probe; add explicit power-on and interconnect bandwidth request in qcom-smmu driver probe before accessing SMMU registers; check qcs9100 DT for correct SMMU power-domain and interconnect-path bindings
4. Detail analysis attachment: failed_case_job207661_4_detailed.md

Job 207662 | SoC sm8750-mtp

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

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

  Case 1: Probe_Failure_Check (Suppressed — Known Benign Firmware Load Failures)

1. Failed case: Probe_Failure_Check (Suppressed — Known Benign Firmware Load Failures)
2. Root cause: The test detected two firmware load failures during boot: regulatory.db (cfg80211 wireless regulatory database) and qca/hmtnv20.b2c (Qualcomm Bluetooth NVM configuration). However, both WiFi (WiFi_OnOff PASS) and Bluetooth (BT_ON_OFF PASS) functional tests passed, confirming that the drivers loaded alternative firmware files successfully and the hardware is fully operational. These are known false positives where the test probes firmware state before driver initialization completes.
3. Possible fix: No action required. Per LAVA Known Benign Failure Suppression Rules (Rule 2 & 3), firmware load failures are suppressed when the corresponding functional ON/OFF tests pass. The Probe_Failure_Check test should be updated to apply these suppression rules before reporting failures, or the test should be configured to ignore -ENOENT (-2) errors for optional firmware files that have fallback mechanisms.
4. Detail analysis attachment: failed_case_job207662_1_detailed.md

  Case 2: PCIe

1. Failed case: PCIe
2. Root cause: Test script false positive — PCIe hardware is fully functional (Gen.2 x2 link up, devices enumerated at 0000:00:00.0 and 0000:01:00.0, BARs assigned), but test script reports failure due to incorrect validation logic checking for DT node presence, "Capabilities:" string in lspci output, or driver load status that don't match sm8750-mtp's actual PCIe configuration.
3. Possible fix: Update the PCIe test script validation logic to correctly detect PCIe functionality on sm8750-mtp by checking for successful link-up messages ("PCIe Gen.2 x2 link up"), enumerated PCI devices in /sys/bus/pci/devices/, or successful BAR assignments in dmesg, rather than relying on DT node checks or lspci "Capabilities:" string matching that may not apply to this platform's PCIe implementation.
4. Detail analysis attachment: failed_case_job207662_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure dependency — no USB devices physically connected to the sm8750-mtp board's USB host ports during test execution.
3. Possible fix: This is not a kernel regression introduced by PR Qcom next staging 7.2 rc7 glymur display #973. The test failure is due to missing test hardware (USB devices) in the LAVA lab setup for sm8750-mtp. Either: (1) connect USB test devices to the board's USB host ports, or (2) mark this test as SKIP for sm8750-mtp until USB host hardware is available in the lab, or (3) suppress this known infrastructure limitation in the CI configuration.
4. Detail analysis attachment: failed_case_job207662_3_detailed.md

  Case 4: ** KVM_Driver (Test Environment Configuration Issue)

1. Failed case: ** KVM_Driver (Test Environment Configuration Issue)
2. Root cause: ** KVM cannot initialize because the system is running as a guest under the Gunyah hypervisor (version gunyah-mobile-1dda77727). KVM requires exclusive EL2 (hypervisor mode) access to create /dev/kvm, which is unavailable when Linux runs as a guest VM. CONFIG_KVM is enabled in the kernel, but the KVM subsystem cannot initialize in this nested virtualization scenario.
3. Possible fix: This is not a kernel bug or PR-introduced regression. To enable KVM testing on sm8750-mtp, either: (1) boot the kernel directly on bare metal without Gunyah hypervisor, or (2) if Gunyah is required for the platform, skip KVM tests in the LAVA job definition for this target, as nested virtualization is not supported in this configuration.
4. Detail analysis attachment: failed_case_job207662_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the SM8750-MTP system is running as a guest under Gunyah hypervisor (gunyah-mobile-1dda77727), which prevents the kernel from accessing EL2 (hypervisor mode) required to create /dev/kvm; nested virtualization is not supported or not enabled in this configuration.
3. Possible fix: This is expected behavior, not a bug. To enable KVM testing on SM8750-MTP: (1) boot the kernel directly on bare metal without Gunyah hypervisor, OR (2) if Gunyah nested virtualization support exists, enable it in the hypervisor configuration and rebuild the firmware. If KVM testing is not required for this platform configuration, mark KVM_EL2_DTB as "skip" or "not applicable" for Gunyah-based test runs.
4. Detail analysis attachment: failed_case_job207662_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver did not initialize because the SM8750-MTP platform is running under the Gunyah hypervisor (gunyah-mobile-1dda77727). KVM requires direct access to EL2 (hypervisor mode) and cannot operate as a nested hypervisor when another hypervisor (Gunyah) is already running at EL2. CONFIG_KVM is enabled in the kernel configuration, but /dev/kvm device node is not created because kvm_arm_init() detects the presence of an existing hypervisor and aborts initialization.
3. Possible fix: This is expected behavior, not a regression. KVM tests should be skipped on platforms configured to run under Gunyah hypervisor. Update the CI test suite to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor/type) and skip KVM tests when running as a guest under another hypervisor. Alternatively, if KVM functionality is required, reconfigure the platform to boot without Gunyah hypervisor (requires bootloader/firmware changes to disable Gunyah and allow Linux to run at EL1 with direct EL2 access).
4. Detail analysis attachment: failed_case_job207662_6_detailed.md

  Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM /dev/kvm device node not created because the kernel is running as a guest under the Gunyah hypervisor (reserved memory region gunyah-hyp@80000000 present), which prevents KVM from accessing EL2 hypervisor mode required for virtualization. CONFIG_KVM is enabled but KVM driver cannot initialize without EL2 access.
3. Possible fix: This is expected behavior on SM8750-MTP when running under Gunyah hypervisor - KVM tests should be skipped or marked as not applicable for guest VM configurations. To enable KVM, the kernel must run directly on hardware (host mode) without an underlying hypervisor, or nested virtualization support must be enabled in Gunyah (if available).
4. Detail analysis attachment: failed_case_job207662_7_detailed.md

Job 207663 | SoC monaco-evk

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

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

  Case 1: System Hang During Boot — login-action timeout (board reset before userspace login)

1. Failed case: System Hang During Boot — login-action timeout (board reset before userspace login)
2. Root cause: Monaco-evk board experienced a silent hang or watchdog reset approximately 7.5 seconds into kernel boot, after PCIe controller initialization began but before userspace login prompt appeared; board automatically reset ~55 seconds later as evidenced by bootloader messages reappearing at 13:21:22 (last kernel message at 13:20:27); no kernel panic, oops, or error messages logged before the hang.
3. Possible fix: This is likely a PR-introduced regression in PCIe, remoteproc, or related subsystem drivers modified in PR Qcom next staging 7.2 rc7 glymur display #973; bisect the PR commits focusing on drivers/pci/controller/dwc/pcie-qcom.c, drivers/remoteproc/qcom_q6v5_pas.c, and related Qualcomm platform drivers; check for watchdog configuration changes or infinite loops/deadlocks in probe paths; enable additional debug (earlycon, watchdog bark logging) and reproduce to capture the hang point.
4. Detail analysis attachment: failed_case_job207663_1_detailed.md

  Case 2: Board Hang — Silent system freeze after successful kernel boot

1. Failed case: Board Hang — Silent system freeze after successful kernel boot
2. Root cause: System hung silently after completing kernel boot initialization (last kernel message at 13:20:27 showing successful PCIe/UFS/remoteproc init); no console output for 55 seconds until watchdog or platform reset triggered reboot at 13:21:22. No kernel crash signature (panic/oops/BUG) present. Likely cause: critical subsystem wedge (interrupt routing, interconnect, or secure firmware stall) preventing userspace init from starting, or init process hung before reaching login prompt on monaco-evk.
3. Possible fix: Enable watchdog bark/bite logging and pstore/ramoops to capture pre-reset state. Add early console debugging (earlycon) and initcall_debug to kernel command line to identify where boot process stalls. Check if init binary is present and executable in rootfs. If issue reproduces, capture SDI/JTAG dump at hang time to identify CPU state and blocked tasks. Verify monaco-evk-specific drivers (especially those probed late in boot) are not causing a deadlock or infinite loop.
4. Detail analysis attachment: failed_case_job207663_2_detailed.md

  Case 3: Board Hang — Login Timeout After Successful Boot

1. Failed case: Board Hang — Login Timeout After Successful Boot
2. Root cause: System hung silently after kernel initialization completed (last kernel message at 7.5s), preventing userspace from reaching the login prompt; watchdog reset triggered after ~55 seconds indicating complete loss of forward progress.
3. Possible fix: This appears to be a pre-existing infrastructure or board-specific issue unrelated to the PR changes (audio subsystem modifications). Re-trigger the CI job to confirm reproducibility. If the hang persists, enable watchdog debug (CONFIG_SOFTLOCKUP_DETECTOR, CONFIG_DETECT_HUNG_TASK) and collect SDI/ramdump to identify which subsystem or driver initialization is blocking. Check for known monaco-evk boot hangs in the issue tracker.
4. Detail analysis attachment: failed_case_job207663_3_detailed.md

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

1. Failed case: ** Complete System Hang — Boot freeze during PCIe initialization
2. Root cause: ** Monaco-evk board hangs during boot at PCIe controller (1c00000.pci) iATU configuration. System stops making forward progress after last kernel message at timestamp 7.555 seconds. No crash, panic, or error messages — the system simply stops responding. LAVA login-action times out after 200 seconds across 3 retry attempts with no console output.
3. Possible fix: Re-trigger the CI job to rule out transient hardware/lab infrastructure issue. If the hang reproduces, bisect PR Qcom next staging 7.2 rc7 glymur display #973 to identify the specific commit causing the PCIe initialization hang. Check for changes affecting PCIe driver probe order, interrupt routing, or device tree bindings for qcom-pcie on monaco/qcs8300 platforms. As a workaround, disable PCIe in the device tree (status = "disabled" for pci@1c00000 and pci@1c10000 nodes) to allow boot to proceed for testing other functionality.
4. Detail analysis attachment: failed_case_job207663_4_detailed.md