Skip to content

FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver - #1010

Open
raryan-qcom wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
raryan-qcom:for-adc-gen3-defconfig
Open

FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver#1010
raryan-qcom wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
raryan-qcom:for-adc-gen3-defconfig

Conversation

@raryan-qcom

@raryan-qcom raryan-qcom commented Aug 25, 2026

Copy link
Copy Markdown

The Qualcomm SOCs device tree i.e. lemans, monaco, describe ADC5 Gen3 channels for the PMM8654au PMICs and connects the PMIC temperature alarm nodes to their DIE_TEMP ADC channels. However, the ADC5 Gen3 driver is not enabled in arm64 defconfig.

Without the driver, the ADC providers do not register and the PMIC temperature alarm devices cannot obtain their ADC channels. As a result, the corresponding thermal zones are not registered.

Enable CONFIG_QCOM_SPMI_ADC5_GEN3 as a module to support the ADC nodes and ADC-backed PMIC thermal monitoring on the Lemans platform.

Link: https://lore.kernel.org/all/20260807-arm64-defconfig-adc5-gen3-v1-1-507521835ec2@oss.qualcomm.com/

CRs-Fixed: 4587292

Raj Aryan @raryan-qcom
FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver
680635b 
The Qualcomm SOCs device tree i.e. lemans, monaco, describe ADC5 Gen3
channels for the PMM8654au PMICs and connects the PMIC temperature
alarm nodes to their DIE_TEMP ADC channels. However, the ADC5 Gen3
driver is not enabled in arm64 defconfig.

Without the driver, the ADC providers do not register and the PMIC
temperature alarm devices cannot obtain their ADC channels. As a
result, the corresponding thermal zones are not registered.

Enable CONFIG_QCOM_SPMI_ADC5_GEN3 as a module to support the ADC nodes
and ADC-backed PMIC thermal monitoring on the Lemans platform.

Link: https://lore.kernel.org/all/20260807-arm64-defconfig-adc5-gen3-v1-1-507521835ec2@oss.qualcomm.com/
Signed-off-by: Raj Aryan <raj.aryan@oss.qualcomm.com>
@qcomlnxci

qcomlnxci commented Aug 25, 2026

Copy link
Copy Markdown

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 ⚠️ skip ⚠️ 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 ◻️ ❌ Fail
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 ◻️ ⚠️ skip
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ❌ Fail ◻️ ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ❌ Fail
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 ◻️ ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️ ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️ ❌ Fail
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 ◻️ ⚠️ skip
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ❌ Fail ◻️ ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ⚠️ skip
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ⚠️ skip
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ◻️ ⚠️ skip
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 ◻️ ◻️
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 ◻️ ✅ Pass
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass

@qcomlnxci

qcomlnxci commented Aug 25, 2026

Copy link
Copy Markdown

Test jobs on 680635b

@qlijarvis

qlijarvis commented Sep 1, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #1010

Job 212463 | SoC qcs9100-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort in SMMU Driver
  1. Failed case: Kernel Crash — Synchronous External Abort in SMMU Driver
  2. Root cause: Hardware bus rejected SMMU S2CR register write at offset 0xc28 during qcom_smmu_write_s2cr() while adding remoteproc device (30000000.remoteproc) to IOMMU group 15. The synchronous external abort (ESR 0x96000010) and MACHINE_CHECK taint flag indicate a hardware-level access violation, likely due to SMMU power/clock domain not enabled, register region misconfiguration, or qcs9100-ride platform-specific hardware issue.
  3. Possible fix: This is a pre-existing platform issue unrelated to the PR (which only enables ADC5 Gen3 config). Immediate action: verify SMMU power domain and clock enablement in device tree for qcs9100-ride; check if remoteproc@30000000 IOMMU binding is correct; compare with working qcs9100 device trees. Long-term: add SMMU register access validation before S2CR writes; investigate if this remoteproc instance requires special IOMMU configuration on Lemans platform.
  4. Detail analysis attachment: failed_case_job212463_1_detailed.md
  Case 2: ** Kernel Crash — Synchronous External Abort in SMMU Initialization
  1. Failed case: ** Kernel Crash — Synchronous External Abort in SMMU Initialization
  2. Root cause: ** The kernel crashed with a synchronous external abort (bus fault) at qcom_smmu_write_s2cr+0x84/0x140 during SMMU (System MMU) initialization at boot time (4.3 seconds after start). The fault occurred when writing to SMMU S2CR register at physical address 0x15000c28 (SMMU base 0x15000000 + offset 0xc28 for stream index 8). This hardware bus fault indicates the SMMU register block was not accessible—most likely due to missing clock enablement, power domain not ready, or the SMMU hardware not being properly initialized on the qcs9100-ride platform.
  3. Possible fix: This is a pre-existing qcs9100-ride platform issue, not introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3 in defconfig and does not touch SMMU code). Recommended actions: (1) Re-trigger the CI job on a different qcs9100-ride board to rule out board-specific hardware failure. (2) Audit the SMMU device tree node at arch/arm64/boot/dts/qcom/qcs9100-ride.dts for the 15000000.iommu device—verify clocks, clock-names, and power-domains properties are present and correct. (3) Compare with upstream qcs9100 SMMU bindings and working Qualcomm platforms (sm8450, sm8550). (4) Coordinate with the Qualcomm platform team to confirm correct clock/power domain requirements for qcs9100 SMMU. (5) If the issue reproduces on multiple boards, temporarily disable SMMU in the qcs9100-ride DT (status = "disabled") to unblock other CI testing while the root cause is fixed.
  4. Detail analysis attachment: failed_case_job212463_2_detailed.md
  Case 3: Kernel Crash — Synchronous External Abort (SMMU register access)
  1. Failed case: Kernel Crash — Synchronous External Abort (SMMU register access)
  2. Root cause: Kernel panic during SMMU (System MMU) initialization on qcs9100-ride. The crash occurred at qcom_smmu_write_s2cr+0x84/0x140 when attempting to write to SMMU S2CR (Stream-to-Context Register) at address offset 0xc28, resulting in a synchronous external abort (ESR 0x96000010). This indicates the SMMU hardware register is not accessible — either the SMMU is not powered/clocked correctly, the register address mapping is incorrect, or the hardware is in a bad state preventing MMIO access.
  3. Possible fix: This is a pre-existing platform/kernel issue unrelated to the PR (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The SMMU crash prevents boot completion. Immediate action: verify SMMU power domain, clock, and reset configuration in the qcs9100-ride device tree. Check if recent SMMU driver or DT changes broke register access. Compare with a known-good kernel version on this board. If the issue is reproducible on baseline (without this PR), escalate to the platform team for SMMU hardware/firmware investigation.
  4. Detail analysis attachment: failed_case_job212463_3_detailed.md
  Case 4: job
  1. Failed case: job
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is a pre-existing qcs9100-ride platform issue unrelated to the PR (which only adds CONFIG_QCOM_SPMI_ADC5_GEN3=m). Verify SMMU power domain, clock enablement, and device tree MMIO region configuration for qcs9100-ride; check if platform requires interconnect vote or additional initialization before SMMU register access; compare with working qcs9100 board configurations.
  4. Detail analysis attachment: failed_case_job212463_4_detailed.md
Job 212464 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Driver Issues
  1. Failed case: Probe_Failure_Check — Pre-existing Platform Driver Issues
  2. Root cause: The test detected 5 probe failures during boot on purwa-evk (iq-x5121): (1) qcom_qseecom_uefisecapp (-EBUSY, secure world resource conflict), (2) qcom-spmi-lpg (-EINVAL, invalid multi-LED DT configuration), (3-4) qcom-pcie x2 (-ENODATA, PCIe PHY power-on failure), (5) regulatory.db (-ENOENT, missing optional firmware). All failures are pre-existing platform/DT/firmware issues unrelated to the PR's ADC5 Gen3 defconfig change.
  3. Possible fix: These probe failures are not introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). They are pre-existing issues on the purwa-evk platform. The Probe_Failure_Check test should be updated to exclude known benign failures (regulatory.db) and platform-specific issues that do not affect functional testing. For the PR validation: APPROVE — the ADC5 Gen3 driver change does not cause these failures, and all functional tests (WiFi, BT, USB, remoteproc, audio) passed successfully.
  4. Detail analysis attachment: failed_case_job212464_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test validation failure — six critical platform devices (USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video codec aa00000.video-codec) are missing IOMMU group attachments on purwa-evk, indicating incomplete device tree IOMMU bindings for these devices.
  3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers at addresses 0xa0f8800, 0xa2f8800, 0xa4f8800, 0xa6f8800, 0xa8f8800 and video codec at 0xaa00000 in arch/arm64/boot/dts/qcom/x1e80100.dtsi (or the purwa-specific overlay), referencing the appropriate SMMU phandle and stream IDs. This is a pre-existing platform issue unrelated to PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables ADC5 Gen3 driver in defconfig).
  4. Detail analysis attachment: failed_case_job212464_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM driver initialization failed because the platform is not running in EL2 (hypervisor) mode — kernel log shows kvm [1]: HYP mode not available at boot time, preventing /dev/kvm device node creation.
  3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The purwa-evk board firmware/bootloader must be configured to boot the kernel in EL2 mode to enable KVM support. Suppress this test failure for this PR as it is not a regression introduced by the ADC5 Gen3 driver change.
  4. Detail analysis attachment: failed_case_job212464_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM driver initialization failed during boot because the platform does not support EL2/HYP mode — the kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or the hypervisor is not enabled in the boot chain, preventing /dev/kvm device node creation. This is a pre-existing platform/firmware configuration issue on purwa-evk, not introduced by the PR (which only enables ADC5 Gen3 driver in defconfig).
  3. Possible fix: This is not a PR-introduced regression. The purwa-evk platform requires bootloader/firmware configuration to enable EL2/HYP mode for KVM support. If KVM testing is required on this platform: (1) verify the bootloader (ABL/UEFI) is configured to boot Linux at EL2 (not EL1), (2) confirm the hypervisor is enabled in the boot chain, (3) check if the platform supports virtualization extensions. If purwa-evk does not support KVM, exclude KVM tests from the CI test suite for this platform.
  4. Detail analysis attachment: failed_case_job212464_4_detailed.md
  Case 5: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is a known platform limitation, not a kernel regression. The PR (ADC5 Gen3 defconfig change) is unrelated. To enable KVM on purwa-evk, either: (1) disable Gunyah hypervisor in the boot configuration to allow Linux direct EL2 access, or (2) use Gunyah's native virtualization APIs instead of KVM. If KVM testing is required for this platform, update the LAVA job definition to skip KVM tests on Gunyah-enabled platforms or reconfigure the platform firmware to boot without Gunyah.
  4. Detail analysis attachment: failed_case_job212464_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM cannot initialize on purwa-evk platform because the hardware does not support HYP (EL2 hypervisor) mode — kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running with virtualization extensions enabled or the platform firmware does not configure EL2.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by the PR (which only enables ADC5 Gen3 driver in defconfig). The KVM tests should be skipped on purwa-evk platform in the LAVA job definition, or the platform firmware should be updated to enable EL2 if the hardware supports it.
  4. Detail analysis attachment: failed_case_job212464_6_detailed.md
Job 212465 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Pre-existing Infrastructure Issues
  1. Failed case: Probe_Failure_Check — Pre-existing Infrastructure Issues
  2. Root cause: The test detected two categories of probe failures that are pre-existing board/infrastructure issues unrelated to the PR (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3): (1) Deferred probe issues for audio subsystem devices (soundwire, codec, pinctrl) waiting on missing pinctrl state suppliers, and (2) Firmware load failures for regulatory.db (cfg80211) and renesas_usb_fw.mem (xhci-pci-renesas) due to missing firmware files in the rootfs. These failures existed before the PR and are not caused by enabling the ADC5 Gen3 driver.
  3. Possible fix: Mark this test case as a false positive for PR validation purposes. The PR change (enabling CONFIG_QCOM_SPMI_ADC5_GEN3=m) does not introduce any new probe failures. The pre-existing issues should be tracked separately: (1) Add missing pinctrl state nodes (wsa-swr-data-state, dmic23-data-state) to the qcs6490-rb3gen2 device tree to resolve audio codec deferred probes, and (2) Add regulatory.db and renesas_usb_fw.mem firmware files to the rootfs image to resolve firmware load failures.
  4. Detail analysis attachment: failed_case_job212465_1_detailed.md
  Case 2: USBHost
  1. Failed case: USBHost
  2. Root cause: The USBHost test failed because no USB host devices were enumerated on the qcs6490-rb3gen2 board. The PCIe-based Renesas xHCI USB host controller (0001:04:00.0) failed to probe due to missing firmware file renesas_usb_fw.mem (error -2 / -ENOENT). The on-SoC USB controllers (8c00000.usb, a600000.usb) are configured in USB gadget/peripheral mode, not host mode, and therefore do not provide USB host functionality.
  3. Possible fix: This is a known hardware/firmware limitation on the rb3gen2 board, not a kernel regression introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables ADC5 Gen3 driver in defconfig). The test failure is expected infrastructure behavior: either (1) add the missing Renesas USB firmware file renesas_usb_fw.mem to /lib/firmware/ in the test rootfs, or (2) mark the USBHost test as SKIP for rb3gen2 boards that lack external USB host hardware or firmware, or (3) reconfigure one of the on-SoC USB controllers to host mode in the device tree if USB host testing is required.
  4. Detail analysis attachment: failed_case_job212465_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM driver initialization failed because the qcs6490-rb3gen2 platform does not support EL2 (hypervisor mode). The kernel message "kvm [1]: HYP mode not available" at boot time (3.427515s) indicates the CPU is not running in a mode that allows KVM virtualization. CONFIG_KVM and CONFIG_VIRTUALIZATION are enabled in the kernel config, but the hardware/firmware does not provide EL2 support.
  3. Possible fix: This is a platform limitation, not a kernel bug or PR-introduced regression. The PR (enabling CONFIG_QCOM_SPMI_ADC5_GEN3 for ADC support) is unrelated to KVM/virtualization. If KVM support is required on this platform, verify that: (1) the bootloader/firmware is configured to boot the kernel at EL2, (2) the SoC supports virtualization extensions, and (3) secure firmware (TrustZone) allows EL2 access. If the platform fundamentally lacks EL2 support, mark KVM tests as expected-to-skip for this SoC in the CI test matrix.
  4. Detail analysis attachment: failed_case_job212465_3_detailed.md
  Case 4: KVM_EL2_DTB — KVM Unavailable (Platform Configuration Issue)
  1. Failed case: KVM_EL2_DTB — KVM Unavailable (Platform Configuration Issue)
  2. Root cause: The qcs6490-rb3gen2 board's bootloader/firmware boots the kernel at EL1 (Exception Level 1) instead of EL2 (Hypervisor mode), as evidenced by "CPU: All CPU(s) started at EL1" and "kvm [1]: HYP mode not available". KVM requires EL2 to function; without it, /dev/kvm cannot be created and all KVM tests fail. This is a platform/firmware configuration issue, not a kernel defect.
  3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only adds ADC5 Gen3 driver config). To enable KVM on qcs6490-rb3gen2: (1) Update the bootloader/firmware to boot the kernel at EL2 instead of EL1, or (2) Configure the board to enter EL2 before kernel handoff. If KVM support is not required for this platform, mark these tests as expected-to-skip in the LAVA job definition for qcs6490-rb3gen2.
  4. Detail analysis attachment: failed_case_job212465_4_detailed.md
  Case 5: ** KVM_Infra (and KVM_Driver, KVM_EL2_DTB — same root cause)
  1. Failed case: ** KVM_Infra (and KVM_Driver, KVM_EL2_DTB — same root cause)
  2. Root cause: /dev/kvm not present.
  3. Possible fix: Exclude KVM test cases from the CI test suite for qcs6490-rb3gen2 (and any other Gunyah-based platforms without nested virtualization support), or update the test suite to mark these tests as "SKIP" (expected unavailable) rather than "FAIL" when running on platforms where nested virtualization is architecturally unavailable. This is not a kernel bug — it is expected behavior on this platform.
  4. Detail analysis attachment: failed_case_job212465_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM infrastructure test failed because the qcs6490-rb3gen2 platform does not support virtualization — kernel reports "HYP mode not available" at boot, preventing /dev/kvm device creation. This is a pre-existing platform limitation unrelated to the PR (which only enables ADC5 Gen3 driver config).
  3. Possible fix: Exclude KVM tests from the CI test suite for qcs6490-rb3gen2 (and other platforms without EL2/HYP support), or mark them as expected failures for non-virtualization-capable platforms. This is not a kernel regression.
  4. Detail analysis attachment: failed_case_job212465_6_detailed.md
Job 212466 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Benign Firmware Load Failures (Suppressed)
  1. Failed case: Probe_Failure_Check — Benign Firmware Load Failures (Suppressed)
  2. Root cause: The test detected three firmware load failures during boot: regulatory.db (WiFi regulatory database) and two Bluetooth firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv). However, both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming that Bluetooth and WiFi drivers successfully loaded fallback firmware at runtime and are fully operational. These are known benign failures per LAVA suppression Rule 3 (Bluetooth) and the functional WiFi test passing indicates the regulatory.db failure is also benign.
  3. Possible fix: Suppress this failure as known benign per lava-known-benign-failures.md Rule 3. The Probe_Failure_Check test should be updated to exclude firmware load errors when corresponding functional tests (BT_ON_OFF, WiFi_OnOff) pass, as these indicate successful fallback firmware loading. No kernel or PR changes required — this is a test framework false positive.
  4. Detail analysis attachment: failed_case_job212466_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: The video-codec device (aa00000.video-codec) is not attached to any IOMMU group on lemans-evk, causing the SMMU validation test to fail its critical master protection check, even though SMMU/IOMMU subsystems are otherwise functional and 57 other platform devices are correctly protected.
  3. Possible fix: This is a pre-existing platform/DT configuration issue unrelated to the PR (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The video-codec device tree node for lemans likely lacks the required iommus property. Add the appropriate IOMMU stream ID mapping to the video-codec DT node in arch/arm64/boot/dts/qcom/sa8775p.dtsi (lemans SoC file), or if the hardware does not support IOMMU for this device, update the test's critical master list to exclude video-codec on lemans.
  4. Detail analysis attachment: failed_case_job212466_2_detailed.md
  Case 3: LAVA Test Infrastructure Issue — Test marked as "unfinished" despite normal completion
  1. Failed case: LAVA Test Infrastructure Issue — Test marked as "unfinished" despite normal completion
  2. Root cause: LAVA dispatcher marked the test definition 0_qcom-next-ci-premerge-tests as failed with error "Marking unfinished test run as failed" even though the test runner completed normally (<LAVA_TEST_RUNNER EXIT> received and acknowledged). The test suite ran to completion with 2 individual test failures (Probe_Failure_Check and smmu), but LAVA's internal state tracking incorrectly classified the run as "unfinished", triggering an infrastructure-level failure. This is not a kernel crash or build load failure — it is a LAVA framework issue with test completion detection.
  3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate the LAVA test definition for the 0_qcom-next-ci-premerge-tests suite to ensure proper test completion signaling. The test runner script should explicitly signal completion to LAVA before exiting. Review the LAVA job definition's test action timeout settings and ensure the test completion signal is properly formatted and sent before the timeout expires.
  4. Detail analysis attachment: failed_case_job212466_3_detailed.md
Job 212467 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the wireless-regdb package (containing regulatory.db) to the rootfs image build recipe, or suppress this specific firmware load failure in the Probe_Failure_Check test filter rules since it is a known benign pattern when built-in regulatory data is present and WiFi tests pass.
  4. Detail analysis attachment: failed_case_job212467_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test expects video encoder/decoder sub-devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to have individual IOMMU group attachments, but the qcom-venus driver on qcs615-ride uses "non legacy binding" where only the parent device (aa00000.video-codec) is attached to IOMMU group 7. The sub-devices are virtual V4L2 video devices that do not perform DMA independently and therefore do not require separate IOMMU group attachments.
  3. Possible fix: Update the smmu test script to recognize the "non legacy binding" pattern for qcom-venus video codec driver — when the parent video-codec device is attached to an IOMMU group and kernel log shows "non legacy binding", skip the check for encoder/decoder sub-device IOMMU attachments as they are not expected to have separate attachments in this binding model.
  4. Detail analysis attachment: failed_case_job212467_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 platform configuration issue, not a kernel bug. To resolve: (1) Update the LAVA test suite to skip KVM tests on platforms running under Gunyah hypervisor, OR (2) If KVM functionality is required, reconfigure the platform to boot Linux directly at EL2 without Gunyah (not recommended if Gunyah virtualization features are needed). The PR patch (ADC5 Gen3 driver enablement) is unrelated and does not cause this failure.
  4. Detail analysis attachment: failed_case_job212467_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 kernel bug or PR regression. To enable KVM testing on this platform, either: (1) Reconfigure the platform firmware/bootloader to boot Linux directly at EL2 without Gunyah, OR (2) Exclude KVM tests from the CI test suite for platforms configured with Gunyah hypervisor, OR (3) Use a different test platform that does not have Gunyah enabled.
  4. Detail analysis attachment: failed_case_job212467_4_detailed.md
  Case 5: KVM_Infra — KVM infrastructure test failure (pre-existing platform limitation)
  1. Failed case: KVM_Infra — KVM infrastructure test failure (pre-existing platform limitation)
  2. Root cause: KVM initialization failed during kernel boot because HYP (EL2 hypervisor) mode is not available on the qcs615-ride platform; the kernel message "kvm [1]: HYP mode not available" at boot time [3.202087s] indicates the CPU is not running at EL2 or the bootloader/firmware did not preserve EL2 for the kernel, preventing /dev/kvm device node creation.
  3. Possible fix: This is a pre-existing platform/firmware limitation unrelated to PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3); KVM requires EL2 hypervisor mode support from the bootloader/firmware — verify the qcs615-ride bootloader preserves EL2 for Linux, or mark KVM tests as expected-fail/skip for this platform in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job212467_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: The qcs615-ride platform does not support ARM EL2 (Hypervisor) mode, which is required for KVM virtualization. The kernel correctly detected this during KVM driver initialization and reported "HYP mode not available", preventing the creation of /dev/kvm device node.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The test should be skipped on platforms without virtualization support. Add platform capability detection to the test suite to skip KVM tests when CONFIG_KVM is enabled but HYP mode is unavailable. Alternatively, if EL2 support is expected on this platform, verify bootloader/firmware configuration enables EL2 mode before kernel handoff.
  4. Detail analysis attachment: failed_case_job212467_6_detailed.md
Job 212468 | SoC shikra-iqs-evk

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

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

  Case 1: ** GIC (Test Infrastructure Bug)
  1. Failed case: ** GIC (Test Infrastructure Bug)
  2. Root cause: ** The GIC test script contains a hardcoded assumption of 8 CPUs and attempts to parse timer interrupt counts for CPUs 4-7, which do not exist on the shikra-iqs-evk platform (4-CPU system). The bash script fails at line 75 with "integer expected" errors when trying to parse non-existent CPU columns from /proc/interrupts, causing false test failures for CPUs 4-7.
  3. Possible fix: Update the GIC test script (/lava-212468/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding 8 CPUs, and only validate timer counts for CPUs that actually exist on the platform.
  4. Detail analysis attachment: failed_case_job212468_1_detailed.md
  Case 2: ** Probe_Failure_Check — Pre-existing Platform Driver Probe Failures (Not PR-Introduced)
  1. Failed case: ** Probe_Failure_Check — Pre-existing Platform Driver Probe Failures (Not PR-Introduced)
  2. Root cause: ** Six pre-existing probe failures on shikra-iqs-evk: (1) coresight-etm4x etm0-3 fail with -EINVAL due to platform-specific ETM configuration mismatch, (2) cpufreq-dt fails with -EEXIST (benign race condition), (3) regulatory.db firmware missing (benign), (4) four devices remain in deferred probe due to missing clock/regulator/DAI dependencies in the platform DT or driver load order.
  3. Possible fix: These failures are not introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3=m for lemans/monaco platforms; shikra-iqs-evk does not use ADC5 Gen3 hardware). The failures are pre-existing platform issues. To resolve: (1) For coresight-etm4x: verify ETM DT nodes match hardware capabilities on shikra (error -22 suggests invalid configuration); (2) For deferred probes: ensure audio clock providers (mclk), sound CPU DAI, I2C device dependencies, and WiFi regulator (vdd-1.8-xo) are correctly described in shikra DT and drivers load in correct order; (3) cpufreq-dt and regulatory.db failures are benign and can be ignored.
  4. Detail analysis attachment: failed_case_job212468_2_detailed.md
  Case 3: USBHost
  1. Failed case: USBHost
  2. Root cause: Test infrastructure issue — USB controller on shikra-iqs-evk is not configured for host mode or no USB host devices are physically connected to the board. The test expects enumerated USB host devices but the USB subsystem shows only gadget mode activation. This is unrelated to the PR which only enables an ADC driver config option.
  3. Possible fix: This is a pre-existing board/lab configuration issue, not a kernel regression. To resolve: (1) verify USB port wiring on shikra-iqs-evk in the LAVA lab, (2) ensure a USB device (e.g., USB flash drive) is physically connected to the USB host port, (3) verify device tree dr_mode property for USB controller is set to "host" or "otg" (not "peripheral"), or (4) mark this test as SKIP for shikra-iqs-evk if the board does not support USB host mode in the current lab configuration.
  4. Detail analysis attachment: failed_case_job212468_3_detailed.md
  Case 4: BT_SCAN
  1. Failed case: BT_SCAN
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is NOT a kernel issue requiring a code fix. The PR (680635b) enables CONFIG_QCOM_SPMI_ADC5_GEN3 for ADC support and has zero impact on Bluetooth. To resolve the test failure, the LAVA lab infrastructure should either: (1) place a Bluetooth beacon/test device in discoverable mode within RF range of the shikra-iqs-evk board, OR (2) mark BT_SCAN as an optional/informational test that does not block PR merges when the lab environment lacks Bluetooth test devices.
  4. Detail analysis attachment: failed_case_job212468_4_detailed.md
  Case 5: ** KVM_Driver — Driver initialization failure (missing platform support)
  1. Failed case: ** KVM_Driver — Driver initialization failure (missing platform support)
  2. Root cause: ** The Shikra IQS EVK platform firmware does not provide EL2 (HYP/hypervisor mode) access to Linux. KVM requires EL2 to initialize; without it, the driver prints "HYP mode not available" and fails to create /dev/kvm. This is a platform/firmware limitation, not a kernel regression. The PR (enabling ADC5 Gen3 driver) is unrelated to virtualization and did not cause this failure.
  3. Possible fix: This is not a bug to fix but a platform limitation to document. If KVM support is required on Shikra IQS EVK: (1) Update platform firmware/bootloader to expose EL2 to Linux, or (2) Disable KVM tests for this platform in CI configuration, or (3) Mark KVM tests as expected-fail for platforms without EL2 support. The PR itself requires no changes.
  4. Detail analysis attachment: failed_case_job212468_5_detailed.md
  Case 6: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM driver initialization failed during boot because HYP (EL2 hypervisor) mode is not available on the Shikra IQS EVK platform, preventing /dev/kvm device node creation; CONFIG_KVM is enabled but the hardware/firmware does not support virtualization extensions required for KVM operation.
  3. Possible fix: This is a pre-existing platform limitation unrelated to the PR (which only enables ADC5 Gen3 driver); mark KVM tests as expected-to-fail or skip them on Shikra IQS EVK in the LAVA job definition, as this platform does not support ARM virtualization extensions (VHE/nVHE) required for KVM.
  4. Detail analysis attachment: failed_case_job212468_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Test infrastructure issue — /dev/kvm device node not present despite CONFIG_KVM=y, indicating KVM failed to initialize on shikra-iqs-evk platform (likely due to firmware/EL2 support limitations or silent initialization failure); unrelated kernel crash occurred in subsequent qcom_hwrng test due to synchronous external abort when qcom_rng driver accessed unmapped/unpowered hardware registers at 0xffff800082c55018
  3. Possible fix: Skip KVM tests on shikra-iqs-evk platform in LAVA job definition until KVM support is confirmed; blacklist qcom_rng module or skip qcom_hwrng test until platform team verifies RNG hardware availability and fixes device tree configuration (clocks, power domains, MMIO base address)
  4. Detail analysis attachment: failed_case_job212468_7_detailed.md
  Case 8: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: ** Hardware random number generator (qcom_rng) driver attempted to read from an MMIO register that triggered a synchronous external abort at PC qcom_rng_read+0xc4/0x228. This indicates the RNG hardware block was either not powered/clocked correctly, not accessible due to security policy, or the MMIO mapping is invalid for the shikra-iqs-evk platform. The crash occurred during the qcom_hwrng test execution at kernel timestamp [807.287042], causing the test suite to hang and eventually timeout after 2400 seconds.
  3. Possible fix: Verify that the qcom_rng device tree node for shikra (QCM2290) includes correct clock, power domain, and IOMMU properties. Check if the RNG hardware block requires explicit power-on or clock enablement before register access. Add runtime PM calls or clock enable/disable in the qcom_rng driver probe path if missing. If the hardware is not present or accessible on shikra-iqs-evk, disable the qcom_rng driver for this platform or mark the DT node as status = "disabled".
  4. Detail analysis attachment: failed_case_job212468_8_detailed.md
  Case 9: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: ** The qcom_rng driver crashed with a synchronous external abort (hardware bus fault) at 807 seconds into runtime while reading from the RNG hardware register during the qcom_hwrng test. The hardware block did not respond to the MMIO read, indicating the RNG peripheral is not correctly powered, clocked, or mapped on the Shikra IQS EVK (QCM2290) platform. This is a pre-existing platform/hardware issue, NOT introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables an ADC driver config).
  3. Possible fix: Investigate RNG hardware block power/clock dependencies on Shikra IQS EVK: verify the RNG device tree node includes correct clock/regulator/power-domain bindings for QCM2290, confirm the RNG power domain is enabled and clocks are running before driver access, and add runtime PM or clock/regulator enable calls in the qcom_rng driver probe path if missing. As an immediate workaround, disable the qcom_hwrng test case for Shikra IQS EVK until the hardware dependencies are resolved.
  4. Detail analysis attachment: failed_case_job212468_9_detailed.md
  Case 10: Kernel Crash — EFI Runtime Service Paging Fault leading to LAVA Test Timeout
  1. Failed case: Kernel Crash — EFI Runtime Service Paging Fault leading to LAVA Test Timeout
  2. Root cause: Kernel panic triggered by synchronous external abort in EFI runtime service (pstore backend write operation) at timestamp 807.848s. The qcom_rng driver triggered a page fault when accessing EFI runtime memory, causing cascading EFI paging faults and ultimately a fatal exception. The board rebooted after the panic, but the LAVA test shell timed out (2400s) waiting for the system to recover and continue testing.
  3. Possible fix: This is a pre-existing firmware/EFI runtime service bug on the shikra-iqs-evk platform, not introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The PR change is unrelated to EFI runtime services or RNG drivers. Recommended actions: (1) Disable EFI pstore backend on shikra-iqs-evk by removing efi=runtime from kernel cmdline or disabling CONFIG_EFI_VARS_PSTORE; (2) Investigate EFI firmware memory mapping issue on this platform; (3) Re-trigger the CI job to verify the ADC5 Gen3 driver change does not introduce other issues.
  4. Detail analysis attachment: failed_case_job212468_10_detailed.md
  Case 11: Kernel Crash — Synchronous External Abort in qcom_rng driver
  1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
  2. Root cause: The qcom_rng driver triggered a synchronous external abort (0x96000010) at PC qcom_rng_read+0xc4 while reading from hardware registers during the qcom_hwrng test, indicating the RNG hardware block was either not powered/clocked or the register mapping was invalid for the shikra-iqs-evk platform.
  3. Possible fix: Verify that the qcom_rng device tree node for shikra (QCM2290) includes correct reg property, clock references, and power domain bindings; if the hardware block is not present or functional on shikra-iqs-evk, mark the qcom_rng node as status="disabled" in the shikra device tree to prevent driver probe and avoid the crash.
  4. Detail analysis attachment: failed_case_job212468_11_detailed.md
Job 212469 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test detected 6 probe/firmware errors during boot on monaco-evk, but 2 are known benign (BT firmware false positives suppressed by passing BT_ON_OFF test). The 4 genuine errors are pre-existing platform issues unrelated to the PR: (1) cpufreq-dt probe failed with -EEXIST (driver already registered), (2) regulatory.db firmware missing (expected on some builds), (3-4) ath11k WiFi firmware load failed and probe timed out (WiFi_OnOff also failed, confirming genuine WiFi issue). The PR only enables CONFIG_QCOM_SPMI_ADC5_GEN3 for ADC support and does not touch WiFi, cpufreq, or regulatory subsystems.
  3. Possible fix: Mark Probe_Failure_Check as a false positive for this PR. The genuine probe failures (cpufreq-dt -EEXIST, regulatory.db missing, ath11k WiFi timeout) are pre-existing platform/infra issues on monaco-evk, not regressions introduced by enabling ADC5 Gen3 driver. To resolve the underlying issues: (1) investigate cpufreq-dt double-registration on monaco, (2) add regulatory.db to rootfs if required, (3) debug ath11k WiFi firmware path and probe timeout (check firmware availability, PCIe link, and MHI state on monaco-evk).
  4. Detail analysis attachment: failed_case_job212469_1_detailed.md
  Case 2: WiFi Driver Probe Failure — ath11k_pci probe timeout
  1. Failed case: WiFi Driver Probe Failure — ath11k_pci probe timeout
  2. Root cause: WiFi driver probe failed with -ETIMEDOUT (-110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing the MHI firmware load to fail with -ENOENT (-2) and the driver to time out waiting for the device to initialize.
  3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). This is a rootfs/build configuration issue, not a kernel regression introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3 for ADC support).
  4. Detail analysis attachment: failed_case_job212469_2_detailed.md
  Case 3: WiFi_OnOff
  1. Failed case: WiFi_OnOff
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Install the missing WCN6855 firmware file for the nfa765 board variant to /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin, or configure the device tree to use the standard firmware path without board-specific subdirectory if nfa765 variant firmware is not available.
  4. Detail analysis attachment: failed_case_job212469_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 runner marked the test definition as "unfinished" and failed because it exited after completing individual test cases but before processing all expected result files. The log shows <LAVA_TEST_RUNNER EXIT> followed immediately by "Marking unfinished test run as failed". Two .res files remained unprocessed: Ethernet_Basic_Validation.res and WiFi_OnOff.res.
  3. Possible fix: This is a LAVA test infrastructure issue, not a kernel regression introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The WiFi failures (ath11k_pci probe error -110) are pre-existing on monaco-evk and unrelated to the ADC5 Gen3 config change. Re-trigger the LAVA job; if the "unfinished" error recurs, investigate the test runner's exit logic and ensure all test result files are processed before the runner exits.
  4. Detail analysis attachment: failed_case_job212469_4_detailed.md
Job 212470 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Three pre-existing platform-specific probe failures unrelated to PR changes: (1) cpufreq-dt driver conflict (-EEXIST) indicating another cpufreq driver already registered for qcs8300, (2) missing regulatory.db firmware file in rootfs (-ENOENT), and (3) Aquantia AQR115C PHY missing required firmware-name DT property (-EINVAL).
  3. Possible fix: Suppress this test failure as false positive — all three probe failures are pre-existing platform/configuration issues unrelated to the PR (which only enables CONFIG_QCOM_SPMI_ADC5_GEN3). The PR does not modify cpufreq, cfg80211, or ethernet PHY drivers. To resolve the underlying issues: (1) disable CONFIG_CPUFREQ_DT or fix qcs8300 DT to use correct cpufreq driver, (2) add regulatory.db to rootfs firmware directory, (3) add firmware-name property to Aquantia PHY DT node.
  4. Detail analysis attachment: failed_case_job212470_1_detailed.md
  Case 2: USBHost (Test Infrastructure Issue — No External USB Device Connected)
  1. Failed case: USBHost (Test Infrastructure Issue — No External USB Device Connected)
  2. Root cause: The USBHost test failed because no functional USB device is physically connected to the qcs8300-ride board's USB port. The kernel USB subsystem initialized successfully (xHCI controller registered, USB bus 1 created, root hub detected with 1 port), but when the test enumerated USB devices using lsusb, only the root hub (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub) was present. The test logic requires at least one non-hub USB device to pass, resulting in the failure message "Only USB hubs detected, no functional USB devices."
  3. Possible fix: This is a test environment issue, not a kernel regression. The PR (enabling ADC5 Gen3 driver in defconfig) is unrelated to USB functionality. To resolve: (1) Connect a functional USB device (keyboard, mouse, flash drive, etc.) to the board's USB port before running the test, or (2) Update the test logic to skip/pass when no external USB device is available in the lab environment, or (3) Mark this test as expected-fail for boards without permanently attached USB peripherals in the LAVA job definition.
  4. Detail analysis attachment: failed_case_job212470_2_detailed.md
  Case 3: Ethernet_Basic_Validation
  1. Failed case: Ethernet_Basic_Validation
  2. Root cause: Aquantia AQR115C PHY driver probe failure due to missing or invalid firmware-name device tree property (error -22 / EINVAL), preventing the qcom-ethqos Ethernet MAC from attaching to the PHY and bringing up the eth0 interface.
  3. Possible fix: Add the required firmware-name property to the Aquantia AQR115C PHY device tree node under the MDIO bus (stmmac-0:08) in the qcs8300-ride device tree, specifying the correct firmware file path for the AQR115C PHY (typically Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LNXDRIVER.cld or platform-specific variant). If the firmware file is not present in /lib/firmware/, ensure it is included in the rootfs firmware directory.
  4. Detail analysis attachment: failed_case_job212470_3_detailed.md
  Case 4: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: /dev/kvm device node not created because the qcs8300-ride platform is running as a guest VM under Gunyah hypervisor (version gunyah-cdfb73831). KVM requires EL2 (hypervisor privilege level) access to create the /dev/kvm interface, but when Linux runs as a guest under an existing hypervisor, it operates at EL1 and cannot access EL2 virtualization extensions. CONFIG_KVM is enabled in the kernel configuration, but the KVM subsystem does not initialize because nested virtualization is not supported or enabled on this Gunyah hypervisor configuration.
  3. Possible fix: This is a pre-existing platform/infrastructure limitation, not a regression introduced by PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 (which only enables ADC5 Gen3 driver in defconfig). To enable KVM functionality on qcs8300-ride: (1) verify the Gunyah hypervisor version supports nested virtualization and enable it in the hypervisor configuration, OR (2) run the kernel directly on bare metal (EL2) instead of as a Gunyah guest, OR (3) mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as expected failures or skip them for qcs8300-ride LAVA jobs when running under Gunyah.
  4. Detail analysis attachment: failed_case_job212470_4_detailed.md
  Case 5: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-cdfb73831"), which occupies EL2 and prevents KVM from accessing ARM virtualization extensions; CONFIG_KVM is enabled but /dev/kvm is not created.
  3. Possible fix: Either (1) disable KVM tests in the LAVA job definition for qcs8300-ride targets that boot under Gunyah, or (2) configure the platform to boot without Gunyah if KVM functionality is required for testing.
  4. Detail analysis attachment: failed_case_job212470_5_detailed.md
  Case 6: KVM Infrastructure Unavailable — Gunyah Hypervisor Conflict
  1. Failed case: KVM Infrastructure Unavailable — Gunyah Hypervisor Conflict
  2. Root cause: QCS8300 Ride is running Gunyah hypervisor (gunyah-cdfb73831), which occupies ARM EL2 (hypervisor mode); KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present, resulting in /dev/kvm device node not being created despite CONFIG_KVM being enabled.
  3. Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM testing on QCS8300 Ride, boot the platform without Gunyah hypervisor (native/bare-metal mode) or use a different test platform that does not run Gunyah. Alternatively, exclude KVM tests from the CI test suite for Gunyah-enabled platforms.
  4. Detail analysis attachment: failed_case_job212470_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Pre-existing platform limitation — QCS8300 (Monaco) SoC does not support KVM virtualization at EL2; CONFIG_KVM is enabled in defconfig but the KVM driver does not initialize on this platform because the hardware/firmware does not provide the necessary virtualization extensions or hypervisor support.
  3. Possible fix: Mark KVM tests as "not applicable" for QCS8300/Monaco platform in the LAVA test suite configuration, or add a platform-specific skip condition that checks SoC compatibility before running KVM tests. This is not a kernel regression — the PR only adds ADC5 Gen3 driver config and does not touch KVM or virtualization code.
  4. Detail analysis attachment: failed_case_job212470_7_detailed.md
Job 212471 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Suppress this test failure as false positive for PR FROMLIST: arm64: defconfig: Enable ADC5 Gen3 driver #1010 validation. The PR change (enabling ADC5_GEN3 driver) is unrelated to these probe failures. For long-term platform health: (1) provision UEFI secure app in TZ firmware or disable qcom_qseecom_uefisecapp in defconfig if not needed, (2) fix hamoa PMIC multi-LED DT node reg property per qcom-spmi-lpg binding requirements, (3) optionally add regulatory.db to rootfs or suppress this benign firmware warning.
  4. Detail analysis attachment: failed_case_job212471_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test validation failure — six critical platform devices (five USB controllers at a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and one video codec at aa00000.video-codec) on hamoa-evk are missing IOMMU group attachments in the device tree, causing the SMMU baseport test to fail its critical master protection validation checks.
  3. Possible fix: Add missing iommus property entries to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video codec aa00000.video-codec in the hamoa-evk device tree, referencing the appropriate SMMU phandle and stream IDs to enable IOMMU protection for these critical masters.
  4. Detail analysis attachment: failed_case_job212471_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM driver initialization failed during kernel boot because HYP (EL2 hypervisor) mode is not available on the Hamoa IoT EVK platform — kernel log shows kvm [1]: HYP mode not available at boot time, preventing /dev/kvm device node creation.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The Hamoa IoT EVK does not support EL2 virtualization extensions or they are disabled in firmware. To resolve: (1) verify the SoC supports virtualization extensions and enable them in bootloader/firmware if disabled, OR (2) exclude KVM-dependent tests from the Hamoa test suite since this platform does not support KVM virtualization.
  4. Detail analysis attachment: failed_case_job212471_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM driver initialization failed because the hamoa-evk platform runs Gunyah hypervisor at EL2, leaving Linux kernel at EL1 without HYP mode access; KVM requires EL2/HYP mode to function.
  3. Possible fix: This is a platform configuration issue, not a kernel regression. The hamoa-evk board is configured to run Gunyah hypervisor, which prevents KVM from operating. To enable KVM testing on this platform, either: (1) reconfigure the bootloader/firmware to boot Linux directly at EL2 without Gunyah, or (2) exclude KVM tests from the hamoa-evk test suite since this platform is designed for Gunyah-based virtualization, not KVM.
  4. Detail analysis attachment: failed_case_job212471_4_detailed.md
  Case 5: KVM Infrastructure Test Failure — Platform Does Not Support Virtualization
  1. Failed case: KVM Infrastructure Test Failure — Platform Does Not Support Virtualization
  2. Root cause: KVM driver initialization fails with "HYP mode not available" because the Hamoa IoT EVK platform firmware does not enable EL2 (hypervisor mode), which is required for ARM64 KVM/virtualization support.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. If KVM support is required on Hamoa, the platform firmware must be updated to enable EL2. Otherwise, disable KVM tests for this platform in the CI configuration, as the hardware does not support virtualization.
  4. Detail analysis attachment: failed_case_job212471_5_detailed.md
  Case 6: KVM_Infra (Test Infrastructure / Platform Capability Mismatch)
  1. Failed case: KVM_Infra (Test Infrastructure / Platform Capability Mismatch)
  2. Root cause: The Hamoa IoT EVK platform is not configured to run in HYP mode (EL2), which is a mandatory prerequisite for ARM KVM virtualization. The kernel correctly detects this limitation at boot time and logs "kvm [1]: HYP mode not available", preventing KVM initialization and /dev/kvm device node creation. The test expects /dev/kvm to exist but this is a platform-level hardware/firmware configuration limitation, not a kernel software bug.
  3. Possible fix: This is not a PR-introduced regression (the PR only enables an ADC driver). The KVM test should be skipped on platforms that do not support HYP mode, or the Hamoa platform firmware/bootloader configuration should be updated to boot the kernel in EL2 (HYP mode) if virtualization support is required. For CI purposes, add a platform capability check to skip KVM tests on non-HYP platforms, or update the test job definition to exclude KVM tests for Hamoa.
  4. Detail analysis attachment: failed_case_job212471_6_detailed.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ndechesne Nicolas Dechesne (ndechesne) Awaiting requested review from ndechesne ndechesne was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@quic-kaushalk Kaushal Kumar (quic-kaushalk) Awaiting requested review from quic-kaushalk quic-kaushalk was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@aiquny aiquny Awaiting requested review from aiquny aiquny was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
1 more reviewer
@jprakash-qc jprakash-qc jprakash-qc approved these changes
Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@raryan-qcom @qcomlnxci @qlijarvis @jprakash-qc