Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

[Salendarsingh Gaud (sgaud-quic)]

Name SHA Commits

tech/bsp/clk b662153 14
tech/bsp/devfreq 0837ca4 7
tech/bsp/sched 9c2e4b8 3
tech/security/firmware-smc 16b0235 9
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 8c716bc 1
tech/bus/peripherals c191e3d 10
tech/bus/pci/all 99c5b35 40
tech/bus/usb/dwc d90fb64 4
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing 257e1ef 26
tech/pmic/misc e7bb366 12
tech/mem/iommu cdc9e80 9
tech/mm/audio/all 762de76 2
tech/mm/camss f9a60f5 43
tech/mm/drm a5b4a5e 66
tech/mm/fastrpc fab5742 4
tech/mm/video bfab35e 47
tech/mm/gpu e065d5a 1
tech/net/ath 284d6dc 7
tech/net/bluetooth e352848 8
tech/pm/power 0d87ce2 10
tech/pm/thermal a58f3b3 8
tech/security/crypto 4c71afd 13
tech/security/ice dc34f45 14
tech/storage/all cb6192d 7
tech/all/dt/qcs6490 55b5c3b 20
tech/all/dt/qcs9100 3e3223b 22
tech/all/dt/qcs8300 6a513e3 28
tech/all/dt/qcs615 c3eea9f 13
tech/all/dt/agatti 2ca1b63 2
tech/all/dt/eliza 2709842 13
tech/all/dt/hamoa 3f57af0 34
tech/all/dt/glymur a43a2eb 27
tech/all/dt/kaanapali 35871da 17
tech/all/dt/pakala 9e50a87 12
tech/all/shikra bba7654 119
tech/all/config 5dbc967 81
tech/overlay/dt 3c5f17c 85
tech/all/workaround 42fd140 13
tech/noup/debug/all f017bf6 33
tech/hwe/unoq a2d85fe 4
early/hwe/nord 814d772 74
early/hwe/staging/nord 56b4e2c 89

[qcomlnxci]

Test jobs on 697ac0f

• multimedia Job 227621 on glymur-crd
• multimedia Job 227617 on hamoa-iot-evk
• multimedia Job 227619 on kaanapali-mtp
• multimedia Job 227623 on lemans-evk
• multimedia Job 227626 on monaco-evk
• multimedia Job 227622 on purwa-iot-evk
• multimedia Job 227624 on qcs615-ride
• multimedia Job 227627 on qcs6490-rb3gen2
• multimedia Job 227628 on qcs8300-ride
• multimedia Job 227618 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227620 on shikra-iqs-evk
• multimedia Job 227625 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 239cdce

• multimedia Job 227690 on glymur-crd
• multimedia Job 227686 on hamoa-iot-evk
• multimedia Job 227693 on kaanapali-mtp
• multimedia Job 227696 on lemans-evk
• multimedia Job 227695 on monaco-evk
• multimedia Job 227694 on purwa-iot-evk
• multimedia Job 227691 on qcs615-ride
• multimedia Job 227692 on qcs6490-rb3gen2
• multimedia Job 227689 on qcs8300-ride
• multimedia Job 227697 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227688 on shikra-iqs-evk
• multimedia Job 227687 on sm8750-mtp

[qcomlnxci]

Test Matrix

Test Case	glymur-crd-multimedia	hamoa-iot-evk-multimedia	kaanapali-mtp-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia	sm8750-mtp-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass
BT_FW_KMD_Service	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
Ethernet_Basic_Validation	⚠️ skip	⚠️ skip	◻️	◻️	✅ Pass	◻️	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	✅ Pass	❌ Fail	◻️	◻️	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail	❌ Fail
Probe_Failure_Check	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	⚠️ skip	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
USBHost	❌ Fail	✅ Pass	❌ Fail	◻️	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	❌ Fail
WiFi_OnOff	✅ Pass	✅ Pass	◻️	◻️	❌ Fail	◻️	✅ Pass	✅ Pass	⚠️ skip	❌ Fail	⚠️ skip	❌ Fail
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	⚠️ skip	⚠️ skip	◻️	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ 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	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass
watchdog	✅ Pass	✅ Pass	◻️	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 239cdce

• multimedia Job 227750 on glymur-crd
• multimedia Job 227752 on hamoa-iot-evk
• multimedia Job 227748 on kaanapali-mtp
• multimedia Job 227742 on lemans-evk
• multimedia Job on monaco-evk
• multimedia Job 227746 on purwa-iot-evk
• multimedia Job 227744 on qcs615-ride
• multimedia Job 227743 on qcs6490-rb3gen2
• multimedia Job 227749 on qcs8300-ride
• multimedia Job 227751 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227747 on shikra-iqs-evk
• multimedia Job 227745 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1085

Job 225058 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a false positive test failure. The Probe_Failure_Check test is overly strict and flags any firmware load failure regardless of functional impact. Recommended actions: (1) Short-term: Suppress this specific regulatory.db failure in the Probe_Failure_Check test logic, as it is a known benign failure when WiFi tests pass. (2) Long-term: Either include the regulatory.db file in the rootfs image (package wireless-regdb or equivalent), or refine the Probe_Failure_Check test to exclude known-optional firmware files from failure criteria.
4. Detail analysis attachment: failed_case_job225058_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Venus video codec child devices (video-decoder and video-encoder) are not attached to IOMMU groups because the qcs615-ride device tree is missing the required iommu-map property for the venus node. The PR introduces iommu-map support for venus firmware IOMMU domain attachment (via new dt-binding VENUS_FIRMWARE in include/dt-bindings/media/qcom,qcs615-venus.h) and updates the talos-el2.dtso overlay, but does not update the base qcs615-ride.dts file.
3. Possible fix: Add the iommu-map property to the venus node in arch/arm64/boot/dts/qcom/qcs615-ride.dts following the pattern used in talos-el2.dtso: iommu-map = <VENUS_FIRMWARE &apps_smmu 0xe42 0x0 0x1>; and include the header #include <dt-bindings/media/qcom,qcs615-venus.h> at the top of the file.
4. Detail analysis attachment: failed_case_job225058_2_detailed.md

  Case 3: KVM_Driver — KVM device node unavailable

1. Failed case: KVM_Driver — KVM device node unavailable
2. Root cause: Gunyah hypervisor (gunyah-1cb9db980) is running at EL2 on QCS615 Ride, preventing KVM from initializing. KVM requires exclusive EL2 access to create /dev/kvm, but EL2 is already occupied by the Gunyah hypervisor. The kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected it cannot access EL2.
3. Possible fix: This is not a PR-introduced regression — it is a platform configuration issue. QCS615 Ride firmware is configured to boot with Gunyah hypervisor enabled, which is incompatible with KVM. To enable KVM: (1) rebuild firmware with Gunyah hypervisor disabled, or (2) configure bootloader to boot Linux directly at EL2 without a hypervisor, or (3) mark KVM tests as expected-fail for QCS615 Ride in the CI test matrix since this platform is configured for Gunyah, not KVM.
4. Detail analysis attachment: failed_case_job225058_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM subsystem initialization failed because ARM EL2 (Hypervisor mode) is not available on the qcs615-ride platform. Kernel log shows kvm [1]: HYP mode not available at boot time (2.259894s), preventing /dev/kvm device node creation. CONFIG_KVM is enabled in kernel config but the underlying hardware/firmware does not support virtualization extensions.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The qcs615-ride board does not support ARM virtualization extensions (EL2/HYP mode). Mark KVM tests as SKIP for this platform in the LAVA test suite, or exclude qcs615-ride from KVM test runs. If EL2 support is expected, verify bootloader/TrustZone firmware configuration allows EL2 entry.
4. Detail analysis attachment: failed_case_job225058_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The qcs615-ride board requires bootloader/firmware configuration to boot Linux at EL2. Options: (1) Configure ABL/XBL to load hypvm.mbn and boot Linux at EL2, or (2) Mark KVM tests as "not applicable" for qcs615-ride in the CI test suite if this platform is not intended to support KVM/virtualization. The PR changes (PCIe, PSCI reboot modes, QSPI) do not affect KVM and are unrelated to this failure.
4. Detail analysis attachment: failed_case_job225058_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 platform does not support ARM EL2 (Hypervisor mode), which is required for KVM functionality. Kernel message at boot shows "kvm [1]: HYP mode not available", preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
3. Possible fix: Exclude KVM tests from the qcs615-ride test suite, as this platform lacks hardware virtualization support (no EL2). Add platform capability detection to skip KVM tests on non-virtualization-capable SoCs.
4. Detail analysis attachment: failed_case_job225058_6_detailed.md

Job 225059 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check — Pre-existing Hardware/Platform Issues

1. Failed case: ** Probe_Failure_Check — Pre-existing Hardware/Platform Issues
2. Root cause: ** Three probe failures detected on qcs8300-ride platform: (1) Two PCIe controllers (1c00000.pcie, 1c10000.pcie) fail with -ETIMEDOUT due to PCIe PHY initialization timeouts, indicating hardware not responding or power/clock/reset sequencing issues; (2) Aquantia AQR115C Ethernet PHY fails with -EINVAL due to missing firmware-name DT property. These are pre-existing platform issues unrelated to the PR, which only modifies documentation and DT bindings without touching driver code or qcs8300 device trees.
3. Possible fix: Mark this test case as a known platform issue for qcs8300-ride and exclude from PR validation. For permanent resolution: (1) Debug PCIe PHY power/clock/reset sequencing on qcs8300-ride hardware — verify PHY power domains, clocks, and reset lines are correctly configured in the device tree and that hardware is functional; (2) Add missing firmware-name property to the Aquantia PHY node in qcs8300-ride device tree if firmware loading is required for this platform configuration.
4. Detail analysis attachment: failed_case_job225059_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is not attached to any IOMMU group because PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 adds a new video codec node with the iommus property only on child nodes (non-pixel and pixel), leaving the parent device without IOMMU protection. The SMMU test expects critical masters like video codec to be attached to IOMMU groups at the device level.
3. Possible fix: Add an iommus property to the top-level iris: video-codec@aa00000 node in arch/arm64/boot/dts/qcom/glymur.dtsi, or update the SMMU test to check child nodes for IOMMU attachment when the parent uses a hierarchical IOMMU binding model.
4. Detail analysis attachment: failed_case_job225059_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: PCIe PHY initialization timeout (-ETIMEDOUT) caused by PR-introduced device tree error: duplicate vdda-qref-supply property (both vreg_l4a and vreg_l7a defined) and undefined regulator reference &refgen in qcs8300-ride.dts, preventing the qcom-qmp-pcie-phy driver from acquiring required regulators after the PR changed the PHY configuration to expect 4 regulators (vdda-phy, vdda-pll, vdda-qref, vdda-refgen) instead of 2.
3. Possible fix: Remove the duplicate vdda-qref-supply property and either define the refgen regulator node in qcs8300-ride.dts or replace vdda-refgen-supply = <&refgen>; with the correct regulator phandle (likely split into vdda-refgen0p9-supply and vdda-refgen1p2-supply following the pattern used in other platforms like sa8775p).
4. Detail analysis attachment: failed_case_job225059_3_detailed.md

  Case 4: USBHost — Test Infrastructure Issue (Not a Kernel Bug)

1. Failed case: USBHost — Test Infrastructure Issue (Not a Kernel Bug)
2. Root cause: USBHost test expects external USB devices to be connected to the qcs8300-ride board, but only the USB root hub is present. The USB host controller (xHCI at 0x0a400000) initialized correctly and detected 1 port, but no external devices are plugged in.
3. Possible fix: This is not a kernel bug and does not require a code fix. The test failure is due to missing test infrastructure (no USB device connected). To resolve: (1) Connect a USB device (keyboard, mouse, flash drive, or hub) to the board's USB host port before running the test, OR (2) Update the USBHost test script to gracefully handle the case where no external devices are present and mark it as SKIP instead of FAIL when only the root hub is detected.
4. Detail analysis attachment: failed_case_job225059_4_detailed.md

  Case 5: Ethernet_Basic_Validation — PHY Attach Failure

1. Failed case: Ethernet_Basic_Validation — PHY Attach Failure
2. Root cause: The qcom-ethqos Ethernet MAC driver fails to attach to the PHY during interface bring-up on qcs8300-ride. The phylink validation of 2500base-x mode fails with -EINVAL because the PHY's advertised capabilities (0x000062c0) don't match the MAC's supported capabilities (0x000062cc). This is likely caused by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085's changes to the dp83867 PHY driver which added regulator power-on logic in the probe path — if the PHY regulators are not properly defined in the qcs8300-ride device tree or fail to enable, the PHY may not initialize correctly, leading to incomplete capability advertisement and subsequent phylink validation failure.
3. Possible fix: Verify that the qcs8300-ride device tree includes all required regulator supplies for the dp83867 PHY (vdda-2p5, vdd-1p0, vdda-1p8, vddio) as introduced in PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. If regulators are missing or misconfigured, add them to the ethernet PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts. If regulators are correctly defined, check dmesg for regulator enable failures during PHY probe and address the root cause (missing PMIC configuration, wrong regulator names, or supply not available). As a temporary workaround to isolate the issue, revert the dp83867 regulator changes from PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 and confirm whether Ethernet works without them.
4. Detail analysis attachment: failed_case_job225059_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: CONFIG_KVM is enabled in kernel config but the KVM driver did not initialize during boot, resulting in /dev/kvm device node not being created. No KVM initialization messages appear in dmesg, indicating the KVM ARM driver failed to probe or was not compiled into the kernel despite CONFIG_KVM=y. This is a pre-existing platform/kernel configuration issue unrelated to the PR (which contains only device tree interconnect changes and documentation updates).
3. Possible fix: Verify that CONFIG_KVM_ARM_HOST=y (or CONFIG_KVM=m with kvm.ko and kvm-arm.ko modules present and loaded). Check that the platform's device tree and bootloader support EL2/hypervisor mode and that the CPU supports ARM virtualization extensions. If KVM is built as a module, ensure the modules are included in the rootfs and loaded during boot. If the qcs8300-ride platform does not support KVM/virtualization in hardware or firmware, mark the KVM tests as expected-fail or skip for this platform.
4. Detail analysis attachment: failed_case_job225059_6_detailed.md

  Case 7: KVM Driver Initialization Failure — /dev/kvm unavailable due to heterogeneous CPU features

1. Failed case: KVM Driver Initialization Failure — /dev/kvm unavailable due to heterogeneous CPU features
2. Root cause: KVM initialization silently aborted on QCS8300 (Monaco) due to CPU feature heterogeneity between Cortex-A78 (0x410fd4b2) and Cortex-X1C (0x412fd050) cores. ARM64 KVM requires all CPUs to have identical instruction set and memory model features (SYS_ID_AA64ISAR0_EL1, SYS_ID_AA64ISAR1_EL1, SYS_ID_AA64MMFR2_EL1) to safely migrate VMs between cores; the kernel detected "Unsupported CPU feature variation" during boot and skipped KVM initialization, preventing /dev/kvm creation.
3. Possible fix: This is a platform hardware limitation, not a software bug. KVM cannot be enabled on QCS8300 without either: (1) disabling big cores to create a homogeneous CPU configuration (boot with maxcpus=4 to use only Cortex-A78 cores), or (2) waiting for upstream ARM64 KVM asymmetric CPU support (experimental patches exist but are not production-ready). For CI: mark KVM tests as SKIP (not FAIL) on heterogeneous platforms like QCS8300; update test runner to detect CPU heterogeneity via /sys/devices/system/cpu/cpu*/regs/identification/midr_el1 and skip KVM tests when CPUs differ.
4. Detail analysis attachment: failed_case_job225059_7_detailed.md

  Case 8: KVM_Infra — KVM driver initialization failure

1. Failed case: KVM_Infra — KVM driver initialization failure
2. Root cause: KVM driver failed to initialize and create /dev/kvm device node on qcs8300-ride platform running under Gunyah hypervisor in protected virtualization mode; CONFIG_KVM is enabled but the KVM ARM driver did not probe successfully, likely due to incompatibility between KVM and the Gunyah protected virtualization environment where the kernel is running as a guest VM.
3. Possible fix: This is a platform/hypervisor configuration issue, not a PR-introduced regression. The qcs8300-ride target runs under Gunyah hypervisor in protected mode, which prevents nested virtualization (KVM requires EL2 access that is not available to guest VMs). Either: (1) disable KVM tests for qcs8300-ride in the LAVA test suite since this platform does not support KVM, or (2) if KVM support is intended, reconfigure the platform to boot the kernel at EL2 (native/host mode) instead of as a Gunyah guest VM.
4. Detail analysis attachment: failed_case_job225059_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm not created despite CONFIG_KVM=y because QCS8300-ride platform runs under a hypervisor (hypvm.mbn/sailhyp.elf) at EL2, preventing KVM from initializing - KVM requires exclusive EL2 access which is unavailable in this configuration.
3. Possible fix: This is expected behavior on QCS8300-ride when running under a hypervisor. Mark KVM tests as SKIP for this platform configuration, or use a non-hypervisor boot configuration if KVM testing is required. Add platform detection to test suite to automatically skip KVM tests on hypervisor-enabled QCS8300 builds.
4. Detail analysis attachment: failed_case_job225059_9_detailed.md

Job 225060 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Pre-existing Platform Limitation (ath11k WiFi hardware timeout)

1. Failed case: Probe_Failure_Check — Pre-existing Platform Limitation (ath11k WiFi hardware timeout)
2. Root cause: ath11k_pci probe failed with -ETIMEDOUT (-110) during MHI power-up on lemans-evk; WiFi PCIe hardware did not respond, indicating missing/unpowered hardware, missing firmware, or incomplete platform bringup. regulatory.db firmware load failure is benign (fallback to built-in certs succeeded). Bluetooth firmware load failures are false positives (BT_ON_OFF test passed). PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 contains only documentation/DT binding updates and does not modify WiFi, Bluetooth, or PCIe drivers.
3. Possible fix: This is a pre-existing platform issue, not a PR regression. No action required for PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. To resolve the underlying issue: (1) verify WiFi PCIe card is installed and powered on lemans-evk, (2) ensure ath11k firmware files are present in /lib/firmware/ath11k/, (3) verify lemans-evk device tree has correct PCIe/WiFi node configuration (clocks, regulators, GPIOs, resets), or (4) suppress Probe_Failure_Check for lemans-evk if WiFi is not supported in the CI lab configuration.
4. Detail analysis attachment: failed_case_job225060_1_detailed.md

  Case 2: smmu (device tree configuration issue — not a CoT-classified failure)

1. Failed case: smmu (device tree configuration issue — not a CoT-classified failure)
2. Root cause: Video codec device at aa00000.video-codec on SA8775P/lemans-evk is missing iommus property in device tree, preventing IOMMU group attachment required for DMA protection.
3. Possible fix: Add iommus property to the video codec device node in arch/arm64/boot/dts/qcom/lemans.dtsi referencing the appropriate SMMU and stream ID, following the pattern used by other critical masters (GPU, Display, USB) on this platform.
4. Detail analysis attachment: failed_case_job225060_2_detailed.md

  Case 3: WiFi Driver Probe Failure — ath11k_pci MHI timeout

1. Failed case: WiFi Driver Probe Failure — ath11k_pci MHI timeout
2. Root cause: The ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the MHI (Modem Host Interface) subsystem could not load the WiFi firmware image over BHI (Boot Host Interface) within the expected timeout period. The wcn6855 hw2.1 WiFi card on PCIe bus 0000:01:00.0 did not respond to the firmware boot handshake, causing the entire driver initialization chain to fail. This is a hardware/firmware communication timeout, not a kernel driver bug.
3. Possible fix: This is a pre-existing intermittent hardware/firmware issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (which only touches documentation, device trees for camera/display, and ath11k AHB driver, not the PCI path). Recommended actions: (1) Re-trigger the LAVA job to confirm if the failure is intermittent; (2) If persistent on lemans-evk, check WiFi card power sequencing, PCIe link stability, and firmware version compatibility with wcn6855 hw2.1 on SA8775P platform; (3) Increase MHI BHI timeout if the card requires longer boot time on this SoC.
4. Detail analysis attachment: failed_case_job225060_3_detailed.md

  Case 4: WiFi_OnOff — ath11k_pci probe failure (driver initialization)

1. Failed case: WiFi_OnOff — ath11k_pci probe failure (driver initialization)
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT during MHI (Modem Host Interface) firmware boot handshake on WCN6855 hw2.1 WiFi chip. Root cause is an SMMU (IOMMU) context fault (fsr=0x402, iova=0xffa00000) occurring immediately after MHI power-on at timestamp 7.013s, preventing the WiFi firmware from loading over BHI (Boot Host Interface), leading to a 21-second timeout and probe failure at 28.528s.
3. Possible fix: Investigate and fix the SMMU context fault for the ath11k_pci device (0000:01:00.0, IOMMU group 23). Verify that: (1) the device tree IOMMU mapping for the PCIe WiFi device is correct, (2) the SMMU context bank configuration matches the device's DMA requirements, (3) the WiFi firmware's DMA address range (iova=0xffa00000) is within the allowed IOMMU aperture. Check if the PR introduces any IOMMU/SMMU configuration changes for SA8775P (lemans-evk) or PCIe devices. If the SMMU fault is a pre-existing platform issue, add a workaround to disable SMMU for this device or expand the IOMMU aperture.
4. Detail analysis attachment: failed_case_job225060_4_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test suite marked as failed due to multiple pre-existing platform issues on lemans-evk: (1) ath11k_pci WiFi driver probe timeout (-110) during MHI power-up, indicating hardware/firmware communication failure; (2) video codec device aa00000.video-codec missing IOMMU group attachment; (3) Probe_Failure_Check detecting these probe failures. PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes only ath11k_ahb (not ath11k_pci) and documentation/bindings, so these failures are NOT PR-introduced regressions.
3. Possible fix: These are known lemans-evk platform issues. No PR changes required. For WiFi: investigate MHI/PCIe link stability and firmware availability on lemans-evk hardware. For video codec SMMU: verify device tree IOMMU bindings for aa00000.video-codec on lemans-evk. Re-run CI on a different board (e.g., rb3gen2, kodiak) to confirm PR does not introduce regressions on stable platforms.
4. Detail analysis attachment: failed_case_job225060_5_detailed.md

Job 225061 | SoC purwa-evk

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

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

  Case 1: Kernel Crash — BUG: sleeping function called from invalid context (qcom_scm atomic context violation)

1. Failed case: Kernel Crash — BUG: sleeping function called from invalid context (qcom_scm atomic context violation)
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes DO_ONCE to DO_ONCE_SLEEPABLE in qcom_tzmem_enable() (drivers/firmware/qcom/qcom_tzmem.c:519), but DO_ONCE_SLEEPABLE internally calls __do_once_sleepable_start() which disables preemption and IRQs. When qcom_tzmem_do_init() subsequently calls qcom_scm_shm_bridge_enable() → qcom_scm_call(), the latter attempts to sleep (via might_sleep() at qcom_scm.c:334) while in atomic context (preempt_count=1, irqs_disabled=1), triggering the BUG. The system then hangs during boot at ~3.8s, never reaching userspace or presenting a login prompt, causing LAVA login-action timeout.
3. Possible fix: Revert the change from DO_ONCE_SLEEPABLE back to DO_ONCE in drivers/firmware/qcom/qcom_tzmem.c line 519, or refactor qcom_tzmem_enable() to avoid calling sleeping functions from the DO_ONCE context. The original DO_ONCE macro is correct here because the initialization path (qcom_tzmem_do_init → qcom_scm_shm_bridge_enable) requires sleeping context, and DO_ONCE does not disable preemption/IRQs.
4. Detail analysis attachment: failed_case_job225061_1_detailed.md

  Case 2: Kernel Crash — BUG: sleeping function called from invalid context

1. Failed case: Kernel Crash — BUG: sleeping function called from invalid context
2. Root cause: PR incorrectly changed DO_ONCE to DO_ONCE_SLEEPABLE in drivers/firmware/qcom/qcom_tzmem.c:519, causing qcom_tzmem_do_init to attempt sleeping SCM calls while in atomic context (preemption disabled by __do_once_start). The purwa-evk SoC requires SCM bridge initialization during qcom_scm probe, which now triggers this atomic-sleep violation.
3. Possible fix: Revert the change from DO_ONCE_SLEEPABLE back to DO_ONCE in drivers/firmware/qcom/qcom_tzmem.c:519, and ensure qcom_tzmem_do_init uses non-sleeping SCM call variants, or refactor the initialization to occur in a sleepable context outside the DO_ONCE macro.
4. Detail analysis attachment: failed_case_job225061_2_detailed.md

  Case 3: Kernel Crash — System hang after BUG in qcom_scm probe

1. Failed case: Kernel Crash — System hang after BUG in qcom_scm probe
2. Root cause: The kernel encountered "BUG: sleeping function called from invalid context at drivers/firmware/qcom/qcom_scm.c:334" during qcom_scm_probe(). The qcom_scm driver attempted to call a potentially sleeping function (qcom_scm_call) while in atomic context (preempt_count: 1, irqs_disabled: 1) during the qcom_tzmem_enable() → qcom_scm_shm_bridge_enable() path. After printing the BUG message and call trace, the system hung and made no further progress. The watchdog eventually triggered a warm reset into ramdump mode approximately 7 seconds later. The system never reached userspace init, and LAVA's login-action timed out waiting for a prompt that never appeared.
3. Possible fix: This is a pre-existing kernel bug in the qcom_scm driver, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (the PR contains only documentation, device tree bindings, and unrelated driver changes). The immediate fix is to identify why qcom_scm_call() is being invoked in atomic context during probe and either: (1) defer the shm_bridge_enable call to a non-atomic context, or (2) ensure the calling path does not disable preemption/IRQs. Check the __do_once_start() mechanism at the call site — it appears to be holding a lock or disabling preemption. For CI purposes, this failure should be marked as a known issue unrelated to the PR under test, and the PR should not be blocked by this pre-existing bug.
4. Detail analysis attachment: failed_case_job225061_3_detailed.md

  Case 4: Kernel Boot Hang — BUG: sleeping function called from invalid context

1. Failed case: Kernel Boot Hang — BUG: sleeping function called from invalid context
2. Root cause: qcom_scm_call() invoked from atomic context (preemption disabled, IRQs disabled) during qcom_scm_probe → qcom_tzmem_enable → qcom_scm_shm_bridge_enable path; qcom_scm_call uses mutexes which can sleep, violating atomic context constraints. System continues boot after BUG but hangs before reaching login prompt, likely due to subsequent driver initialization failures or resource starvation caused by the atomic context violation.
3. Possible fix: This is a pre-existing kernel bug, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR contains no changes to drivers/firmware/qcom/qcom_scm.c probe path or qcom_tzmem code that would cause this issue. The fix requires upstream kernel patch to refactor qcom_scm_shm_bridge_enable to avoid sleeping calls in atomic context, or to defer the shm_bridge_enable call to a context where sleeping is allowed. For immediate CI unblocking, consider: (1) bisecting upstream kernel to identify the commit that introduced the __do_once_start atomic section around this call path, (2) applying a local workaround to defer qcom_tzmem_enable to a workqueue context, or (3) disabling CONFIG_QCOM_TZMEM if not required for purwa-evk platform.
4. Detail analysis attachment: failed_case_job225061_4_detailed.md

Job 225062 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC Test Infrastructure Failure

1. Failed case: GIC Test Infrastructure Failure
2. Root cause: Test script assumes all 8 CPUs (0-7) are online, but CPUs 6-7 failed to boot during kernel initialization with PSCI error -22 (EINVAL). The test script has a bash parsing bug at line 75 ([: GICv3: integer expected) when attempting to parse /proc/interrupts for CPUs that don't exist in the interrupt counter output, causing false failures for CPUs 6-7.
3. Possible fix: Update the GIC test script to dynamically detect online CPUs from /sys/devices/system/cpu/online before testing, and only validate timer interrupts for CPUs that are actually online. The script should skip offline CPUs rather than reporting them as failures.
4. Detail analysis attachment: failed_case_job225062_1_detailed.md

  Case 2: Probe_Failure_Check — False Positive Test Failure

1. Failed case: Probe_Failure_Check — False Positive Test Failure
2. Root cause: The Probe_Failure_Check test flags four benign firmware load failures as errors: (1) regulatory.db for cfg80211 (WiFi works, WiFi_OnOff test passed), (2) renesas_usb_fw.mem for optional PCIe xHCI controller (not critical for qcs6490-rb3gen2 platform functionality), (3) modem.mbn for remoteproc0 (modem is intentionally offline as a non-autoboot processor, remoteproc test passed). All failures are -ENOENT (error -2) for optional/non-critical firmware files that do not impact platform functionality.
3. Possible fix: Update the Probe_Failure_Check test to suppress known benign firmware load failures: (1) regulatory.db when WiFi functional tests pass, (2) renesas_usb_fw.mem for optional PCIe devices, (3) modem.mbn when modem remoteproc is configured as non-autoboot and remoteproc test passes. Alternatively, provide these optional firmware files in the test image to eliminate the warnings.
4. Detail analysis attachment: failed_case_job225062_2_detailed.md

  Case 3: Freq_Scaling

1. Failed case: Freq_Scaling
2. Root cause: Test expects 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 platform only successfully booted 6 CPUs (cpu0-cpu5); CPU6 and CPU7 failed to boot via PSCI with error -22 (EINVAL), causing the Freq_Scaling test to fail when checking for cpufreq interface on cpu7.
3. Possible fix: Update the Freq_Scaling test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding an expected CPU count, or adjust the test expectations for qcs6490-rb3gen2 to account for the 6-CPU configuration (CPU6/CPU7 boot failure is a known platform limitation, not a regression).
4. Detail analysis attachment: failed_case_job225062_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Connect a USB device (e.g., USB flash drive, USB keyboard, or USB hub) to the board's USB host port before running the USBHost test. Alternatively, mark this test as SKIP when no USB host hardware is available in the test environment, or update the test to check for USB controller presence rather than requiring a connected device.
4. Detail analysis attachment: failed_case_job225062_4_detailed.md

  Case 5: KVM_Driver — KVM initialization failure (HYP mode not available)

1. Failed case: KVM_Driver — KVM initialization failure (HYP mode not available)
2. Root cause: The qcs6490-rb3gen2 board is running under the Gunyah hypervisor in the Primary VM (PVM), which prevents nested virtualization. KVM requires direct access to EL2 (HYP mode), but when Linux runs as a guest under Gunyah, it executes at EL1 and cannot access EL2. The kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected it cannot initialize because the CPU is not in HYP mode.
3. Possible fix: This is not a PR-introduced regression — it is a platform configuration issue. The KVM_Driver test should be skipped on boards running under Gunyah hypervisor (PVM configuration). Add a test precondition check to skip KVM tests when /sys/hypervisor/type indicates Gunyah or when the boot log contains "Gunyah based bootup". Alternatively, to enable KVM functionality, the board must be configured to boot Linux directly at EL2 without the Gunyah hypervisor layer.
4. Detail analysis attachment: failed_case_job225062_5_detailed.md

  Case 6: KVM/Virtualization Failure — HYP mode not available (Gunyah hypervisor conflict)

1. Failed case: KVM/Virtualization Failure — HYP mode not available (Gunyah hypervisor conflict)
2. Root cause: KVM driver initialization failed because ARM EL2 (hypervisor exception level) is already claimed by the Gunyah hypervisor running on qcs6490-rb3gen2. KVM requires exclusive EL2 access but detected "HYP mode not available" at boot (log line showing "[ 3.037639][ T1] kvm [1]: HYP mode not available"). This is a platform firmware configuration issue where Gunyah and KVM are mutually exclusive - only one hypervisor can control EL2.
3. Possible fix: Skip KVM tests on Gunyah-enabled platforms by updating the LAVA test job definition to detect Gunyah presence (check for "Hypervisor cold boot" in early boot logs or "kvm.*HYP mode not available" in dmesg) and mark KVM tests as SKIP rather than FAIL. Alternatively, if KVM functionality is required, disable Gunyah in the bootloader/firmware configuration to allow Linux to boot at EL2 and enable KVM initialization.
4. Detail analysis attachment: failed_case_job225062_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the board runs under Gunyah hypervisor at EL1; KVM requires EL2 (HYP mode) which is not available when a hypervisor is already running. The kernel message "kvm [1]: HYP mode not available" confirms this architectural limitation.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM test suite should be skipped on platforms running under a hypervisor (Gunyah). Add a pre-test check in the LAVA job definition to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor) and skip all KVM tests when a hypervisor is detected, or mark them as expected failures for this platform configuration.
4. Detail analysis attachment: failed_case_job225062_7_detailed.md

  Case 8: KVM_Infra (test infrastructure issue — platform limitation)

1. Failed case: KVM_Infra (test infrastructure issue — platform limitation)
2. Root cause: KVM driver initialization failed with "HYP mode not available" because the qcs6490-rb3gen2 platform does not support EL2 hypervisor mode, which is a hardware prerequisite for KVM functionality. CONFIG_KVM is enabled in the kernel config, but the platform lacks the necessary hardware virtualization extensions.
3. Possible fix: Exclude KVM tests from the CI test suite for qcs6490-rb3gen2 (and other platforms without HYP/virtualization support), or mark them as expected-to-skip when /dev/kvm is not present. This is not a kernel regression — it's a pre-existing platform limitation.
4. Detail analysis attachment: failed_case_job225062_8_detailed.md

Job 225063 | SoC glymur-crd

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test flagged a benign cfg80211 regulatory database firmware load failure (regulatory.db failed with error -2) that occurs during normal boot when the regulatory.db file is not present in the filesystem. This is not a kernel regression — cfg80211 successfully loaded compiled-in X.509 certificates and fell back to built-in regulatory rules, and all WiFi/BT functionality is working correctly (as evidenced by passing WiFi and Bluetooth tests later in the job).
3. Possible fix: Update the Probe_Failure_Check test to suppress cfg80211 regulatory.db firmware load failures (error -2) when cfg80211 successfully loads X.509 certificates and falls back to built-in regulatory data. This is a known benign pattern in upstream cfg80211 when regulatory.db is not packaged in the rootfs.
4. Detail analysis attachment: failed_case_job225063_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The SMMU test detected that the critical master device "Video aa00000.video-codec" (iris video codec) is missing IOMMU group attachment on glymur-crd, despite the device node being added to the device tree in this PR with proper iommus properties in its sub-nodes.
3. Possible fix: Enable the iris video codec device in the glymur-crd board-specific device tree file by adding &iris { status = "okay"; }; to arch/arm64/boot/dts/qcom/glymur-crd.dtsi, or update the SMMU test's critical master list to exclude the iris device if it's intentionally disabled on this board variant.
4. Detail analysis attachment: failed_case_job225063_2_detailed.md

  Case 3: ** USBHost (Test Infrastructure Issue — Not a Kernel Failure)

1. Failed case: ** USBHost (Test Infrastructure Issue — Not a Kernel Failure)
2. Root cause: ** The USBHost test expects external USB devices (keyboard, mouse, storage) to be physically connected to the board's USB ports, but none are present in the LAVA lab setup. The kernel USB host stack initialized successfully (xHCI controller registered, root hubs detected), but the test fails because it requires at least one non-hub USB device to be enumerated.
3. Possible fix: This is NOT a kernel bug or PR-introduced regression. The PR contains only documentation and device tree binding updates with no functional USB driver changes. To resolve: (1) Connect a USB device (keyboard, mouse, or storage) to the glymur-crd board's USB port in the LAVA lab, OR (2) Update the USBHost test to skip/pass when no external devices are available (test infrastructure fix), OR (3) Mark this test as expected-fail for lab configurations without USB peripherals attached.
4. Detail analysis attachment: failed_case_job225063_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test suite marked as failed because 3 individual test cases failed: (1) Probe_Failure_Check detected regulatory.db firmware load error -2 (benign, pre-existing), (2) smmu test detected Video codec aa00000.video-codec missing iommu_group attachment (pre-existing driver/DT issue), (3) USBHost test found no USB devices connected (test environment issue - only USB hubs present, no devices plugged in). The kernel booted successfully and all tests executed; this is NOT a build load failure or kernel crash.
3. Possible fix: Re-trigger the CI job. The 3 failures are pre-existing issues unrelated to this PR (which only adds documentation for AEST debugfs and STP policy configfs). If failures persist: (1) regulatory.db firmware error is benign and can be suppressed, (2) investigate Video codec IOMMU binding in glymur-crd DT, (3) connect a USB device to the test board for USBHost validation.
4. Detail analysis attachment: failed_case_job225063_4_detailed.md

Job 225064 | SoC monaco-evk

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

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

  Case 1: Driver Probe Failure — ath11k_pci WiFi driver

1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk (iq-8275-evk) because the MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to time out during WiFi device initialization.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/), or if the firmware path is incorrect for this board variant (nfa765 vs standard WCN6855), update the board-specific firmware path configuration in the ath11k driver or device tree to match the available firmware files in the rootfs.
4. Detail analysis attachment: failed_case_job225064_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) exists in the monaco-evk device tree but lacks IOMMU group attachment because the device tree node is missing the iommus property, leaving this critical DMA master unprotected by the SMMU.
3. Possible fix: This is a pre-existing platform configuration issue on monaco-evk, not introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085. The PR adds video codec nodes to other SoCs (glymur, etc.) but does not modify monaco's video codec configuration. To fix: add the iommus property to the video codec node in arch/arm64/boot/dts/qcom/monaco.dtsi with the appropriate SMMU stream IDs for the platform, or if the video codec is intentionally disabled/not supported on monaco-evk, mark the node status = "disabled" or remove it from the enabled device tree.
4. Detail analysis attachment: failed_case_job225064_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure failure — no USB host devices physically connected to the monaco-evk board's USB host ports during test execution. The kernel USB subsystem is not initialized because no USB host controller driver (dwc3/xhci) probe messages appear in the boot log, indicating the USB host functionality is either not enabled in the device tree for this platform or the hardware lacks external USB host peripherals.
3. Possible fix: This is a known test infrastructure limitation for monaco-evk. The USBHost test expects external USB devices (keyboard, mouse, storage) to be physically connected to USB host ports. Either: (1) connect USB host peripherals to the board before running the test suite, (2) mark this test as "skip" or "not applicable" for monaco-evk in the LAVA job definition if the board does not expose USB host ports in the lab setup, or (3) verify the monaco-evk device tree enables USB host controller nodes (usb@a400000, usb@a600000) with dr_mode = "host" or "otg" and required PHY/clock/regulator dependencies.
4. Detail analysis attachment: failed_case_job225064_3_detailed.md

  Case 4: WiFi Driver Probe Failure — ath11k_pci firmware dependency

1. Failed case: WiFi Driver Probe Failure — ath11k_pci firmware dependency
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (error -110) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (-ENOENT, error -2), causing MHI power-up to time out during driver initialization.
3. Possible fix: Add the missing ath11k WCN6855 firmware files to the rootfs image under /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin and any required companion files (m3.bin, regdb.bin) — then rebuild and reflash the image.
4. Detail analysis attachment: failed_case_job225064_4_detailed.md

  Case 5: ** WiFi_OnOff — WiFi Driver Probe Failure (ath11k_pci)

1. Failed case: ** WiFi_OnOff — WiFi Driver Probe Failure (ath11k_pci)
2. Root cause: ** ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to timeout during driver initialization on monaco-evk.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). Verify the firmware package (linux-firmware or board-specific firmware package) includes WCN6855 hw2.1 nfa765 variant firmware, or add it explicitly to the build recipe.
4. Detail analysis attachment: failed_case_job225064_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests (LAVA Test Infrastructure Issue)

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Test Infrastructure Issue)
2. Root cause: LAVA test runner marked the test suite as "unfinished" after detecting unprocessed result files (Ethernet_Basic_Validation.res, WiFi_OnOff.res) in the working directory, even though these tests had already been executed and reported. This is a LAVA test harness cleanup/parsing issue, not a kernel regression. The underlying genuine failures (WiFi ath11k_pci probe timeout -110, USBHost no devices) are pre-existing monaco-evk platform issues unrelated to this documentation-only PR.
3. Possible fix: This is not a PR-blocking issue. The PR modifies only documentation and DT bindings and cannot cause WiFi driver probe failures or LAVA test harness issues. Recommended actions: (1) Re-trigger the CI job to confirm the LAVA test harness issue is transient; (2) If WiFi/USB failures persist across runs, file separate platform-specific bugs for monaco-evk ath11k_pci probe timeout and USB enumeration, as these are board/firmware issues independent of this PR's changes.
4. Detail analysis attachment: failed_case_job225064_6_detailed.md

Job 225065 | SoC sm8750-mtp

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

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

  Case 1: PCIe

1. Failed case: PCIe
2. Root cause: PCIe test script failure due to missing test-specific device tree node or sysfs entry — PCIe hardware is functional (link up, devices enumerated), but test validation logic expects a specific DT node or sysfs capability file that is not present on sm8750-mtp.
3. Possible fix: Update the PCIe test script to handle sm8750-mtp platform-specific PCIe configuration, or add the expected DT node/sysfs entry if it represents a genuine platform requirement. Verify test expectations against sm8750-mtp hardware capabilities.
4. Detail analysis attachment: failed_case_job225065_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (xhci-hcd) driver not initialized on sm8750-mtp; dwc3_qcom glue driver loaded but no xHCI host mode enabled, likely due to missing USB host hardware, incorrect device tree configuration for host mode, or USB controller configured in device/peripheral mode only.
3. Possible fix: Verify sm8750-mtp hardware supports USB host mode; if supported, check device tree usb@a600000 node for correct dr_mode property (should be "host" or "otg", not "peripheral"), ensure USB PHY and Type-C port-controller configurations enable host mode, and confirm xhci-hcd module is built into kernel or loaded; if hardware does not support USB host, mark test as SKIP for this platform.
4. Detail analysis attachment: failed_case_job225065_2_detailed.md

  Case 3: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Provision a valid Bluetooth BD address for the sm8750-mtp board via device tree local-bd-address property, bootloader environment variable, or userspace configuration file; verify address persistence across reboots and re-run BT_FW_KMD_Service test.
4. Detail analysis attachment: failed_case_job225065_3_detailed.md

  Case 4: BT_ON_OFF — Bluetooth Runtime Initialization Failure

1. Failed case: BT_ON_OFF — Bluetooth Runtime Initialization Failure
2. Root cause: Bluetooth adapter hci0 failed to obtain a valid BD (Bluetooth Device) address within the 40-second initialization timeout, causing the BT_ON_OFF functional test to fail after 2 recovery attempts; PR modifies Qualcomm Bluetooth drivers (btqca.c, hci_qca.c) which are directly responsible for BD address provisioning on sm8750-mtp.
3. Possible fix: Revert or debug the Bluetooth driver changes in drivers/bluetooth/btqca.c and drivers/bluetooth/hci_qca.c introduced by this PR; specifically investigate BD address read/provisioning logic for sm8750 platform; verify firmware loading sequence and NVM (non-volatile memory) access paths for BD address retrieval.
4. Detail analysis attachment: failed_case_job225065_4_detailed.md

  Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Bluetooth firmware download failure — WCN7850 controller repeatedly fails to respond to firmware download commands (command 0xfc00 tx timeout, error -110 ETIMEDOUT), preventing hci0 adapter initialization and leaving it without a valid BD address after multiple recovery attempts.
3. Possible fix: Investigate WCN7850 hardware/firmware communication path on SM8750-MTP: verify UART transport configuration (baud rate, flow control, pinctrl), check power sequencing and regulators for the Bluetooth subsystem, confirm firmware file qca/hmtbtfw20.tlv is present and valid, and review recent changes to QCA Bluetooth UART driver or device tree that may affect command/response timing or interrupt delivery.
4. Detail analysis attachment: failed_case_job225065_5_detailed.md

  Case 6: ** KVM_Driver (Test Infrastructure Limitation — Not a Kernel Bug)

1. Failed case: ** KVM_Driver (Test Infrastructure Limitation — Not a Kernel Bug)
2. Root cause: ** /dev/kvm device node is not present because the SM8750-MTP target is running under the Gunyah hypervisor (reserved memory region gunyah-hyp@80000000 detected at boot line 3036). KVM requires EL2 (Exception Level 2) access to create the /dev/kvm device, but EL2 is already occupied by Gunyah. Nested virtualization (running KVM inside a VM or under another hypervisor) is not supported on this platform. This is not a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085, which does not modify any KVM or virtualization code.
3. Possible fix: Update the KVM test suite (KVM_Driver/run.sh, KVM_EL2_DTB/run.sh, KVM_Infra/run.sh) to detect hypervisor presence before running tests. Add a check at the start of each test script:
4. Detail analysis attachment: failed_case_job225065_6_detailed.md

  Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM failed to initialize because the system is running under Gunyah hypervisor (nested virtualization not supported). CONFIG_KVM is enabled but /dev/kvm was never created because KVM silently skips initialization when it detects it's running as a guest under another hypervisor.
3. Possible fix: This is not a PR-introduced regression. KVM tests are expected to fail on sm8750-mtp when booted under Gunyah hypervisor. Either: (1) skip KVM tests on Gunyah-enabled platforms, or (2) boot without Gunyah to test native KVM functionality, or (3) add a test gate that checks for nested virtualization support before running KVM tests.
4. Detail analysis attachment: failed_case_job225065_7_detailed.md

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

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm not available
2. Root cause: KVM cannot initialize on SM8750 MTP because the platform is running under Gunyah hypervisor at EL2; KVM requires direct EL2 access to create /dev/kvm, but Gunyah occupies EL2 and prevents KVM from initializing, even though CONFIG_KVM is enabled in the kernel configuration.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (which contains no KVM-related changes). To enable KVM testing on SM8750 MTP, either: (1) disable Gunyah hypervisor in the firmware/boot configuration to allow KVM direct EL2 access, or (2) skip KVM tests on platforms configured with Gunyah, or (3) use a different test platform without a pre-installed hypervisor for KVM validation.
4. Detail analysis attachment: failed_case_job225065_8_detailed.md

  Case 9: ** DPU Display Driver Runtime Failure — PR-Introduced Encoder Interface Selection Regression

1. Failed case: ** DPU Display Driver Runtime Failure — PR-Introduced Encoder Interface Selection Regression
2. Root cause: ** PR 1085 modified dpu_encoder_get_intf() to add MST stream_id matching logic (&& cnt++ == stream_id). On sm8750-mtp, encoder 35's display_info has a non-zero stream_id (likely 1) for a non-MST display with only one matching interface. The counter-based check fails (cnt=0 when stream_id=1), returning NULL. Encoder 35 operates without a hardware interface, causing continuous frame done timeouts (-ETIMEDOUT) starting at boot.
3. Possible fix: Modify dpu_encoder_get_intf() logic to handle non-MST displays: change condition to (stream_id == 0 || cnt++ == stream_id) OR ensure disp_info->stream_id is initialized to 0 for non-MST displays in display init paths (msm_dsi_modeset_init(), msm_dp_modeset_init()). Verify sm8750 DT and driver code correctly initialize stream_id=0 for single-stream displays.
4. Detail analysis attachment: failed_case_job225065_9_detailed.md

Job 225066 | SoC shikra-iqs-evk

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

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

  Case 1: login-action

1. Failed case: login-action
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Enable CONFIG_KASAN=y in the kernel build to get precise alloc/free stacks for the freed OPP table object. Revert the OPP core error handling change in drivers/opp/core.c (lines 137583-137625 of pr.patch) and retest. If crash persists, audit all device tree OPP table additions in the PR for shikra-iqs-evk to ensure correct phandle references and table structure. Apply a targeted fix to correct the refcount/lifetime issue in _update_opp_table_clk or fix malformed device tree OPP table references.
4. Detail analysis attachment: failed_case_job225066_1_detailed.md

  Case 2: Kernel Crash — Use-after-free in OPP table initialization

1. Failed case: Kernel Crash — Use-after-free in OPP table initialization
2. Root cause: Use-after-free memory corruption in _of_add_table_indexed() during cpufreq driver probe. The function dereferenced a freed OPP table structure (poison value 0x6b6b6b6b6b6b6b6b indicates SLUB freed memory), causing a kernel Oops followed by panic. The crash occurred during deferred probe of the dt-cpufreq driver on shikra-iqs-evk when attempting to add OPP tables for CPU frequency scaling.
3. Possible fix: This is a kernel memory safety bug in the OPP subsystem. The PR introduces new OPP table definitions for the Iris GPU (iris_opp_table) in device tree, which may have exposed a latent use-after-free race in the OPP core during concurrent probe/table-add operations. Immediate mitigation: revert the OPP table additions from the PR and re-test. Proper fix: investigate the OPP core lifetime management in drivers/opp/of.c — likely missing refcount or premature free of OPP table during error path or concurrent access. Check if dev_pm_opp_of_cpumask_add_table() and _of_add_table_indexed() properly serialize access to shared OPP table structures.
4. Detail analysis attachment: failed_case_job225066_2_detailed.md

  Case 3: Kernel Crash — Use-After-Free in OPP subsystem

1. Failed case: Kernel Crash — Use-After-Free in OPP subsystem
2. Root cause: PR introduces a use-after-free bug in drivers/opp/core.c:_update_opp_table_clk(). The modified code calls dev_pm_opp_put_opp_table(opp_table) which frees the OPP table and poisons it with 0x6b6b6b6b6b6b6b6b, then returns ERR_PTR(ret) where ret contains the poisoned value. The caller dt_cpufreq_early_init() attempts to dereference this freed pointer, triggering a kernel panic at _of_add_table_indexed+0x44/0x1e8 with "Unable to handle kernel paging request at virtual address 006b6b6b6b6b6c2b".
3. Possible fix: Revert the incorrect change in drivers/opp/core.c:_update_opp_table_clk(). The original code correctly returned ERR_CAST(opp_table->clk) before freeing the table. The PR incorrectly moved dev_pm_opp_put_opp_table() before the return, creating a use-after-free. Restore the original order: call dev_err_probe(), then return ERR_CAST(opp_table->clk), then call dev_pm_opp_put_opp_table() only on the error path where the pointer is not returned to the caller.
4. Detail analysis attachment: failed_case_job225066_3_detailed.md

  Case 4: Kernel Crash — Use-after-free in OPP framework

1. Failed case: Kernel Crash — Use-after-free in OPP framework
2. Root cause: Kernel panic triggered by use-after-free bug in _of_add_table_indexed+0x44/0x1e8 during cpufreq driver probe on shikra-iqs-evk. The crash occurs when the dt_cpufreq driver attempts to add OPP tables for CPU frequency scaling; dereferencing freed memory (poison pattern 0x6b6b6b6b6b6b6b6b) causes a level 0 translation fault at virtual address 006b6b6b6b6b6c2b, leading to immediate kernel panic and preventing userspace from reaching login prompt.
3. Possible fix: Investigate and fix the OPP table lifecycle bug in the cpufreq-dt or OPP core code. The crash signature indicates a freed OPP table structure is being accessed during deferred probe of the cpufreq platform device. Check for missing reference counting, premature kfree, or race conditions in dev_pm_opp_of_cpumask_add_table and _of_add_table_indexed. As a short-term workaround, disable cpufreq-dt in the kernel config or remove the cpufreq device tree node for shikra-iqs-evk to allow boot to complete.
4. Detail analysis attachment: failed_case_job225066_4_detailed.md

Job 225067 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three driver probe failures detected: (1) regulatory.db firmware load failure (benign - optional file, cfg80211 uses built-in rules), (2) Aquantia AQR115C PHY probe failure due to missing firmware-name DT property (pre-existing board configuration issue), (3) ath11k_pci WiFi probe failure with MHI firmware load timeout -110 (pre-existing intermittent hardware/firmware issue on qcs9100-ride). None of these failures are introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: Suppress this test failure as all three probe failures are pre-existing issues unrelated to PR changes. For long-term fixes: (1) regulatory.db is benign and requires no action, (2) add firmware-name property to qcs9100-ride DT for Aquantia PHY if custom firmware is needed, (3) investigate MHI firmware load reliability on qcs9100-ride WiFi hardware (increase timeout or fix firmware/hardware initialization race).
4. Detail analysis attachment: failed_case_job225067_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add explicit synchronization after icc_set_bw() in arm_smmu_icc_enable() to ensure interconnect bandwidth is applied before SMMU register writes proceed, or move ICC path setup to an earlier initialization phase in arm_smmu_device_probe() before context bank allocation. Short-term: re-run LAVA job to confirm reproducibility; if deterministic, temporarily revert ICC voting changes and verify fault disappears.
4. Detail analysis attachment: failed_case_job225067_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no physical USB devices connected to the qcs9100-ride board's USB ports; only USB root hubs (Bus 001, 002, 003) are enumerated, indicating USB host controllers are functional but no external USB peripherals are attached to the test fixture.
3. Possible fix: Connect a functional USB device (e.g., USB flash drive, USB keyboard, or USB hub with downstream devices) to one of the board's USB ports before running the USBHost test; alternatively, update the test to skip or pass when only root hubs are present if external USB device connectivity is not a requirement for this SoC/board configuration.
4. Detail analysis attachment: failed_case_job225067_3_detailed.md

  Case 4: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Ethernet driver probe succeeded but runtime interface bring-up failed due to two distinct issues: (1) end0 (23040000.ethernet) cannot attach to PHY with -EINVAL error, indicating PHY configuration or device tree mismatch; (2) end1 (23000000.ethernet) experiences repeated MAC_VLAN_Tag_Filter register access timeouts, suggesting hardware clock/power gating or register access path failure on qcs9100-ride platform.
3. Possible fix: For end0: Verify PHY device tree node configuration (phy-handle, phy-mode, MDIO bus wiring) matches hardware expectations for 23040000.ethernet on qcs9100-ride; check if PHY driver is loaded and PHY device is enumerated on MDIO bus. For end1: Investigate clock/power domain configuration for 23000000.ethernet MAC registers; verify VLAN filter register access path is not gated; check if recent DT binding changes (qcom,shikra-ethqos addition in PR) introduced clock or power-domain dependency changes that are not met on qcs9100-ride.
4. Detail analysis attachment: failed_case_job225067_4_detailed.md

  Case 5: WiFi Driver Probe Failure — MHI BHI Firmware Load Timeout

1. Failed case: WiFi Driver Probe Failure — MHI BHI Firmware Load Timeout
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because MHI (Modem Host Interface) could not load the WiFi firmware image over BHI (Boot Host Interface) within the expected timeout period on qcs9100-ride (SA8775P) platform with QCA6698AQ hw2.1 WiFi chip; the failure is introduced by the tech/bus/pci/mhi topic branch merge in PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085.
3. Possible fix: Revert or debug the tech/bus/pci/mhi topic branch changes affecting BHI firmware loading; specifically investigate MHI BHI timeout handling, firmware download state machine, and power sequencing for PCIe WiFi devices on SA8775P platforms; if the timeout is too aggressive, increase the BHI image load timeout in drivers/bus/mhi/host/boot.c.
4. Detail analysis attachment: failed_case_job225067_5_detailed.md

  Case 6: ** WiFi_OnOff — Driver Probe Failure (MHI Firmware Load Timeout)

1. Failed case: ** WiFi_OnOff — Driver Probe Failure (MHI Firmware Load Timeout)
2. Root cause: ** ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the MHI bus could not load the WiFi firmware image over BHI within 20 seconds. The PR merges topic branch tech/bus/pci/mhi which introduced MHI subsystem changes that regressed the BHI firmware load handshake for qca6698aq WiFi chip on qcs9100-ride platform.
3. Possible fix: Revert or fix the MHI topic branch changes that affect BHI firmware loading timing/handshake. Specifically investigate MHI BHI timeout values, interrupt handling, and state machine transitions introduced in tech/bus/pci/mhi for compatibility with qca6698aq on SA8775P/qcs9100 platforms.
4. Detail analysis attachment: failed_case_job225067_6_detailed.md

  Case 7: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM cannot initialize on qcs9100-ride (LeMans) because the platform does not support EL2/HYP mode — the kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running with virtualization extensions enabled or the bootloader/firmware did not configure EL2 properly.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression. The qcs9100-ride target does not support KVM virtualization in its current firmware/bootloader configuration. To enable KVM: (1) verify the SoC supports ARMv8 virtualization extensions, (2) ensure the bootloader (ABL/XBL) boots the kernel at EL2 or enables EL2 access, (3) if the platform genuinely lacks virtualization support, mark the KVM tests as "skip" for this target in the LAVA test definition.
4. Detail analysis attachment: failed_case_job225067_7_detailed.md

  Case 8: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed at boot because the qcs9100-ride (LeMans) platform did not boot in EL2 (hypervisor mode); kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform boot-mode issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 (the PR contains no KVM or virtualization code changes). The board must be configured to boot in EL2 mode via bootloader/firmware settings, or the test should be marked as expected-fail/skip for platforms that do not support EL2 boot (qcs9100-ride currently boots in EL1).
4. Detail analysis attachment: failed_case_job225067_8_detailed.md

  Case 9: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a bug — it is the expected behavior when Gunyah hypervisor is running. To enable KVM on this platform, either: (1) boot without the Gunyah hypervisor (if supported by the platform firmware), or (2) use a nested virtualization configuration if Gunyah supports exposing virtual EL2 to Linux (requires Gunyah hypervisor support). For CI purposes, mark KVM tests as "expected skip" on qcs9100-ride when Gunyah is present, or exclude this platform from KVM test runs.
4. Detail analysis attachment: failed_case_job225067_9_detailed.md

  Case 10: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed at boot because HYP (EL2 hypervisor) mode is not available on qcs9100-ride platform — kernel logged "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. If KVM support is required on qcs9100-ride, verify: (1) the SoC supports virtualization extensions (EL2), (2) the bootloader/firmware enables EL2 mode, and (3) the device tree does not explicitly disable KVM. If the platform genuinely lacks EL2 support, mark KVM tests as expected-fail or skip them for this target in the LAVA job definition.
4. Detail analysis attachment: failed_case_job225067_10_detailed.md

Job 225068 | SoC kaanapali-mtp

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

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

  Case 1: PCIe

1. Failed case: PCIe
2. Root cause: PCIe test expects enumerated PCIe endpoint devices (checks for "Capabilities:" string from lspci output), but kaanapali-mtp board has no PCIe devices physically connected despite PCIe controller successfully probing and link training completing (Gen.3 x2 link up at 5.932s). Test also reports "DT node is not present" and "Driver is not loaded" warnings, indicating the test script's device detection logic does not recognize the successfully initialized PCIe root complex at 1c00000.pcie.
3. Possible fix: This is a test infrastructure issue, not a kernel regression. The PR introduces no PCIe-related code changes for kaanapali. Fix options: (1) Update the PCIe test script to distinguish between "PCIe controller not functional" vs "no endpoint devices connected" and mark the latter as SKIP rather than FAIL when the root complex is operational. (2) Connect a PCIe endpoint device (e.g., NVMe, WiFi card) to the kaanapali-mtp test fixture. (3) Mark this test as expected-fail or skip for kaanapali-mtp in the LAVA job definition until hardware is available.
4. Detail analysis attachment: failed_case_job225068_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no physical USB device connected to kaanapali-mtp USB host port during test execution; kernel USB subsystem initialized correctly (dwc3_qcom loaded, USB controller at a600000.usb probed successfully), but test expects at least one USB device to be enumerated.
3. Possible fix: Connect a USB device (e.g., USB flash drive, USB keyboard, or USB hub) to the kaanapali-mtp board's USB host port before running the USBHost test; alternatively, update the test to skip or pass when no USB devices are present if USB host functionality is not a validation requirement for this PR.
4. Detail analysis attachment: failed_case_job225068_2_detailed.md

  Case 3: BT_FW_KMD_Service

1. Failed case: BT_FW_KMD_Service
2. Root cause: Bluetooth HCI command 0xfc00 (QCA vendor-specific version read) times out repeatedly with -ETIMEDOUT (-110), preventing firmware download and Bluetooth stack initialization on kaanapali-mtp (WCN7850 controller).
3. Possible fix: Investigate whether PR#1085 Bluetooth changes (QCC2072 support additions in drivers/bluetooth/hci_qca.c) inadvertently affect WCN7850 initialization timing or command handling; verify WCN7850 firmware (qca/hmtbtfw20.tlv) is present and accessible; check for power sequencing or clock/regulator issues specific to kaanapali-mtp that may cause HCI transport layer timeouts.
4. Detail analysis attachment: failed_case_job225068_3_detailed.md

  Case 4: BT_ON_OFF

1. Failed case: BT_ON_OFF
2. Root cause: Bluetooth firmware initialization repeatedly fails with timeout (-ETIMEDOUT) when reading QCA version information from the QCA6390 Bluetooth controller on kaanapali-mtp; the hci0 adapter never acquires a valid BD address, preventing Bluetooth runtime from becoming operational.
3. Possible fix: Investigate QCA6390 Bluetooth controller power sequencing and UART communication path on kaanapali-mtp; verify that the pwrseq_qcom_wcn power sequencer is correctly enabling BT_EN and providing stable clocks before firmware download; check for conflicts with concurrent DPU (display) activity that may be starving the Bluetooth UART or causing system-wide timing issues; if the issue is PR-introduced, bisect the DRM/MSM display changes in this PR to identify any resource contention or power management regressions affecting the Bluetooth subsystem.
4. Detail analysis attachment: failed_case_job225068_4_detailed.md

  Case 5: Test Timeout — DPU Encoder Frame Done Timeout (Display Subsystem Regression)

1. Failed case: Test Timeout — DPU Encoder Frame Done Timeout (Display Subsystem Regression)
2. Root cause: PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 introduces changes to dpu_encoder_get_intf() that add stream_id matching logic (cnt++ == stream_id), causing the DPU encoder (enc35) to fail wait_for_idle operations with -ETIMEDOUT (-110) starting at 6.6 seconds into boot and persisting throughout the 40-minute test run, ultimately causing LAVA test-shell timeout on kaanapali-mtp.
3. Possible fix: Revert or fix the stream_id matching logic in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:dpu_encoder_get_intf() — the new condition && cnt++ == stream_id appears to prevent correct interface selection for kaanapali-mtp's display configuration, causing encoder initialization to fail and frame done callbacks to never complete.
4. Detail analysis attachment: failed_case_job225068_5_detailed.md

  Case 6: lava-test-shell timeout

1. Failed case: lava-test-shell timeout
2. Root cause: LAVA test timed out after 2400 seconds due to persistent DRM/MSM display subsystem errors on kaanapali-mtp — DSI link clock configuration failed with -EINVAL at boot, causing continuous DPU encoder frame done timeouts (enc35) and vblank wait timeouts that prevented test completion.
3. Possible fix: Investigate PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 DRM/MSM changes for kaanapali-mtp (SM8650) display initialization regression — specifically DSI pixel clock rate setting in dsi_link_clk_set_rate_6g() and DPU encoder frame completion signaling for encoder ID 35; revert or fix the clock configuration logic that returns -EINVAL during msm_dsi_host_power_on().
4. Detail analysis attachment: failed_case_job225068_6_detailed.md

  Case 7: lava-test-retry — Test timeout caused by continuous DPU encoder failures

1. Failed case: lava-test-retry — Test timeout caused by continuous DPU encoder failures
2. Root cause: PR introduces DPU encoder regression on kaanapali-mtp causing DSI link clock initialization failure (-EINVAL) at boot, leading to continuous DPU encoder frame timeout errors (30,242 occurrences) that prevent test completion within the 2400-second LAVA timeout.
3. Possible fix: Revert or fix the dpu_encoder_get_intf() changes in drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c that modify interface selection logic by adding stream_id matching — the new logic incorrectly selects the display interface for kaanapali-mtp's DSI panel, causing clock rate setting to fail with -EINVAL.
4. Detail analysis attachment: failed_case_job225068_7_detailed.md

  Case 8: LAVA Test Timeout — lava-test-shell exceeded 2400s limit

1. Failed case: LAVA Test Timeout — lava-test-shell exceeded 2400s limit
2. Root cause: The LAVA test suite timed out after 2400 seconds while running the BT_SCAN test following a failed BT_ON_OFF test. The timeout is a LAVA infrastructure limit, not a kernel crash. The system was making forward progress (kernel scheduler, interrupts, and test execution continued) but the test suite did not complete within the allocated time window. Contributing factor: continuous DPU encoder errors (dpu_encoder_phys_cmd_prepare_for_kickoff failed wait_for_idle: id:35 ret:-110) from early boot may have degraded system performance.
3. Possible fix: Re-trigger the LAVA job with an increased test timeout (from 2400s to 3600s or 4800s) in the LAVA job definition. If the timeout recurs, investigate why BT_SCAN hangs: check Bluetooth firmware loading, bluetoothd service status, and whether the DPU display errors are blocking system resources. The DPU encoder timeout errors should be investigated separately as they indicate a display subsystem issue unrelated to the test timeout.
4. Detail analysis attachment: failed_case_job225068_8_detailed.md

Job 225069 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two benign probe/firmware errors detected during boot on hamoa-evk: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16), likely due to resource conflict or the device being claimed by another driver/interface; (2) regulatory.db firmware file missing (-ENOENT, -2), a known non-critical issue when the regulatory database is compiled into the kernel or not required for the wireless configuration.
3. Possible fix: These are pre-existing platform-specific issues unrelated to PR Prepare qcom-next based on tag 'Linux 7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #1085 changes (which add documentation, device tree bindings, and a new mutually-exclusive TEE driver). The qseecom probe failure may indicate the platform uses QCOMTEE instead of QSEECOM for UEFI secure app access. The regulatory.db failure is benign if CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n or the database is built-in. To suppress these known benign failures in CI, update the Probe_Failure_Check test to exclude: (a) qcom_qseecom_uefisecapp probe failures on platforms without RPMB-in-SPI-NOR, and (b) regulatory.db firmware load failures when cfg80211 loads successfully.
4. Detail analysis attachment: failed_case_job225069_1_detailed.md

  Case 2: ** smmu (test validation failure — not a kernel crash)

1. Failed case: ** smmu (test validation failure — not a kernel crash)
2. Root cause: ** The SMMU test on hamoa-evk (x7181) expects the video codec device (aa00000.video-codec) to be attached to an IOMMU group for memory protection, but the device is not attached. The video codec driver (qcom-iris) probed successfully and the device is functional (firmware loaded, no runtime errors), but the IOMMU subsystem did not attach it to a group. This indicates the device tree for hamoa-evk does not specify an iommus property for the video codec node, or the test expectation is incorrect for this platform.
3. Possible fix: Verify the device tree source for hamoa-evk (arch/arm64/boot/dts/qcom/x7181-*.dts*) and confirm whether the video codec node (video-codec@aa00000) includes an iommus property pointing to the SMMU. If missing, add the property following the pattern used by other protected masters (UFS at group 3, GPU at group 14, Display at group 11, USB at groups 6-10) on this platform. If the video codec on hamoa-evk is intentionally not IOMMU-protected due to hardware or firmware limitations, update the test to exclude this device from the critical master check on this SoC.
4. Detail analysis attachment: failed_case_job225069_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because hypervisor (EL2) mode is not available on the hamoa-evk platform — kernel log shows "kvm [1]: HYP mode not available" at boot, causing /dev/kvm device node creation to be skipped.
3. Possible fix: This is a test expectation mismatch, not a kernel regression. The hamoa-evk platform does not support KVM/virtualization (no EL2 hypervisor mode available). Either: (1) exclude KVM tests from the hamoa-evk test suite, or (2) if KVM support is expected on this platform, investigate the bootloader/firmware configuration to ensure the CPU is booted at EL2 and hypervisor mode is enabled.
4. Detail analysis attachment: failed_case_job225069_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM Driver Initialization Failure

1. Failed case: KVM_EL2_DTB — KVM Driver Initialization Failure
2. Root cause: KVM driver reports "HYP mode not available" because the hamoa-iot-evk platform firmware/bootloader has not enabled EL2 (Hypervisor Exception Level) access, preventing KVM from initializing and creating /dev/kvm. This is a platform configuration limitation, not a kernel regression.
3. Possible fix: This is a known platform limitation for hamoa-iot-evk in non-EL2 boot mode. To enable KVM: (1) Use the hamoa-iot-evk-el2.dtb variant which configures EL2 boot, or (2) Update bootloader/firmware to enable EL2 access before kernel boot. For CI: mark KVM tests as expected-fail for hamoa-iot-evk base configuration, or configure LAVA job to use the -el2 DTB variant when testing KVM functionality.
4. Detail analysis attachment: failed_case_job225069_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed with "HYP mode not available" because hamoa-evk boots under Gunyah hypervisor at EL1, preventing access to EL2/HYP mode required for KVM operation.
3. Possible fix: This is expected behavior, not a bug. Either: (1) exclude KVM tests from hamoa-evk LAVA jobs when running under hypervisor, or (2) use a non-virtualized boot configuration (without Gunyah) if KVM testing is required on this platform.
4. Detail analysis attachment: failed_case_job225069_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests — Test Infrastructure Issue (KVM unavailable on platform)

1. Failed case: 0_qcom-next-ci-premerge-tests — Test Infrastructure Issue (KVM unavailable on platform)
2. Root cause: The hamoa-evk platform does not support ARM EL2/HYP mode, as evidenced by kernel message "[3.211969] kvm [1]: HYP mode not available" during boot. This causes all three KVM test cases (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail because /dev/kvm cannot be created without hypervisor support. This is a hardware/firmware platform limitation, not a kernel regression.
3. Possible fix: Exclude KVM tests from the hamoa-evk test suite, as this platform does not have EL2/HYP mode support required for KVM functionality. The PR patch contains no KVM-related changes and does not introduce this issue.
4. Detail analysis attachment: failed_case_job225069_6_detailed.md

[qcomlnxci]

Test jobs on 84c4976

• multimedia Job 227840 on glymur-crd
• multimedia Job 227839 on hamoa-iot-evk
• multimedia Job 227829 on kaanapali-mtp
• multimedia Job 227835 on lemans-evk
• multimedia Job 227836 on monaco-evk
• multimedia Job 227834 on purwa-iot-evk
• multimedia Job 227830 on qcs615-ride
• multimedia Job 227831 on qcs6490-rb3gen2
• multimedia Job 227828 on qcs8300-ride
• multimedia Job 227837 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227833 on shikra-iqs-evk
• multimedia Job 227832 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 84c4976

• multimedia Job 227840 on glymur-crd
• multimedia Job 227839 on hamoa-iot-evk
• multimedia Job 227829 on kaanapali-mtp
• multimedia Job 227835 on lemans-evk
• multimedia Job 227836 on monaco-evk
• multimedia Job 227834 on purwa-iot-evk
• multimedia Job 227892 on qcs615-ride
• multimedia Job 227831 on qcs6490-rb3gen2
• multimedia Job 227828 on qcs8300-ride
• multimedia Job 227837 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227833 on shikra-iqs-evk
• multimedia Job 227832 on sm8750-mtp

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 912d106

• multimedia Job 227919 on glymur-crd
• multimedia Job 227914 on hamoa-iot-evk
• multimedia Job 227915 on kaanapali-mtp
• multimedia Job 227912 on lemans-evk
• multimedia Job 227916 on monaco-evk
• multimedia Job 227911 on purwa-iot-evk
• multimedia Job 227913 on qcs615-ride
• multimedia Job 227910 on qcs6490-rb3gen2
• multimedia Job 227918 on qcs8300-ride
• multimedia Job 227920 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 227917 on shikra-iqs-evk
• multimedia Job 227909 on sm8750-mtp

[qcomlnxci]

Test Matrix

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