QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage by shubammm · Pull Request #1067 · qualcomm-linux/kernel

shubammm (shubammm) · 2026-09-09T15:55:08Z

Update rgltr-min-voltage for cam-sensor0 (cmk_imx577), cam-sensor1
(og0a1b), and cam-sensor4 (imx688) on the Hamoa board from 1808000
to 1800000 to match the corrected vreg_l3m_1p8 / vreg_l4m_1p8 /
vreg_l6m_1p8 LDO regulator-min-microvolt value.

CRs-Fixed: 4665973

shubammm (shubammm) · 2026-09-10T11:20:54Z

qli-2.1 pull-request freeze

qcomlnxci · 2026-09-10T13:48:23Z

Test jobs on 9dbc406

qcomlnxci · 2026-09-10T13:48:28Z

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	◻️	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

Salendarsingh Gaud (sgaud-quic) · 2026-09-10T15:50:06Z

shubammm (@shubammm) please fix this sign-off issue :

Summary
Commit sha: [9dbc406](https://github.com/qualcomm-linux/kernel/pull/1067/commits/9dbc406e95a1a061735a67f660434f0a2ee9e1aa), Author: shubamm, Committer: shubamm; Expected "shubamm [shubamm@qti.qualcomm.com](mailto:shubamm@qti.qualcomm.com)", but got "Shubam Mishra [shubamm@qti.qualcomm.com](mailto:shubamm@qti.qualcomm.com)".

Update rgltr-min-voltage for cam-sensor0 (cmk_imx577), cam-sensor1 (og0a1b), and cam-sensor4 (imx688) on the Hamoa board from 1808000 to 1800000 to match the corrected vreg_l3m_1p8/vreg_l4m_1p8/ vreg_l6m_1p8 LDO regulator-min-microvolt value. Signed-off-by: Shubam Mishra <shubamm@qti.qualcomm.com>

qcomlnxci · 2026-09-11T10:16:30Z

Test jobs on 175171e

qcomlnxci · 2026-09-11T10:16:30Z

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
BT_FW_KMD_Service	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPUFreq_Validation	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	◻️	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	◻️	❌ Fail	⚠️ skip
Freq_Scaling	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	◻️	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	◻️	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	◻️	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	◻️	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	◻️	❌ Fail	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass

qcomlnxci · 2026-09-11T12:29:08Z

Test jobs on 175171e

qcomlnxci · 2026-09-11T12:29:12Z

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
BT_FW_KMD_Service	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPUFreq_Validation	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	◻️	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	◻️	❌ Fail	⚠️ skip
Freq_Scaling	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	◻️	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	◻️	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	◻️	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	◻️	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	◻️	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	◻️	❌ Fail	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass

qcomlnxci · 2026-09-11T13:19:11Z

Test jobs on 175171e

qcomlnxci · 2026-09-11T13:19:12Z

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	◻️	✅ Pass	⚠️ 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	✅ 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	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ 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	◻️	❌ Fail	❌ 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	✅ Pass	✅ 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	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass

qlijarvis · 2026-09-15T15:02:01Z

LAVA Failed Case Triage Summary

PR: #1067

Job 222525 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check — Benign Firmware Load Failure (False Positive)

Failed case: Probe_Failure_Check — Benign Firmware Load Failure (False Positive)

Root cause: The cfg80211 wireless regulatory subsystem attempted to load an optional external regulatory.db firmware file which is not present in the rootfs (error -2 / ENOENT). However, cfg80211 successfully loaded built-in X.509 regulatory certificates as fallback, and WiFi functionality is fully operational (WiFi_Firmware_Driver and WiFi_OnOff tests passed). This is a false positive test failure caused by the Probe_Failure_Check test being overly strict — it flags any firmware load error without validating whether the subsystem remains functional.

Possible fix: Suppress this specific regulatory.db firmware failure in the Probe_Failure_Check test logic by adding it to the known-benign firmware failures list, similar to how WiFi/BT firmware false positives are already suppressed when functional tests pass. The suppression condition should be: if "regulatory.db failed with error -2" AND WiFi_OnOff test passed, then suppress this failure.

Detail analysis attachment: failed_case_job222525_1_detailed.md

Case 2: smmu (Test Validation Failure — Not a Kernel Issue)

Failed case: smmu (Test Validation Failure — Not a Kernel Issue)

Root cause: The smmu test expects video-decoder and video-encoder child devices of the video-codec (aa00000.video-codec) to be individually attached to IOMMU groups, but the kernel correctly attaches only the parent video-codec device to IOMMU group 7. This is a test expectation mismatch, not a kernel regression. The PR modifies only hamoa-camera-sensor.dtsi (Hamoa board camera voltage settings), while the test runs on qcs615-ride — the failure is unrelated to the PR changes and represents a pre-existing test infrastructure issue.

Possible fix: Update the smmu test validation logic to accept IOMMU group attachment at the parent video-codec device level (aa00000.video-codec → group 7) without requiring separate attachments for child video-decoder and video-encoder devices, which are not separate platform devices but rather video4linux2 (V4L2) sub-devices that inherit IOMMU protection from their parent.

Detail analysis attachment: failed_case_job222525_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization fails because HYP mode (EL2) is not available to the kernel on qcs615-ride platform. The board boots under Gunyah hypervisor (version gunyah-1cb9db980) which occupies EL2, preventing KVM from initializing. Kernel log shows kvm [1]: HYP mode not available at boot. This is a pre-existing platform configuration issue, not a regression introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which only modifies camera sensor regulator voltages in device tree).

Possible fix: This is not a PR-introduced failure. The test should be skipped on qcs615-ride or any platform running under a Type-1 hypervisor (Gunyah) that occupies EL2. To enable KVM on this platform, the board would need to boot without Gunyah hypervisor, or use nested virtualization if supported. For CI purposes, exclude KVM tests from qcs615-ride test suite or mark them as expected-skip when Gunyah hypervisor is detected.

Detail analysis attachment: failed_case_job222525_3_detailed.md

Case 4: ** KVM_EL2_DTB

Failed case: ** KVM_EL2_DTB

Root cause: ** The qcs615-ride platform does not boot at EL2 (Hypervisor mode), preventing KVM ARM driver initialization. The kernel message kvm [1]: HYP mode not available indicates the platform lacks the required execution level for KVM functionality. This is a platform/firmware configuration limitation, not a kernel driver bug.

Possible fix: This is not a bug to fix. The qcs615-ride platform does not support KVM virtualization in its current firmware/bootloader configuration. To enable KVM: (1) verify the SoC supports virtualization extensions, (2) configure the bootloader/firmware to boot the kernel at EL2 instead of EL1, or (3) exclude KVM-related tests from the qcs615-ride test suite as they are not applicable to this platform configuration.

Detail analysis attachment: failed_case_job222525_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failed because the QCS615 platform does not support EL2/HYP mode — kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or virtualization extensions are disabled/unavailable on this SoC.

Possible fix: This is not a PR-introduced regression. The PR modifies camera sensor regulator voltages on Hamoa board (unrelated to KVM). QCS615-ride does not support KVM/virtualization. Exclude KVM tests from the QCS615-ride test suite, or mark them as expected-skip for platforms without virtualization support.

Detail analysis attachment: failed_case_job222525_5_detailed.md

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

Failed case: 0_qcom-next-ci-premerge-tests

Root cause: Could not be determined confidently from available logs.

Possible fix: Add platform capability detection to the LAVA test suite to skip KVM tests on platforms without EL2 support; check for /dev/kvm existence or parse dmesg for "HYP mode not available" before running KVM tests, and mark as SKIP (not FAIL) when virtualization is unavailable; alternatively, update the QCS615 test job definition to exclude KVM tests entirely.

Detail analysis attachment: failed_case_job222525_6_detailed.md

Job 222526 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: WiFi firmware file missing from rootfs (ath11k/WCN6855/hw2.1/nfa765/amss.bin not found, error -2/ENOENT), causing ath11k_pci probe to timeout (-110/ETIMEDOUT) during MHI power-up; Bluetooth firmware load failures are benign (BT_ON_OFF test passed, indicating runtime firmware load succeeded).

Possible fix: Add missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image under /lib/firmware/; alternatively, if the firmware path is incorrect for this board variant (nfa765), update the board-specific firmware path mapping in the ath11k driver or device tree to point to the correct firmware variant for Monaco EVK.

Detail analysis attachment: failed_case_job222526_1_detailed.md

Case 2: ** Driver Probe Failure — WiFi ath11k_pci (firmware dependency)

Failed case: ** Driver Probe Failure — WiFi ath11k_pci (firmware dependency)

Root cause: ** ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on Monaco EVK because the required WiFi firmware file /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the test image. The MHI subsystem attempted to load the firmware for the WCN6855 hw2.1 WiFi chip but received error -2 (ENOENT), causing the MHI power-up sequence to time out after waiting for firmware that never arrived.

Possible fix: Add the missing ath11k WCN6855 hw2.1 nfa765 firmware files to the Monaco EVK test image. The firmware package should include amss.bin and related files in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/. This is a test infrastructure/image packaging issue, not a kernel regression — the PR changes only Hamoa camera regulators and does not affect Monaco WiFi.

Detail analysis attachment: failed_case_job222526_2_detailed.md

Case 3: WiFi_OnOff — ath11k_pci probe failure

Failed case: WiFi_OnOff — ath11k_pci probe failure

Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware directory. The MHI bus power-up timed out waiting for firmware load, causing the entire WiFi driver initialization chain to fail.

Possible fix: Add the missing WCN6855 WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Yocto image recipe's firmware package (likely linux-firmware-ath11k or equivalent). Verify the firmware file is present in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ after image rebuild and reflash.

Detail analysis attachment: failed_case_job222526_3_detailed.md

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

Failed case: 0_qcom-next-ci-premerge-tests

Root cause: WiFi driver (ath11k_pci WCN6855) probe failure on monaco-evk due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image — MHI firmware load returned error -2 (ENOENT), causing MHI power-up timeout (-110 ETIMEDOUT) and complete probe failure. This is a pre-existing infrastructure/image packaging issue unrelated to the PR (which modifies Hamoa camera sensor DT, not monaco-evk or WiFi).

Possible fix: Add the missing WCN6855 firmware files to the monaco-evk rootfs image build recipe. The required firmware path is ath11k/WCN6855/hw2.1/nfa765/amss.bin and should be packaged from the linux-firmware repository or Qualcomm firmware drop. Verify the firmware package is included in the Yocto/distro image recipe for monaco-evk builds.

Detail analysis attachment: failed_case_job222526_4_detailed.md

Job 222527 | SoC qcs9100-ride

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

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

Case 1: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** Pre-existing platform-specific probe failures on qcs9100-ride: (1) Aquantia AQR115C Ethernet PHY fails probe with -EINVAL due to missing or incorrect firmware-name DT property, (2) four PMIC temp-alarm thermal sensors remain in deferred probe state due to missing thermal zone or IIO channel dependencies, (3) benign regulatory.db firmware load failure (false positive — WiFi functional tests passed).

Possible fix: These are pre-existing qcs9100-ride platform issues unrelated to PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which modifies Hamoa camera sensors). Recommended actions: (1) Add or correct the firmware-name property in the qcs9100-ride DT for the Aquantia PHY node at stmmac-0:08, (2) verify thermal zone bindings for the four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and ensure IIO channel providers are available, (3) suppress the regulatory.db false positive in the test harness (WiFi is functional).

Detail analysis attachment: failed_case_job222527_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device (aa00000.video-codec) on qcs9100-ride is missing IOMMU group attachment in device tree, causing SMMU test validation to fail. This is a pre-existing platform DT configuration issue unrelated to the PR (PR only modifies Hamoa camera sensor regulator voltages).

Possible fix: Add iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/qcs9100.dtsi to attach it to an appropriate SMMU context bank, following the pattern used by other DMA-capable devices on this SoC (GPU, display, USB, ethernet all have IOMMU group attachments).

Detail analysis attachment: failed_case_job222527_2_detailed.md

Case 3: USBHost — Test Infrastructure Issue

Failed case: USBHost — Test Infrastructure Issue

Root cause: The USBHost test failed because no external USB devices are physically connected to the qcs9100-ride board in the LAVA lab. The kernel USB subsystem initialized correctly (3 xhci-hcd buses registered: Bus 001, 002, 003), but only USB root hubs are enumerated. The test expects at least one functional USB device beyond the root hubs. This is a test environment/hardware setup issue, not a kernel regression. The PR changes camera sensor regulator voltages on the Hamoa board and does not touch USB drivers or qcs9100-ride device tree.

Possible fix: Connect a functional USB device (e.g., USB flash drive, keyboard, or mouse) to one of the USB ports on the qcs9100-ride board in the LAVA lab. If USB devices are already connected, verify physical connections, cable integrity, and power delivery. If this is expected behavior for this board configuration, update the test to skip USBHost validation on qcs9100-ride or adjust the test criteria to pass when USB controllers are functional even without external devices.

Detail analysis attachment: failed_case_job222527_3_detailed.md

Case 4: Driver Probe Failure — Ethernet PHY Attachment

Failed case: Driver Probe Failure — Ethernet PHY Attachment

Root cause: Aquantia AQR115C PHY driver probe failed with error -22 (-EINVAL) due to missing firmware-name property in device tree, causing qcom-ethqos Ethernet driver to fail PHY attachment for end0 interface on qcs9100-ride board. This is a pre-existing platform/DT issue unrelated to the PR (PR only modifies Hamoa camera sensor regulator voltages).

Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs9100-ride device tree, or configure the PHY driver to use a default firmware path when the property is absent. This is a board-specific DT fix required for qcs9100-ride Ethernet functionality.

Detail analysis attachment: failed_case_job222527_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

Root cause: The qcs9100-ride platform boots with the Gunyah Type-1 hypervisor active, which takes exclusive control of EL2 (Hypervisor mode). KVM requires direct EL2 access to initialize and create /dev/kvm, but detects "HYP mode not available" because Gunyah has already claimed EL2. This is expected architectural behavior when a Type-1 hypervisor is present.

Possible fix: Skip KVM tests on qcs9100-ride and other Gunyah-enabled platforms by adding a test precondition check that detects Gunyah presence in dmesg and exits with SKIP status. Update LAVA device type definitions to include platform capability metadata (hypervisor: gunyah, kvm_supported: false) and modify KVM test definitions to check these capabilities before execution.

Detail analysis attachment: failed_case_job222527_5_detailed.md

Case 6: KVM_EL2_DTB — Platform Limitation (No EL2 Support)

Failed case: KVM_EL2_DTB — Platform Limitation (No EL2 Support)

Root cause: The qcs9100-ride platform does not support ARM Virtualization Extensions (EL2/Hypervisor mode). KVM initialization detects "HYP mode not available" at boot (line 3126) and fails to create /dev/kvm. This is a hardware/firmware limitation, not a kernel defect or PR-introduced regression.

Possible fix: Update the KVM_EL2_DTB test to skip on platforms without EL2 support by checking for the "HYP mode not available" kernel message in dmesg, or add qcs9100-ride to a platform-specific test exclusion list. Alternatively, if EL2 support is expected on this platform, investigate firmware/bootloader configuration to ensure the kernel is entered at EL2 (not EL1).

Detail analysis attachment: failed_case_job222527_6_detailed.md

Case 7: KVM Infrastructure Failure — KVM driver initialization failed (HYP mode not available)

Failed case: KVM Infrastructure Failure — KVM driver initialization failed (HYP mode not available)

Root cause: The qcs9100-ride (SA8775P/LeMans) platform is not running in a hypervisor mode that supports KVM virtualization. The kernel boot log shows "kvm [1]: HYP mode not available" and the bootloader message "Skipping overlay of hyp dt nodes for non-Gunyah hypervisor" confirms the platform is not configured with a KVM-compatible hypervisor (requires EL2/HYP mode). CONFIG_KVM is enabled in the kernel but the hardware/firmware is not configured to provide the required EL2 virtualization support.

Possible fix: This is a platform configuration issue, not a kernel regression. The qcs9100-ride board firmware/bootloader must be configured to boot in hypervisor mode (EL2) with a KVM-compatible hypervisor (e.g., Gunyah in KVM mode or native KVM). Either: (1) exclude KVM tests from the CI test suite for this platform configuration, or (2) flash a firmware image that enables hypervisor mode and provides EL2 support for KVM.

Detail analysis attachment: failed_case_job222527_7_detailed.md

Case 8: KVM_Infra (Test Infrastructure Limitation — Not a Kernel Regression)

Failed case: KVM_Infra (Test Infrastructure Limitation — Not a Kernel Regression)

Root cause: KVM cannot initialize on qcs9100-ride because Gunyah hypervisor is already running at EL2; kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm creation despite CONFIG_KVM being enabled.

Possible fix: This is not a PR-introduced regression (PR only modifies Hamoa camera sensor DT voltages, unrelated to KVM/virtualization). The test failure is expected platform behavior: qcs9100-ride boots with Gunyah hypervisor by default, which occupies EL2 and prevents KVM from running. To enable KVM testing, either: (1) boot the board without Gunyah hypervisor (requires bootloader/firmware configuration change), or (2) exclude KVM tests from the CI test suite for boards configured with Gunyah.

Detail analysis attachment: failed_case_job222527_8_detailed.md

Job 222528 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Pre-existing platform issue on qcs8300-ride: deferred probe for 3440000.pinctrl device and missing regulatory.db firmware file in rootfs. Not PR-introduced (PR modifies Hamoa camera sensors; test runs on qcs8300-ride).

Possible fix: Suppress this test failure for the PR as it is unrelated to camera sensor voltage changes. Platform team should independently: (1) investigate and resolve 3440000.pinctrl deferred probe dependency issue in qcs8300 DT, and (2) add wireless-regdb package to rootfs or suppress benign regulatory.db firmware load errors in the test.

Detail analysis attachment: failed_case_job222528_1_detailed.md

Case 2: ** USBHost

Failed case: ** USBHost

Root cause: ** Test infrastructure issue — the USBHost test expects a functional USB device (keyboard, mouse, storage, etc.) to be physically connected to the qcs8300-ride board's USB host port in the LAVA lab, but no such device is present. The kernel USB subsystem is fully functional: xhci-hcd driver loaded successfully, USB2 hub initialized with 1 port detected, and no USB-related kernel errors. The test failure message explicitly states "Only USB hubs detected, no functional USB devices" — this is a test environment configuration issue, not a kernel bug.

Possible fix: Connect a functional USB device (e.g., USB flash drive, keyboard, or mouse) to the qcs8300-ride board's USB host port in the LAVA lab setup. If the test is intended to verify USB host controller functionality only (not external device enumeration), update the test script to pass when the USB host controller initializes successfully and at least one USB port is detected, rather than requiring an external device.

Detail analysis attachment: failed_case_job222528_2_detailed.md

Case 3: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

Root cause: Could not be determined confidently from available logs.

Possible fix: Verify qcs8300-ride board hardware (SerDes reference clock, power rails, signal integrity); check bootloader SerDes initialization; review qcs8300 SGMII PHY device tree configuration (clock rates, regulator bindings, phy-mode); consult platform team for known qcs8300 Ethernet hardware errata or required board modifications.

Detail analysis attachment: failed_case_job222528_3_detailed.md

Case 4: KVM_Driver — /dev/kvm device node not present

Failed case: KVM_Driver — /dev/kvm device node not present

Root cause: QCS8300 Ride platform is running as a guest under Gunyah hypervisor (evidenced by gunyah-md-region@91a80000 reserved memory region at boot), which prevents nested virtualization; KVM driver initialization is silently skipped because the kernel detects it is not running at EL2 with VHE/nVHE support, resulting in no /dev/kvm device node creation despite CONFIG_KVM=y.

Possible fix: This is a platform architectural limitation, not a kernel bug or PR-introduced regression. The KVM_Driver test should be skipped on QCS8300 Ride (and other Gunyah-guest platforms) via LAVA job definition test selection, or the test itself should detect Gunyah presence and report SKIP instead of FAIL. No kernel code change is required.

Detail analysis attachment: failed_case_job222528_4_detailed.md

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

Failed case: KVM_EL2_DTB — KVM device node unavailable (platform limitation)

Root cause: QCS8300 Ride platform runs Gunyah hypervisor at EL2, preventing KVM initialization. KVM requires exclusive EL2 access but Gunyah already occupies it. This is an architectural incompatibility, not a kernel bug.

Possible fix: This is not a fixable issue — it is expected platform behavior. KVM and Gunyah cannot coexist. Either: (1) Skip KVM tests on Gunyah-based platforms (recommended), or (2) Use a different platform without Gunyah if KVM testing is required. Update CI test matrix to exclude KVM tests for QCS8300/Gunyah platforms.

Detail analysis attachment: failed_case_job222528_5_detailed.md

Case 6: ** KVM_Infra — /dev/kvm unavailable (platform configuration issue)

Failed case: ** KVM_Infra — /dev/kvm unavailable (platform configuration issue)

Root cause: ** The qcs8300-ride target is running as a guest under Gunyah hypervisor. KVM requires EL2 access to initialize, but guest VMs run at EL1 and cannot access hypervisor mode. CONFIG_KVM is enabled but the KVM driver cannot create /dev/kvm because nested virtualization is not supported or enabled in the Gunyah configuration.

Possible fix: Exclude KVM tests from the qcs8300-ride LAVA test suite, as this platform runs under Gunyah and does not support nested virtualization. Alternatively, if nested KVM support is required, enable nested virtualization in the Gunyah hypervisor configuration and rebuild the firmware.

Detail analysis attachment: failed_case_job222528_6_detailed.md

Case 7: ** KVM_Infra (test infrastructure limitation — not a kernel regression)

Failed case: ** KVM_Infra (test infrastructure limitation — not a kernel regression)

Root cause: ** The QCS8300-ride platform runs under Gunyah hypervisor, which occupies EL2. KVM requires exclusive EL2 access and cannot initialize when a hypervisor is already running. CONFIG_KVM is enabled in the kernel config, but the /dev/kvm device node is never created because KVM initialization is skipped at boot. This is a pre-existing platform architectural constraint, not a PR-introduced regression. The PR only modifies camera sensor regulator voltages in device tree (hamoa-camera-sensor.dtsi), which has no relationship to KVM or virtualization.

Possible fix: Mark this test as "expected to fail" or "not applicable" for QCS8300-ride in the LAVA test suite, since this platform runs under Gunyah hypervisor and cannot support nested virtualization. Alternatively, disable KVM tests for platforms running under a hypervisor, or run KVM tests only on bare-metal configurations where EL2 is available to the kernel.

Detail analysis attachment: failed_case_job222528_7_detailed.md

Job 222529 | SoC shikra-iqs-evk

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

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

Case 1: GIC (Test Script Bug)

Failed case: GIC (Test Script Bug)

Root cause: The GIC test script has a parsing bug at line 75 that fails to correctly extract interrupt counts from /proc/interrupts when the system has only 4 CPUs (0-3), causing it to attempt comparison on non-existent CPUs 4-7 and parse non-numeric fields ("GICv3", "Level", "arch_timer") as integers.

Possible fix: Update the GIC test script (/lava-222529/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 and only validate timer interrupts for CPUs that actually exist on the platform.

Detail analysis attachment: failed_case_job222529_1_detailed.md

Case 2: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Could not be determined confidently from available logs.

Possible fix: Mark test as expected failure for shikra-iqs-evk baseline. PR1067 does not introduce any new probe failures (changes only affect Hamoa board). To resolve underlying issues: (1) fix ETM DT nodes with required properties, (2) suppress cpufreq-dt probe when qcom-cpufreq-hw is active, (3) verify lt9611c hardware presence and I2C bus configuration, (4) add regulatory.db to rootfs, (5) allow more time for audio deferred probe resolution before running test.

Detail analysis attachment: failed_case_job222529_2_detailed.md

Case 3: USBHost

Failed case: USBHost

Root cause: USB host controller driver (dwc3-qcom/xhci-plat-hcd) did not probe during boot — no dwc3 or xhci driver messages present in kernel log despite USB PHY drivers (phy_qcom_qmp_usbc, phy_qcom_qusb2) loading successfully. The USB controller at 4e00000.usb is configured in gadget mode (systemd reached "Hardware activated USB gadget" target), preventing host mode operation. This is a pre-existing platform/kernel configuration issue unrelated to the PR's camera sensor regulator voltage changes on Hamoa board.

Possible fix: Verify USB DT node at /soc@0/usb@4e00000 has dr_mode = "host" or dr_mode = "otg" (not "peripheral"), ensure dwc3-qcom and xhci-plat-hcd drivers are built and loaded (CONFIG_USB_DWC3_QCOM=y/m, CONFIG_USB_XHCI_PLATFORM=y/m), and confirm no userspace gadget configuration is forcing peripheral mode. If the test requires external USB device presence, verify hardware setup includes a USB host cable/adapter and a USB device plugged into the shikra-iqs-evk board.

Detail analysis attachment: failed_case_job222529_3_detailed.md

Case 4: BT_SCAN

Failed case: BT_SCAN

Root cause: Bluetooth scan test failed to discover any devices after 3 attempts with 15-second scan windows. The Bluetooth adapter (hci0) was powered on and visible to bluetoothctl, but no nearby Bluetooth devices were detected during the scan period. This is a test environment issue — no scannable Bluetooth devices were present in the RF environment around the shikra-iqs-evk board during the test execution.

Possible fix: Ensure at least one active Bluetooth device (phone, beacon, or dedicated test device) is present and discoverable within RF range of the shikra-iqs-evk board before running the BT_SCAN test. Alternatively, update the test to be optional or provide a mock/loopback Bluetooth device in the LAVA lab environment for consistent test execution.

Detail analysis attachment: failed_case_job222529_4_detailed.md

Case 5: KVM_Driver — /dev/kvm device node unavailable (driver probe failure)

Failed case: KVM_Driver — /dev/kvm device node unavailable (driver probe failure)

Root cause: KVM driver initialization failed during early boot because HYP (Hypervisor/EL2) mode is not available on the Shikra IQS EVK platform. Kernel message at boot time [3.298803]: "kvm [1]: HYP mode not available" indicates the CPU is not running in EL2 or EL2 is not accessible, preventing KVM from creating the /dev/kvm device node despite CONFIG_KVM=y being enabled.

Possible fix: This is a platform/firmware limitation, not a kernel bug. KVM requires EL2 (Hypervisor mode) support which must be enabled by the bootloader/firmware. To enable KVM on Shikra IQS EVK: (1) verify the SoC supports virtualization extensions (ARM Virtualization Extensions v8.0+), (2) configure the bootloader (ABL/UEFI) to boot the kernel at EL2 instead of EL1, or (3) if the platform does not support EL2, mark KVM tests as expected-to-skip for this board in the CI configuration.

Detail analysis attachment: failed_case_job222529_5_detailed.md

Case 6: Kernel Crash — Synchronous External Abort (qcom_rng hardware access fault)

Failed case: Kernel Crash — Synchronous External Abort (qcom_rng hardware access fault)

Root cause: The KVM_EL2_DTB test failure is a false positive caused by a kernel crash in the preceding qcom_hwrng test. The crash occurred when the qcom_rng driver attempted to read a hardware register from an unpowered or clock-gated RNG block on Shikra IQS EVK, resulting in a synchronous external abort (ESR 0x96000010) at PC qcom_rng_read+0xc4. The system panicked and rebooted; KVM_EL2_DTB then failed because /dev/kvm was not available in the post-reboot state. This is a pre-existing Shikra platform power management issue, NOT introduced by PR 1067 (which modifies Hamoa camera sensor DTS on a different platform).

Possible fix: Short-term: Skip qcom_hwrng test on Shikra in CI until fixed. Long-term: Add runtime PM support to qcom_rng driver (pm_runtime_get_sync before register access, pm_runtime_put after), verify Shikra DTS RNG node has correct power-domains property, and ensure RNG clocks are enabled before access. Verify fix by running qcom_hwrng test 100 times without crash.

Detail analysis attachment: failed_case_job222529_6_detailed.md

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

Failed case: Kernel Crash — synchronous external abort in qcom_rng driver

Root cause: Hardware RNG (qcom_rng) driver triggered a synchronous external abort (bus error 0x96000010) at PC qcom_rng_read+0xc4 while reading from MMIO registers during the qcom_hwrng test on Shikra IQS EVK, causing kernel panic and system crash. The KVM_Infra test failure (/dev/kvm not available) is a pre-existing configuration issue unrelated to the crash.

Possible fix: This is a hardware/firmware-level bus access fault in the qcom_rng driver on Shikra IQS EVK, not introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which only modifies Hamoa camera sensor DT). Investigate: (1) whether the RNG hardware block is properly powered/clocked on Shikra, (2) whether the MMIO register map in the qcom_rng driver matches the Shikra SoC variant, (3) whether firmware has disabled or misconfigured the RNG block. Short-term: disable the qcom_hwrng test on Shikra until root-caused. Long-term: add defensive MMIO access checks in qcom_rng_read and validate hardware block availability before register access.

Detail analysis attachment: failed_case_job222529_7_detailed.md

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

Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

Root cause: ** The kernel crashed with a synchronous external abort (bus fault) while the qcom_rng driver attempted to read a hardware register at offset 0x4 from the RNG base address during the qcom_hwrng test. The CPU received an external abort response from the bus, indicating the RNG hardware is either not powered, not clocked, not mapped correctly, or in a fault state. This is a pre-existing hardware/driver issue on the Shikra IQS EVK platform, unrelated to the PR changes (which only affect camera sensor regulators on the Hamoa board). After the panic, the system entered warm reset and ramdump mode, and LAVA timed out waiting for test completion.

Possible fix: Short-term: Skip the qcom_hwrng test on Shikra IQS EVK boards in the LAVA job definition to unblock CI while the root cause is investigated. Long-term: Debug the RNG hardware access fault by verifying device tree configuration (clocks, regulators, power domains, interconnects), enabling runtime PM/clock debugging, checking for hardware errata, and testing with reduced load. Once the root cause is identified (likely missing clock enable, wrong power domain, or hardware errata), apply the appropriate fix (DT update, driver patch, or workaround) and re-enable the test after validating stability across 10+ LAVA runs.

Detail analysis attachment: failed_case_job222529_8_detailed.md

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

Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver

Root cause: Hardware access fault in qcom_rng_read() at offset +0xc4 during qcom_hwrng test execution; synchronous external abort (ESR 0x96000010) indicates the RNG hardware register read failed, likely due to clock/power gating or incorrect MMIO mapping for the Shikra platform's RNG hardware block.

Possible fix: Verify qcom_rng device tree node for shikra-iqs-evk includes correct reg address, clocks, and power-domain properties; ensure RNG hardware block is powered and clocked before driver access; add runtime PM calls or explicit clock/regulator enable in qcom_rng probe path; cross-check with working platforms' DT and compare MMIO base addresses.

Detail analysis attachment: failed_case_job222529_9_detailed.md

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

Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

Root cause: ** The qcom_hwrng test triggered a synchronous external abort (bus error) at PC qcom_rng_read+0xc4 when the qcom_rng driver attempted to read from a hardware register. The abort indicates the hardware RNG block was either not clocked/powered, had an invalid MMIO mapping, or the register access violated platform security policy. After the crash, the kernel panic handler attempted to write to EFI pstore but encountered repeated "Unable to handle paging request in EFI runtime service" errors, then entered warm reset/ramdump mode as configured by reboot=panic_warm. The LAVA test shell timed out after 2400 seconds (40 minutes) waiting for the board to recover from ramdump mode, which never completed.

Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR (which only modifies Hamoa camera sensor DT voltage values). The qcom_rng driver crash on shikra-iqs-evk indicates a platform-specific hardware access failure. Recommended actions: (1) Verify qcom_rng DT node clock/power-domain/reg properties for shikra-iqs-evk are correct and match hardware documentation. (2) Check if RNG hardware block requires explicit clock/regulator enable before register access. (3) Add error handling in qcom_rng_read to detect and gracefully handle bus faults. (4) For immediate CI unblocking: skip or disable the qcom_hwrng test on shikra-iqs-evk until the root cause is fixed, as this is a known platform instability.

Detail analysis attachment: failed_case_job222529_10_detailed.md

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

Failed case: Kernel Crash — synchronous external abort in qcom_rng driver

Root cause: The qcom_hwrng test triggered a synchronous external abort (memory access fault) at PC qcom_rng_read+0xc4 when the qcom_rng driver attempted to read from hardware RNG registers, indicating the RNG hardware block is either not powered, not clocked, or the MMIO mapping is invalid on shikra-iqs-evk.

Possible fix: Add missing clock/regulator/power-domain dependencies for the qcom_rng device node in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts (or the SoC dtsi), ensure the RNG hardware block is properly enabled in the device tree with correct clocks, clock-names, and power-domains properties, and verify the MMIO region is correctly mapped and accessible.

Detail analysis attachment: failed_case_job222529_11_detailed.md

Job 222530 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Could not be determined confidently from available logs.

Possible fix: These are pre-existing hamoa-evk platform issues, not regressions introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067. The PR changes only camera sensor regulator voltages and does not affect QSEECOM, SPMI-LPG, or WiFi regulatory subsystems. Recommend: (1) Suppress these known failures in CI for hamoa-evk, or (2) Fix upstream: add regulatory.db to rootfs, correct SPMI-LPG multi-LED DT node reg property, and investigate QSEECOM TrustZone resource conflict.

Detail analysis attachment: failed_case_job222530_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Could not be determined confidently from available logs.

Possible fix: Add iommus = <&apps_smmu 0x... 0x0>; properties to the six missing device nodes in arch/arm64/boot/dts/qcom/hamoa.dtsi (or the appropriate hamoa DT include file). Reference the existing USB controller nodes (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb) which already have correct iommus properties, and apply the same pattern to the PHY nodes and video codec node.

Detail analysis attachment: failed_case_job222530_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: Could not be determined confidently from available logs.

Possible fix: This is not a PR-introduced regression (PR only modifies camera sensor regulator voltages in DT). The failure is a pre-existing platform configuration issue. Recommended action: If KVM functionality is required on Hamoa, the platform must be configured to boot without Gunyah hypervisor, or use a nested virtualization approach if supported. If KVM is not required for this platform, mark the KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as "not applicable" for Hamoa-based CI runs to prevent false failures. For immediate CI unblocking: add Hamoa to the KVM test skip list in the LAVA test definition.

Detail analysis attachment: failed_case_job222530_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: Hamoa platform lacks hardware virtualization support (EL2/HYP mode). The kernel correctly detects this at boot with "kvm [1]: HYP mode not available", preventing /dev/kvm device creation. CONFIG_KVM is enabled but cannot initialize without EL2 hardware support.

Possible fix: Exclude KVM tests from the Hamoa test suite, as this platform does not support hardware virtualization. Add a platform capability check to skip KVM tests on non-virtualization-capable SoCs (check for /dev/kvm presence or CONFIG_KVM runtime availability before running KVM test suite).

Detail analysis attachment: failed_case_job222530_4_detailed.md

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

Failed case: ** KVM Driver Initialization Failure — HYP mode not available

Root cause: ** The KVM driver detected at boot time that the CPU is not running in EL2 (Hypervisor Exception Level), preventing KVM initialization and /dev/kvm device creation; this is a platform limitation of the Hamoa IoT EVK where the bootloader boots the kernel at EL1 without EL2 access, not a regression introduced by the PR's camera sensor regulator voltage changes.

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR changes camera sensor regulator voltages (unrelated to virtualization). To enable KVM on Hamoa: (1) verify the SoC supports virtualization extensions (ARMv8.0-A with VHE or ARMv8.1-A+), (2) configure the bootloader (UEFI) to boot the kernel at EL2 instead of EL1, (3) ensure TrustZone firmware does not lock EL2 access. If the platform does not support EL2, disable KVM tests for this target or mark them as expected-to-skip in the CI configuration.

Detail analysis attachment: failed_case_job222530_5_detailed.md

Case 6: ** KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)

Failed case: ** KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)

Root cause: ** Platform does not support ARM EL2 (Hypervisor) mode required for KVM virtualization. Kernel correctly detects "HYP mode not available" at boot (line: kvm [1]: HYP mode not available), preventing /dev/kvm device creation. This is a hardware/firmware platform constraint on the Hamoa IoT EVK, not a kernel bug.

Possible fix: This is a pre-existing platform limitation unrelated to the PR (which only changes camera sensor regulator voltages). The KVM tests should be skipped or marked as expected-fail for hamoa-evk platform in the CI test matrix, as this SoC does not provide EL2 virtualization support. No kernel or PR changes required.

Detail analysis attachment: failed_case_job222530_6_detailed.md

Job 222531 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test detected deferred probe devices (four SPMI PMIC temp-alarm devices at c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) that are known benign — BT_ON_OFF and WiFi_OnOff functional tests both passed, confirming Bluetooth and WiFi subsystems are operational despite the firmware load error messages during early boot.

Possible fix: Suppress this test failure as a false positive — the deferred probe devices are waiting for dependencies that may resolve later or are non-critical, and the firmware load failures are known benign per lava-known-benign-failures.md Rule 2 and Rule 3 (WiFi and BT functional tests passed). The PR changes (hamoa-camera-sensor.dtsi regulator voltage corrections for a different SoC) are unrelated to lemans-evk SPMI/PMIC/firmware issues. No kernel or PR fix required.

Detail analysis attachment: failed_case_job222531_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Test infrastructure issue — the SMMU test expects a video codec device at aa00000.video-codec to be present and attached to an IOMMU group, but lemans-evk SoC uses the Iris video codec driver which creates iris_non_pixel.0 and iris_pixel.0 devices instead (both correctly attached to IOMMU groups 25 and 27). The test's hardcoded device path does not match the actual video codec implementation on this platform.

Possible fix: Update the SMMU test script to recognize platform-specific video codec device naming — for lemans-evk, check for iris_non_pixel.0 and iris_pixel.0 instead of aa00000.video-codec, or make the test query the actual video codec compatible string from device tree and resolve the corresponding platform device dynamically.

Detail analysis attachment: failed_case_job222531_2_detailed.md

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

Failed case: 0_qcom-next-ci-premerge-tests

Root cause: LAVA test definition marked as failed due to two genuine test failures within the test suite: (1) smmu test failed because video codec device aa00000.video-codec is missing IOMMU group attachment, and (2) Probe_Failure_Check test failed due to firmware load errors. The kernel booted successfully and all tests executed; this is NOT a build load failure or kernel crash. The PR changes camera sensor regulator voltages on Hamoa board, which is unrelated to the lemans-evk SoC where this test ran, indicating these are pre-existing platform issues not introduced by the PR.

Possible fix: The smmu failure is a genuine platform configuration issue on lemans-evk where the video codec device lacks IOMMU protection. This requires a device tree fix to add the video codec device to an IOMMU group. The Probe_Failure_Check failure is due to missing firmware files (regulatory.db, Bluetooth firmware) which are expected on production systems but may be absent in CI test images. These are pre-existing lemans-evk platform issues unrelated to the PR's Hamoa camera sensor voltage changes. Re-run the test on the correct target (Hamoa) or accept these known lemans-evk platform limitations.

Detail analysis attachment: failed_case_job222531_3_detailed.md

Job 222532 | SoC qcs6490-rb3gen2

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

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

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

Failed case: ** GIC (Test Infrastructure Bug — Not a Kernel Issue)

Root cause: ** The GIC test script fails to validate CPU online status before parsing /proc/interrupts. CPUs 6-7 failed to boot during kernel initialization (PSCI error -22 at boot time, pre-existing platform/firmware issue unrelated to the PR). The script attempts to parse interrupt counts for offline CPUs 6-7, receives "GICv3" (interrupt controller name) instead of a number, and hits bash error at line 75: [: GICv3: integer expected.

Possible fix: Update the GIC test script to check /sys/devices/system/cpu/online and only test online CPUs. For the underlying CPU boot failure, investigate PSCI/firmware/device-tree configuration for CPUs 6-7 on qcs6490-rb3gen2 (separate issue, not PR-related).

Detail analysis attachment: failed_case_job222532_1_detailed.md

Case 2: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** Two probe/firmware errors detected: (1) regulatory.db firmware load failure (benign — cfg80211 falls back to built-in regulatory rules; WiFi unaffected), and (2) Renesas xHCI PCIe USB controller probe failure due to missing proprietary firmware file renesas_usb_fw.mem (-ENOENT). This is a pre-existing firmware packaging issue on the qcs6490-rb3gen2 test image, unrelated to the PR's camera sensor voltage changes on Hamoa board.

Possible fix: Add the Renesas USB firmware package to the rootfs build: install linux-firmware package or manually add renesas_usb_fw.mem to /lib/firmware/. For the regulatory.db warning, either install wireless-regdb package or suppress this known-benign failure in the Probe_Failure_Check test filter rules (regulatory DB is optional; built-in rules are sufficient).

Detail analysis attachment: failed_case_job222532_2_detailed.md

Case 3: Freq_Scaling

Failed case: Freq_Scaling

Root cause: Test infrastructure issue — the Freq_Scaling test expects all 8 CPUs (cpu0-cpu7) on qcs6490-rb3gen2 to have cpufreq interfaces, but CPUs 6 and 7 failed to boot during kernel initialization with PSCI error -22 (EINVAL), causing the test to fail when it couldn't find cpu7's cpufreq interface despite cpu0-cpu6 passing.

Possible fix: This is a pre-existing platform/firmware issue unrelated to the PR (which modifies camera sensor voltage on Hamoa board). The test should be updated to handle platforms where not all CPUs successfully boot, or the underlying PSCI/firmware issue causing CPUs 6-7 boot failure should be investigated and fixed.

Detail analysis attachment: failed_case_job222532_3_detailed.md

Case 4: USBHost

Failed case: USBHost

Root cause: USB host controller driver (xhci-pci-renesas) probe failed with error -2 (ENOENT) due to missing firmware file renesas_usb_fw.mem, preventing USB device enumeration on the qcs6490-rb3gen2 platform.

Possible fix: Install the missing Renesas USB firmware file (renesas_usb_fw.mem) in /lib/firmware/ on the target rootfs, or add the firmware package to the Yocto/build configuration if using a distro build. Alternatively, if the Renesas USB host controller is not required for this platform, blacklist the xhci-pci-renesas driver module.

Detail analysis attachment: failed_case_job222532_4_detailed.md

Case 5: KVM_Driver — /dev/kvm not available

Failed case: KVM_Driver — /dev/kvm not available

Root cause: qcs6490-rb3gen2 platform runs under Gunyah hypervisor which occupies EL2; KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present, resulting in "HYP mode not available" and no /dev/kvm device node creation.

Possible fix: This is expected behavior on Gunyah-enabled platforms. To enable KVM testing: (1) use a non-Gunyah build configuration for this platform, or (2) mark KVM tests as "skip" for Gunyah-enabled builds in the LAVA test definition, or (3) test KVM functionality on platforms without Gunyah hypervisor.

Detail analysis attachment: failed_case_job222532_5_detailed.md

Case 6: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM/virtualization not supported on qcs6490-rb3gen2 (Kodiak) platform — kernel reports "HYP mode not available" at boot, indicating the platform firmware/bootloader does not enable EL2 (hypervisor mode), which is a prerequisite for KVM functionality. /dev/kvm device node is not created because the KVM driver initialization fails when EL2 is unavailable.

Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which only modifies camera sensor regulator voltages). To enable KVM on this platform: (1) verify the bootloader/firmware supports EL2 mode and is configured to boot the kernel at EL2 or enable VHE (Virtualization Host Extensions), (2) if the platform does not support EL2 in hardware or firmware, disable KVM tests for qcs6490-rb3gen2 in the CI test suite, or (3) mark these tests as expected failures for this specific platform.

Detail analysis attachment: failed_case_job222532_6_detailed.md

Case 7: KVM Infrastructure Test — Platform Configuration Mismatch

Failed case: KVM Infrastructure Test — Platform Configuration Mismatch

Root cause: KVM cannot initialize on qcs6490-rb3gen2 because Gunyah hypervisor is running at EL2, preventing KVM from accessing the hypervisor privilege level required for virtualization. This is an architectural limitation, not a kernel bug. The PR changes (camera sensor voltage) are unrelated to KVM.

Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test suite, or run KVM tests on a platform without Gunyah enabled. If KVM testing is required on this SoC, boot without Gunyah (requires bootloader/firmware configuration change to not load Gunyah at EL2).

Detail analysis attachment: failed_case_job222532_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM infrastructure test failed because /dev/kvm device node is not present; kernel reports "HYP mode not available" at boot, indicating the qcs6490-rb3gen2 platform does not support ARM virtualization extensions (EL2) or they are disabled by the bootloader/firmware.

Possible fix: This is a pre-existing platform limitation unrelated to PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which only modifies camera sensor regulator voltages). The KVM tests should be skipped for qcs6490-rb3gen2 in the CI test plan, or the platform firmware should be updated to enable EL2 if the hardware supports it.

Detail analysis attachment: failed_case_job222532_8_detailed.md

Job 222533 | SoC purwa-evk

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

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

Case 1: login-action

Failed case: login-action

Root cause: Could not be determined confidently from available logs.

Possible fix: This is a pre-existing kernel bug in the MSM DRM driver on purwa-evk, not introduced by this PR. The PR should not be blocked by this failure. To fix the underlying issue: investigate why msm_disp_snapshot_add_block receives a NULL pointer (likely a missing initialization or resource allocation failure in the display snapshot path), add NULL pointer checks before dereferencing, and ensure proper error handling in the display snapshot initialization sequence for purwa-evk.

Detail analysis attachment: failed_case_job222533_1_detailed.md

Case 2: Kernel Crash — NULL pointer dereference in MSM DRM display snapshot

Failed case: Kernel Crash — NULL pointer dereference in MSM DRM display snapshot

Root cause: Kernel panic at boot due to NULL pointer dereference in msm_disp_snapshot_add_block+0x188 triggered by DPU encoder frame timeout during display initialization; the crash occurs in the display snapshot capture path when attempting to dereference a NULL pointer (virtual address 0x0000000000000000) while processing DisplayPort snapshot state after a frame done timeout on encoder 40.

Possible fix: This is a pre-existing kernel bug in the MSM DRM driver's display snapshot code, not introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (which only modifies camera sensor regulator voltages in DT). The NULL pointer dereference indicates missing validation in msm_disp_snapshot_add_block() when handling DP snapshot data structures. Recommended fix: Add NULL pointer check in drivers/gpu/drm/msm/disp/msm_disp_snapshot.c:msm_disp_snapshot_add_block() before dereferencing the block pointer at offset +0x188, and investigate why the DP snapshot context is not properly initialized when msm_dp_snapshot() is called following a frame timeout.

Detail analysis attachment: failed_case_job222533_2_detailed.md

Case 3: ** Kernel Crash — NULL pointer dereference in MSM DRM display snapshot

Failed case: ** Kernel Crash — NULL pointer dereference in MSM DRM display snapshot

Root cause: ** NULL pointer dereference at virtual address 0x0000000000000000 in msm_disp_snapshot_add_block+0x188/0x3c8 within the MSM DRM driver. The crash occurred in the disp_snapshot kthread worker during display snapshot state capture, triggered by a prior display error (panel probe warning). The function attempted to dereference a NULL pointer (register x2 = 0x0000000000000000), causing a fatal exception and kernel panic. This is a pre-existing kernel bug in the MSM DRM driver's error-handling path, unrelated to the PR's camera sensor regulator voltage changes.

Possible fix: Apply a NULL pointer check in msm_disp_snapshot_add_block() before dereferencing block pointers. Add defensive code: if (!block || !block->base_addr) return; at the function entry. As a short-term workaround, disable display snapshot capture via kernel config. This issue is NOT introduced by PR QCLINUX: arm64: dts: qcom: Update Hamoa camera sensor regulator voltage #1067 (camera sensor DT changes); it is a latent bug in the MSM DRM driver exposed by display initialization on purwa-evk.

Detail analysis attachment: failed_case_job222533_3_detailed.md

Case 4: ** Kernel Crash — NULL pointer dereference in display driver snapshot code

Failed case: ** Kernel Crash — NULL pointer dereference in display driver snapshot code

Root cause: ** The display driver's msm_disp_snapshot_add_block function dereferences a NULL pointer (x27 = 0x0) when attempting to capture debug state after a display encoder frame timeout. The crash occurs in the disp_snapshot kthread at timestamp 13.075s, immediately following a "dpu_encoder_frame_done_timeout" error at 13.066s. This is a pre-existing kernel bug in the display driver's error-handling/debug path, not introduced by the PR (which modifies Hamoa camera DTS while the test runs on Purwa EVK).

Possible fix: This is a pre-existing kernel bug unrelated to the PR changes. The display driver's snapshot code must validate pointers before dereferencing. Immediate mitigation: re-trigger the CI job to confirm the failure reproduces independently of this PR. Long-term fix: patch drivers/gpu/drm/msm/disp/msm_disp_snapshot.c to add NULL pointer checks in msm_disp_snapshot_add_block before accessing snapshot block data structures, especially in the error/timeout path triggered by dpu_encoder_frame_done_timeout.

Detail analysis attachment: failed_case_job222533_4_detailed.md

qlijarvis · 2026-09-15T23:16:40Z