FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access by xueyaoan · Pull Request #1018 · qualcomm-linux/kernel

xueyaoan · 2026-08-26T10:56:28Z

GPIOs 14-17 are routed to the SPI5 bus on the Shikra EVK boards. These pins were incorrectly included in the tlmm gpio-reserved-ranges, preventing Linux from claiming the SPI5 controller. SPI5 is needed to support the ST33 discrete TPM connected to the EVK boards.

Since there is no TZ use case for these pins, remove them from the reserved list in shikra-cqm-evk.dtsi, shikra-cqs-evk.dtsi and shikra-iqs-evk.dtsi.

Fixes: 234030f ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")

Link: https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
qcom-next PR: qualcomm-linux/kernel-topics#1743
CRs-Fixed: 4654974

qcomlnxci · 2026-08-26T13:11:43Z

Test jobs on 21ad900

qcomlnxci · 2026-08-26T13:11:45Z

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

Salendarsingh Gaud (sgaud-quic)

No Tag in commit message ?

qcomlnxci · 2026-08-31T10:46:50Z

Test jobs on 8f71305

qcomlnxci · 2026-08-31T10:46:51Z

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	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	⚠️ skip	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ 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	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	✅ 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	◻️

qcomlnxci · 2026-09-01T05:44:36Z

Test jobs on 8f71305

qcomlnxci · 2026-09-01T05:44:37Z

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	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	⚠️ skip	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ 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	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	✅ 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)

Shikra is not booting with this, please check
https://lava-oss.qualcomm.com/scheduler/job/218379

Salendarsingh Gaud (sgaud-quic) · 2026-09-02T10:12:26Z

This PR is dependent on boot bins which is not consumed by meta-qcom, once boot bins are available this will go through CI again.

psarma-qcom · 2026-09-10T16:53:55Z

qli-2.1 pull-request freeze

Salendarsingh Gaud (sgaud-quic) · 2026-09-10T17:17:01Z

This PR is dependent on boot bins which is not consumed by meta-qcom, once boot bins are available this will go through CI again.

Comment if this is taken care of ?

Also rebase PR on tip

psarma-qcom · 2026-09-10T17:39:50Z

This PR is dependent on boot bins which is not consumed by meta-qcom, once boot bins are available this will go through CI again.

Comment if this is taken care of ?

Also rebase PR on tip

Seems firmware PR is approved, however not merged yet.
qualcomm-linux/meta-qcom#3075

xueyaoan please take care of rebase.

xueyaoan · 2026-09-11T04:15:58Z

Rebased on top of latest tip.

qcomlnxci · 2026-09-12T08:36:37Z

Test jobs on 054b33f

qcomlnxci · 2026-09-12T08:36:39Z

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	◻️
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	◻️	❌ Fail	✅ 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	◻️

qcomlnxci · 2026-09-12T16:22:18Z

Test jobs on 054b33f

qcomlnxci · 2026-09-12T16:22:27Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	◻️	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ 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	✅ Pass	◻️
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	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

qcomlnxci · 2026-09-13T05:08:32Z

Test jobs on 054b33f

qcomlnxci · 2026-09-13T05:08:33Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ 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	✅ Pass	◻️
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	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

Salendarsingh Gaud (sgaud-quic) · 2026-09-13T12:40:58Z

Rebased on top of latest tip.

Shikra device crashed even after updating the bootbins, please check.
https://lava-oss.qualcomm.com/scheduler/job/227350

… SPI5 access GPIOs 14-17 are routed to the SPI5 bus on the Shikra EVK boards. These pins were incorrectly included in the tlmm gpio-reserved-ranges, preventing Linux from claiming the SPI5 controller. SPI5 is needed to support the ST33 discrete TPM connected to the EVK boards. Since there is no TZ use case for these pins, remove them from the reserved list in shikra-cqm-evk.dtsi, shikra-iqs-evk.dtsi and shikra-cqs-evk.dtsi. Fixes: 234030f ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm") Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/

xueyaoan · 2026-09-13T13:46:41Z

Rebased on top of latest tip.

Shikra device crashed even after updating the bootbins, please check. https://lava-oss.qualcomm.com/scheduler/job/227350

Fixed. Could you please re-trigger the LAVA job?

qcomlnxci · 2026-09-13T21:03:52Z

Test jobs on f63d0de

qcomlnxci · 2026-09-13T21:03:53Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	◻️
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	◻️
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ 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	✅ Pass	◻️
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	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

Salendarsingh Gaud (sgaud-quic) · 2026-09-14T12:15:57Z

Rebased on top of latest tip.

Shikra device crashed even after updating the bootbins, please check. https://lava-oss.qualcomm.com/scheduler/job/227350

Fixed. Could you please re-trigger the LAVA job?

Shikra bootup still failed :
https://lava-oss.qualcomm.com/scheduler/job/227451

qcomlnxci · 2026-09-15T18:22:39Z

Test jobs on f63d0de

qcomlnxci · 2026-09-15T18:22:41Z

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	❌ Fail
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	⚠️ skip	◻️	✅ Pass	⚠️ skip	◻️	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	◻️	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	◻️	✅ 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	⚠️ skip	◻️	✅ 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

qlijarvis · 2026-09-15T21:48:04Z

PR #1018 — validate-patch

PR: #1018

Verdict	Issues	Detailed Report
❌	6	Full report

Final Summary

Lore link present: Yes — https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
Lore link matches PR commits: No — PR modifies 3 EVK .dts files (shikra-cqm-evk.dts, shikra-cqs-evk.dts, shikra-iqs-evk.dts) while lore modifies 2 SOM .dtsi files (shikra-cqm-som.dtsi, shikra-iqs-som.dtsi). Completely different file set. Subject line also differs. Fixes tag present in PR but missing in lore.
Upstream patch status: ✅ Upstreamed — Bjorn Andersson applied the lore patch on Sep 2, 2026 as commit cc7b14be66ed with Abel Vesa's Reviewed-by. However, the lore patch that was merged modifies different files than this PR.
PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1018 — FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access
Upstream commit: https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
Verdict: ❌ FAIL

Commit Message

Check Status Note

Subject matches upstream ❌ PR: "Fix gpio-reserved-ranges to allow SPI5 access" vs Lore: "Unreserve GPIOs 14-17 blocking SPI5 access" — different wording

Body preserves rationale ⚠️ PR body is more detailed than lore; lore is shorter and less specific about EVK board variants

Fixes tag present/correct ⚠️ PR has Fixes: 234030fb4824 but lore patch does NOT have this tag (Abel Vesa noted this in review)

Authorship preserved ✅ Both have Xueyao An <xueyao.an@oss.qualcomm.com> as author; FROMLIST allows submitter in From:

Backport note (if applicable) N/A Not a backport

Diff

File Status Notes

File set mismatch ❌ PR changes 3 EVK .dts files; lore changes 2 SOM .dtsi files — completely different files!

arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts ❌ PR only — not in lore patch

arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts ❌ PR only — not in lore patch

arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts ❌ PR only — not in lore patch

arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi ❌ Lore only — not in PR

arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi ❌ Lore only — not in PR

Issues

1. File Set Mismatch (CRITICAL)

The PR and lore patches modify completely different files:

PR patch removes <14 4> from gpio-reserved-ranges in:

shikra-cqm-evk.dts

shikra-cqs-evk.dts

shikra-iqs-evk.dts

Lore patch removes <14 4> from gpio-reserved-ranges in:

shikra-cqm-som.dtsi

shikra-iqs-som.dtsi

This is a fundamental mismatch. The PR does not faithfully represent the lore patch — it applies the same logical change (unreserving GPIOs 14-17) but to a different set of device tree files.

2. Subject Line Mismatch

PR: Fix gpio-reserved-ranges to allow SPI5 access

Lore: Unreserve GPIOs 14-17 blocking SPI5 access

While semantically similar, the wording differs.

3. Fixes Tag Discrepancy

The PR includes Fixes: 234030fb4824 but the lore patch does NOT. Abel Vesa's review comment explicitly noted "No fixes tag?" — indicating the lore patch was missing this tag. The PR appears to have added it independently.

4. Commit Message Body Differs

PR body mentions specific board variants: "remove them from the reserved list in shikra-cqm-evk.dtsi, shikra-iqs-evk.dtsi and shikra-cqs-evk.dtsi"

Lore body mentions: "Removing them from the reserved list across all three Shikra EVK variants (CQM, CQS, IQS)"

The PR body references .dtsi files but the PR actually changes .dts files.

Verdict

Do NOT merge. This PR does not faithfully represent the lore patch it claims to be from. The file set is completely different — the lore patch modifies SOM .dtsi files while the PR modifies EVK .dts files. While the logical intent (unreserving GPIOs 14-17) may be the same, this is a different implementation targeting different device tree hierarchy levels.

Required Actions:

Clarify intent: Is this PR meant to be a faithful FROMLIST: cherry-pick of the lore patch, or is it a related but separate change?

If faithful cherry-pick intended: The PR must be updated to match the lore patch exactly:

Change files to shikra-cqm-som.dtsi and shikra-iqs-som.dtsi

Update subject to match lore: "Unreserve GPIOs 14-17 blocking SPI5 access"

Remove the Fixes tag (or post a v2 to lore with the Fixes tag first)

If this is a separate/additional change: Remove the FROMLIST: prefix and the lore link. Use QCLINUX: or PENDING: prefix instead, and explain why the EVK .dts files need this change in addition to (or instead of) the SOM .dtsi files.

Address the missing CQS file in lore: The lore patch only touches CQM and IQS SOM files, but the PR touches CQM, CQS, and IQS EVK files. If CQS needs the change, the lore patch may be incomplete.

Final Summary

Lore link present: Yes — https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/

Lore link matches PR commits: No — PR modifies 3 EVK .dts files (shikra-cqm-evk.dts, shikra-cqs-evk.dts, shikra-iqs-evk.dts) while lore modifies 2 SOM .dtsi files (shikra-cqm-som.dtsi, shikra-iqs-som.dtsi). Completely different file set. Subject line also differs. Fixes tag present in PR but missing in lore.

Upstream patch status: ✅ Upstreamed — Bjorn Andersson applied the lore patch on Sep 2, 2026 as commit cc7b14be66ed with Abel Vesa's Reviewed-by. However, the lore patch that was merged modifies different files than this PR.

PR present in qcom-next/topics: Fail — per integration_presence_report.md, this PR commit (with its specific file changes to EVK .dts files) is missing from both qcom-next and topics. This is consistent with the finding that the lore patch (which modifies SOM .dtsi files) is what was merged upstream, not this PR's version.

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: d49c33864d06e9672dce57738be8851384578fcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final

1/1 [PATCH] FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing

Final Status

overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-09-15T21:48:06Z

PR #1018 — checker-log-analyzer

PR: #1018
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/34561519198

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 warning: incorrect Fixes: tag format
dt-binding-check	⏭️	No binding changes
dtb-check	✅	All DTB validations passed
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	Content mismatch with upstream link
tag-check	✅	Subject has valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1018 - FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34561519198

Checker Result Summary

checkpatch ❌ 1 warning: incorrect Fixes: tag format

dt-binding-check ⏭️ No binding changes

dtb-check ✅ All DTB validations passed

sparse-check ⏭️ No C/H file changes

check-uapi-headers ⏭️ No UAPI changes

check-patch-compliance ❌ Content mismatch with upstream link

tag-check ✅ Subject has valid FROMLIST: prefix

❌ checkpatch

Root cause: The Fixes: tag references commit 234030f but the subject line in the tag is missing the "PENDING:" prefix that was present in the original commit.

Failure details:
WARNING: Please use correct Fixes: style 'Fixes: <12+ chars of sha1> ("<title line>")' - ie: 'Fixes: 234030fb4824 ("PENDING: arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")'
#16: 
Fixes: 234030fb4824 ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")

054b33f89810a2d4ac000688b84714a6cc43b09b total: 0 errors, 1 warnings, 0 checks, 24 lines checked
Fix: Update the Fixes: tag to include the exact subject line from the original commit:
git rebase -i acbf23d72fa0   # mark commit 054b33f89810 as 'edit'
# Edit the commit message to change:
# Fixes: 234030fb4824 ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
# to:
# Fixes: 234030fb4824 ("PENDING: arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
git commit --amend
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git acbf23d72fa0..054b33f89810
❌ check-patch-compliance

Root cause: The patch content in the PR differs from the upstream patch posted at the lore.kernel.org link.

Failure details:
Checking commit: FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access
Change is different from the one mentioned in Link
Analysis: The checker detected that the diff in commit 054b33f does not exactly match the patch posted at https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/

This could be due to:

Context line differences — the surrounding code may have changed between when the patch was posted and when it was applied to this tree

Additional changes — the PR may include extra hunks not present in the upstream patch

Missing changes — the PR may be missing hunks from the upstream patch

Fix: Fetch the upstream patch and compare:
# Fetch the upstream patch
b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/ -o /tmp/upstream

# Compare the actual changes (+ and - lines only)
git format-patch -1 054b33f89810 --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]' > /tmp/pr_changes.txt
awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]' > /tmp/upstream_changes.txt
diff /tmp/pr_changes.txt /tmp/upstream_changes.txt
Action required:

If the difference is only in context lines (lines starting with space), this is a false positive due to tree divergence — document this in the PR description

If there are actual code differences, either:

Update the PR to match the upstream patch exactly, OR

Document the intentional differences in the commit message (e.g., "Adapted for vendor tree context")

Reproduce locally:
cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . --base acbf23d72fa0 --head 054b33f89810
Verdict

2 blockers must be fixed before merge:

checkpatch — Fix the Fixes: tag to include the "PENDING:" prefix in the subject line

check-patch-compliance — Investigate and resolve the content mismatch with the upstream patch

The checkpatch issue is straightforward to fix. The check-patch-compliance issue requires investigation to determine if it's a legitimate difference or a false positive due to context changes.

qlijarvis · 2026-09-16T07:28:41Z

LAVA Failed Case Triage Summary

PR: #1018

Job 225921 | SoC qcs6490-rb3gen2

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

Failed test cases in LAVA job 225921 (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 has a parsing bug that fails when CPUs are present/possible but not online. CPUs 6-7 failed to boot during kernel initialization (PSCI error -22: EINVAL), leaving only CPUs 0-5 online. The test script at line 75 attempts to parse interrupt counts for all 8 CPUs from /proc/interrupts, but the file only contains 6 columns (for online CPUs 0-5). When parsing CPU6/7 columns, the script reads "GICv3" (the interrupt controller name from the next field) instead of an integer, triggering a bash arithmetic error: [: GICv3: integer expected.

Possible fix: This is not a kernel regression introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies GPIO reserved ranges for Shikra boards and does not affect qcs6490-rb3gen2). The CPU6/7 boot failure is a pre-existing platform/firmware limitation on this board. Recommended action: Update the GIC test script to handle the case where possible CPUs are not online — the script should iterate only over /sys/devices/system/cpu/online CPUs or skip CPUs that have no corresponding column in /proc/interrupts. Alternatively, mark this test as expected-fail or skip it on platforms where not all possible CPUs boot successfully.

Detail analysis attachment: failed_case_job225921_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: Add the linux-firmware-renesas package (or equivalent containing renesas_usb_fw.mem) to the Yocto/buildroot image recipe for qcs6490-rb3gen2 test images. Alternatively, if the Renesas USB controller is not required for CI testing, suppress this specific probe failure in the Probe_Failure_Check test script by adding xhci-pci-renesas to the known-benign probe failure exclusion list.

Detail analysis attachment: failed_case_job225921_2_detailed.md

Case 3: Freq_Scaling

Failed case: Freq_Scaling

Root cause: Test script expects cpufreq interfaces for all present CPUs (0-7), but CPUs 6 and 7 failed to boot during kernel initialization (PSCI error -22) and remain permanently offline, so they have no cpufreq interfaces exposed.

Possible fix: Update the Freq_Scaling test script to iterate only through online CPUs (from /sys/devices/system/cpu/online) instead of present CPUs, or skip CPUs that don't have cpufreq interfaces without failing the test.

Detail analysis attachment: failed_case_job225921_3_detailed.md

Case 4: USBHost

Failed case: USBHost

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

Possible fix: Install the missing Renesas USB firmware package (renesas_usb_fw.mem) in the root filesystem image at /lib/firmware/. For Yocto/OE builds, add linux-firmware-renesas to IMAGE_INSTALL or ensure the firmware-renesas package is included. For immediate CI unblocking, either: (1) add the firmware file to the build artifacts, or (2) investigate why the on-SoC DWC3 USB controllers are not probing and fix the DWC3 driver initialization for qcs6490-rb3gen2.

Detail analysis attachment: failed_case_job225921_4_detailed.md

Case 5: BT_SCAN (Test Infrastructure / Environmental Issue)

Failed case: BT_SCAN (Test Infrastructure / Environmental Issue)

Root cause: Bluetooth scan test failed because no discoverable Bluetooth devices were present in the LAVA lab environment during the 3 scan attempts (15 seconds each). The Bluetooth stack is fully functional (BT_ON_OFF test passed, hci0 adapter operational, power on/off working, discovery start/stop working), but the test requires at least one external Bluetooth device to be discoverable within RF range to pass.

Possible fix: This is a test infrastructure issue, not a kernel regression. The PR changes only Shikra SPI5/GPIO device tree entries and does not affect qcs6490-rb3gen2 Bluetooth functionality. Recommended actions: (1) Verify a Bluetooth beacon/test device is powered on and discoverable in the LAVA lab near the rb3gen2 board; (2) If no test device is available, mark BT_SCAN as expected-fail or skip for this board in the CI configuration; (3) Re-run the test with a known-good Bluetooth device in range to confirm scan functionality.

Detail analysis attachment: failed_case_job225921_5_detailed.md

Case 6: KVM_Driver

Failed case: KVM_Driver

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

Possible fix: This is not a kernel bug or PR-introduced regression. The KVM_Driver test is not applicable to boards running under a hypervisor (PVM configuration). Recommended action: Update the LAVA test suite to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) when the system is running under a hypervisor. Add a pre-test check: if dmesg | grep -q "Hypervisor cold boot"; then echo "SKIP: KVM tests not applicable under hypervisor"; exit 0; fi. Alternatively, configure the test suite to run KVM tests only on bare-metal (non-virtualized) board configurations by adding board capability filtering at job generation time.

Detail analysis attachment: failed_case_job225921_6_detailed.md

Case 7: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

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

Possible fix: Exclude KVM-dependent tests from qcs6490-rb3gen2 (Kodiak) test suite, or disable Gunyah hypervisor in the build configuration if KVM functionality is required. KVM and Gunyah are mutually exclusive on ARM platforms.

Detail analysis attachment: failed_case_job225921_7_detailed.md

Case 8: KVM_Infra — KVM device node unavailable (platform configuration issue)

Failed case: KVM_Infra — KVM device node unavailable (platform configuration issue)

Root cause: The qcs6490-rb3gen2 board is not booting with EL2/HYP mode enabled. The kernel reports "HYP mode not available" at boot (line 2962), preventing KVM initialization and /dev/kvm creation. This is a platform/firmware/bootloader configuration issue, not a kernel regression. The PR changes only GPIO reserved ranges for Shikra boards and is unrelated to KVM or the rb3gen2 platform.

Possible fix: This is not a PR-introduced regression. The failure is pre-existing infrastructure/platform configuration. To enable KVM on qcs6490-rb3gen2: (1) verify the bootloader/firmware boots the kernel in EL2 mode (check bootloader configuration and secure boot settings), (2) confirm CONFIG_KVM and CONFIG_ARM64_VHE are enabled in the kernel config, (3) verify the device tree does not disable virtualization. For CI purposes, either fix the platform configuration or mark KVM tests as expected-fail/skip for rb3gen2 until EL2 boot is enabled.

Detail analysis attachment: failed_case_job225921_8_detailed.md

Case 9: 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: This is a pre-existing platform/bootloader limitation, not a regression introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies Shikra DTS GPIO reserved ranges). The qcs6490-rb3gen2 board requires bootloader/firmware configuration to boot Linux at EL2 to enable KVM support. No kernel code change can fix this; either update the board's bootloader to enable EL2 boot, or mark KVM tests as expected-fail/skip for this platform in the CI configuration.

Detail analysis attachment: failed_case_job225921_9_detailed.md

Job 225922 | SoC monaco-evk

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

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

Case 1: ** Probe_Failure_Check — ath11k_pci WiFi driver probe failure

Failed case: ** Probe_Failure_Check — ath11k_pci WiFi driver probe failure

Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT (-110) on Monaco EVK because the required board-variant-specific firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware package. The MHI (Modem Host Interface) power-up sequence timed out waiting for firmware load, causing the entire probe sequence to fail. This is a pre-existing firmware packaging issue on Monaco EVK, unrelated to the PR (which modifies Shikra GPIO configuration).

Possible fix: Add the missing WCN6855 board-variant firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin and related files) to the Monaco EVK rootfs firmware package, or configure the ath11k driver/device-tree to use the standard WCN6855 firmware path (ath11k/WCN6855/hw2.1/amss.bin) if board-variant-specific firmware is not required for Monaco EVK.

Detail analysis attachment: failed_case_job225922_1_detailed.md

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

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

Root cause: ** The ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image. The MHI (Modem Host Interface) subsystem attempted to load the firmware during WiFi card power-up but received error -2 (ENOENT, file not found), causing the MHI power-up to timeout after waiting for firmware load completion. This cascaded to ath11k_pci probe failure. The failure is specific to the monaco-evk test image and is unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018, which only modifies shikra device trees.

Possible fix: Add the missing WCN6855 firmware files to the monaco-evk rootfs image build. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board/regdb files are included in /lib/firmware/. The firmware package linux-firmware-ath11k or equivalent must be installed in the Yocto/distro build recipe for monaco-evk. This is an image/infrastructure fix, not a kernel code fix. Re-trigger the CI job after updating the image build to include the firmware.

Detail analysis attachment: failed_case_job225922_2_detailed.md

Case 3: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110

Failed case: WiFi Driver Probe Failure — ath11k_pci probe failed with error -110

Root cause: The ath11k_pci WiFi driver probe failed with -ETIMEDOUT (-110) during boot on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. The MHI (Modem Host Interface) firmware load failed with error -2 (ENOENT), causing the MHI power-up to timeout, which cascaded into the ath11k_pci probe failure. This is a pre-existing platform/firmware packaging issue unrelated to the PR changes (which only modify shikra DTS gpio-reserved-ranges).

Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/) in the Yocto build recipe or firmware package for monaco-evk. The firmware should be sourced from the linux-firmware repository or Qualcomm's firmware release for WCN6855 hw2.1 with board variant nfa765.

Detail analysis attachment: failed_case_job225922_3_detailed.md

Case 4: Driver Probe Failure — ath11k WiFi driver

Failed case: Driver Probe Failure — ath11k WiFi driver

Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (firmware load failed with error -2 = ENOENT). This is a pre-existing test environment issue not introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018, which only modifies Shikra device tree GPIO reserved ranges for SPI5 access.

Possible fix: Install the missing WiFi firmware package for WCN6855 hardware (ath11k/WCN6855/hw2.1/nfa765/amss.bin) in the monaco-evk test rootfs. The firmware should be available in the linux-firmware package or Qualcomm's firmware repository. After installing the firmware, re-trigger the LAVA job to verify WiFi driver probe succeeds.

Detail analysis attachment: failed_case_job225922_4_detailed.md

Job 225923 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test detected 4 SPMI PMIC temp-alarm devices stuck in deferred probe (waiting for qpnp-adc-tm5 thermal monitoring driver dependency), 1 benign regulatory.db firmware load failure (cfg80211 wireless regulatory database - non-critical), and 1 Aquantia AQR115C Ethernet PHY probe failure with error -22 (EINVAL - likely missing or invalid firmware-name DT property). These are pre-existing platform issues unrelated to the PR (PR modifies Shikra GPIO ranges; test runs on qcs9100-ride).

Possible fix: For temp-alarm deferred probe: verify qpnp-adc-tm5 driver is enabled in kernel config and probing successfully; check DT for correct io-channel-names and thermal-zone linkage. For Aquantia PHY: add valid firmware-name property to stmmac-0:08 PHY node in qcs9100-ride DT, or confirm PHY firmware is present in rootfs at expected path. Regulatory.db failure is benign (cfg80211 falls back to built-in regulatory rules). None of these failures are caused by the PR under test.

Detail analysis attachment: failed_case_job225923_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device aa00000.video-codec failed to attach to any IOMMU group during boot on qcs9100-ride; the device is present in the device tree but the IOMMU attachment did not complete, causing the SMMU validation test to fail when checking critical master protection.

Possible fix: Verify the video codec device tree node includes correct iommus property referencing the appropriate SMMU; check kernel logs for video codec driver probe failures or deferred probe issues; if the driver failed to probe, the IOMMU attachment will not occur—resolve the underlying driver probe failure first.

Detail analysis attachment: failed_case_job225923_2_detailed.md

Case 3: USBHost

Failed case: USBHost

Root cause: Test infrastructure issue — the USBHost test expects physical USB devices (keyboard, mouse, storage, etc.) to be connected to the qcs9100-ride board's USB ports, but the LAVA lab setup has no USB peripherals attached. The kernel USB host stack initialized correctly (3 USB buses registered: Bus 001, Bus 002 USB 2.0, Bus 003 USB 3.1), but lsusb output shows only root hubs (ID 1d6b:0002/0003 Linux Foundation root hub), indicating no external USB devices are plugged in.

Possible fix: This is not a kernel bug and does not require a code fix. The PR changes only affect Shikra board GPIO reservations for SPI5 (GPIOs 14-17) and do not touch USB subsystem code or qcs9100-ride device trees. To resolve: (1) connect at least one USB device (e.g., USB flash drive, keyboard) to the qcs9100-ride board's USB ports in the LAVA lab, or (2) mark this test as SKIP when no USB peripherals are available in the test environment, or (3) suppress this test for boards where USB peripheral connectivity is not guaranteed in CI.

Detail analysis attachment: failed_case_job225923_3_detailed.md

Case 4: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

Root cause: qcom-ethqos driver on qcs9100-ride fails to attach to PHY with -EINVAL when bringing up end0 interface at runtime; driver probed successfully during boot but PHY attachment fails when interface is administratively enabled, indicating a device tree PHY configuration issue (missing or incorrect phy-handle/phy-mode properties) specific to the qcs9100-ride platform.

Possible fix: This is a pre-existing platform issue on qcs9100-ride, NOT introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies Shikra device trees). Verify the qcs9100-ride device tree has correct PHY configuration: check that the ethernet@23040000 node includes valid phy-handle phandle pointing to a PHY node under an MDIO bus, and that phy-mode is set correctly (e.g., "rgmii-id"). If PHY node or MDIO bus is missing, add them following the qcom-ethqos driver bindings. If configuration exists, check for PHY driver probe failures in boot log.

Detail analysis attachment: failed_case_job225923_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

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

Possible fix: This is expected behavior on platforms without virtualization hardware. Either: (1) Skip KVM tests on qcs9100-ride in the CI test suite, or (2) Mark KVM tests as expected-to-skip on platforms without EL2 support. No kernel or PR changes needed.

Detail analysis attachment: failed_case_job225923_5_detailed.md

Case 6: KVM_EL2_DTB — Platform Hardware Capability Limitation (Not PR-Introduced)

Failed case: KVM_EL2_DTB — Platform Hardware Capability Limitation (Not PR-Introduced)

Root cause: The qcs9100-ride (LeMans) platform does not support ARM EL2 (hypervisor mode), which is required for KVM functionality. The kernel correctly detected this limitation during boot and reported "kvm [1]: HYP mode not available" at timestamp [3.866603], preventing /dev/kvm device node creation. This is expected behavior for this SoC and is unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018, which only modifies GPIO reserved ranges for SPI5 on Shikra boards (a different SoC).

Possible fix: This is not a bug requiring a fix. The KVM_EL2_DTB test should be skipped or marked as "not applicable" for qcs9100-ride platforms that lack EL2 support. Update the LAVA test suite configuration to exclude KVM tests for platforms without hypervisor capability, or add a platform capability check to the test runner that skips KVM tests when CONFIG_KVM is enabled but /dev/kvm is unavailable due to missing EL2 support.

Detail analysis attachment: failed_case_job225923_6_detailed.md

Case 7: KVM Infrastructure Test — KVM Not Available (Expected Platform Limitation)

Failed case: KVM Infrastructure Test — KVM Not Available (Expected Platform Limitation)

Root cause: The qcs9100-ride platform boots with Gunyah hypervisor at EL2, causing Linux kernel to run at EL1. KVM requires EL2 (HYP mode) to function, which is unavailable when another hypervisor (Gunyah) owns EL2. Boot log shows "CPU: All CPU(s) started at EL1" and "kvm [1]: HYP mode not available". This is expected platform behavior, not a kernel regression.

Possible fix: Mark KVM_Infra, KVM_Driver, and KVM_EL2_DTB tests as "expected-fail" or "skip" for qcs9100-ride platform in the LAVA job definition, as this platform runs Gunyah hypervisor which prevents KVM from accessing EL2. Alternatively, if KVM testing is required, boot the platform without Gunyah hypervisor (bare-metal mode) to allow Linux to run at EL2.

Detail analysis attachment: failed_case_job225923_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

Root cause: The qcs9100-ride (LeMans) platform does not support KVM/virtualization in hardware — the kernel reports "HYP mode not available" during early boot, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled in the kernel configuration.

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR modifies GPIO reserved ranges for Shikra boards only and does not affect qcs9100-ride. No fix required for the PR; consider excluding KVM tests from qcs9100-ride CI runs or marking them as expected failures for this platform.

Detail analysis attachment: failed_case_job225923_8_detailed.md

Job 225924 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Three pre-existing platform-specific probe failures on hamoa-evk (x7181): (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) due to secure firmware dependency or TrustZone configuration mismatch; (2) qcom-spmi-lpg probe failed with -EINVAL (-22) due to invalid multi-LED "reg" property in device tree; (3) regulatory.db firmware file missing from rootfs (-ENOENT, -2). None are related to the PR, which modifies GPIO reserved ranges only for Shikra boards.

Possible fix: These are known platform-specific issues on hamoa-evk and should be suppressed in CI or fixed independently: (1) verify TZ firmware and qseecom configuration for hamoa; (2) correct the SPMI LPG multi-LED "reg" property in hamoa device tree (c42d000.spmi:pmic@1:pwm node); (3) add regulatory.db to the rootfs image or mark as optional. The PR itself is not the cause and should not be blocked by these pre-existing failures.

Detail analysis attachment: failed_case_job225924_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: The SMMU functional validation test detected that 6 critical platform devices (5 USB PHY controllers: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb; and 1 Video codec: aa00000.video-codec) are missing IOMMU group attachments on hamoa-evk (x7181), indicating incomplete device tree IOMMU bindings for these peripherals. This is a pre-existing platform configuration issue, not introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 which only modifies gpio-reserved-ranges for shikra boards.

Possible fix: Add missing iommus properties to the device tree nodes for the 5 USB PHY controllers (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and the video codec (aa00000.video-codec) in the hamoa/x7181 device tree. Reference the working USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb) which are correctly attached to IOMMU groups 10, 11, 12, 9, and 13 respectively to determine the correct IOMMU phandle and stream ID assignments.

Detail analysis attachment: failed_case_job225924_2_detailed.md

Case 3: ** KVM_Driver — Driver Initialization Failure

Failed case: ** KVM_Driver — Driver Initialization Failure

Root cause: ** KVM driver initialization failed because the Hamoa IoT EVK (X1E80100) platform does not provide EL2 (hypervisor mode) support. The kernel message kvm [1]: HYP mode not available indicates the CPU is running in EL1 without virtualization extensions enabled, preventing KVM from creating /dev/kvm.

Possible fix: This is a pre-existing platform/firmware limitation on Hamoa IoT EVK, not a regression from this PR (which only modifies Shikra GPIO ranges). To enable KVM: (1) verify the SoC supports virtualization extensions, (2) configure the bootloader/firmware to boot the kernel in EL2 or enable VHE (Virtualization Host Extensions), (3) ensure the platform firmware enables the virtualization MMIO/SMMU context. If the platform does not support virtualization, exclude KVM tests from the Hamoa test suite.

Detail analysis attachment: failed_case_job225924_3_detailed.md

Case 4: KVM_EL2_DTB — Platform Hardware/Firmware Limitation (No Applicable CoT)

Failed case: KVM_EL2_DTB — Platform Hardware/Firmware Limitation (No Applicable CoT)

Root cause: The hamoa-evk platform does not support ARM virtualization extensions at EL2, or the bootloader/firmware did not configure the CPU to enable HYP mode. The kernel correctly detected this limitation and reported "kvm [1]: HYP mode not available" at boot (line 2714 of LAVA log), preventing /dev/kvm device creation. This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression.

Possible fix: This is not a bug requiring a fix. The test expectation is misaligned with platform capabilities. Recommended action: exclude KVM-dependent tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the hamoa-evk CI test suite, or update the platform firmware/bootloader to enable virtualization extensions if the hardware supports them. The PR (shikra GPIO changes) is unrelated and does not cause this failure.

Detail analysis attachment: failed_case_job225924_4_detailed.md

Case 5: KVM Infrastructure Failure — HYP mode unavailable

Failed case: KVM Infrastructure Failure — HYP mode unavailable

Root cause: KVM driver initialization fails on Hamoa IoT EVK because ARM64 EL2 (Hypervisor Exception Level) is not available; the platform firmware/bootloader does not enable or expose hypervisor mode to the kernel, preventing KVM from creating /dev/kvm device node.

Possible fix: This is a pre-existing platform limitation unrelated to the PR (which only modifies GPIO ranges for Shikra boards). Suppress this test failure for Hamoa platform in CI configuration, or update Hamoa firmware/bootloader to enable EL2 support if virtualization is required.

Detail analysis attachment: failed_case_job225924_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM hypervisor mode (EL2) is not available on the Hamoa IoT EVK platform — the kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running in a virtualization-capable mode or the hypervisor is disabled/unavailable, preventing /dev/kvm device creation.

Possible fix: This is a platform/firmware limitation, not a kernel regression. The Hamoa EVK either lacks EL2 support, has EL2 disabled in firmware/bootloader, or is running under a hypervisor that does not expose nested virtualization. To enable KVM: (1) verify the SoC supports virtualization extensions (ARMv8.0-A Virtualization Host Extensions), (2) ensure the bootloader/firmware boots Linux at EL2 or enables VHE, (3) if running under a hypervisor, enable nested virtualization support. This failure is unrelated to the PR (which only modifies Shikra GPIO ranges for SPI5).

Detail analysis attachment: failed_case_job225924_6_detailed.md

Job 225925 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: This is a pre-existing platform/firmware issue unrelated to the PR (PR modifies Shikra GPIO ranges, not Lemans). Suppress this failure in CI for lemans-evk until the PMIC ADC initialization issue is resolved in firmware or device tree. The Bluetooth firmware failures are already suppressed per Rule 3 (BT_ON_OFF passed).

Detail analysis attachment: failed_case_job225925_1_detailed.md

Case 2: ** smmu (IOMMU group attachment validation)

Failed case: ** smmu (IOMMU group attachment validation)

Root cause: ** The SMMU test expects the video codec platform device aa00000.video-codec to be directly attached to an IOMMU group, but on Lemans EVK the video codec driver (qcom_iris) creates virtual sub-devices (iris_non_pixel.0, iris_pixel.0) that ARE properly attached to IOMMU groups 25 and 26. The base platform device itself is not directly attached, causing the test's critical master check to fail. This is a pre-existing platform/driver architecture characteristic of Lemans, not a regression introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies GPIO reserved ranges for Shikra boards).

Possible fix: Update the SMMU test script to recognize that for Lemans EVK video codec, the IOMMU protection is provided via the iris sub-devices (iris_non_pixel.0 and iris_pixel.0 in groups 25/26) rather than the base aa00000.video-codec device. Add a platform-specific exception or adjust the test logic to check for iris sub-device IOMMU attachment when the base video-codec device is not directly attached.

Detail analysis attachment: failed_case_job225925_2_detailed.md

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

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

Root cause: The LAVA test suite reported failure due to two sub-test failures on lemans-evk: (1) Probe_Failure_Check detected deferred probe issues for PMIC temp-alarm devices and missing firmware files (regulatory.db, Bluetooth firmware), and (2) smmu test detected that the video codec device (aa00000.video-codec) lacks IOMMU group attachment. These are pre-existing platform configuration issues unrelated to the PR, which only modifies GPIO reserved ranges for Shikra boards.

Possible fix: These failures are not PR-introduced regressions. The PR changes Shikra device tree GPIO reservations and should not affect lemans-evk. The test failures indicate: (1) PMIC temp-alarm deferred probe is a known benign issue on this platform, (2) missing firmware files (regulatory.db, Bluetooth TLV) are expected on test images without full firmware packages, and (3) video codec IOMMU attachment may require device tree or driver updates for lemans-evk. Re-run the test on a Shikra board (shikra-cqm-evk, shikra-cqs-evk, or shikra-iqs-evk) to validate the actual PR changes. Mark lemans-evk failures as pre-existing platform issues.

Detail analysis attachment: failed_case_job225925_3_detailed.md

Job 225926 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Two pre-existing platform-specific probe failures on qcs8300-ride: (1) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property (-EINVAL), and (2) regulatory.db firmware load failure (-ENOENT) which is a known benign issue when the regulatory database is not packaged in the rootfs. These failures are unrelated to the PR under test (shikra GPIO reserved-ranges fix for SPI5).

Possible fix: For Aquantia PHY: Add the missing "firmware-name" property to the stmmac-0:08 PHY node in qcs8300-ride device tree. For regulatory.db: This is a known benign failure when cfg80211 regulatory database is not included in the rootfs; WiFi functionality is not impacted as evidenced by WiFi_OnOff test passing. The PR should not be blocked by these pre-existing qcs8300-ride platform issues.

Detail analysis attachment: failed_case_job225926_1_detailed.md

Case 2: USBHost — Test Infrastructure Issue (No Physical USB Device Connected)

Failed case: USBHost — Test Infrastructure Issue (No Physical USB Device Connected)

Root cause: The USBHost test expects a functional USB device to be connected to the board's USB host port, but only the USB root hub is present. The USB host controller driver (xhci-hcd) initialized successfully and the USB subsystem is functioning correctly at the kernel level. This is a LAVA lab hardware setup issue specific to the qcs8300-ride board, not a kernel regression.

Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB mouse) to the qcs8300-ride board's USB host port before running the USBHost test. If the board's USB port is physically inaccessible or non-functional, update the LAVA job definition to skip the USBHost test for this board configuration, or investigate whether the board's USB port hardware is damaged or requires a specific cable/adapter.

Detail analysis attachment: failed_case_job225926_2_detailed.md

Case 3: Ethernet_Basic_Validation — PHY Attachment Failure

Failed case: Ethernet_Basic_Validation — PHY Attachment Failure

Root cause: Aquantia AQR115C PHY driver probe failed with -EINVAL (error -22) during phylink validation of 2500base-x link mode; the PHY's supported link modes (0x000062cc) and advertised modes (0x000062c0) are incompatible with the MAC's 2500base-x configuration, preventing eth0 from attaching to the PHY and bringing up the interface.

Possible fix: This is a pre-existing platform/hardware configuration issue on qcs8300-ride, not introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies gpio-reserved-ranges for SPI5 on Shikra boards). The failure requires either: (1) updating the qcs8300-ride device tree to configure the correct PHY interface mode and link capabilities for the Aquantia AQR115C PHY at stmmac-0:08, or (2) updating the Aquantia PHY driver to correctly advertise 2500base-x support if the hardware supports it. Re-trigger the CI job on a baseline commit without this PR to confirm the failure is pre-existing.

Detail analysis attachment: failed_case_job225926_3_detailed.md

Case 4: KVM_Driver

Failed case: KVM_Driver

Root cause: QCS8300-ride is running as a guest VM under a hypervisor (evidenced by "arm-pv: using stolen time PV" in boot log), and KVM cannot initialize because the platform does not support nested virtualization or EL2 is not available to the guest kernel. CONFIG_KVM is enabled but /dev/kvm device node is not created because kvm_arch_init() fails when the kernel detects it's running at EL1 under a hypervisor without nested virt support.

Possible fix: This is not a PR-introduced regression (the PR only modifies GPIO reserved ranges for Shikra SPI5). The failure is a pre-existing platform limitation: QCS8300-ride boots as a guest VM and lacks nested virtualization support. Either: (1) skip KVM tests on qcs8300-ride in CI, or (2) configure the board to boot Linux at EL2 (native/host mode) instead of as a guest, or (3) enable nested virtualization in the hypervisor configuration if the platform supports it.

Detail analysis attachment: failed_case_job225926_4_detailed.md

Case 5: KVM Device Unavailable — Gunyah Hypervisor Conflict

Failed case: KVM Device Unavailable — Gunyah Hypervisor Conflict

Root cause: qcs8300-ride platform runs Gunyah hypervisor (gunyah-cdfb73831) in EL2, which takes exclusive control of ARM virtualization extensions; KVM cannot initialize because it requires direct EL2 access that Gunyah occupies, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.

Possible fix: This is a platform configuration issue, not a kernel regression. Either: (1) Disable Gunyah hypervisor in the bootloader/firmware configuration for this platform if KVM testing is required, or (2) Skip KVM tests on qcs8300-ride in CI since this platform is configured for Gunyah-based virtualization, not KVM. The PR under test (GPIO changes for Shikra) is unrelated and should not be blocked by this pre-existing platform limitation.

Detail analysis attachment: failed_case_job225926_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM cannot initialize on qcs8300-ride because the platform boots with Gunyah hypervisor occupying EL2, preventing KVM from accessing the hypervisor exception level required for operation. This is a platform architecture limitation, not a kernel bug or PR-introduced regression.

Possible fix: This is expected behavior on Gunyah-based platforms. To enable KVM testing: (1) Use a platform that boots Linux directly at EL2 without a hypervisor, or (2) Exclude KVM tests from the qcs8300-ride test suite, or (3) Configure the platform to boot without Gunyah if KVM functionality is required for this use case.

Detail analysis attachment: failed_case_job225926_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: /dev/kvm device node is not present on qcs8300-ride despite CONFIG_KVM being enabled in the kernel configuration. The KVM kernel module either failed to load, did not create the device node, or the platform does not support KVM virtualization at EL2.

Possible fix: This is a pre-existing platform/kernel configuration issue unrelated to the PR changes (which only modify Shikra DTS gpio-reserved-ranges). Investigate: (1) Check if KVM module is loaded (lsmod | grep kvm), (2) Check dmesg for KVM initialization errors during boot, (3) Verify qcs8300 hardware supports virtualization extensions, (4) Check if hypervisor is running in a mode that prevents nested virtualization. If this is expected behavior for qcs8300-ride, mark KVM tests as skipped for this platform in the test plan.

Detail analysis attachment: failed_case_job225926_7_detailed.md

Job 225927 | SoC qcs615-ride

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

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

Case 1: Kernel Crash — Synchronous External Abort during USB enumeration

Failed case: Kernel Crash — Synchronous External Abort during USB enumeration

Root cause: The kernel crashed with a synchronous external abort (ESR 0x96000010) at PC __pi_memcpy_generic+0x2c during swiotlb bounce buffer copy for USB device descriptor fetch on qcs615-ride. The crash occurred in kworker/2:2 (PID 130) while processing hub_event for a newly connected low-speed USB device. The fault address (x19: 000000010d7b5480) suggests an invalid physical address access during DMA bounce buffer operations, indicating either an IOMMU/SMMU mapping issue, a swiotlb buffer allocation problem, or a hardware bus fault during the memory copy. After the crash, the board entered warm reset but failed to reach userspace login prompt on subsequent boot attempts, causing the login-action timeout.

Possible fix: This is a pre-existing kernel/platform issue unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies Shikra GPIO reserved ranges). The crash signature indicates a potential IOMMU/SMMU configuration issue or swiotlb buffer corruption on qcs615-ride during USB device enumeration. Recommended actions: (1) Re-trigger the CI job to confirm reproducibility; (2) If reproducible, enable CONFIG_IOMMU_DEBUGFS, CONFIG_ARM_SMMU_TESTBUS_DUMP, and CONFIG_SWIOTLB_DEBUG to capture detailed IOMMU/SMMU state and swiotlb buffer allocation logs; (3) Check if the issue is specific to qcs615-ride hardware or firmware version; (4) Verify USB host controller (xhci-hcd) and IOMMU domain configuration for the USB controller in the device tree; (5) If the issue persists, collect a full crash dump with SDI to analyze SMMU context bank registers and TBU state at the time of the external abort.

Detail analysis attachment: failed_case_job225927_1_detailed.md

Case 2: Kernel Crash — Synchronous External Abort during USB enumeration

Failed case: Kernel Crash — Synchronous External Abort during USB enumeration

Root cause: Kernel panic triggered by synchronous external abort at __pi_memcpy_generic+0x2c/0x230 during SWIOTLB bounce buffer copy operation in USB DMA mapping path (usb_hcd_map_urb_for_dma → dma_map_page_attrs → swiotlb_tbl_map_single). The crash occurred on qcs615-ride during USB hub enumeration at boot time (~8 seconds after kernel start). This is a pre-existing platform-specific kernel issue unrelated to the PR changes (PR modifies Shikra board DTS files; test runs on qcs615-ride).

Possible fix: This is NOT a PR-introduced regression. The PR changes gpio-reserved-ranges for Shikra boards only and does not affect qcs615-ride. The crash is a pre-existing kernel bug on qcs615-ride related to SWIOTLB/DMA memory access during USB initialization. Recommended actions: (1) Re-run the test to confirm reproducibility; (2) If reproducible, investigate SWIOTLB configuration and USB DMA mapping on qcs615-ride separately from this PR; (3) Consider testing the PR on the correct target platform (Shikra boards) where the changes are intended to apply.

Detail analysis attachment: failed_case_job225927_2_detailed.md

Case 3: Kernel Crash — synchronous external abort during USB hub enumeration

Failed case: Kernel Crash — synchronous external abort during USB hub enumeration

Root cause: Kernel panic triggered by synchronous external abort in __pi_memcpy_generic during SWIOTLB bounce buffer operation for USB device descriptor read. The crash occurs at ~8 seconds into boot during USB hub enumeration (kworker/2:2 executing hub_event → hub_port_init → usb_get_device_descriptor). The fault address (0x10d7b5480) suggests an invalid DMA mapping or IOMMU translation failure during USB DMA setup. This is NOT related to the PR changes (which only modify Shikra DTS gpio-reserved-ranges), but is a pre-existing kernel or platform issue on qcs615-ride.

Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR (PR modifies only Shikra DTS files; test runs on qcs615-ride). The crash indicates a USB/DMA/IOMMU subsystem bug. Recommended actions: (1) Re-trigger the CI job to confirm reproducibility; (2) If reproducible, file a kernel bug report with full dmesg and register dump; (3) As a workaround, add iommu.strict=0 or swiotlb=noforce to kernel cmdline to test if IOMMU/SWIOTLB configuration is the trigger; (4) Check if recent USB or IOMMU patches in the integration branch introduced a regression; (5) Bisect the kernel to identify the commit that introduced the synchronous external abort.

Detail analysis attachment: failed_case_job225927_3_detailed.md

Case 4: Kernel Crash — Synchronous External Abort (USB/DMA)

Failed case: Kernel Crash — Synchronous External Abort (USB/DMA)

Root cause: Kernel panic due to synchronous external abort (ESR 0x96000010) during USB hub enumeration when SWIOTLB bounce buffer memcpy attempted to access invalid physical memory address 0x10d7b5480, indicating a DMA mapping or IOMMU configuration issue on qcs615-ride platform during USB device probe.

Possible fix: This is a pre-existing kernel bug unrelated to the PR (PR modifies Shikra DTS; test ran on qcs615-ride). Investigate USB/SWIOTLB/IOMMU configuration for qcs615-ride: verify DMA address translation, check IOMMU domain setup for USB controller, and review recent USB or DMA subsystem changes that may have introduced the invalid physical address mapping.

Detail analysis attachment: failed_case_job225927_4_detailed.md

Job 225928 | SoC shikra-iqs-evk

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

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

Case 1: ** Kernel Boot Hang — Watchdog Reset During Late Init

Failed case: ** Kernel Boot Hang — Watchdog Reset During Late Init

Root cause: ** The PR unreserves GPIOs 14-17 to enable SPI5 controller probe on shikra-iqs-evk. A driver in the SPI5 probe path (likely ST33 TPM or SPI controller) blocks indefinitely during late_initcall at ~4.3s, preventing boot completion. Platform watchdog bites after 8 seconds, triggering warm reset. The hang is PR-introduced; SPI5 was not probed before this change.

Possible fix: Identify the blocking driver on SPI5 bus (check DT for spi@a94000 and ST33 TPM node). Add probe timeout or defer probe for the problematic device. Short-term: revert gpio-reserved-ranges change or disable SPI5/TPM node in DT. Long-term: fix the driver's probe function to handle missing hardware gracefully with timeout.

Detail analysis attachment: failed_case_job225928_1_detailed.md

Case 2: auto-login-action

Failed case: auto-login-action

Root cause: Kernel hang/silent panic during late initialization (at ~4.3s after boot, during fscrypt registration) triggered warm reset into ramdump mode; system never reached userspace or login prompt. The hang occurred after the PR's device tree change removed GPIOs 14-17 from reserved ranges on shikra-iqs-evk, potentially exposing a latent issue with SPI5/GPIO initialization or a race condition in late-init device probing.

Possible fix: Revert the gpio-reserved-ranges change for shikra-iqs-evk specifically and investigate why unreserving GPIOs 14-17 causes a kernel hang on this board variant. Check for SPI5 controller probe failures, GPIO subsystem conflicts, or pinctrl driver issues specific to shikra-iqs-evk hardware. Add debug instrumentation around fscrypt/late-init to capture the exact hang point before ramdump entry.

Detail analysis attachment: failed_case_job225928_2_detailed.md

Case 3: minimal-boot — Kernel hang during early init (no login prompt)

Failed case: minimal-boot — Kernel hang during early init (no login prompt)

Root cause: Kernel boots successfully but hangs silently at ~4.3 seconds during early initialization (last message: fscrypt-provisioning registered), followed by watchdog reset/reboot after ~8 seconds. The system never reaches userspace or presents a login prompt. The PR modifies gpio-reserved-ranges for shikra-iqs-evk, removing GPIOs 14-17 from the reserved list to enable SPI5. This change may trigger device probing or driver initialization that causes the hang, possibly due to a hardware conflict, driver bug when accessing the newly-available GPIOs, or a dependency on firmware/bootloader state that expects these GPIOs to remain reserved.

Possible fix: Revert the gpio-reserved-ranges change for shikra-iqs-evk specifically and test if boot completes. If the issue persists without the change, it's a pre-existing board/firmware issue. If reverting fixes it, investigate: (1) whether SPI5 driver probe is causing the hang (add initcall_debug to kernel cmdline to identify the hanging initcall), (2) whether there's a hardware conflict on GPIOs 14-17 on this specific board variant (IQS vs CQM/CQS), (3) whether the ST33 TPM device or SPI5 controller requires additional DT configuration or firmware support that's missing on shikra-iqs-evk.

Detail analysis attachment: failed_case_job225928_3_detailed.md

Case 4: ** Board Reset — Silent secure watchdog bite during GPIO/SPI5 initialization

Failed case: ** Board Reset — Silent secure watchdog bite during GPIO/SPI5 initialization

Root cause: ** PR removes GPIOs 14-17 from gpio-reserved-ranges, but TrustZone firmware still protects these pins. When the kernel attempts to configure or access these GPIOs (likely during SPI5 controller initialization), TZ detects an unauthorized access and triggers a secure watchdog reset. The reset occurs after kernel init (4.339s) but before userspace starts, with no kernel-visible panic trace because the reset is initiated by secure firmware, not the kernel.

Possible fix: Revert the gpio-reserved-ranges change for shikra-iqs-evk and keep GPIOs 14-17 reserved (<14 4> entry). If SPI5 access is genuinely required, coordinate with the TZ/firmware team to update the secure firmware configuration to allow kernel access to these pins, or use a different GPIO range that is not TZ-protected. Verify TZ firmware version and secure boot policy before attempting to unreserve these GPIOs.

Detail analysis attachment: failed_case_job225928_4_detailed.md

Job 225929 | SoC purwa-evk

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

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

Case 1: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** The Probe_Failure_Check test detected 5 pre-existing probe failures on purwa-evk that are unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018. The PR modifies gpio-reserved-ranges for Shikra EVK DTBs to enable SPI5/TPM, but the test ran on purwa-evk using dtb-purwa-iot-evk-image.vfat (not modified by PR). The probe failures (qcom_qseecom_uefisecapp -EBUSY, qcom-pcie -ENODATA ×2, qcom-spmi-lpg -EINVAL, regulatory.db -ENOENT) represent known platform-specific hardware/firmware limitations on purwa-evk. All functional tests passed (PCIe, USB, WiFi, BT), confirming these are benign failures that do not break functionality.

Possible fix: Suppress these known benign probe failures in the Probe_Failure_Check test for purwa-evk. Add platform-specific suppression lists to distinguish critical probe failures (that break functionality) from benign ones (optional drivers, missing non-critical firmware). For this PR: No action required — the failures are not caused by the PR and do not represent a regression.

Detail analysis attachment: failed_case_job225929_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Pre-existing platform configuration issue on purwa-evk — six critical USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec device (aa00000.video-codec) are missing IOMMU group attachments in the device tree, causing the SMMU validation test to fail.

Possible fix: Add missing iommus properties to the USB PHY and video codec device tree nodes in arch/arm64/boot/dts/qcom/purwa*.dts* files to bind these devices to their respective IOMMU groups; this is a platform DT issue unrelated to the PR (which modifies Shikra gpio-reserved-ranges for SPI5 access).

Detail analysis attachment: failed_case_job225929_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 bug to fix — it is expected behavior for this platform configuration. If KVM functionality is required on Purwa IoT EVK, the platform firmware/bootloader must be reconfigured to either (1) boot Linux at EL2 without a secure hypervisor, or (2) use a hypervisor that supports nested virtualization. For CI purposes, disable KVM-related tests on Purwa IoT EVK or mark them as expected-fail, as this platform does not support KVM in its current configuration.

Detail analysis attachment: failed_case_job225929_3_detailed.md

Case 4: KVM Driver Initialization Failure — HYP mode not available

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

Root cause: KVM initialization failed because HYP/EL2 mode is not available on Purwa IoT EVK. The platform runs a hypervisor (hypvm.mbn) at EL2, preventing Linux from using ARM virtualization extensions. CONFIG_KVM is enabled but the driver cannot create /dev/kvm because is_hyp_mode_available() returns false.

Possible fix: This is a platform limitation, not a kernel regression. The PR modifies Shikra DTS files and does not affect Purwa. To resolve: (1) exclude KVM tests from Purwa CI runs, OR (2) configure the platform firmware to boot Linux at EL2 (requires bootloader/hypervisor changes), OR (3) use a different platform that supports native KVM (e.g., boards without a hypervisor at EL2).

Detail analysis attachment: failed_case_job225929_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is a pre-existing platform limitation, not a PR-introduced issue. The PR modifies GPIO ranges for Shikra boards and does not affect Purwa or KVM. To enable KVM on Purwa EVK: (1) Update firmware/bootloader to boot kernel at EL2, or (2) Exclude KVM tests from Purwa EVK CI runs if virtualization is not a supported use case for this platform.

Detail analysis attachment: failed_case_job225929_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM cannot initialize because Gunyah hypervisor is already running at EL2 on the Purwa platform, preventing KVM from taking control of the hypervisor mode (kernel message: "kvm [1]: HYP mode not available").

Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR modifies Shikra device tree GPIO ranges and is unrelated to Purwa KVM functionality. To enable KVM on Purwa, either: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) skip KVM tests on platforms where Gunyah is enabled, as both cannot coexist at EL2.

Detail analysis attachment: failed_case_job225929_6_detailed.md

qlijarvis · 2026-09-16T16:38:53Z

LAVA Failed Case Triage Summary

PR: #1018

Job 227733 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: Update the Probe_Failure_Check test to exclude known-optional firmware files from the failure criteria. Add regulatory.db to the test's benign firmware failure suppression list. Alternatively, include the regulatory.db file in the rootfs image if strict compliance with all firmware requests is required.

Detail analysis attachment: failed_case_job227733_1_detailed.md

Case 2: ** USBHost (Test Infrastructure Issue — No USB Device Connected)

Failed case: ** USBHost (Test Infrastructure Issue — No USB Device Connected)

Root cause: ** The USBHost test expects at least one functional USB device to be physically connected to the qcs8300-ride board's USB host port, but only the USB root hub (Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub) is enumerated. The USB host controller driver loaded successfully and the USB subsystem is functional, but no external USB device (keyboard, mouse, storage, etc.) is attached to the board in the LAVA lab setup.

Possible fix: This is a LAVA lab infrastructure/setup issue, not a kernel bug or PR-introduced regression. Connect a USB device (e.g., USB flash drive, keyboard, or mouse) to the qcs8300-ride board's USB host port before running the test suite. If the test is optional and USB host functionality is not critical for this PR validation, mark USBHost as a known infrastructure dependency and allow the job to pass with this test skipped.

Detail analysis attachment: failed_case_job227733_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver failed to initialize on qcs8300-ride platform running under Gunyah hypervisor — /dev/kvm device node was never created despite CONFIG_KVM=y being enabled, indicating KVM requires EL2 access that is not available when Linux runs as a guest under Gunyah.

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR only modifies GPIO reserved ranges for Shikra boards). Mark KVM tests as expected-to-fail on qcs8300-ride in the CI test matrix, or configure the platform to boot Linux at EL2 without Gunyah if KVM support is required.

Detail analysis attachment: failed_case_job227733_3_detailed.md

Case 4: KVM_EL2_DTB — /dev/kvm device node unavailable

Failed case: KVM_EL2_DTB — /dev/kvm device node unavailable

Root cause: KVM driver failed to initialize because the kernel is running under Gunyah hypervisor (gunyah-cdfb73831) on QCS8300 Ride; KVM requires direct EL2 access or VHE support which is not available when running as a guest under a Type-1 hypervisor.

Possible fix: This is a platform/configuration limitation, not a kernel bug. Either: (1) disable KVM tests for QCS8300 Ride in the LAVA test suite when Gunyah hypervisor is present, or (2) configure the platform to boot Linux at EL2 without Gunyah if KVM functionality is required for testing.

Detail analysis attachment: failed_case_job227733_4_detailed.md

Case 5: KVM_Infra — /dev/kvm device node not present

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

Root cause: QCS8300 (Monaco) platform boots under Gunyah hypervisor as a guest VM (Primary VM). KVM requires EL2 (hypervisor mode) access to create /dev/kvm, but when Linux runs as a guest under Gunyah, it executes at EL1 and cannot access EL2 virtualization extensions. CONFIG_KVM is enabled in the kernel config, but the KVM driver does not initialize because nested virtualization is not supported in this Gunyah-based boot configuration.

Possible fix: This is not a kernel regression introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies gpio-reserved-ranges for Shikra SPI5 access). The KVM test failure is a pre-existing platform limitation on QCS8300-Ride when booting under Gunyah. Either: (1) exclude KVM tests from the QCS8300-Ride LAVA test suite, or (2) configure the platform to boot Linux at EL2 (bare-metal or VHE mode) instead of as a Gunyah guest if KVM functionality is required for testing.

Detail analysis attachment: failed_case_job227733_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver failed to initialize on qcs8300-ride platform — CONFIG_KVM is enabled but /dev/kvm device node was never created during boot, indicating the KVM ARM driver did not successfully probe or the platform does not support virtualization at EL2.

Possible fix: This is a pre-existing platform/infrastructure issue unrelated to the PR (which modifies GPIO reserved ranges for Shikra SPI5). The qcs8300-ride platform either lacks hypervisor support in firmware/bootloader, or the KVM ARM driver has unmet dependencies (missing DT nodes, EL2 not available). Investigate platform boot logs for EL2/hypervisor initialization; verify qcs8300 DT includes required KVM/virtualization nodes; or exclude KVM tests from qcs8300-ride CI runs if the platform does not support virtualization.

Detail analysis attachment: failed_case_job227733_6_detailed.md

Job 227734 | SoC lemans-evk

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

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

Case 1: System Hang — PCIe initialization hang

Failed case: System Hang — PCIe initialization hang

Root cause: The lemans-evk board hangs completely during PCIe host bridge initialization at timestamp [6.232960], immediately after printing "qcom-pcie 1c00000.pcie: host bridge /pcie@1c00000 ranges:". No kernel panic, oops, or crash occurred — the system simply stopped making forward progress during PCIe enumeration. This is a pre-existing platform/infra issue unrelated to the PR, which only modifies Shikra board device trees (gpio-reserved-ranges for SPI5), not lemans-evk or PCIe subsystem code.

Possible fix: This is a known lemans-evk PCIe initialization hang issue in the test infrastructure. Re-trigger the CI job on a different lemans-evk board instance. If the issue persists across multiple boards, disable PCIe controller nodes in the lemans-evk device tree (set status = "disabled" for pcie@1c00000 and pcie@1c10000 nodes) as a workaround, or investigate PCIe PHY/clock/regulator configuration for lemans platform.

Detail analysis attachment: failed_case_job227734_1_detailed.md

Case 2: Board Hang — PCIe initialization deadlock

Failed case: Board Hang — PCIe initialization deadlock

Root cause: lemans-evk board hung during PCIe host controller initialization at 6.232960s; system stopped outputting console data while qcom-pcie driver was enumerating host bridge ranges for 1c00000.pcie; no kernel panic or crash occurred, indicating a hardware/firmware-level deadlock during PCIe link training or PHY initialization specific to the lemans-evk platform.

Possible fix: Re-trigger the CI job on lemans-evk; if the hang recurs, this is a known lemans-evk PCIe stability issue unrelated to the PR (which targets Shikra GPIO/SPI5). Consider: (1) increasing PCIe link timeout in the LAVA job definition, (2) disabling PCIe in the lemans-evk device tree for this test run, or (3) switching to a different lemans-evk board in the lab if hardware-specific.

Detail analysis attachment: failed_case_job227734_2_detailed.md

Case 3: minimal-boot — Boot Hang (Login Timeout)

Failed case: minimal-boot — Boot Hang (Login Timeout)

Root cause: The kernel booted successfully (Linux 6.18.44-gfbed88d0063c) and started userspace init (systemd-udevd), but the boot process hung before reaching a login prompt. LAVA waited for login for 3 attempts (185s, 200s, 200s) but received no response. The last kernel message was at 6.23 seconds showing PCIe initialization, then no further console output. This is a userspace boot hang on lemans-evk, unrelated to the PR which only modifies Shikra device trees (gpio-reserved-ranges for SPI5).

Possible fix: This is a pre-existing lemans-evk boot issue unrelated to the PR changes (PR only touches Shikra DTS files). The PR should not be blocked by this failure. Investigate lemans-evk boot hang separately: check if systemd services are stalling (increase systemd debug verbosity with systemd.log_level=debug on kernel cmdline), verify rootfs integrity, check for missing firmware/drivers preventing boot completion, or increase LAVA login timeout if boot is legitimately slow on this platform.

Detail analysis attachment: failed_case_job227734_3_detailed.md

Case 4: job

Failed case: job

Root cause: LAVA login timeout on lemans-evk board — kernel booted successfully and reached userspace (systemd-udevd started), but the system appears to hang during PCIe initialization at approximately 6.2 seconds into boot, preventing the login prompt from appearing; the PR changes only affect Shikra DTS gpio-reserved-ranges and are unrelated to lemans-evk, indicating this is a pre-existing board-specific or infrastructure issue, not a PR-introduced regression.

Possible fix: This is not a PR-introduced failure — the PR only modifies Shikra board DTS files while the failure occurs on lemans-evk; re-trigger the LAVA job to rule out transient infrastructure issues; if the hang persists, investigate lemans-evk-specific PCIe initialization (the last kernel message shows PCIe host bridge enumeration in progress) and check for known lemans-evk boot issues in the CI history; consider increasing the LAVA login timeout from 200s to 300s if PCIe link training on this board is known to be slow.

Detail analysis attachment: failed_case_job227734_4_detailed.md

Job 227735 | SoC qcs615-ride

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

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

Case 1: Kernel Crash — Synchronous External Abort (Memory Access Fault)

Failed case: Kernel Crash — Synchronous External Abort (Memory Access Fault)

Root cause: Kernel panic due to synchronous external abort (0x96000010) at 7.75s during USB hub enumeration on qcs615-ride. The crash occurred in __pi_memcpy_generic while copying data to a SWIOTLB bounce buffer (address 0xffff00007ffbf000) during USB DMA mapping for device descriptor fetch. This indicates either an invalid physical address mapping in the SWIOTLB pool or a hardware bus fault when accessing the bounce buffer memory region.

Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR (PR modifies Shikra DTS gpio-reserved-ranges; test runs on QCS615). Immediate action: Re-trigger the CI job to confirm reproducibility. If reproducible: (1) verify SWIOTLB pool configuration and reserved memory regions in qcs615-ride DTS, (2) check for SMMU/IOMMU mapping conflicts with USB controller at 0xa600000/0xa800000, (3) enable CONFIG_DMA_API_DEBUG and CONFIG_SWIOTLB_DEBUG to capture DMA mapping violations, (4) review recent USB/DMA/SWIOTLB changes in the kernel tree that may have introduced a regression on this platform.

Detail analysis attachment: failed_case_job227735_1_detailed.md

Case 2: Kernel Crash — Synchronous External Abort during USB enumeration

Failed case: Kernel Crash — Synchronous External Abort during USB enumeration

Root cause: Kernel panic at 8.06s due to synchronous external abort (0x96000010) in __pi_memcpy_generic during SWIOTLB bounce buffer operation while USB hub was enumerating a low-speed USB device (device number 2). The crash occurred in the DMA mapping path (iommu_dma_map_phys → swiotlb_tbl_map_single → swiotlb_bounce → __pi_memcpy_generic) when attempting to copy data to/from a bounce buffer at physical address 0x10e1bfde0, indicating an invalid or inaccessible memory region used by SWIOTLB on qcs615-ride.

Possible fix: This is a pre-existing kernel/platform issue unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies GPIO reserved ranges for Shikra boards). The crash suggests SWIOTLB buffer corruption or misconfiguration on qcs615-ride. Recommended actions: (1) Verify SWIOTLB buffer allocation and reserved memory regions in qcs615-ride device tree; (2) Check if IOMMU/SMMU configuration for USB controller is correct; (3) Test with swiotlb=force or increased SWIOTLB size via kernel cmdline; (4) Bisect to identify when this regression was introduced on qcs615-ride; (5) Since PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 is not the cause, mark this failure as a known platform issue and proceed with PR merge if other boards pass.

Detail analysis attachment: failed_case_job227735_2_detailed.md

Case 3: Kernel Crash — Synchronous External Abort during USB DMA mapping

Failed case: Kernel Crash — Synchronous External Abort during USB DMA mapping

Root cause: Hardware-level memory access fault (synchronous external abort ESR=0x96000010) occurred during SWIOTLB bounce buffer copy at physical address 0x10e1bfde0 while mapping USB URB for DMA during low-speed USB device enumeration on qcs615-ride; crash is unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which modifies GPIO ranges on shikra SoC only).

Possible fix: This is a pre-existing qcs615-ride platform issue. Short-term: exclude qcs615-ride from USB-dependent CI tests or add usb.nousb to kernel cmdline. Long-term: investigate qcs615 USB controller DMA addressing constraints, verify SWIOTLB/IOMMU aperture configuration in device tree, check for qcs615-specific USB errata, and ensure physical address 0x10e1bfde0 is in valid DMA range per qcs615 TRM.

Detail analysis attachment: failed_case_job227735_3_detailed.md

Case 4: Kernel Crash — Synchronous External Abort during USB DMA Setup

Failed case: Kernel Crash — Synchronous External Abort during USB DMA Setup

Root cause: Synchronous external abort (hardware memory access fault) during SWIOTLB bounce buffer copy operation while setting up DMA for USB device enumeration on qcs615-ride. The crash occurred at physical address 0x10e1bfde0 (x19 register) during memcpy from SWIOTLB bounce buffer (x1: ffff00008e1bfde0) to device-accessible memory (x0: ffff00007ffbf000), indicating an invalid or unmapped physical address in the IOMMU/SMMU translation path for the USB controller.

Possible fix: This is a pre-existing kernel issue unrelated to the PR (PR modifies shikra board DTS, crash is on qcs615-ride board). The crash indicates a platform-specific USB/IOMMU configuration issue on qcs615-ride. Recommended actions: (1) Verify USB controller IOMMU domain configuration in qcs615-ride.dts; (2) Check if USB controller DMA address constraints are correctly specified (dma-ranges property); (3) Enable CONFIG_IOMMU_DEBUGFS and CONFIG_ARM_SMMU_TESTBUS_DUMP to capture SMMU fault details; (4) Verify SWIOTLB buffer allocation is within valid DMA-accessible range for the USB controller; (5) Re-trigger CI job to confirm if this is a transient hardware/board issue or reproducible kernel bug.

Detail analysis attachment: failed_case_job227735_4_detailed.md

Job 227736 | SoC qcs6490-rb3gen2

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

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

Case 1: GIC

Failed case: GIC

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

Possible fix: Fix the GIC test script (Runner/suites/Kernel/Baseport/GIC/run.sh line 75) to correctly parse /proc/interrupts when CPUs are offline. The script should: (1) detect the number of online CPUs from /sys/devices/system/cpu/online, (2) only validate timer interrupts for online CPUs, (3) skip offline CPUs instead of reporting them as failures. This is NOT a kernel regression — the PR modifies Shikra device trees (gpio-reserved-ranges for SPI5), which is unrelated to qcs6490-rb3gen2 CPU topology.

Detail analysis attachment: failed_case_job227736_1_detailed.md

Case 2: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** Two firmware load failures detected: (1) cfg80211 regulatory.db missing (benign — WiFi functional tests passed, indicating fallback to built-in regulatory rules works correctly); (2) Renesas USB3 controller firmware (renesas_usb_fw.mem) missing from rootfs, causing xhci-pci-renesas probe failure at PCIe device 0001:04:00.0. Both are pre-existing infrastructure issues unrelated to the PR changes (PR modifies Shikra board GPIO/SPI5 DTS; test runs on RB3Gen2 with firmware packaging gaps).

Possible fix: For immediate CI unblocking: suppress the Probe_Failure_Check test or update its filter to exclude known-benign firmware load failures (regulatory.db, renesas_usb_fw.mem on RB3Gen2). For proper resolution: (1) add linux-firmware-regulatory package to rootfs to provide regulatory.db (optional, low priority since fallback works); (2) add renesas-usb-firmware package or manually include renesas_usb_fw.mem in /lib/firmware/ to enable the external USB3 controller on RB3Gen2 boards.

Detail analysis attachment: failed_case_job227736_2_detailed.md

Case 3: Freq_Scaling — Test Infrastructure Issue (CPU Topology Mismatch)

Failed case: Freq_Scaling — Test Infrastructure Issue (CPU Topology Mismatch)

Root cause: The Freq_Scaling test script expects 8 CPUs (cpu0-cpu7) based on the qcs6490 SoC specification, but CPU6 and CPU7 failed to boot during kernel initialization (PSCI error -22: EINVAL). The test successfully validated cpufreq interfaces for cpu0-cpu6 but failed when attempting to check cpu7, which does not exist in the running system. This is a pre-existing platform/firmware issue, not a regression introduced by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (which only modifies GPIO reserved ranges for Shikra boards).

Possible fix: Update the Freq_Scaling test script to dynamically detect online CPUs from /sys/devices/system/cpu/online instead of assuming a fixed CPU count. The test should validate cpufreq interfaces only for CPUs that successfully booted. For the underlying CPU6/7 boot failure, investigate PSCI firmware configuration and device tree CPU topology for qcs6490-rb3gen2 — this is a separate board-level issue requiring firmware/bootloader investigation.

Detail analysis attachment: failed_case_job227736_3_detailed.md

Case 4: USBHost

Failed case: USBHost

Root cause: Renesas xHCI USB host controller (PCIe device 0001:04:00.0) probe failed with error -2 (ENOENT) due to missing firmware file renesas_usb_fw.mem. Without a functional USB host controller, no USB devices can be enumerated on the qcs6490-rb3gen2 board.

Possible fix: Install the missing Renesas USB firmware package in the root filesystem. Add linux-firmware or linux-firmware-renesas package to the Yocto image recipe, or manually place renesas_usb_fw.mem in /lib/firmware/ on the target. Verify the firmware loads successfully by checking dmesg for "xhci-pci-renesas 0001:04:00.0: xHCI Host Controller" after reboot.

Detail analysis attachment: failed_case_job227736_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

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

Possible fix: Exclude KVM tests from LAVA test suites for boards configured to boot under Gunyah hypervisor (qcs6490-rb3gen2, and any other Gunyah-based platforms); alternatively, reconfigure the board to boot Linux directly at EL2 without Gunyah if KVM functionality is required for testing.

Detail analysis attachment: failed_case_job227736_5_detailed.md

Case 6: KVM_EL2_DTB — Platform Capability Limitation

Failed case: KVM_EL2_DTB — Platform Capability Limitation

Root cause: KVM/ARM virtualization (EL2/HYP mode) is not available on the qcs6490-rb3gen2 (Kodiak) platform. The kernel correctly detects this at boot with "kvm [1]: HYP mode not available" and does not create /dev/kvm. This is a pre-existing platform limitation, not a regression.

Possible fix: Mark KVM_EL2_DTB, KVM_Driver, and KVM_Infra tests as "skip" (not "fail") for qcs6490-rb3gen2 in the LAVA test suite configuration, since this platform does not support virtualization. Alternatively, exclude these tests from the qcs6490-rb3gen2 test matrix entirely.

Detail analysis attachment: failed_case_job227736_6_detailed.md

Case 7: ** KVM_Infra — Platform Capability Limitation (HYP mode unavailable)

Failed case: ** KVM_Infra — Platform Capability Limitation (HYP mode unavailable)

Root cause: /dev/kvm is not present

Possible fix: This is not a bug to fix — it is a known platform limitation. The qcs6490-rb3gen2 board does not support KVM/virtualization in its current firmware configuration. To resolve: (1) exclude KVM tests from the CI test suite for qcs6490-rb3gen2 platform, or (2) if virtualization support is required, work with the platform team to enable EL2 mode in the bootloader/firmware for this board. The PR under test (GPIO changes for Shikra SPI5) is unrelated and should not be blocked by this failure.

Detail analysis attachment: failed_case_job227736_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM initialization failed because the qcs6490-rb3gen2 platform is running under the Gunyah hypervisor (version gunyah-cdfb73831), which prevents KVM from accessing EL2 (HYP mode). The kernel message "kvm [1]: HYP mode not available" at boot time (4.633s) indicates KVM detected it cannot operate in nested virtualization mode.

Possible fix: This is a platform configuration issue, not a kernel regression. The test expectation is incorrect for this hardware configuration. Either: (1) disable KVM tests on platforms running under Gunyah hypervisor, or (2) configure the platform to boot without Gunyah if KVM testing is required, or (3) mark KVM tests as expected-fail/skip when Gunyah is detected at boot.

Detail analysis attachment: failed_case_job227736_8_detailed.md

Job 227737 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: WiFi driver (ath11k_pci) probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image, causing MHI power-up timeout (-110 ETIMEDOUT). This is a pre-existing Monaco platform issue unrelated to the PR (PR only modifies Shikra device trees).

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Monaco rootfs build recipe (Yocto/meta-qcom layer). Verify the linux-firmware package includes WCN6855 hw2.1 nfa765 variant firmware, or add it to the EXTRA_FIRMWARE list in the kernel config.

Detail analysis attachment: failed_case_job227737_1_detailed.md

Case 2: WiFi_Firmware_Driver

Failed case: WiFi_Firmware_Driver

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

Possible fix: Add the missing WCN6855 firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files) to the Monaco EVK rootfs image firmware directory (/lib/firmware/). Verify firmware packaging in the Yocto/build recipe includes the linux-firmware-ath11k or equivalent package for WCN6855 hw2.1 nfa765 variant.

Detail analysis attachment: failed_case_job227737_2_detailed.md

Case 3: ** WiFi Driver Probe Failure — ath11k_pci

Failed case: ** WiFi Driver Probe Failure — ath11k_pci

Root cause: ** WiFi driver probe failed with -110 (ETIMEDOUT) because the required firmware file /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the test image (error -2 ENOENT). The WCN6855 hw2.1 WiFi chip on monaco-evk requires platform-specific firmware variant nfa765/amss.bin which is not present in the filesystem. This is a pre-existing platform/image issue unrelated to the PR under test (PR modifies only shikra board GPIO configuration).

Possible fix: Add the missing WCN6855 nfa765 firmware variant to the monaco-evk test image by including the linux-firmware-ath11k package with the nfa765 variant, or create a symlink from the nfa765 path to an available WCN6855 firmware variant if nfa765 is not required for this test configuration. Verify firmware presence with ls -la /lib/firmware/ath11k/WCN6855/hw2.1/ before running WiFi tests on monaco-evk.

Detail analysis attachment: failed_case_job227737_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) probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the test rootfs. The firmware load failure (-ENOENT) causes MHI power-up timeout (-ETIMEDOUT), which cascades to probe failure. This is a pre-existing test infrastructure issue unrelated to the PR changes (PR modifies Shikra GPIO reserved ranges; test runs on Monaco EVK).

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the test rootfs image under /lib/firmware/. This is a test infrastructure fix, not a kernel code fix. The PR itself is not the cause of this failure.

Detail analysis attachment: failed_case_job227737_4_detailed.md

Job 227738 | SoC shikra-iqs-evk

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

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

Case 1: GIC

Failed case: GIC

Root cause: Test script bug — the GIC test script hardcodes a loop over CPUs 0-7 but shikra-iqs-evk has only 4 CPUs (0-3); when parsing /proc/interrupts for non-existent CPUs 4-7, the script extracts non-numeric strings ("GICv3", "Level", "arch_timer") causing bash integer comparison failures at line 75.

Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding a loop over CPUs 0-7; alternatively, add bounds checking to skip CPUs that don't have interrupt count columns in /proc/interrupts.

Detail analysis attachment: failed_case_job227738_1_detailed.md

Case 2: ** Probe_Failure_Check — Multiple driver probe failures detected

Failed case: ** Probe_Failure_Check — Multiple driver probe failures detected

Root cause: ** The Probe_Failure_Check test detected 7 probe/firmware errors, of which only the TPM (tpm_tis_spi spi0.0: error -110) is related to the PR's SPI5 GPIO unreservation; the TPM hardware times out because it is not present, powered, or configured correctly on the shikra-iqs-evk test board, despite SPI5 now being accessible.

Possible fix: Verify TPM hardware presence and power/reset configuration on the shikra-iqs-evk test board; if TPM is intentionally absent on this board variant, update the device tree to conditionally include the TPM node only for boards with TPM hardware, or suppress this specific probe failure in CI for boards without TPM.

Detail analysis attachment: failed_case_job227738_2_detailed.md

Case 3: USBHost — Test Infrastructure / Hardware Dependency Issue

Failed case: USBHost — Test Infrastructure / Hardware Dependency Issue

Root cause: The USBHost test failed because no USB host devices were detected on the shikra-iqs-evk board. The USB controller at 4e00000.usb is configured in gadget mode (systemd log shows "Hardware activated USB gadget" target reached), not host mode. The test expects external USB devices to be connected to a USB host port, but either: (1) the board's USB port is in peripheral/gadget mode by default in the device tree, (2) no USB host hardware is physically available on this EVK variant, or (3) no USB devices are physically connected to the test setup in the LAVA lab.

Possible fix: This is a test environment configuration issue, not a kernel regression introduced by the PR (which only modifies GPIO reserved ranges for SPI5, unrelated to USB). Recommended actions: (1) Verify the shikra-iqs-evk hardware has a USB host port and that it is wired correctly; (2) Check the device tree for the USB controller dr_mode property — if set to "peripheral" or "otg" defaulting to peripheral, consider changing to "host" or "otg" with proper role-switching support; (3) Ensure a USB device (e.g., USB flash drive, keyboard) is physically connected to the USB host port in the LAVA lab setup for this board; (4) If USB host is not supported on shikra-iqs-evk hardware, mark this test as SKIP for this platform rather than FAIL.

Detail analysis attachment: failed_case_job227738_3_detailed.md

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

Failed case: ** BT_SCAN (Test Environment Issue — No Discoverable Devices)

Root cause: ** Bluetooth scan test failed because no Bluetooth devices were present in the LAVA lab environment to be discovered. The Bluetooth stack is fully functional: hci0 adapter is powered on, bluetoothd is running, discovery can be started and stopped successfully, and the BT_ON_OFF functional test passed. The test executed 3 scan attempts with multiple fallback methods but found zero devices in all attempts. This is a test environment limitation, not a kernel regression.

Possible fix: This is not a kernel bug requiring a code fix. To resolve: (1) Ensure at least one Bluetooth device (phone, speaker, beacon) is powered on and discoverable within range of the shikra-iqs-evk board in the LAVA lab during test execution, OR (2) Modify the BT_SCAN test to be informational rather than blocking when zero devices are found but the Bluetooth stack is confirmed functional via BT_ON_OFF passing.

Detail analysis attachment: failed_case_job227738_4_detailed.md

Case 5: Kernel Crash — Synchronous External Abort in qcom_rng Hardware Access

Failed case: Kernel Crash — Synchronous External Abort in qcom_rng Hardware Access

Root cause: The qcom_rng driver crashed with a synchronous external abort (ESR 0x96000010) when attempting to read from RNG hardware registers at qcom_rng_read+0xc4. This indicates the CPU attempted to access a physical address that is not responding on the bus, likely because the RNG hardware block is unpowered, clock-gated, or has an incorrect MMIO mapping. The crash occurred on Shikra IQS EVK during the qcom_hwrng test when reading entropy from /dev/hwrng. The PR modifies gpio-reserved-ranges to enable SPI5 (GPIOs 14-17) for TPM support, but there is no direct evidence linking this GPIO change to RNG hardware power/clock state.

Possible fix: Verify that the RNG hardware block has correct power domain, clock, and MMIO mappings in the Shikra IQS EVK device tree. Check if the gpio-reserved-ranges change inadvertently affects any shared power rail or clock tree that supplies the RNG block. Add runtime PM and clock enable checks in qcom_rng_read before accessing hardware registers. If the issue reproduces, enable CONFIG_IOMMU_DEBUGFS and CONFIG_ARM_SMMU_TESTBUS_DUMP to capture detailed bus transaction state, and collect full device tree dump to verify RNG node configuration.

Detail analysis attachment: failed_case_job227738_5_detailed.md

Case 6: Kernel Crash — Synchronous External Abort (Hardware Bus Error)

Failed case: Kernel Crash — Synchronous External Abort (Hardware Bus Error)

Root cause: The qcom_hwrng driver triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xc4 when attempting to read from the hardware RNG MMIO registers on Shikra IQS EVK, causing a kernel panic and system reboot; the subsequent KVM_EL2_DTB test failure (missing /dev/kvm) is a consequence of the reboot, not an independent issue.

Possible fix: This is a pre-existing hardware/driver/firmware issue unrelated to PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (GPIO reserved ranges for SPI5). Investigate qcom_rng driver MMIO access on Shikra: verify RNG hardware is properly powered/clocked in device tree, check if RNG MMIO base address is correct for this SoC revision, and review firmware/TZ configuration for RNG access permissions. Short-term: disable qcom_hwrng test or mark as known issue for Shikra IQS EVK until root cause is resolved.

Detail analysis attachment: failed_case_job227738_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: ** The qcom_rng driver attempted to read from a hardware register (ldr w28, [x26] at qcom_rng_read+0xc4) that is not accessible on the Shikra IQS EVK platform. The bus rejected the access with a synchronous external abort (ESR 0x96000010), causing a kernel panic at timestamp [ 1015.897322] during the qcom_hwrng test. This is a platform-specific hardware availability issue where the RNG hardware block is either not present, not powered, or not clocked on this board variant. PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 (GPIO reserved ranges for SPI5/TPM) is unrelated to this failure.

Possible fix: Collect additional focused logs and rerun the failed test case.

Detail analysis attachment: failed_case_job227738_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 qcom_rng driver triggered a synchronous external abort (hardware bus fault) when attempting to read from RNG hardware registers during the qcom_hwrng test. This indicates the RNG hardware block was either not powered/clocked correctly, or the register address is invalid/inaccessible on this board. This is a pre-existing kernel bug unrelated to the PR, which only modifies GPIO reservations for SPI5/TPM.

Possible fix: Investigate qcom_rng driver probe sequence on shikra-iqs-evk: verify RNG device tree node includes correct clocks, power-domains, and reg properties; confirm clocks/power-domains are enabled before register access; check if firmware/TZ restricts RNG access on this board. As a workaround, disable the qcom_hwrng test in CI for shikra-iqs-evk until the driver issue is resolved.

Detail analysis attachment: failed_case_job227738_8_detailed.md

Case 9: lava-test-shell

Failed case: lava-test-shell

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

Possible fix: Verify RNG device tree node in shikra-iqs-evk.dts includes correct power-domains, clocks, and reg properties; confirm RNG power domain is enabled in firmware; if RNG is not supported on this EVK variant, disable the RNG node in the device tree with status = "disabled".

Detail analysis attachment: failed_case_job227738_9_detailed.md

Case 10: Kernel Crash — Synchronous External Abort in qcom_rng driver during qcom_hwrng test

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

Root cause: Hardware fault (synchronous external abort 0x96000010) triggered in qcom_rng_read+0xc4 when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The crash occurred at kernel timestamp 1015.897s during the qcom_hwrng test execution on shikra-iqs-evk. After the kernel panic, the warm reset path encountered repeated EFI runtime service paging faults, preventing proper crashdump collection. The board eventually reset to bootloader (XBL), and LAVA timed out after 2400 seconds waiting for the system to recover.

Possible fix: This is a pre-existing hardware/firmware issue unrelated to the PR (which only modifies GPIO reserved ranges for SPI5). The synchronous external abort indicates a bus-level fault when accessing the PRNG hardware registers. Recommended actions: (1) Verify PRNG hardware clock/power domain configuration in device tree for shikra-iqs-evk; (2) Check if PRNG register base address mapping is correct; (3) Add kernel cmdline reboot=panic_warm qcom_scm.download_mode=1 and ensure TCSR DT node is present to enable crashdump collection on future panics; (4) Re-trigger the CI job to confirm if this is a transient hardware fault or reproducible regression.

Detail analysis attachment: failed_case_job227738_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: Hardware random number generator (HWRNG) register access triggered a synchronous external abort at qcom_rng_read+0xc4, indicating the HWRNG hardware block was not accessible (likely powered off, clocked off, or in an invalid state) when the qcom_hwrng test attempted to read entropy from /dev/hwrng.

Possible fix: The PR changes gpio-reserved-ranges for SPI5 (GPIOs 14-17) and is unrelated to HWRNG hardware access. This is a pre-existing platform/firmware issue. Short-term: skip the qcom_hwrng test on shikra-iqs-evk until HWRNG power/clock dependencies are resolved. Long-term: audit qcom_rng driver probe to ensure all power domains, clocks, and resets are correctly acquired and enabled before registering the hwrng device; verify shikra-iqs-evk device tree includes correct HWRNG power-domain, clock, and interconnect bindings.

Detail analysis attachment: failed_case_job227738_11_detailed.md

Job 227739 | SoC hamoa-evk

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

Failed test cases in LAVA job 227739 (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 not PR-introduced regressions. (1) For QSEECOM: verify TrustZone firmware includes UEFI secure app and is loaded correctly on hamoa-evk. (2) For LPG: fix the reg property in hamoa-evk PMIC DT node to match qcom-spmi-lpg driver expectations (check Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml). (3) For regulatory.db: add wireless-regdb package to rootfs or suppress this known-benign failure in the Probe_Failure_Check test filter. The PR can proceed — these failures are unrelated to the GPIO changes.

Detail analysis attachment: failed_case_job227739_1_detailed.md

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

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

Root cause: ** Test expects IOMMU group attachment for USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video-codec (aa00000.video-codec) on hamoa-evk, but these devices are not attached to IOMMU groups in the current device tree configuration. This is a pre-existing platform configuration issue unrelated to the PR, which only modifies gpio-reserved-ranges for Shikra boards.

Possible fix: Update the smmu test's critical device list to exclude USB PHY devices and video-codec on hamoa-evk, or add IOMMU bindings for these devices in the hamoa device tree if they are genuine DMA masters requiring protection. The PR itself does not require changes.

Detail analysis attachment: failed_case_job227739_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization failed because Gunyah hypervisor is already running at EL2 on the Hamoa IoT EVK platform, preventing KVM from taking control of HYP mode; kernel message "kvm [1]: HYP mode not available" indicates KVM detected it cannot run in nested virtualization configuration.

Possible fix: This is a platform configuration issue, not a PR-introduced regression (PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018 only modifies GPIO reserved ranges for Shikra boards). KVM and Gunyah hypervisor are mutually exclusive on ARM64 — only one can control EL2. To enable KVM testing: (1) disable Gunyah hypervisor in the boot configuration, or (2) exclude KVM tests from the Hamoa EVK test suite, or (3) use a different board without Gunyah for KVM validation.

Detail analysis attachment: failed_case_job227739_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: ** hamoa-evk does not support ARM Virtualization Extensions (EL2/HYP mode)

Possible fix: Collect additional focused logs and rerun the failed test case.

Detail analysis attachment: failed_case_job227739_4_detailed.md

Case 5: ** KVM_Infra

Failed case: ** KVM_Infra

Root cause: ** The Hamoa EVK firmware/bootloader does not configure the CPU to boot at EL2 (hypervisor exception level), preventing KVM initialization. The kernel message kvm [1]: HYP mode not available at boot time (line 3942) confirms EL2 is unavailable, causing /dev/kvm device node creation to be skipped and all KVM tests to fail.

Possible fix: This is a pre-existing platform limitation, not a PR-introduced issue (the PR only modifies GPIO reserved ranges for Shikra boards, unrelated to Hamoa or KVM). Recommended action: Skip KVM tests on hamoa-evk in the LAVA job definition, or work with the Qualcomm firmware team to enable EL2 support by updating the bootloader/UEFI configuration to drop to EL2 before kernel entry.

Detail analysis attachment: failed_case_job227739_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM cannot initialize because HYP mode (EL2) is not available — the Gunyah hypervisor is already running at EL2 on the hamoa-evk platform, preventing KVM from taking control of the hypervisor privilege level.

Possible fix: This is a platform configuration issue, not a kernel regression. The hamoa-evk board runs under the Gunyah hypervisor by default, which occupies EL2 and prevents KVM from initializing. To enable KVM testing on this platform, either: (1) boot without the Gunyah hypervisor (if supported by the platform firmware), or (2) exclude KVM tests from the hamoa-evk CI test suite, or (3) use a different test platform that boots Linux directly at EL1 without a hypervisor.

Detail analysis attachment: failed_case_job227739_6_detailed.md

Job 227740 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check — Pre-existing Platform Driver Issues (Not PR-Introduced)

Failed case: Probe_Failure_Check — Pre-existing Platform Driver Issues (Not PR-Introduced)

Root cause: The Probe_Failure_Check test detected 5 pre-existing driver probe failures on purwa-evk (iq-x5121-evk): qcom_qseecom_uefisecapp (-EBUSY, TrustZone resource conflict), qcom-spmi-lpg (-EINVAL, invalid multi-led DT property), two qcom-pcie controllers (-ENODATA, missing PCIe configuration), and regulatory.db firmware (-ENOENT, missing file). These are platform-specific configuration issues unrelated to the PR, which only modifies Shikra device trees (gpio-reserved-ranges for SPI5 GPIOs 14-17). The test platform is purwa-evk, not Shikra.

Possible fix: Mark this test failure as a false positive for PR validation. The probe failures are pre-existing purwa-evk platform issues that should be tracked separately. For proper PR validation, either: (1) run tests on Shikra boards where the PR changes apply, or (2) configure the Probe_Failure_Check test to exclude known platform-specific probe failures that don't indicate kernel regressions. The PR is safe to merge as it does not affect purwa-evk.

Detail analysis attachment: failed_case_job227740_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Pre-existing platform configuration issue on purwa-evk — six critical master devices (five USB PHY controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800, and video codec at aa00000) are missing IOMMU group attachments in the device tree, causing the SMMU validation test to fail. This is unrelated to the PR changes, which only modify GPIO reserved ranges on shikra boards.

Possible fix: This failure is not caused by PR FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access #1018. The PR modifies shikra board DTS files (shikra-cqm-evk.dts, shikra-cqs-evk.dts, shikra-iqs-evk.dts) to fix GPIO reserved ranges for SPI5 access, while the test ran on purwa-evk and failed due to missing IOMMU bindings for USB PHY and video codec devices in the purwa-evk device tree. Mark this test failure as a known pre-existing issue for purwa-evk; the PR should not be blocked by this failure.

Detail analysis attachment: failed_case_job227740_2_detailed.md

Case 3: ** KVM_Driver — Platform Configuration Mismatch (Gunyah Hypervisor Owns EL2)

Failed case: ** KVM_Driver — Platform Configuration Mismatch (Gunyah Hypervisor Owns EL2)

Root cause: ** The Purwa EVK platform runs under the Gunyah hypervisor, which owns EL2 (HYP mode). KVM requires direct EL2 access to initialize and create /dev/kvm. When Gunyah is active, KVM correctly reports "HYP mode not available" and does not create /dev/kvm. This is architecturally correct behavior, not a kernel bug.

Possible fix: Exclude KVM tests from the Purwa EVK test suite. Add a platform-specific test filter to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests on Gunyah-enabled platforms. Alternatively, document this as expected behavior and mark these tests as "N/A" for Purwa EVK in CI reporting.

Detail analysis attachment: failed_case_job227740_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM driver initialization failed on purwa-evk because Gunyah hypervisor is running at EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" indicates EL2 is already claimed by Gunyah. This is a platform configuration issue, not a PR-introduced regression (PR modifies GPIO ranges on shikra boards, unrelated to purwa-evk KVM functionality).

Possible fix: This is expected behavior on platforms running Gunyah hypervisor. To enable KVM testing: (1) boot without Gunyah hypervisor (requires firmware/bootloader changes to boot Linux at EL2), or (2) exclude KVM tests from purwa-evk CI runs since Gunyah and KVM are mutually exclusive, or (3) use nested virtualization if Gunyah supports exposing virtual EL2 to guest (requires Gunyah feature support).

Detail analysis attachment: failed_case_job227740_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR modifies Shikra GPIO ranges and is unrelated to KVM or Purwa. To enable KVM on purwa-evk, either: (1) disable Gunyah hypervisor in the boot configuration and rebuild the firmware/bootloader to boot Linux directly at EL2, or (2) exclude KVM tests from the purwa-evk test suite since this platform is configured for Gunyah-based virtualization, not KVM-based virtualization. KVM and Gunyah are mutually exclusive architectures.

Detail analysis attachment: failed_case_job227740_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failed because HYP mode is already occupied by the Gunyah hypervisor on Purwa IoT EVK — the kernel message kvm [1]: HYP mode not available indicates that EL2 (hypervisor exception level) is not available to KVM, as Gunyah is running at EL2.

Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR modifies GPIO reserved ranges for Shikra boards and does not affect KVM or hypervisor configuration. On Purwa IoT EVK, KVM and Gunyah hypervisor cannot coexist — either disable Gunyah in the firmware/bootloader configuration to allow KVM to run, or skip KVM tests on platforms where Gunyah is enabled. Update the LAVA test suite to skip KVM tests when Gunyah hypervisor is detected at boot.

Detail analysis attachment: failed_case_job227740_6_detailed.md

Job 227741 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: The failures are not PR-introduced (PR modifies Shikra DTS; test runs on qcs9100-ride). For the Aquantia PHY failure: add a valid firmware-name property to the stmmac-0:08 PHY node in the qcs9100-ride DTS, specifying the correct Aquantia firmware file path (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld";), or mark the property as optional if firmware is not required for this PHY variant.

Detail analysis attachment: failed_case_job227741_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device (aa00000.video-codec) is not attached to any IOMMU group on qcs9100-ride, indicating missing or incorrect iommu DT binding for the video-codec node in the device tree.

Possible fix: Add or verify the iommu property in the video-codec device tree node (aa00000.video-codec) for qcs9100-ride to ensure it is properly attached to an IOMMU group; this is a pre-existing platform DT issue unrelated to the PR's GPIO reserved-ranges changes for Shikra boards.

Detail analysis attachment: failed_case_job227741_2_detailed.md

Case 3: USBHost

Failed case: USBHost

Root cause: LAVA lab infrastructure issue — no physical USB devices connected to the qcs9100-ride board's USB ports. The USB host controllers (xhci-hcd) initialized successfully and enumerated three USB root hubs (Bus 001, 002, 003), but the test expects at least one functional USB device beyond root hubs to be physically connected.

Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB hub with downstream devices) to one of the qcs9100-ride board's USB ports in the LAVA lab. If this is a known lab limitation for this board, add USBHost to the known-benign-failures suppression list for qcs9100-ride with condition "always suppress" and rationale "qcs9100-ride lab setup does not include USB peripherals".

Detail analysis attachment: failed_case_job227741_3_detailed.md

Case 4: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

Root cause: Aquantia AQR115C PHY driver probe failure with error -EINVAL (-22) due to missing firmware-name property in device tree for the PHY node at stmmac-0:08, preventing the qcom-ethqos driver from attaching to the PHY when bringing up interface end0 (23040000.ethernet) on qcs9100-ride.

Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY device tree node (stmmac-0:08) in the qcs9100-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 similar based on the PHY firmware available in /lib/firmware/aquantia/).

Detail analysis attachment: failed_case_job227741_4_detailed.md

Case 5: KVM_Driver — /dev/kvm device node unavailable

Failed case: KVM_Driver — /dev/kvm device node unavailable

Root cause: KVM driver initialization failed because the Gunyah hypervisor running on qcs9100-ride does not expose EL2 (HYP mode) to Linux; kernel message "kvm [1]: HYP mode not available" indicates KVM detected it cannot access virtualization extensions, preventing /dev/kvm creation.

Possible fix: This is expected behavior on qcs9100-ride when Gunyah hypervisor is active — Gunyah reserves EL2 for its own use and does not delegate virtualization to Linux KVM. Mark KVM_Driver test as SKIP (not FAIL) for qcs9100-ride in the LAVA test definition, or configure the board firmware to boot without Gunyah if native KVM support is required for this validation.

Detail analysis attachment: failed_case_job227741_5_detailed.md

Case 6: KVM_EL2_DTB — Platform Architecture Limitation (Not a Defect)

Failed case: KVM_EL2_DTB — Platform Architecture Limitation (Not a Defect)

Root cause: qcs9100-ride (LeMans) platform runs Gunyah hypervisor in EL2, preventing Linux KVM from accessing HYP mode. KVM correctly detects "HYP mode not available" and fails to initialize. This is expected behavior on Gunyah-enabled platforms where Gunyah and KVM are mutually exclusive.

Possible fix: Update LAVA test suite to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on Gunyah-enabled platforms by detecting "Hypervisor cold boot" message in dmesg or checking /sys/hypervisor/type. Mark these tests as SKIP (not FAIL) when Gunyah is present.

Detail analysis attachment: failed_case_job227741_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM initialization failed because the qcs9100-ride (LeMans) platform is running Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" indicates EL2 is already occupied by Gunyah (version gunyah-cdfb73831, cold boot at 1.384564s).

Possible fix: This is not a PR-introduced regression. The PR modifies GPIO reserved ranges for Shikra SPI5/TPM support and is unrelated to KVM/virtualization. The failure is expected platform behavior: qcs9100 (LeMans Ride) runs Gunyah hypervisor by default, making KVM unavailable. To enable KVM testing on this platform, either: (1) disable Gunyah in the bootloader/firmware configuration and rebuild the image without Gunyah hypervisor, or (2) exclude KVM tests from the qcs9100-ride LAVA job definition, as KVM and Gunyah cannot coexist.

Detail analysis attachment: failed_case_job227741_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

Root cause: qcs9100-ride platform boots Linux in EL1 without hypervisor (EL2) mode enabled; KVM driver initialization fails with "HYP mode not available" and /dev/kvm device node is not created.

Possible fix: This is not a kernel regression. The qcs9100-ride platform requires bootloader/firmware configuration to enable EL2 mode for KVM support. Either: (1) update ABL/UEFI firmware to boot Linux in EL2, or (2) exclude KVM tests from the qcs9100-ride CI test suite until EL2 support is enabled on this platform.

Detail analysis attachment: failed_case_job227741_8_detailed.md

xueyaoan requested review from a team, Komal Bajaj (Komal-Bajaj), Ricardo Salveti (ricardosalveti) and Trilok Soni (trsoni) August 26, 2026 10:56

xueyaoan changed the title ~~arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access~~ FROMLIST: arm64: dts: qcom: shikra: Fix gpio-reserved-ranges to allow SPI5 access Aug 26, 2026

Shiraz Hashim (shashim-quic) approved these changes Aug 26, 2026

View reviewed changes

Komal Bajaj (Komal-Bajaj) previously approved these changes Aug 26, 2026

View reviewed changes

Salendarsingh Gaud (sgaud-quic) requested changes Aug 28, 2026

View reviewed changes

xueyaoan force-pushed the shikra-dtpm-qli branch from 21ad900 to 8f71305 Compare August 31, 2026 09:14

qcomlnxci requested review from a team and Mukesh Ojha (mukeshojha-linux) August 31, 2026 09:16

Salendarsingh Gaud (sgaud-quic) requested changes Sep 1, 2026

View reviewed changes

Shiraz Hashim (shashim-quic) added this to the qli-2.1 pull-request freeze milestone Sep 11, 2026

Shiraz Hashim (shashim-quic) approved these changes Sep 11, 2026

View reviewed changes

Shiraz Hashim (shashim-quic) previously approved these changes Sep 11, 2026

View reviewed changes

xueyaoan dismissed stale reviews from Shiraz Hashim (shashim-quic) and Komal Bajaj (Komal-Bajaj) via 054b33f September 11, 2026 04:14

xueyaoan force-pushed the shikra-dtpm-qli branch from 8f71305 to 054b33f Compare September 11, 2026 04:14

qcomlnxci requested a review from a team September 11, 2026 04:15

Shiraz Hashim (shashim-quic) previously approved these changes Sep 12, 2026

View reviewed changes

xueyaoan dismissed Shiraz Hashim (shashim-quic)’s stale review via f63d0de September 13, 2026 13:42

xueyaoan force-pushed the shikra-dtpm-qli branch from 054b33f to f63d0de Compare September 13, 2026 13:42

qcomlnxci requested a review from a team September 13, 2026 13:43

Komal Bajaj (Komal-Bajaj) approved these changes Sep 13, 2026

View reviewed changes

Salendarsingh Gaud (sgaud-quic) approved these changes Sep 15, 2026

View reviewed changes

Salendarsingh Gaud (sgaud-quic) merged commit 2fe2508 into qualcomm-linux:qcom-6.18.y Sep 15, 2026
6 of 8 checks passed

Conversation

xueyaoan commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qcomlnxci commented Aug 26, 2026

Test jobs on 21ad900

Uh oh!

qcomlnxci commented Aug 26, 2026

Test Matrix

Uh oh!

Salendarsingh Gaud (sgaud-quic) left a comment

Choose a reason for hiding this comment

Uh oh!

qcomlnxci commented Aug 31, 2026

Test jobs on 8f71305

Uh oh!

qcomlnxci commented Aug 31, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 1, 2026

Test jobs on 8f71305

Uh oh!

qcomlnxci commented Sep 1, 2026

Test Matrix

Uh oh!

Salendarsingh Gaud (sgaud-quic) left a comment

Choose a reason for hiding this comment

Uh oh!

Salendarsingh Gaud (sgaud-quic) commented Sep 2, 2026

Uh oh!

psarma-qcom commented Sep 10, 2026

Uh oh!

Salendarsingh Gaud (sgaud-quic) commented Sep 10, 2026

Uh oh!

psarma-qcom commented Sep 10, 2026

Uh oh!

xueyaoan commented Sep 11, 2026

Uh oh!

qcomlnxci commented Sep 12, 2026

Test jobs on 054b33f

Uh oh!

qcomlnxci commented Sep 12, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 12, 2026

Test jobs on 054b33f

Uh oh!

qcomlnxci commented Sep 12, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 13, 2026

Test jobs on 054b33f

Uh oh!

qcomlnxci commented Sep 13, 2026

Test Matrix

Uh oh!

Salendarsingh Gaud (sgaud-quic) commented Sep 13, 2026

Uh oh!

xueyaoan commented Sep 13, 2026

Uh oh!

qcomlnxci commented Sep 13, 2026

Test jobs on f63d0de

Uh oh!

qcomlnxci commented Sep 13, 2026

Test Matrix

Uh oh!

Salendarsingh Gaud (sgaud-quic) commented Sep 14, 2026

Uh oh!

qcomlnxci commented Sep 15, 2026

Test jobs on f63d0de

Uh oh!

qcomlnxci commented Sep 15, 2026

Test Matrix

Uh oh!

Uh oh!

qlijarvis commented Sep 15, 2026

PR #1018 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

xueyaoan commented Aug 26, 2026 •

edited

Loading