BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0

[mohitdsor]

The commit fixed bonded DSI mode but broke non-bonded DSI: clock divider
is programmed incorrectly, resulting in wrong display mode being selected.

Revert the offending commit, letting Neil Armstrong work on a proper fix
that handles both bonded and non-bonded cases.

Fixes: 93c97bc ("drm/msm: dsi: fix PLL init in bonded mode")
Reported-by: Mohit Dsor mohit.dsor@oss.qualcomm.com
Closes: https://lore.kernel.org/r/ae07cef84AmXK43H@hu-mdsor-hyd.qualcomm.com

PR for 0.0 -> https://github.com/qualcomm-linux/kernel-topics/pull/1623/commits

CRs-fixed: 4364171

[qcomlnxci]

Test jobs on 810b701

• multimedia Job 207622 on hamoa-iot-evk
• multimedia Job 207624 on lemans-evk
• multimedia Job 207618 on monaco-evk
• multimedia Job 207623 on purwa-iot-evk
• multimedia Job 207619 on qcs615-ride
• multimedia Job 207621 on qcs6490-rb3gen2
• multimedia Job 207617 on qcs8300-ride
• multimedia Job 207620 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 207616 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	◻️
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	◻️
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	✅ Pass	◻️
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #885

Job 207616 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug at line 75 — incorrect parsing of /proc/interrupts output causes the script to attempt integer comparison on non-numeric fields ("GICv3", "Level", "arch_timer") when checking for non-existent CPUs 4-7 on a 4-CPU system (shikra-iqs-evk has only CPUs 0-3).
3. Possible fix: Update the GIC test script to correctly detect the number of online CPUs before parsing /proc/interrupts, or fix the awk/parsing logic at line 75 to handle the interrupt descriptor format correctly and skip non-existent CPU columns.
4. Detail analysis attachment: failed_case_job207616_1_detailed.md

  Case 2: Remoteproc Boot Failure — modem subsystem (remoteproc0)

1. Failed case: Remoteproc Boot Failure — modem subsystem (remoteproc0)
2. Root cause: remoteproc0 (modem subsystem with firmware qcom/shikra/cqs/qdsp6sw.mbn) remains in 'offline' state and was never automatically started during boot, while remoteproc1 (cdsp) and remoteproc2 (lpaicp) both booted successfully to 'running' state. The modem subsystem is detected (remoteproc remoteproc0: modem is available at boot time 6.126s) but no automatic boot attempt is logged, indicating either: (1) the modem subsystem is configured for manual start only on this platform/build, or (2) a platform-specific dependency (clock/regulator/power-domain/DT configuration) prevents automatic boot. This is a pre-existing platform/configuration issue, not introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which only touches drm/msm DSI PHY code unrelated to remoteproc).
3. Possible fix: Verify the device tree configuration for the modem remoteproc node on shikra-iqs-evk — confirm whether qcom,auto-boot property is present and set correctly. If modem is intentionally configured for manual start on this platform, update the LAVA test expectation to match (either manually start modem before the test, or mark remoteproc0 as expected 'offline'). If modem should auto-boot, check for missing clocks, regulators, power-domains, or memory-region bindings in the DT that would prevent automatic initialization, and compare with a known-good reference platform DT.
4. Detail analysis attachment: failed_case_job207616_2_detailed.md

  Case 3: ** Probe_Failure_Check — Pre-existing Platform Configuration Issues (Not PR-Introduced)

1. Failed case: ** Probe_Failure_Check — Pre-existing Platform Configuration Issues (Not PR-Introduced)
2. Root cause: ** The test detected 6 probe/firmware errors that are pre-existing platform/DT/firmware configuration issues on shikra-iqs-evk, unrelated to the PR changes (DSI PHY PLL revert in drivers/gpu/drm/msm/dsi/phy/). Errors: (1) regulatory.db firmware missing (-ENOENT), (2) cpufreq-dt probe collision (-EEXIST, benign), (3-6) deferred probes for audio codec, sound card, I2C device, and WiFi due to missing DT clock/regulator/DAI resources.
3. Possible fix: Mark this test case as expected-fail or suppress these specific errors in the Probe_Failure_Check test filter for shikra-iqs-evk until the platform DT and firmware packaging are corrected. The PR itself is not the cause and should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job207616_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controller on shikra-iqs-evk is configured in gadget (device) mode rather than host mode; no USB host controller driver (dwc3-qcom/xhci-hcd) probed during boot, preventing USB host device enumeration. The test expects USB host functionality but the device tree or kernel configuration has USB in peripheral/gadget mode only. This is a board/test infrastructure configuration issue, not a kernel regression introduced by the PR (which only modifies DSI display driver code).
3. Possible fix: Verify the shikra-iqs-evk device tree USB node configuration and ensure the USB controller is configured for host or dual-role (OTG) mode with dr_mode = "host" or "otg". If the board hardware does not support USB host mode, mark this test as SKIP for this platform in the LAVA test definition. This is not a PR-introduced issue and does not block the PR.
4. Detail analysis attachment: failed_case_job207616_4_detailed.md

  Case 5: ** BT_SCAN (Test Environment Issue — No Discoverable Devices)

1. Failed case: ** BT_SCAN (Test Environment Issue — No Discoverable Devices)
2. Root cause: ** The BT_SCAN test failed because no discoverable Bluetooth devices were present in the physical environment surrounding the shikra-iqs-evk board during test execution. The Bluetooth stack is fully functional (BT_ON_OFF passed, hci0 operational, firmware loaded), but the scan returned zero devices across all retry attempts because the LAVA lab environment lacks nearby Bluetooth devices in discoverable mode.
3. Possible fix: This is NOT a kernel regression. The PR changes DSI/DRM code unrelated to Bluetooth. To resolve: (1) Place a discoverable Bluetooth device (phone, speaker, or beacon) within range of the shikra-iqs-evk board in the LAVA lab, OR (2) Mark BT_SCAN as an optional/informational test that does not block PR merges when the lab environment has no BT devices, OR (3) Deploy a dedicated Bluetooth beacon in the lab rack for consistent scan test coverage.
4. Detail analysis attachment: failed_case_job207616_5_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng
2. Root cause: ** The qcom_rng driver encountered a synchronous external abort (bus error) when attempting to read from the hardware RNG MMIO registers during the qcom_hwrng test. This indicates the RNG hardware block was not accessible (likely unpowered, unclocked, or in reset) at the time of access. This is a pre-existing platform/firmware configuration issue on the Shikra IQS EVK, not a regression introduced by the PR (which only modifies DSI display driver code).
3. Possible fix: This is not a PR-introduced issue. The PR should not be blocked by this failure. For the platform team: investigate why the RNG hardware is not accessible on Shikra IQS EVK — check power domain, clock enablement, and reset state for the RNG block. As a workaround, skip the qcom_hwrng test on this platform until the hardware access issue is resolved.
4. Detail analysis attachment: failed_case_job207616_6_detailed.md

  Case 7: Kernel Crash — synchronous external abort in qcom_rng driver during qcom_hwrng test, followed by failed warm reboot recovery causing LAVA timeout

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver during qcom_hwrng test, followed by failed warm reboot recovery causing LAVA timeout
2. Root cause: The qcom_rng driver triggered a synchronous external abort (hardware bus fault) at PC qcom_rng_read+0xc4 when attempting to read from the hardware RNG registers. The kernel panicked and attempted a warm reboot, but the board became stuck in the bootloader (XBL ramdump mode) and never returned to Linux, causing LAVA to timeout after 40 minutes. This is a pre-existing hardware/driver issue on shikra-iqs-evk, not introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which only modifies DSI PHY code unrelated to RNG).
3. Possible fix: This is a known hardware/driver stability issue on shikra-iqs-evk with the qcom_rng driver. Short-term: Skip the qcom_hwrng test on shikra-iqs-evk in the LAVA test definition. Long-term: Debug the qcom_rng driver register access on this SoC — the synchronous external abort indicates the RNG hardware block may not be properly clocked/powered, or the register mapping is incorrect for this platform. Check device tree for correct qcom,prng-ee reg property and verify PRNG clocks are enabled before register access.
4. Detail analysis attachment: failed_case_job207616_7_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver attempted to read a hardware register (qcom_rng_read+0xc4) that triggered a synchronous external abort, indicating the RNG hardware block was not accessible (likely not clocked/powered or in an invalid state). The crash occurred during a userspace dd read from /dev/hwrng at timestamp 704 seconds after boot. This is a hardware access fault unrelated to the PR changes (which only touch DSI display driver code).
3. Possible fix: Investigate why the RNG hardware block became inaccessible on shikra-iqs-evk. Check: (1) RNG clock/power domain state at crash time, (2) whether RNG driver probe succeeded and hardware was properly initialized, (3) whether any power management transitions (suspend/runtime PM) disabled RNG access, (4) DT configuration for RNG node on shikra platform. Add runtime PM state checks and clock/power validation before hardware access in qcom_rng_read(). This is a pre-existing platform/driver issue, not a regression from PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885.
4. Detail analysis attachment: failed_case_job207616_8_detailed.md

  Case 9: job

1. Failed case: job
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Disable the qcom_hwrng test for shikra-iqs-evk in the LAVA job definition, or fix the platform device tree by adding missing power-domains/clocks for the qcom_rng node. Re-run PR 885 validation on a platform where RNG hardware is known to work (rb5, sm8450-hdk, sm8650-qrd) to confirm the DSI PHY changes are safe. If RNG hardware is not present on shikra, mark the qcom_rng device node as status = "disabled" in the device tree.
4. Detail analysis attachment: failed_case_job207616_9_detailed.md

Job 207617 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Issues

1. Failed case: Probe_Failure_Check — Pre-existing Platform Issues
2. Root cause: Two pre-existing platform-specific probe failures on qcs8300-ride: (1) cfg80211 regulatory.db firmware file missing from rootfs (error -2 / ENOENT), which is benign as WiFi functional tests pass; (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property (error -22 / EINVAL), which is a known qcs8300-ride board configuration issue unrelated to the PR's DSI driver changes.
3. Possible fix: These are pre-existing platform issues not introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885. For regulatory.db: no action needed as WiFi is functional (suppression candidate). For Aquantia PHY: add firmware-name property to qcs8300-ride DT ethernet PHY node or mark as expected if PHY firmware is intentionally not used on this board. The PR should not be blocked by these failures.
4. Detail analysis attachment: failed_case_job207617_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB-to-serial adapter) to the qcs8300-ride board's USB host port in the LAVA lab setup. If USB host testing is not required for this SoC/board configuration, mark this test as SKIP or exclude it from the qcs8300-ride test suite.
4. Detail analysis attachment: failed_case_job207617_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: /dev/kvm device node is not present because KVM cannot initialize on qcs8300-ride when running under the Gunyah hypervisor — nested virtualization (running KVM as a guest under another hypervisor) is not supported on this platform configuration.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 modifies DSI driver code unrelated to KVM). Mark KVM tests as expected-to-fail or skip them for qcs8300-ride targets running under Gunyah hypervisor. To enable KVM on this platform, boot without the Gunyah hypervisor or use a platform configuration that supports nested virtualization.
4. Detail analysis attachment: failed_case_job207617_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: qcs8300-ride target is running as a guest VM under Gunyah hypervisor; KVM cannot initialize because EL2 is occupied by Gunyah and nested virtualization is not enabled; /dev/kvm device node is not created as expected when running as a guest.
3. Possible fix: Skip KVM tests on qcs8300-ride in LAVA job definition by detecting hypervisor presence (dmesg | grep -q "Hypervisor cold boot") and exiting with SKIP status instead of running tests that will always fail in guest VM configuration.
4. Detail analysis attachment: failed_case_job207617_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: Disable KVM tests for QCS8300 platforms running under Gunyah hypervisor, or reconfigure the platform to boot without Gunyah if KVM functionality is required (note: this would require bootloader/firmware changes and is a platform-level decision, not a kernel fix).
4. Detail analysis attachment: failed_case_job207617_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark KVM tests as "not applicable" or "skip" for QCS8300-Ride and other Gunyah-based platforms in the LAVA test suite. Update the test runner to detect Gunyah hypervisor presence (check for "Hypervisor cold boot, version: gunyah" in boot log or /sys/hypervisor/type) and automatically skip KVM tests. Alternatively, configure the LAVA job definition to exclude KVM tests for qcs8300-ride device type.
4. Detail analysis attachment: failed_case_job207617_6_detailed.md

Job 207618 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — ath11k_pci WiFi driver probe failure

1. Failed case: Probe_Failure_Check — ath11k_pci WiFi driver probe failure
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI (Modem Host Interface) power-up to time out during device initialization.
3. Possible fix: Add the missing ath11k WCN6855 firmware files to the rootfs image used by monaco-evk LAVA jobs. The firmware package should include ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files. This is a test infrastructure issue, not a kernel regression introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which only modifies DSI PHY code).
4. Detail analysis attachment: failed_case_job207618_1_detailed.md

  Case 2: WiFi_Firmware_Driver — WiFi driver probe failure (ath11k_pci)

1. Failed case: WiFi_Firmware_Driver — WiFi driver probe failure (ath11k_pci)
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -2 / ENOENT during firmware load), causing MHI power-up timeout. This is a pre-existing infrastructure/image issue, NOT introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 which only modifies DSI PHY code in drivers/gpu/drm/msm/dsi/phy/.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/ for monaco-evk builds. Verify firmware package version matches the kernel ath11k driver expectations. Re-flash and confirm ath11k_pci probe succeeds.
4. Detail analysis attachment: failed_case_job207618_2_detailed.md

  Case 3: ** WiFi Driver Probe Failure — ath11k_pci probe timeout

1. Failed case: ** WiFi Driver Probe Failure — ath11k_pci probe timeout
2. Root cause: ** The ath11k_pci driver probe failed with -ETIMEDOUT (error -110) because the MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory. The MHI bus controller timed out waiting for the firmware to load, causing the entire WiFi PCI device initialization to fail. This is a firmware packaging issue in the build image, not a kernel regression introduced by the PR (which only touches DSI display driver code).
3. Possible fix: Add the missing WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs /lib/firmware/ directory in the Yocto build recipe. The firmware package should include the complete WCN6855 hw2.1 nfa765 variant firmware set. Verify the firmware is present in the deployed image before re-running the test.
4. Detail analysis attachment: failed_case_job207618_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: ath11k_pci WiFi driver probe timeout (error -110 ETIMEDOUT) on monaco-evk due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2 ENOENT); this is a pre-existing board/firmware configuration issue unrelated to the PR's DSI/DRM changes.
3. Possible fix: Add the missing ath11k/WCN6855/hw2.1/nfa765/amss.bin firmware file to the rootfs firmware directory, or update the board's device tree to reference the correct firmware path that exists in the image (e.g., ath11k/WCN6855/hw2.0/amss.bin as detected by WiFi_Firmware_Driver test).
4. Detail analysis attachment: failed_case_job207618_4_detailed.md

Job 207619 | SoC qcs615-ride

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

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

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

1. Failed case: ** Probe_Failure_Check — WiFi Regulatory Database Firmware Load Failure (False Positive)
2. Root cause: ** The Probe_Failure_Check test scanner flagged a benign cfg80211 regulatory.db firmware load failure (error -2: file not found). This is a false positive because: (1) regulatory.db is an optional file for WiFi regulatory domain enforcement, (2) WiFi driver (ath11k) probed successfully and is fully functional, (3) WiFi_OnOff and WiFi_Firmware_Driver tests passed, confirming WiFi subsystem health, and (4) the "faux_driver" prefix suggests this may be a test infrastructure artifact rather than a real driver message. The qcs615-ride rootfs does not include regulatory.db, but this does not prevent WiFi operation.
3. Possible fix: Suppress this failure in the Probe_Failure_Check test logic by adding a filter rule: exclude "regulatory.db" firmware load failures when the corresponding WiFi functional test (WiFi_OnOff) passes. Alternatively, add regulatory.db to the rootfs if regulatory domain enforcement is required for this test configuration. This is NOT a kernel bug and does NOT require a code fix.
4. Detail analysis attachment: failed_case_job207619_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test script expects video-decoder and video-encoder sub-devices to have separate IOMMU group attachments, but the qcom-venus driver on qcs615-ride creates these as V4L2 video devices under the parent aa00000.video-codec platform device, which is correctly attached to IOMMU group 7. The sub-devices do not appear in /sys/kernel/iommu_groups because they are not separate DMA-capable platform devices.
3. Possible fix: Update the smmu test script to recognize that video-decoder and video-encoder are V4L2 sub-devices of aa00000.video-codec and should not be expected to have independent IOMMU group entries. The test should verify only that the parent video-codec device is protected by SMMU, which it is (group 7).
4. Detail analysis attachment: failed_case_job207619_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. To enable KVM testing on qcs615-ride: (1) boot without Gunyah hypervisor (requires bootloader/firmware configuration change to disable Gunyah), OR (2) exclude KVM tests from the qcs615-ride test suite since this platform is configured for Gunyah-based virtualization, not KVM-based virtualization. The PR changes (DSI PHY driver) are unrelated and did not cause this failure.
4. Detail analysis attachment: failed_case_job207619_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: QCS615 platform does not support ARM EL2 (Hypervisor mode) — kernel message at boot: "kvm [1]: HYP mode not available". KVM requires EL2 support to create /dev/kvm device node. This is a hardware platform limitation, not a kernel regression.
3. Possible fix: This is not a bug — QCS615 hardware does not support virtualization extensions. Either: (1) Skip KVM tests on QCS615 platform in CI (add platform exclusion rule), or (2) Use a different SoC with EL2 support (e.g., SM8450, SM8550) for KVM validation. The PR (DSI driver revert) is unrelated to this failure.
4. Detail analysis attachment: failed_case_job207619_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: KVM ARM driver reports "HYP mode not available" during kernel initialization on QCS615 (SM6150-based SoC). The QCS615 platform does not support EL2 (Hypervisor mode) in the current firmware/bootloader configuration, preventing KVM from initializing and creating the /dev/kvm device node. CONFIG_KVM is enabled in the kernel but the hardware prerequisite (EL2 support) is not met on this SoC/board combination.
3. Possible fix: This is not a kernel regression introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which modifies DSI/DRM drivers only). The KVM_Infra test failure is a pre-existing platform limitation: QCS615-ride does not support KVM/virtualization in the current firmware configuration. To resolve: (1) Mark KVM tests as "expected skip" for qcs615-ride in the LAVA test suite, or (2) Update the board's bootloader/firmware to boot Linux at EL2 if the SoC supports it (requires vendor firmware update and may not be possible on all QCS615 variants).
4. Detail analysis attachment: failed_case_job207619_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests — KVM Test Failures (Pre-existing Platform Limitation)

1. Failed case: 0_qcom-next-ci-premerge-tests — KVM Test Failures (Pre-existing Platform Limitation)
2. Root cause: The qcs615-ride platform is running as a guest VM under the Gunyah hypervisor (evidence: "Hypervisor cold boot, version: gunyah-1cb9db980 perf"). KVM requires EL2 (HYP mode) to function, but when running as a guest VM, EL2 is not available to the guest kernel because it is used by the host hypervisor. The kernel correctly detects this condition and reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm creation. This is expected behavior on this platform configuration, not a kernel regression.
3. Possible fix: This is not a bug requiring a fix. The KVM tests should be skipped or marked as expected failures on platforms running under a hypervisor (Gunyah-based configurations). Update the test suite to detect when the system is running as a guest VM (check for Gunyah hypervisor presence or "HYP mode not available" message) and skip KVM tests with an appropriate message indicating nested virtualization is not supported on this platform configuration.
4. Detail analysis attachment: failed_case_job207619_6_detailed.md

Job 207620 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three distinct pre-existing platform issues unrelated to the PR: (1) regulatory.db firmware file missing from rootfs (benign — cfg80211 regulatory database is optional); (2) Aquantia AQR115C Ethernet PHY at stmmac-0:08 failing probe with -EINVAL due to missing or invalid firmware-name DT property on qcs9100-ride; (3) four qcom-spmi-temp-alarm devices (PMIC thermal sensors) stuck in deferred probe, likely awaiting a thermal zone or IIO dependency that never resolves on this platform.
3. Possible fix: These are known platform-specific issues on qcs9100-ride, not regressions introduced by the DSI PHY patch in PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885. (1) Regulatory.db: no action needed — cfg80211 falls back to built-in regulatory rules. (2) Aquantia PHY: add a valid firmware-name property to the Aquantia PHY node in qcs9100-ride.dts, or mark the PHY as disabled if not used. (3) PMIC temp-alarm: verify the qcs9100 PMIC DT nodes include correct thermal-zone linkage or IIO channel references; if the sensors are non-critical, suppress this check for qcs9100-ride in the CI test filter.
4. Detail analysis attachment: failed_case_job207620_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is not attached to any IOMMU group on qcs9100-ride platform, causing the SMMU test to fail when validating that all critical masters are protected by IOMMU.
3. Possible fix: Add missing IOMMU binding for the video codec device node (aa00000.video-codec) in the qcs9100-ride device tree, or if the device is intentionally not using IOMMU on this platform, update the SMMU test's critical master list to exclude video codec for qcs9100-ride.
4. Detail analysis attachment: failed_case_job207620_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices physically connected to the qcs9100-ride board USB host ports; only USB root hubs enumerated (Bus 001, 002, 003 Device 001). The USB host controllers (xHCI) initialized successfully and are functional, but the test expects at least one non-hub USB device to be attached.
3. Possible fix: Connect a functional USB device (keyboard, mouse, storage, or test dongle) to one of the qcs9100-ride board's USB host ports before running the USBHost test. This is a lab/hardware setup issue, not a kernel bug. The PR (DSI/display changes) is unrelated to USB functionality.
4. Detail analysis attachment: failed_case_job207620_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test harness marked the test definition as failed with "Marking unfinished test run as failed" despite all individual test cases completing execution and the test runner signaling <LAVA_TEST_RUNNER EXIT>. This is a LAVA infrastructure issue where the test definition's completion was not properly recognized by LAVA's state machine, likely due to missing or malformed test completion signals.
3. Possible fix: This is not a kernel regression introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (DSI PLL revert). The failure is a LAVA test harness issue. Re-trigger the CI job. If the issue persists, review the LAVA job definition to ensure proper test completion signals are configured, and check LAVA dispatcher logs for state machine errors.
4. Detail analysis attachment: failed_case_job207620_4_detailed.md

Job 207621 | SoC qcs6490-rb3gen2

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

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

  Case 1: ** Probe_Failure_Check — Firmware Load Failure (regulatory.db)

1. Failed case: ** Probe_Failure_Check — Firmware Load Failure (regulatory.db)
2. Root cause: ** The cfg80211 wireless subsystem attempted to load the regulatory database firmware file (regulatory.db) during boot but the file was not present in the test image filesystem (/lib/firmware/). Error -2 (ENOENT: No such file or directory). This is a pre-existing infrastructure/image packaging issue, NOT introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885, which only modifies DRM/MSM DSI display driver code.
3. Possible fix: Add the wireless-regdb package to the test image build recipe to include /lib/firmware/regulatory.db, OR suppress this specific error in the Probe_Failure_Check test as a known benign failure when WiFi regulatory enforcement is not required for the test suite. If WiFi functional tests are not part of the test matrix, this error can be safely ignored.
4. Detail analysis attachment: failed_case_job207621_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no USB devices physically connected to the qcs6490-rb3gen2 board during test execution. The kernel USB subsystem initialized correctly (usbcore registered at boot), USB controller (a600000.usb) was added to IOMMU group 9, but the test script found zero enumerated USB devices when querying the USB bus.
3. Possible fix: This is not a PR-introduced regression. The PR modifies only DRM/MSM DSI PHY code (drivers/gpu/drm/msm/dsi/phy/) and has no relationship to USB functionality. The fix is to ensure a USB device (e.g., USB storage, USB keyboard, or USB hub) is physically connected to the board's USB host port before running the USBHost test, or mark this test as SKIP when no USB peripherals are available in the test environment.
4. Detail analysis attachment: failed_case_job207621_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM initialization failed because the qcs6490-rb3gen2 platform does not support EL2 (Hypervisor mode) — kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation.
3. Possible fix: Update the KVM_Driver test to skip (not fail) when /dev/kvm is absent due to platform limitations; alternatively, exclude KVM tests from the test suite for platforms without EL2 support (qcs6490-rb3gen2).
4. Detail analysis attachment: failed_case_job207621_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform limitation, not a kernel regression. To enable KVM on rb3gen2: (1) update ABL/XBL firmware to boot kernel at EL2, OR (2) exclude KVM tests from qcs6490-rb3gen2 CI job definitions, OR (3) mark KVM tests as "expected fail" for this platform in LAVA job metadata.
4. Detail analysis attachment: failed_case_job207621_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: KVM driver failed to initialize because ARM HYP mode (EL2) is not available on the qcs6490-rb3gen2 platform; kernel message at boot: kvm [1]: HYP mode not available, preventing /dev/kvm device creation.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression. The qcs6490-rb3gen2 board's bootloader or firmware does not enable EL2/HYP mode. To fix: (1) verify bootloader enables EL2 before entering kernel, (2) check if SoC/board supports virtualization extensions in current configuration, (3) if virtualization is not required for this platform, mark KVM tests as expected-fail or skip them in the LAVA job definition for rb3gen2.
4. Detail analysis attachment: failed_case_job207621_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 qcs6490-rb3gen2 platform does not support EL2 (hypervisor mode), which is required for KVM functionality. The KVM driver detected this hardware limitation during initialization (kvm [1]: HYP mode not available) and aborted, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware limitation, not a kernel regression. The KVM tests should be excluded from the CI test suite for qcs6490-rb3gen2 (and other platforms without EL2 support). Add platform capability detection to the LAVA job definition to skip KVM tests when HYP mode not available is detected in dmesg.
4. Detail analysis attachment: failed_case_job207621_6_detailed.md

Job 207622 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing platform-specific probe failures unrelated to the PR: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) due to missing or incompatible secure firmware configuration on hamoa-evk; (2) qcom-spmi-lpg probe failed with -EINVAL (-22) due to invalid "reg" property in multi-led device tree configuration for PMIC@1 PWM; (3) regulatory.db firmware load failed with -ENOENT (-2) because the file is not present in the rootfs (known benign — cfg80211 falls back to built-in regulatory database).
3. Possible fix: These are pre-existing platform/configuration issues not introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (DSI PHY PLL revert). No action required for this PR. For platform maintainers: (1) verify qcom_qseecom secure app availability and TrustZone configuration for hamoa-evk; (2) correct the PMIC@1 PWM multi-led "reg" property in the device tree; (3) optionally add regulatory.db to rootfs or accept the built-in fallback.
4. Detail analysis attachment: failed_case_job207622_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six critical devices (five USB PHY devices: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb; and one video codec: aa00000.video-codec) are missing IOMMU group attachments in sysfs on hamoa-evk, indicating incomplete device tree iommus property configuration for these devices. No SMMU/IOMMU runtime errors detected in kernel log.
3. Possible fix: Add missing iommus properties to the device tree nodes for the five USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and the video codec device (aa00000.video-codec) in the hamoa-evk device tree, following the pattern used for the working USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb).
4. Detail analysis attachment: failed_case_job207622_2_detailed.md

  Case 3: WiFi_Firmware_Driver — Test Infrastructure False Positive

1. Failed case: WiFi_Firmware_Driver — Test Infrastructure False Positive
2. Root cause: Test script incorrectly flags a transient DMA allocation retry warning as a failure, despite the ath12k WiFi driver successfully completing probe and creating a functional interface (wlan0 renamed to wlP4p1s0). The warning "qmi dma allocation failed (7274496 B type 1), will try later with small size" is a normal retry path in the driver, not a fatal error. PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (DSI/display revert) does not touch WiFi or DMA code.
3. Possible fix: Update the WiFi_Firmware_Driver test script to distinguish between transient warnings and actual probe failures. The test should verify final driver state (interface creation, firmware version reported) rather than pattern-matching on intermediate retry messages. This is a test infrastructure fix, not a kernel fix.
4. Detail analysis attachment: failed_case_job207622_3_detailed.md

  Case 4: ** WiFi_OnOff — Test False Positive (Driver Probe Warning)

1. Failed case: ** WiFi_OnOff — Test False Positive (Driver Probe Warning)
2. Root cause: ** The WiFi_OnOff test script incorrectly flags a transient driver warning (ath12k_wifi7_pci qmi dma allocation failed, will try later with small size) as a failure. The ath12k driver implements a graceful fallback: when the initial 7.3 MB DMA allocation fails, it retries with a smaller size and successfully completes probe. The WiFi interface (wlP4p1s0) was created and functional. This is a test pattern-matching issue, not a kernel regression.
3. Possible fix: Update the WiFi_OnOff test script to suppress or correctly interpret the will try later with small size message as a non-fatal warning. The test should verify WiFi interface creation and functionality, not fail on transient retry messages that the driver handles internally.
4. Detail analysis attachment: failed_case_job207622_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because EL2 (Hypervisor mode) is not available to Linux - the Gunyah hypervisor (version gunyah-mobile-c487961e9) has taken exclusive control of EL2, preventing the Linux KVM driver from accessing hypervisor mode on the hamoa-evk platform.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The hamoa-evk board is configured to run under the Gunyah hypervisor, which occupies EL2 and prevents nested virtualization. Either: (1) disable the KVM_Driver test for hamoa-evk in the LAVA test suite since KVM cannot function under Gunyah, or (2) if KVM support is required, reconfigure the platform firmware to boot Linux at EL2 without the Gunyah hypervisor (not recommended for production configurations).
4. Detail analysis attachment: failed_case_job207622_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 IoT EVK platform does not support ARM Virtualization Extensions (HYP/EL2 mode), which is a hardware prerequisite for KVM. The kernel message kvm [1]: HYP mode not available indicates that the KVM driver detected the absence of hypervisor mode during initialization and aborted, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware limitation, not a kernel bug or PR-introduced regression. The Hamoa SoC does not implement ARM Virtualization Extensions. To resolve: (1) Skip KVM-related tests on Hamoa platform in the CI test suite, or (2) Use a different platform that supports virtualization (e.g., platforms with Cortex-A cores that implement EL2) for KVM testing. The PR patch (DSI PHY changes) is unrelated to this failure.
4. Detail analysis attachment: failed_case_job207622_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test environment configuration issue, not a kernel bug. To enable KVM testing on Hamoa EVK: (1) disable Gunyah hypervisor in the firmware/bootloader configuration and reflash, OR (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, OR (3) use a separate test image without Gunyah for KVM validation. The PR does not introduce this issue (DSI PHY changes are unrelated).
4. Detail analysis attachment: failed_case_job207622_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on hamoa-evk because the platform runs under the Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" at boot confirms that KVM detected the hypervisor and aborted initialization, so /dev/kvm was never created.
3. Possible fix: This is not a kernel regression. The test expectation is incorrect for this platform. Either: (1) skip KVM tests on hamoa-evk (and other Gunyah-based platforms) in the CI job definition, or (2) update the test to expect KVM unavailability on platforms running under Gunyah and mark it as SKIP instead of FAIL.
4. Detail analysis attachment: failed_case_job207622_8_detailed.md

Job 207623 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected five pre-existing platform-specific probe failures on purwa-evk (iq-x5121-evk) that are unrelated to PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (DSI PHY revert): qcom_qseecom_uefisecapp (-EBUSY, device busy), qcom-spmi-lpg (-EINVAL, invalid multi-LED reg property in DT), two qcom-pcie instances (-ENODATA, missing PHY init sequences for PCIe Gen4/Gen5 controllers), and regulatory.db firmware (-ENOENT, optional WiFi regulatory database not in rootfs).
3. Possible fix: These are known platform limitations on purwa-evk and not regressions introduced by this PR. The PR only modifies drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c and does not touch qseecom, lpg, pcie, or cfg80211 subsystems. Suppress this test failure for purwa-evk or update the test's platform-specific allowlist to exclude these expected probe failures for this SoC.
4. Detail analysis attachment: failed_case_job207623_1_detailed.md

  Case 2: smmu (test expectation mismatch)

1. Failed case: smmu (test expectation mismatch)
2. Root cause: Test script expects 6 devices (5 secondary USB PHY controllers at addresses ending in f8800, and video codec aa00000.video-codec) to be present and attached to IOMMU groups, but these devices are not defined in the purwa-evk device tree; SMMU subsystem is functioning correctly with 35 devices properly protected.
3. Possible fix: Update the smmu test's critical device list for purwa-evk to exclude devices not present on this platform, or add the missing device tree nodes if the hardware supports them; this is not a kernel regression introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which only modifies DSI PHY code).
4. Detail analysis attachment: failed_case_job207623_2_detailed.md

  Case 3: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath12k_wifi7_pci driver QMI DMA allocation failed during probe for a 7274496-byte (≈7MB) type-1 buffer; driver logged "will try later with small size" and successfully recovered by creating the wlan0 interface, but the test harness flagged the warning message as a probe failure despite functional WiFi initialization completing successfully.
3. Possible fix: This is a test false positive — the WiFi driver probe succeeded (firmware loaded, interface created and renamed to wlP4p1s0). Update the WiFi_Firmware_Driver test script to distinguish between fatal probe failures and recoverable warnings where the driver explicitly states "will try later with small size" and subsequently succeeds. If the QMI DMA allocation warning is a genuine concern for this SoC (purwa-evk), investigate whether the reserved DMA memory region size in the device tree is sufficient for the ath12k_wifi7_pci driver's initial allocation request, or whether the driver's fallback to smaller allocations is the intended behavior for this platform.
4. Detail analysis attachment: failed_case_job207623_3_detailed.md

  Case 4: WiFi_OnOff — ath12k_wifi7_pci QMI DMA allocation warning (non-fatal)

1. Failed case: WiFi_OnOff — ath12k_wifi7_pci QMI DMA allocation warning (non-fatal)
2. Root cause: ath12k_wifi7_pci driver attempted to allocate 7274496 bytes (7MB) of DMA memory during QMI initialization at probe time, initial allocation failed, driver fallback succeeded with smaller size and WiFi interface initialized successfully (firmware loaded, interface renamed to wlP4p1s0). Test framework incorrectly flagged this as a failure by matching the "qmi dma allocation failed" log string without verifying that the driver's retry/fallback mechanism succeeded.
3. Possible fix: Update the WiFi_OnOff test probe-failure pattern matching to exclude log lines containing "will try later with small size" — this is an informational message indicating the driver will retry with a smaller allocation, not a fatal probe failure. The test should only fail if no WiFi interface appears or firmware load fails.
4. Detail analysis attachment: failed_case_job207623_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on purwa-evk because the platform does not support ARM Hypervisor (EL2) mode — kernel log shows kvm [1]: HYP mode not available at boot, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware limitation, not a kernel bug or PR-introduced regression. The PR changes only DRM/DSI driver code unrelated to KVM. No kernel fix is possible; either use a platform with EL2 support for KVM testing, or exclude KVM tests from the purwa-evk CI test suite.
4. Detail analysis attachment: failed_case_job207623_5_detailed.md

  Case 6: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM driver initialization failure — /dev/kvm device node not created because KVM cannot initialize on purwa-evk: the Gunyah hypervisor is already running at EL2, preventing KVM from entering HYP mode (kernel message: kvm [1]: HYP mode not available).
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR changes DSI PHY driver code unrelated to KVM/virtualization. On purwa-evk, Gunyah hypervisor runs at EL2 by design for protected VM support. KVM tests should be skipped on platforms where Gunyah is enabled, or the test suite should detect Gunyah presence and mark KVM tests as "not applicable" rather than "fail". Update the LAVA test definition to skip KVM tests when Gunyah hypervisor is detected in boot logs.
4. Detail analysis attachment: failed_case_job207623_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on purwa-evk because the Gunyah hypervisor is already running at EL2 (hypervisor privilege level), preventing KVM from accessing the required hypervisor mode — kernel message "kvm [1]: HYP mode not available" confirms EL2 is unavailable to KVM.
3. Possible fix: This is expected behavior on Gunyah-enabled platforms where KVM and Gunyah are mutually exclusive. To enable KVM testing: (1) disable Gunyah hypervisor in the platform firmware/bootloader configuration, or (2) use a different test platform without Gunyah, or (3) mark KVM tests as "not applicable" for Gunyah-enabled platforms in the CI test matrix.
4. Detail analysis attachment: failed_case_job207623_7_detailed.md

  Case 8: KVM_Driver / KVM_EL2_DTB / KVM_Infra (all three tests failed with identical root cause)

1. Failed case: KVM_Driver / KVM_EL2_DTB / KVM_Infra (all three tests failed with identical root cause)
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available to the kernel — the Purwa EVK board is running under the Gunyah hypervisor which occupies EL2, preventing KVM from initializing and creating /dev/kvm.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The Purwa EVK board runs under Gunyah hypervisor by default, which makes KVM unavailable. Either: (1) exclude KVM tests from the Purwa EVK test suite, or (2) configure the board to boot without the Gunyah hypervisor if KVM testing is required, or (3) mark these tests as expected-to-skip on hypervisor-enabled platforms.
4. Detail analysis attachment: failed_case_job207623_8_detailed.md

Job 207624 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Deferred Probe Not Resolved (SPMI PMIC temp-alarm devices)

1. Failed case: Probe_Failure_Check — Deferred Probe Not Resolved (SPMI PMIC temp-alarm devices)
2. Root cause: Four SPMI PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state at test time, indicating the qcom-spmi-temp-alarm driver's dependencies (likely thermal zone or IIO channel providers) are not probing successfully or in the correct order on lemans-evk.
3. Possible fix: Investigate the thermal zone and IIO ADC channel providers for the lemans-evk platform; verify device tree bindings for the temp-alarm nodes include correct thermal-zone and io-channel references; check if the qcom-spmi-adc5 or qcom-vadc-common drivers probe successfully before temp-alarm; if dependencies are missing from the device tree, add them following the qcom,spmi-temp-alarm.yaml binding schema.
4. Detail analysis attachment: failed_case_job207624_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not registered as a platform device or failed to probe during boot, causing the SMMU test to fail when checking for critical master IOMMU group attachments; this is a pre-existing platform/driver/DT issue on lemans-evk, not introduced by PR BACKPORT: Revert "drm/msm: dsi: fix PLL init in bonded mode" for QLI2.0 #885 (which only modifies DSI PHY code in drivers/gpu/drm/msm/dsi/phy/).
3. Possible fix: Investigate why the video codec device at address aa00000 is not probing on lemans-evk — check device tree for missing/disabled video-codec node, verify driver is built and loaded, check boot log for probe failures; alternatively, update the SMMU test script to skip video codec validation on lemans-evk if this device is not expected on this platform.
4. Detail analysis attachment: failed_case_job207624_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Two test validation failures on lemans-evk: (1) Probe_Failure_Check detected deferred probe devices (temp-alarm@a00 on 4 PMICs) and missing firmware files (regulatory.db, Bluetooth firmware); (2) smmu test detected video-codec device (aa00000.video-codec) missing IOMMU group attachment. These are pre-existing platform configuration issues unrelated to the PR's DSI PHY changes.
3. Possible fix: These failures are not PR-introduced regressions. The PR modifies only DSI PHY PLL initialization (drivers/gpu/drm/msm/dsi/phy/) and does not touch thermal alarm drivers, firmware loading, video codec drivers, or SMMU configuration. Mark these test failures as known platform issues for lemans-evk and approve the PR if no other genuine failures exist.
4. Detail analysis attachment: failed_case_job207624_3_detailed.md