Fix qup core icc votes

[vdadhani]

The GENI_TO_CORE ("qup-core") interconnect vote selects the QUP Core 2X
clock rate. The Core 2X bandwidth constants currently contain values that
are several orders of magnitude too small. Also, at baud rates up to
115200, the serial console uses only a 1 kBps keepalive vote, which does
not request a Core clock and can leave console RX unresponsive after the
system enters a deep CPU idle state.

Correct the common Core 2X bandwidth constants and use the 19.2 MHz Core
2X vote for the low-baud console path. Higher baud rates continue to use
the 50 MHz vote.

Patch 1 corrects the common Core 2X bandwidth constants. Patch 2 updates
the serial console's low-baud vote to use the corrected 19.2 MHz value.

CRs-fixed: 4628868
qli-2.1 pull-request freeze

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4628868 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4628868
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

[psarma-qcom]

qli-2.1 pull-request freeze

[qcomlnxci]

Test jobs on f985020

• multimedia Job 223450 on hamoa-iot-evk
• multimedia Job 223454 on lemans-evk
• multimedia Job 223447 on monaco-evk
• multimedia Job 223448 on purwa-iot-evk
• multimedia Job 223455 on qcs615-ride
• multimedia Job 223452 on qcs6490-rb3gen2
• multimedia Job 223451 on qcs8300-ride
• multimedia Job 223453 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223449 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on f985020

• multimedia Job 223450 on hamoa-iot-evk
• multimedia Job 223454 on lemans-evk
• multimedia Job 223447 on monaco-evk
• multimedia Job 223448 on purwa-iot-evk
• multimedia Job 226868 on qcs615-ride
• multimedia Job 223452 on qcs6490-rb3gen2
• multimedia Job 223451 on qcs8300-ride
• multimedia Job 223453 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223449 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on f985020

• multimedia Job 223450 on hamoa-iot-evk
• multimedia Job 223454 on lemans-evk
• multimedia Job 223447 on monaco-evk
• multimedia Job 223448 on purwa-iot-evk
• multimedia Job 226951 on qcs615-ride
• multimedia Job 223452 on qcs6490-rb3gen2
• multimedia Job 223451 on qcs8300-ride
• multimedia Job 223453 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223449 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on f985020

• multimedia Job 223450 on hamoa-iot-evk
• multimedia Job 223454 on lemans-evk
• multimedia Job 223447 on monaco-evk
• multimedia Job 223448 on purwa-iot-evk
• multimedia Job 227414 on qcs615-ride
• multimedia Job 223452 on qcs6490-rb3gen2
• multimedia Job 223451 on qcs8300-ride
• multimedia Job 223453 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 223449 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1060

Job 223447 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: WiFi ath11k_pci driver probe failure due to missing firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) causing -ETIMEDOUT (-110) during MHI power-up; Bluetooth firmware load failures are benign (BT_ON_OFF test passed); regulatory.db failure is benign (cfg80211 fallback works).
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/); this is a pre-existing platform/image issue unrelated to the PR's GENI ICC vote changes.
4. Detail analysis attachment: failed_case_job223447_1_detailed.md

  Case 2: WiFi Driver Probe Failure — ath11k_pci probe timeout

1. Failed case: WiFi Driver Probe Failure — ath11k_pci probe timeout
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) during MHI (Modem Host Interface) power-up on Monaco EVK. The MHI state machine timed out waiting for the WCN6855 WiFi device to respond over PCIe. Continuous PCIe AER correctable errors (RxErr, Timeout) throughout boot indicate an underlying PCIe link stability or device initialization issue on this platform. This is a pre-existing platform/hardware issue, not introduced by the PR's GENI ICC bandwidth constant fixes.
3. Possible fix: Investigate Monaco EVK PCIe link stability and WCN6855 WiFi chip initialization: (1) Verify PCIe link training completes successfully and link is in L0 state before ath11k_pci probe; (2) Check if WCN6855 requires platform-specific power sequencing, GPIO configuration, or firmware that is missing on Monaco EVK; (3) Review PCIe root complex and endpoint configuration for Monaco platform; (4) If this is a known Monaco EVK limitation, document it and exclude WiFi tests from Monaco CI runs. The PR's GENI ICC fixes are correct and should not be reverted.
4. Detail analysis attachment: failed_case_job223447_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the root filesystem image under /lib/firmware/. Verify the firmware package (linux-firmware or board-specific firmware package) is included in the Yocto/build configuration for monaco-evk.
4. Detail analysis attachment: failed_case_job223447_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner marked the test run as "unfinished" because individual test failures (WiFi_OnOff, WiFi_Firmware_Driver, Probe_Failure_Check) were detected during execution. The WiFi probe failure (ath11k_pci probe failed with error -110, ETIMEDOUT) is correlated with the PR's changes to GENI ICC bandwidth constants, which increased QUP Core clock votes by 10,000x. On monaco-evk, this may have triggered power/clock sequencing issues affecting PCIe link stability during WiFi device enumeration, as evidenced by continuous PCIe AER correctable errors (RxErr, Timeout, Rollover) throughout the test run.
3. Possible fix: The WiFi probe timeout and PCIe errors suggest the increased ICC bandwidth votes may be exposing a platform-specific power or clock sequencing issue on monaco-evk. Verify that the new CORE_2X_* constants (now in actual Bps) are correctly handled by the monaco ICC provider and do not cause voltage/frequency mismatches during device probe. Check if monaco-evk requires platform-specific ICC constraints or if the PCIe PHY/link training needs adjustment for the new clock rates. As an immediate mitigation, re-run the test on a different monaco-evk board to rule out hardware-specific issues, and collect detailed PCIe link state and clock/voltage logs during WiFi probe to identify the exact failure point.
4. Detail analysis attachment: failed_case_job223447_4_detailed.md

Job 223448 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: These probe failures are not introduced by this PR and should be triaged separately as baseline platform issues. For this PR validation: mark Probe_Failure_Check as a known baseline failure and exclude from PR regression analysis. To address the underlying issues: (1) investigate qcom_qseecom_uefisecapp -EBUSY (likely TrustZone dependency), (2) fix qcom-spmi-lpg DT configuration causing -EINVAL, (3) verify PCIe endpoint presence for the two qcom-pcie instances or mark as optional, (4) add regulatory.db firmware file to rootfs or mark as non-critical.
4. Detail analysis attachment: failed_case_job223448_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expectation mismatch — the smmu test expects all USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) to be attached to IOMMU groups, but these devices are not present in the device tree or are not probed on the purwa-evk platform. The SMMU subsystem is functioning correctly (35 devices properly attached to IOMMU groups, no SMMU/IOMMU errors in kernel log), but the test's hardcoded device list does not match the actual hardware configuration of this SoC.
3. Possible fix: Update the smmu test's critical device list to match the purwa-evk (or make it platform-aware) — the missing USB devices appear to be USB PHY companion devices that may not be instantiated on all platforms, and the video codec device may not be enabled in this board's device tree. The PR changes (GENI ICC vote corrections) are unrelated to SMMU functionality and do not cause this failure.
4. Detail analysis attachment: failed_case_job223448_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm unavailable (platform limitation)

1. Failed case: KVM_Driver — /dev/kvm unavailable (platform limitation)
2. Root cause: KVM driver initialization failed during boot with "kvm [1]: HYP mode not available" at timestamp 5.779811s. The purwa-evk platform does not support ARM virtualization extensions (EL2/HYP mode) required for KVM operation, preventing /dev/kvm device node creation.
3. Possible fix: This is a pre-existing platform hardware limitation, not a PR-introduced regression. The PR modifies GENI serial ICC voting and is unrelated to KVM/virtualization. Mark KVM_Driver test as "not applicable" or "skip" for purwa-evk in the LAVA test suite, or exclude purwa-evk from KVM test runs until hardware with virtualization support is used.
4. Detail analysis attachment: failed_case_job223448_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM initialization failure (not a crash, not build load failure)

1. Failed case: KVM_EL2_DTB — KVM initialization failure (not a crash, not build load failure)
2. Root cause: KVM driver initialization failed with "HYP mode not available" because the Purwa EVK board is running under the Gunyah hypervisor (gunyah-mobile-c487961e9), which prevents KVM from acquiring EL2 (HYP mode). The /dev/kvm device node is not created, causing all KVM-dependent tests to fail. This is a platform configuration issue, not a PR-introduced regression (PR modifies GENI serial ICC voting, unrelated to KVM/virtualization).
3. Possible fix: This is a known platform limitation — KVM cannot run when the system is already under a hypervisor (Gunyah). To enable KVM tests on Purwa EVK: (1) boot without Gunyah hypervisor, or (2) configure nested virtualization support if available in Gunyah, or (3) exclude KVM tests from the Purwa EVK test suite as they are not applicable to this hypervisor-enabled platform configuration.
4. Detail analysis attachment: failed_case_job223448_4_detailed.md

  Case 5: KVM_Infra — KVM driver initialization failure (HYP mode unavailable)

1. Failed case: KVM_Infra — KVM driver initialization failure (HYP mode unavailable)
2. Root cause: The KVM driver is enabled in kernel config (CONFIG_KVM=y) but the Purwa IoT EVK (iq-x5121) platform does not provide EL2/HYP mode support required for ARM KVM virtualization, causing the driver to report "HYP mode not available" at boot and preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The Purwa IoT EVK does not support virtualization (EL2/HYP mode is not available in the boot chain/firmware). Disable CONFIG_KVM in the kernel config for this platform, or mark KVM tests as "not applicable" for purwa-evk in the LAVA test suite configuration. This failure is NOT introduced by PR Fix qup core icc votes #1060 (which only modifies GENI serial ICC voting constants).
4. Detail analysis attachment: failed_case_job223448_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform hardware/firmware limitation — Purwa IoT EVK (iq-x5121-evk) does not support KVM virtualization because the CPU is not running at EL2 (hypervisor exception level). Kernel correctly detects and reports "HYP mode not available" at boot, preventing /dev/kvm device creation.
3. Possible fix: This is a test environment configuration issue, not a kernel regression. Either: (1) exclude KVM tests from the Purwa platform test suite, or (2) reconfigure the platform bootloader/firmware to boot Linux at EL2 if virtualization support is required. The PR changes (GENI ICC voting) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job223448_6_detailed.md

Job 223449 | SoC shikra-iqs-evk

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

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

  Case 1: GIC (Test Script Bug — No Applicable CoT)

1. Failed case: GIC (Test Script Bug — No Applicable CoT)
2. Root cause: The GIC test script incorrectly assumes 8 CPUs (0-7) are present, but the shikra-iqs-evk board has only 4 CPUs (0-3). When the script attempts to parse interrupt counts for non-existent CPUs 4-7, it encounters bash integer comparison errors ([: GICv3: integer expected) because the /proc/interrupts output for those CPUs is empty or malformed, causing the test to report false failures for CPUs 4-7 while CPUs 0-3 passed correctly.
3. Possible fix: Update the GIC test script (/lava-223449/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh line 75) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo before attempting to validate timer interrupt counts, rather than hardcoding an assumption of 8 CPUs. The script should iterate only over CPUs that are actually present on the target platform.
4. Detail analysis attachment: failed_case_job223449_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing probe failures unrelated to PR changes — coresight-etm4x (-EINVAL), regulatory.db firmware (-ENOENT), cpufreq-dt (-EEXIST), and lt9611c (-EIO) failures are board/DT/firmware configuration issues not introduced by the GENI ICC bandwidth fix.
3. Possible fix: Mark test as expected-fail for shikra-iqs-evk until board DT/firmware is corrected; PR changes (GENI ICC bandwidth constants) do not affect these subsystems and should not block merge.
4. Detail analysis attachment: failed_case_job223449_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — the shikra-iqs-evk board's USB controller is configured in gadget (device) mode rather than host mode in the device tree, and no USB host controller driver is loaded. The test expects to enumerate USB devices on a host port, but the hardware is configured as a USB peripheral.
3. Possible fix: This is not a kernel bug introduced by the PR (which modifies GENI ICC bandwidth constants unrelated to USB). If USB host functionality is required for this board: (1) verify the board hardware supports USB host mode, (2) update the device tree to set dr_mode = "host" or dr_mode = "otg" for the USB controller node, (3) ensure the appropriate USB host controller driver (dwc3-host/xhci-hcd) is enabled in the kernel config. If USB host is not supported on this board variant, mark the USBHost test as SKIP for shikra-iqs-evk in the LAVA test definition.
4. Detail analysis attachment: failed_case_job223449_3_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault (synchronous external abort 0x96000010) when qcom_rng_read attempts to read RNG hardware registers at offset +0xc4, indicating the RNG hardware block is not properly powered/clocked or is in an inaccessible state on Shikra IQS EVK. The PR changes to ICC bandwidth voting for GENI serial (increasing votes from ~1000 Bps to ~10-100 MBps) may have altered system-wide power/clock states, exposing a latent hardware initialization or power sequencing issue in the qcom_rng driver or RNG hardware block.
3. Possible fix: This is NOT a PR-introduced bug but a pre-existing platform issue exposed by correct ICC voting. The qcom_rng driver needs proper runtime PM and clock/power management for Shikra (SM8750). Short-term: revert the PR to restore previous (incorrect but stable) ICC votes. Proper fix: add runtime PM support to drivers/char/hw_random/qcom-rng.c to ensure RNG hardware is powered/clocked before register access, and verify RNG power domain and clock bindings in arch/arm64/boot/dts/qcom/sm8750.dtsi.
4. Detail analysis attachment: failed_case_job223449_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform hardware limitation, not a software bug. The Shikra IQS EVK board does not support KVM/virtualization. To resolve: (1) Skip KVM tests on this platform in CI configuration, OR (2) Use a different platform that supports ARM virtualization extensions (e.g., boards with Cortex-A cores that implement EL2). This is NOT a PR-introduced regression—the PR modifies GENI serial ICC voting (unrelated to KVM).
4. Detail analysis attachment: failed_case_job223449_5_detailed.md

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

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** Hardware RNG (qcom_rng) driver attempted to read from MMIO register at address 0xffff800083285004 but received a synchronous external abort (ESR 0x96000010), indicating the hardware block is not accessible—most likely due to missing clock/power enablement, incorrect device tree MMIO mapping, or missing platform-specific initialization for the RNG hardware on Shikra (SM8750) SoC.
3. Possible fix: Verify and enable RNG hardware prerequisites on Shikra: (1) Check device tree qcom,prng-ee node has correct reg property for SM8750 RNG base address; (2) Ensure RNG clock (core_clk) is defined in DT and enabled in driver probe; (3) Confirm interconnect path votes are set if required; (4) Check if secure firmware initialization is needed for RNG on this platform. This is a pre-existing Shikra platform issue, NOT introduced by PR Fix qup core icc votes #1060 (which only modifies GENI serial ICC voting).
4. Detail analysis attachment: failed_case_job223449_6_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_rng driver crashed with a synchronous external abort when userspace (dd process) attempted to read from /dev/hwrng. The fault occurred at qcom_rng_read+0xc4 when dereferencing an invalid address (x26), indicating either a hardware register access failure or a driver bug where the MMIO region is not properly mapped or accessible on this shikra-iqs-evk platform. This is a pre-existing platform/driver issue unrelated to the PR's GENI ICC vote changes.
3. Possible fix: Investigate qcom_rng driver initialization and MMIO mapping on shikra-iqs-evk. Check device tree for correct qcom,prng-ee-v2 node configuration and reg property. Verify hardware RNG block is powered and clocked correctly. As a short-term workaround, blacklist the qcom_rng module or avoid reading from /dev/hwrng during CI tests. This is not a PR-introduced regression.
4. Detail analysis attachment: failed_case_job223449_7_detailed.md

  Case 8: ** Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: ** Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: ** The qcom_rng hardware RNG driver attempted to read a hardware register that was not accessible (synchronous external abort), likely because the RNG hardware block was not properly clocked or powered at the time of access. The crash occurred when userspace read from /dev/hwrng, triggering qcom_rng_read to access RNG registers. After the panic, the board correctly entered EDL mode for ramdump collection (expected behavior on shikra-iqs-evk).
3. Possible fix: This is a pre-existing qcom_rng driver issue, not introduced by the PR. The PR changes ICC bandwidth votes for GENI serial engines, which do not directly affect qcom_rng. To resolve: (1) verify qcom_rng driver runtime PM and clock management on shikra platform, (2) ensure RNG hardware is properly initialized and clocked before register access, (3) add defensive checks in qcom_rng_read to validate hardware state before register access. For CI: re-trigger the job — this crash is intermittent and unrelated to the PR changes.
4. Detail analysis attachment: failed_case_job223449_8_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (ESR 0x96000010) at PC qcom_rng_read+0xc4/0x228 when reading from /dev/hwrng. The crash occurred during a memory access (instruction b940035c = ldr w28, [x26, #0]) to an unmapped or inaccessible hardware register in the qcom_rng driver, causing the kernel to panic with "synchronous external abort: Fatal exception". The system entered a crash loop with repeated EFI paging faults, preventing test completion and causing LAVA to timeout after 2400 seconds. This is a pre-existing kernel/driver/firmware issue unrelated to the PR (which modifies GENI serial ICC voting).
3. Possible fix: Investigate the qcom_rng driver hardware register mapping and clock/power dependencies on shikra-iqs-evk. The synchronous external abort indicates the RNG hardware block was either not powered/clocked correctly or the MMIO region was not properly mapped. Check: (1) DT node for qcom,prng-ee (RNG device) includes correct reg/clocks/power-domains, (2) runtime PM state of the RNG device before access, (3) whether the RNG hardware requires additional firmware/secure-world initialization on this SoC. Short-term: disable or skip the qcom_hwrng test on shikra-iqs-evk until the root cause is resolved.
4. Detail analysis attachment: failed_case_job223449_9_detailed.md

  Case 10: Test Timeout — qcom_hwrng test triggered kernel crash (synchronous external abort)

1. Failed case: Test Timeout — qcom_hwrng test triggered kernel crash (synchronous external abort)
2. Root cause: Synchronous external abort (ESR 0x96000010) in qcom_rng_read at offset +0xc4 when accessing hardware RNG registers; the abort indicates the hardware block was not accessible (likely unpowered, unclocked, or in an invalid state when the test attempted to read from /dev/hwrng).
3. Possible fix: This is a pre-existing kernel/hardware issue unrelated to the PR changes (GENI ICC voting). The qcom_hwrng test should be skipped or the qcom_rng driver probe should be fixed to ensure the RNG hardware is properly powered and clocked before allowing reads. For immediate CI unblocking: add qcom_hwrng to the test skip list for shikra-iqs-evk until the driver/DT/power-domain issue is resolved.
4. Detail analysis attachment: failed_case_job223449_10_detailed.md

Job 223450 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: These failures are not introduced by PR Fix qup core icc votes #1060 (GENI ICC vote corrections). The PR modifies only GENI serial engine ICC bandwidth constants and serial console voting logic, which do not affect qseecom, spmi-lpg, or cfg80211 regulatory database loading. All tested platforms (7 of 7) exhibit Probe_Failure_Check failures with platform-specific probe errors, confirming these are pre-existing baseline issues. No action required for this PR; track platform-specific probe failures separately: (1) investigate qseecom secure world dependencies on hamoa-evk, (2) correct spmi-lpg multi-led DT "reg" property for hamoa PMIC configuration, (3) add regulatory.db to production rootfs images if WiFi regulatory compliance is required.
4. Detail analysis attachment: failed_case_job223450_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — six platform devices (five USB PHY controllers: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb, and one video codec: aa00000.video-codec) are missing IOMMU group attachments on hamoa-evk, indicating incomplete device tree iommus property bindings for these devices.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only modifies GENI ICC bandwidth constants). Add missing iommus properties to the device tree nodes for the five USB PHY controllers (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and the video codec (aa00000) in arch/arm64/boot/dts/qcom/hamoa.dtsi, following the pattern used by the successfully attached USB controllers (a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb).
4. Detail analysis attachment: failed_case_job223450_2_detailed.md

  Case 3: KVM Platform Support — HYP mode not available

1. Failed case: KVM Platform Support — HYP mode not available
2. Root cause: The hamoa-evk platform does not have EL2 (Hypervisor mode) enabled in firmware/bootloader. KVM initialization fails with "HYP mode not available" at boot, preventing /dev/kvm device node creation. This is a platform/firmware limitation, not a kernel regression. The PR changes (GENI serial ICC voting) are unrelated to virtualization.
3. Possible fix: This is not a PR-introduced regression. To enable KVM on hamoa-evk: (1) verify the SoC supports virtualization extensions (ARMv8.0-A with EL2), (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 instead of EL1, (3) check that secure firmware (TZ) allows EL2 access and has not disabled virtualization extensions. If the platform does not support EL2, mark KVM tests as "skip" for this board in the CI configuration.
4. Detail analysis attachment: failed_case_job223450_3_detailed.md

  Case 4: ** KVM_EL2_DTB (Test Environment Mismatch - Not a Kernel Bug)

1. Failed case: ** KVM_EL2_DTB (Test Environment Mismatch - Not a Kernel Bug)
2. Root cause: ** KVM cannot initialize on hamoa-evk because the Gunyah hypervisor is already running at EL2 (HYP mode). Linux kernel runs as a guest under Gunyah and cannot access EL2 to initialize KVM. The kernel correctly reports "HYP mode not available" at boot. This is expected platform behavior, not a regression.
3. Possible fix: Mark KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) as "SKIP" or "N/A" for hamoa-evk and any other platforms running under Gunyah or other hypervisors. Add a platform-specific test filter in the LAVA job definition to exclude KVM tests when Hypervisor cold boot is detected in boot logs, or maintain a static list of hypervisor-based platforms that should skip KVM tests.
4. Detail analysis attachment: failed_case_job223450_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — Pre-existing Platform Limitation

1. Failed case: KVM Infrastructure Test Failure — Pre-existing Platform Limitation
2. Root cause: KVM cannot initialize on hamoa-evk because the platform runs under Gunyah hypervisor, which occupies EL2 (HYP mode). KVM requires EL2 to function, making KVM and Gunyah mutually exclusive. The kernel correctly reports "HYP mode not available" and does not create /dev/kvm. This is not a regression — it is the expected behavior on Gunyah-enabled platforms.
3. Possible fix: Update the LAVA test job definition for hamoa-evk to skip all KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) when Gunyah hypervisor is detected. Add a pre-test check that detects Gunyah presence (via dmesg grep for "Hypervisor cold boot, version: gunyah") and marks KVM tests as SKIP rather than FAIL. This is not a kernel issue requiring a code fix.
4. Detail analysis attachment: failed_case_job223450_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform does not support KVM virtualization — kernel message "HYP mode not available" indicates the Hamoa IoT EVK hardware/firmware does not provide EL2 (hypervisor) mode, preventing KVM initialization and /dev/kvm device creation.
3. Possible fix: This is a pre-existing platform limitation unrelated to PR Fix qup core icc votes #1060 (which only modifies GENI serial ICC bandwidth constants). Either: (1) skip KVM tests on hamoa-evk in the CI job definition, or (2) use a different platform that supports virtualization (e.g., platforms with Gunyah hypervisor or native EL2 support) for KVM validation.
4. Detail analysis attachment: failed_case_job223450_6_detailed.md

Job 223451 | SoC qcs8300-ride

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Two pre-existing platform configuration issues detected: (1) Missing regulatory.db firmware file in rootfs (non-critical - WiFi functional), (2) Missing firmware-name device tree property for Aquantia AQR115C PHY at stmmac-0:08 on qcs8300-ride platform, causing probe failure with -EINVAL.
3. Possible fix: These are not regressions from PR Fix qup core icc votes #1060. (1) For regulatory.db: Add regulatory.db firmware to rootfs or suppress this benign warning. (2) For Aquantia PHY: Add firmware-name = "..."; property to the Aquantia PHY node in qcs8300-ride device tree, or remove the PHY node if the hardware is not populated on this board revision.
4. Detail analysis attachment: failed_case_job223451_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: USBHost test failure on qcs8300-ride — test expects enumeration of USB host devices but finds none or insufficient devices; USB host controller (xhci-hcd) initialized successfully and USB hub detected during boot, indicating kernel USB stack is functional; failure is test infrastructure/hardware-related (no USB devices physically connected to board), not a kernel regression introduced by PR Fix qup core icc votes #1060 (GENI serial ICC voting changes).
3. Possible fix: Verify USB host test hardware setup for qcs8300-ride board in LAVA lab — ensure USB devices (e.g., USB storage, USB keyboard, or test fixture) are physically connected to the board's USB host ports before test execution; if hardware is correctly connected, review USBHost test script expectations and update test to handle boards with no external USB devices or mark as expected-fail for this board configuration.
4. Detail analysis attachment: failed_case_job223451_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Aquantia AQR115C PHY driver probe failed with -EINVAL because the device tree node is missing the required firmware-name property, preventing PHY attachment and Ethernet interface bring-up on qcs8300-ride.
3. Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY device tree node in the qcs8300-ride DTS file. This is a pre-existing platform configuration issue unrelated to PR Fix qup core icc votes #1060 (which only modifies GENI ICC bandwidth constants).
4. Detail analysis attachment: failed_case_job223451_3_detailed.md

  Case 4: KVM_Driver (Test Environment Issue — Platform Does Not Support KVM)

1. Failed case: KVM_Driver (Test Environment Issue — Platform Does Not Support KVM)
2. Root cause: QCS8300 (Monaco) platform does not support ARM virtualization extensions (EL2/VHE) required for KVM. CONFIG_KVM is enabled in the kernel config, but the KVM driver does not initialize because the underlying hardware does not provide the necessary virtualization support. As a result, /dev/kvm is never created, causing the test to fail.
3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as "not applicable" or "skip" for QCS8300 (Monaco) platform in the LAVA test suite configuration. These tests should only run on platforms with confirmed EL2/VHE support (e.g., platforms with Gunyah hypervisor or native KVM support).
4. Detail analysis attachment: failed_case_job223451_4_detailed.md

  Case 5: KVM_EL2_DTB — /dev/kvm not available (platform limitation, not a regression)

1. Failed case: KVM_EL2_DTB — /dev/kvm not available (platform limitation, not a regression)
2. Root cause: KVM cannot initialize on qcs8300-ride because the Gunyah hypervisor (version gunyah-cdfb73831) is running and owns EL2. KVM requires exclusive EL2 access to create /dev/kvm; when a Type-1 hypervisor like Gunyah is present, the kernel runs as a guest at EL1 and cannot access EL2 virtualization extensions. CONFIG_KVM is enabled but the KVM driver silently skips initialization when it detects it's running under a hypervisor.
3. Possible fix: This is not a bug. The test expectation is incorrect for this platform configuration. Either: (1) disable KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) in the LAVA test suite for qcs8300-ride and other Gunyah-based platforms, or (2) configure the platform to boot without Gunyah if KVM functionality is required for testing. The PR changes (GENI serial ICC voting) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job223451_5_detailed.md

  Case 6: KVM_Infra (also KVM_Driver, KVM_EL2_DTB — same root cause)

1. Failed case: KVM_Infra (also KVM_Driver, KVM_EL2_DTB — same root cause)
2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running as a guest under the Gunyah hypervisor (nested virtualization not supported). CONFIG_KVM is enabled but KVM requires EL2 (hypervisor mode) access, which is already occupied by Gunyah. No /dev/kvm device node is created because KVM initialization is silently skipped when running under a hypervisor.
3. Possible fix: This is not a PR-introduced regression — the PR modifies GENI serial ICC voting and is unrelated to KVM. The KVM tests are expected to fail on qcs8300-ride when booted under Gunyah. Either: (1) exclude KVM tests from the qcs8300-ride test suite when Gunyah is active, or (2) boot qcs8300-ride without Gunyah to enable native KVM support, or (3) mark KVM tests as expected-fail for Gunyah-based configurations in the LAVA job definition.
4. Detail analysis attachment: failed_case_job223451_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM device node /dev/kvm is not present on QCS8300 Ride platform despite CONFIG_KVM=y in kernel config. No KVM initialization messages appear in kernel boot log, indicating KVM failed to initialize silently or the platform does not support KVM virtualization (possibly running under a hypervisor that prevents nested virtualization, or missing EL2 support).
3. Possible fix: Verify QCS8300 Ride platform supports KVM/virtualization at EL2. Check if the platform is running under a hypervisor that blocks nested virtualization. If KVM is built as a module, ensure it's loaded during boot. If the platform fundamentally does not support KVM, mark KVM tests as expected failures for this SoC or exclude them from the test suite for QCS8300.
4. Detail analysis attachment: failed_case_job223451_7_detailed.md

Job 223452 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check (suppressed — known benign: WiFi regulatory.db false positive)

1. Failed case: Probe_Failure_Check (suppressed — known benign: WiFi regulatory.db false positive)
2. Root cause: The Probe_Failure_Check test detected a cfg80211 regulatory.db firmware load failure (error -2: ENOENT) during early boot. This error occurs before the WiFi driver (ath11k) fully initializes. The regulatory database is subsequently loaded successfully when the WiFi driver completes initialization, as evidenced by passing WiFi_Firmware_Driver and WiFi_OnOff functional tests. This is a known false positive caused by the test scanning dmesg for firmware errors without correlating them with subsequent successful driver initialization.
3. Possible fix: Suppress this failure per Rule 2 of lava-known-benign-failures.md. The Probe_Failure_Check test should be enhanced to exclude regulatory.db firmware load failures when WiFi functional tests pass, or to scan only for firmware errors that occur after driver initialization is complete. No kernel or PR changes are required — this is a test infrastructure improvement.
4. Detail analysis attachment: failed_case_job223452_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark this test as SKIP or EXPECTED_FAIL for qcs6490-rb3gen2 until USB host hardware support is enabled in the board device tree and validated. If USB host is required, verify the board hardware supports USB host mode, enable the USB controller node in the device tree (status = "okay"), ensure the dwc3/xhci drivers are built and loaded, and confirm USB host PHY and power supplies are configured. Re-run the test only after confirming USB host controller probe messages appear in dmesg.
4. Detail analysis attachment: failed_case_job223452_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Platform does not support EL2 (hypervisor mode) required for KVM. Kernel correctly reports "HYP mode not available" at boot (timestamp 3.391993s). The qcs6490-rb3gen2 platform either lacks hardware virtualization extensions or the bootloader/firmware does not boot the kernel at EL2, preventing KVM initialization and /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR regression. The test expectation is incorrect for this platform. Recommended action: Update the LAVA test suite configuration to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) on qcs6490-rb3gen2 (Kodiak) platform, or enable EL2 support in the platform firmware/bootloader if virtualization is a required feature for this SoC.
4. Detail analysis attachment: failed_case_job223452_3_detailed.md

  Case 4: KVM_EL2_DTB — /dev/kvm device node unavailable (KVM initialization failed)

1. Failed case: KVM_EL2_DTB — /dev/kvm device node unavailable (KVM initialization failed)
2. Root cause: KVM driver initialization failed during boot because the platform is not running in EL2 (hypervisor mode). Kernel message at boot: kvm [1]: HYP mode not available indicates the CPU did not enter hypervisor mode, preventing KVM from creating the /dev/kvm device node. This is a platform/firmware/bootloader configuration issue on qcs6490-rb3gen2, not a kernel regression introduced by the PR (which only modifies GENI serial ICC voting constants).
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR changes. The qcs6490-rb3gen2 board's bootloader/firmware is not configured to boot the kernel in EL2 mode. To enable KVM: (1) verify the bootloader is configured to enter EL2 before jumping to the kernel, (2) check if the platform supports virtualization extensions and EL2 mode, (3) if supported, update bootloader/firmware configuration to enable EL2 entry. The PR should not be blocked by this pre-existing platform limitation.
4. Detail analysis attachment: failed_case_job223452_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: The qcs6490-rb3gen2 platform does not provide EL2/HYP mode support required for KVM virtualization; kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware lacks hypervisor capability, preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR modifies GENI serial ICC voting, unrelated to KVM). No kernel fix possible. Options: (1) Skip KVM tests on qcs6490-rb3gen2 in CI configuration, or (2) Enable EL2 support in the board's firmware/bootloader if hardware supports it, or (3) Use a different platform with hypervisor support for KVM testing.
4. Detail analysis attachment: failed_case_job223452_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM tests fail because HYP (Hypervisor) mode is not available on qcs6490-rb3gen2 — kernel message "kvm [1]: HYP mode not available" at boot indicates the platform does not support EL2 virtualization extensions required for KVM, causing /dev/kvm device node creation to be skipped.
3. Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test suite in the LAVA job definition, as this SoC/board does not support virtualization extensions; alternatively, mark these tests as expected-fail for this platform.
4. Detail analysis attachment: failed_case_job223452_6_detailed.md

Job 223453 | SoC qcs9100-ride

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

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

  Case 1: ** Probe_Failure_Check (driver probe failure test)

1. Failed case: ** Probe_Failure_Check (driver probe failure test)
2. Root cause: Missing or malformed firmware-name property in device tree node for Aquantia PHY
3. Possible fix: Mark this test failure as a false positive for PR validation. The PR does not introduce any new probe failures. To resolve the underlying platform issues: (1) add firmware-name property to Aquantia PHY DT node or disable the PHY if unused, (2) add regulatory.db to rootfs or disable cfg80211 regulatory checks if wireless is not used, (3) investigate thermal framework probe ordering or mark temp-alarm devices as optional if they are not critical for qcs9100-ride platform functionality.
4. Detail analysis attachment: failed_case_job223453_1_detailed.md

  Case 2: smmu (test false positive — iris video codec architecture)

1. Failed case: smmu (test false positive — iris video codec architecture)
2. Root cause: The SMMU test incorrectly expects the parent platform device aa00000.video-codec to be directly attached to an IOMMU group. The iris video codec driver uses a split-device architecture where the parent device (aa00000.video-codec) is a non-DMA platform wrapper, and the actual DMA masters are child devices (iris_non_pixel.0 and iris_pixel.0) which ARE correctly attached to IOMMU groups 17 and 18 respectively. This is the expected and correct behavior for the iris driver on qcs9100-ride.
3. Possible fix: Update the SMMU test's critical master validation logic to recognize split-device video codec architectures (iris, venus) where child devices perform DMA and parent devices do not. The test should verify that either the device itself OR its child devices are attached to IOMMU groups. Alternatively, remove aa00000.video-codec from the critical master list and add iris_non_pixel.0 and iris_pixel.0 instead.
4. Detail analysis attachment: failed_case_job223453_2_detailed.md

  Case 3: USBHost (Test Infrastructure Issue)

1. Failed case: USBHost (Test Infrastructure Issue)
2. Root cause: No external USB devices physically connected to the qcs9100-ride board's USB host ports; test expects functional USB devices but only root hubs are enumerated (Bus 001/002/003 Device 001 all show "Linux Foundation root hub").
3. Possible fix: Connect at least one functional USB device (USB storage, keyboard, or mouse) to the qcs9100-ride board's USB host port before running the USBHost test; alternatively, mark this test as SKIP when no USB peripherals are available in the lab setup.
4. Detail analysis attachment: failed_case_job223453_3_detailed.md

  Case 4: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Device tree PHY configuration issue for 23040000.ethernet (end0) — PHY attach fails with -EINVAL indicating missing or incorrect PHY phandle, phy-mode, or PHY driver binding in the device tree for this specific Ethernet port on qcs9100-ride.
3. Possible fix: Verify and correct the device tree PHY configuration for 23040000.ethernet node in arch/arm64/boot/dts/qcom/qcs9100-ride.dts — ensure phy-handle phandle is valid, phy-mode matches hardware, and PHY node is properly defined with compatible string matching an available PHY driver.
4. Detail analysis attachment: failed_case_job223453_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM-related tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for qcs9100-ride and other platforms without EL2 support. Add a platform capability check in the CI configuration to skip virtualization tests on non-EL2 platforms. This is not a kernel bug or regression - it's expected behavior on platforms without virtualization hardware.
4. Detail analysis attachment: failed_case_job223453_5_detailed.md

  Case 6: KVM_EL2_DTB — KVM/Virtualization Test Failure (Platform Capability Issue)

1. Failed case: KVM_EL2_DTB — KVM/Virtualization Test Failure (Platform Capability Issue)
2. Root cause: The qcs9100-ride (LeMans Ride Rev3) platform is not running in EL2 (hypervisor mode), preventing KVM initialization. The kernel reports "kvm [1]: HYP mode not available" at boot, which means the CPU is running in EL1 (kernel mode) without hypervisor support enabled. As a result, /dev/kvm device node is not created, causing all KVM-dependent tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail.
3. Possible fix: This is a pre-existing platform/firmware limitation, not a kernel regression. The qcs9100-ride board's bootloader/firmware does not enable EL2 mode. To enable KVM support: (1) Update the board's bootloader/firmware to boot the kernel in EL2 mode, or (2) Configure the platform to support virtualization extensions, or (3) Mark KVM tests as "not applicable" for this platform in the CI test matrix, as the hardware/firmware configuration does not support virtualization.
4. Detail analysis attachment: failed_case_job223453_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a fixable issue - it is an architectural constraint. Recommended action: Exclude KVM tests from the CI test suite for qcs9100-ride and other Gunyah-based platforms, as KVM cannot function when the kernel runs under a hypervisor. Add a platform-specific test filter in the LAVA job definition to skip Virtualization/KVM/* tests for boards running Gunyah. If nested virtualization is required, it must be implemented through Gunyah's own VM management interfaces, not KVM.
4. Detail analysis attachment: failed_case_job223453_7_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Test definition marked as failed due to three KVM test case failures (KVM_Driver, KVM_EL2_DTB, KVM_Infra); all three failed because /dev/kvm is not available on qcs9100-ride, which boots with "kvm [1]: HYP mode not available" — the platform does not support EL2/hypervisor mode required for KVM functionality.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR changes GENI serial ICC bandwidth, unrelated to KVM). Either: (1) exclude KVM tests from qcs9100-ride CI runs since the platform lacks EL2 support, or (2) configure the platform/bootloader to enable EL2 if hardware supports it, or (3) mark KVM tests as expected-fail/skip for this SoC in the test plan.
4. Detail analysis attachment: failed_case_job223453_8_detailed.md

Job 223454 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check (deferred probe + firmware load warnings)

1. Failed case: Probe_Failure_Check (deferred probe + firmware load warnings)
2. Root cause: Test reports failure due to (1) four PMIC temp-alarm devices remaining in deferred probe state (known benign on lemans-evk — thermal zone DT configuration incomplete for all 4 PMICs), and (2) three firmware load failures that are false positives (Bluetooth and WiFi functional tests passed, confirming runtime firmware loading succeeded via fallback paths).
3. Possible fix: Suppress this test failure as known benign — the deferred temp-alarm probes do not affect system functionality (thermal monitoring may be limited but not critical for CI), and the firmware load "failures" are false positives contradicted by passing BT_ON_OFF and WiFi_OnOff tests. If strict probe checking is required, add thermal zone DT nodes for all 4 PMICs on lemans-evk and package the missing firmware files in the rootfs.
4. Detail analysis attachment: failed_case_job223454_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) failed to attach to an IOMMU group during boot, likely due to altered QUP Core clock voting from the PR causing initialization timing or power sequencing issues that prevented the video driver from completing IOMMU attachment.
3. Possible fix: Revert the PR changes temporarily to confirm the regression; if confirmed, adjust the GENI ICC vote constants or serial console bandwidth logic to ensure video codec driver initialization completes before IOMMU group enumeration, or add explicit power/clock dependencies for the video codec device tree node.
4. Detail analysis attachment: failed_case_job223454_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner completed all test cases successfully but failed to send the required <LAVA_SIGNAL_ENDRUN> signal, causing LAVA dispatcher to mark the test definition as "unfinished" and fail it despite all individual tests passing.
3. Possible fix: This is a test infrastructure issue in the qcom-linux-testkit test runner script. The test runner should emit lava-test-run-attach or send <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests 223454_1.1.3.1> after <LAVA_TEST_RUNNER EXIT>. Re-trigger the CI job to confirm if this is a transient issue; if it recurs, fix the test runner script in https://github.com/qualcomm-linux/qcom-linux-testkit.git to properly signal test completion to LAVA.
4. Detail analysis attachment: failed_case_job223454_3_detailed.md

Job 223455 | SoC qcs615-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort (SWIOTLB DMA bounce buffer access fault during USB enumeration)

1. Failed case: Kernel Crash — Synchronous External Abort (SWIOTLB DMA bounce buffer access fault during USB enumeration)
2. Root cause: The kernel crashed at 7.36 seconds during USB device enumeration with a synchronous external abort while accessing a SWIOTLB bounce buffer. The crash occurred in __pi_memcpy_generic called from swiotlb_bounce during xhci_map_urb_for_dma for a USB low-speed device (1-1). The fault address 0x10d863660 indicates an invalid physical address access, suggesting either incorrect SWIOTLB buffer allocation, corrupted DMA mapping, or a hardware bus fault. This is NOT related to the PR changes (which modify GENI serial ICC voting constants) — the crash occurs in the USB/SWIOTLB/IOMMU DMA path during early boot hardware enumeration on qcs615-ride.
3. Possible fix: This is a pre-existing kernel or platform issue unrelated to PR Fix qup core icc votes #1060. The PR modifies only GENI serial driver ICC bandwidth constants and does not touch USB, SWIOTLB, IOMMU, or DMA subsystems. Recommended actions: (1) Check if this crash reproduces on the baseline kernel without the PR patches; (2) Verify SWIOTLB buffer configuration and size for qcs615-ride platform; (3) Check for known USB/xHCI errata on QCS615 SoC; (4) Enable CONFIG_DMA_API_DEBUG and CONFIG_IOMMU_DEBUG to capture detailed DMA mapping state before the crash; (5) If reproducible, bisect the mainline kernel to identify the introducing commit. The PR should NOT be blocked by this failure unless reproduction testing confirms it is PR-introduced (highly unlikely given the code paths involved).
4. Detail analysis attachment: failed_case_job223455_1_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA
2. Root cause: Hardware bus error (synchronous external abort) triggered during SWIOTLB bounce buffer DMA copy operation for USB device enumeration at 7.36 seconds post-boot. The crash occurred in __pi_memcpy_generic called from swiotlb_bounce while mapping a USB URB for DMA, indicating an attempt to access an invalid or unmapped physical address (x19: 0x10d863660) in the SWIOTLB bounce buffer region. This is a pre-existing hardware/platform issue unrelated to the PR's ICC bandwidth vote changes for GENI serial console.
3. Possible fix: This is a pre-existing platform/hardware issue on qcs615-ride, not introduced by PR Fix qup core icc votes #1060. The PR changes only ICC bandwidth constants for GENI serial (I2C/SPI/UART) and does not touch USB, PCIe, DMA, or SWIOTLB subsystems. Recommended actions: (1) Verify SWIOTLB configuration and size in kernel config and bootargs; (2) Check if USB device connected to the board has known DMA addressing issues; (3) Enable CONFIG_DMA_API_DEBUG and CONFIG_IOMMU_DEBUG to capture detailed DMA mapping failures; (4) Verify PCIe/USB IOMMU group configuration in device tree; (5) Re-run the test without the USB device to confirm boot completes successfully.
4. Detail analysis attachment: failed_case_job223455_2_detailed.md

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

1. Failed case: Kernel Crash — synchronous external abort during USB device enumeration
2. Root cause: Hardware memory access fault (synchronous external abort) at address 0x10d863660 during SWIOTLB bounce buffer copy operation while enumerating a USB low-speed device. The fault occurred in __pi_memcpy_generic called from swiotlb_bounce during DMA mapping for USB control transfer. This is a fatal hardware exception indicating the CPU attempted to access an invalid or unmapped physical address, triggering an external abort from the memory subsystem.
3. Possible fix: This is a pre-existing hardware/platform issue unrelated to the PR changes (which only modify GENI serial ICC bandwidth constants). The PR does not touch USB, DMA, SWIOTLB, or PCIe code paths. To mitigate: (1) verify the SWIOTLB buffer pool is correctly configured and not corrupted; (2) check if the USB device at port 1-1 is faulty or requires specific quirks; (3) add USB device ID to quirk list if this is a known problematic device; (4) increase SWIOTLB buffer size via kernel command line swiotlb=<size> if buffer exhaustion is suspected; (5) test with the USB device disconnected to confirm the board boots successfully without it.
4. Detail analysis attachment: failed_case_job223455_3_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort during USB enumeration
2. Root cause: PR-introduced kernel panic due to synchronous external abort in SWIOTLB bounce buffer memcpy during USB device enumeration; the 10,000x increase in ICC bandwidth vote constants (CORE_2X_*_MHZ) destabilizes QUP Core clock transitions during early boot on qcs615-ride, triggering a memory access fault in the DMA/IOMMU path.
3. Possible fix: Revert the ICC bandwidth constant changes in patch 1/2 and re-test; if the constants are correct, add proper clock rate transition sequencing or introduce a gradual ramp-up mechanism in the GENI ICC vote path to prevent synchronous external aborts during early boot hardware initialization.
4. Detail analysis attachment: failed_case_job223455_4_detailed.md