Skip to content

Shikra rpmcc latest changes - #1076

Merged
Salendarsingh Gaud (sgaud-quic) merged 6 commits into
qualcomm-linux:qcom-6.18.yfrom
imrashai:shikra-rpmcc-latest-changes
Sep 16, 2026
Merged

Shikra rpmcc latest changes#1076
Salendarsingh Gaud (sgaud-quic) merged 6 commits into
qualcomm-linux:qcom-6.18.yfrom
imrashai:shikra-rpmcc-latest-changes

Conversation

@imrashai

@imrashai imrashai commented Sep 10, 2026 •
edited
Loading

Copy link
Copy Markdown

Revert the old FROMLIST changes of Shikra RPMCC and update the latest RPMCC changes as per the linux-next.

And add the Skip RPMCC clocks proxy votes FROMLIST changes. This change is dependent on crypto DTS changes [1] Without crypto side changes the device boot-up will be impacted.

Dependent PR:
[1] #1077

CRs-Fixed: 4635293

@qswat-orbit-external

qswat-orbit-external Bot commented Sep 10, 2026

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4635293 is not eligible for merge.

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

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

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

@imrashai

imrashai commented Sep 10, 2026

Copy link
Copy Markdown
Author

qli-2.1 pull-request freeze

@qcomlnxci

qcomlnxci commented Sep 10, 2026

Copy link
Copy Markdown

Test jobs on 90970b9

@qcomlnxci

qcomlnxci commented Sep 10, 2026

Copy link
Copy Markdown

Test Matrix

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

shashim-quic
Shiraz Hashim (shashim-quic) requested changes Sep 12, 2026
View reviewed changes

@shashim-quic Shiraz Hashim (shashim-quic) left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
This reverts commit 521561d.

Mention reason for revert in each revert commit log.

@imrashai
imrashai force-pushed the shikra-rpmcc-latest-changes branch from 90970b9 to d8db001 Compare September 12, 2026 16:56
@qcomlnxci
qcomlnxci requested a review from a team September 12, 2026 16:57
@imrashai

imrashai commented Sep 12, 2026

Copy link
Copy Markdown
Author

Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
This reverts commit 521561d.

Mention reason for revert in each revert commit log.

Updated the commit text in each revert commit log mentioning the reason details.

@qcomlnxci

qcomlnxci commented Sep 12, 2026

Copy link
Copy Markdown

Test jobs on d8db001

@qcomlnxci

qcomlnxci commented Sep 12, 2026

Copy link
Copy Markdown

Test Matrix

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

@imrashai
Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra…
0d81461 
… SoC RPMCC"

Revert the v2 series changes of Shikra RPMCC to update with the UPSTREAM
version changes in which the QCM2290 RPMCC compatible used as the fallback
compatible.

This reverts commit 521561d.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
@imrashai
Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Q…
b312b67 
…ualcomm Shikra SoC"

Revert the v2 series changes of Shikra RPMCC to update with the UPSTREAM
version changes in which the QCM2290 RPMCC compatible used as the fallback
compatible.

This reverts commit 2d56ae2.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
@imrashai
UPSTREAM: clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 clocks supp…
f7342ef 
…ort on Agatti

Add support for missing RF_CLK1/RF_CLK2 clocks on Qualcomm Agatti (QCM2290)
SoC.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260608-shikra-gcc-rpmcc-clks-v5-3-94cefe092ee3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
@imrashai
UPSTREAM: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC
796a63b 
Add bindings documentation for RPM clock controller on Qualcomm Shikra SoC.
The Qualcomm Shikra RPMCC has the clocks same as Agatti (QCM2290) RPMCC.
Hence, add support to use the QCM2290 RPMCC compatible as fallback for
Shikra RPMCC.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260608-shikra-gcc-rpmcc-clks-v5-1-94cefe092ee3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
@imrashai
UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node
3982f5b 
Update Shikra RPMCC node to use the Agatti (QCM2290) RPMCC as fallback
compatible.

Link: https://lore.kernel.org/r/20260612-shikra-dt-v6-2-6b6cb58db477@oss.qualcomm.com
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
@imrashai
FROMLIST: clk: qcom: smd-rpm: Skip proxy votes on clocks for QCM2290
6c563f5 
clk_smd_rpm_handoff() votes both active and sleep RPM resource states for
every clock, keeping them non-zero until a consumer takes over. If there
is no consumer, those clocks will remain active in the idle scenario as
well, and the sleep vote is never cleared, blocking XO shutdown.

Introduce the skip_clks_handoff flag to handle this on QCM2290 clocks,
keeping other targets unaffected.

Link: https://lore.kernel.org/r/20260910-clk-smd-rpm-skip-proxy-v1-1-1cb5694a99d9@oss.qualcomm.com
Fixes: 00f64b5 ("clk: qcom: Add support for SMD-RPM Clocks")
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
@imrashai
imrashai force-pushed the shikra-rpmcc-latest-changes branch from d8db001 to 6c563f5 Compare September 15, 2026 11:35
@qcomlnxci
qcomlnxci requested a review from a team September 15, 2026 11:37
@qcomlnxci

qcomlnxci commented Sep 15, 2026

Copy link
Copy Markdown

Test jobs on d8db001

@qcomlnxci

qcomlnxci commented Sep 15, 2026

Copy link
Copy Markdown

Test Matrix

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

@qcomlnxci

qcomlnxci commented Sep 15, 2026

Copy link
Copy Markdown

Test jobs on 6c563f5

@qcomlnxci

qcomlnxci commented Sep 15, 2026

Copy link
Copy Markdown

Test Matrix

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

@qlijarvis

qlijarvis commented Sep 15, 2026

Copy link
Copy Markdown

PR #1076 — validate-patch

PR: #1076

Verdict Issues Detailed Report
⚠️ 0 Full report

Final Summary

  1. Lore link present: Yes — commits 3-6 have lore links; commits 1-2 are reverts (no lore link expected)
  2. Lore link matches PR commits: Yes — all 4 commits with lore links (3-6) are faithful to their upstream sources; diff content is identical
  3. Upstream patch status:
    • Commits 3-5: ✅ ACKed — merged by Bjorn Andersson (Jul 8, 2026) and DT maintainer
    • Commit 6: ⏳ Decision Pending — posted Sep 10, 2026; under review; no maintainer decision yet
  4. PR present in qcom-next/topics: Fail - 2/6 commit(s) are missing from both qcom-next and topics
Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1076 - Shikra RPMCC updates (revert v2, apply UPSTREAM v5 + FROMLIST proxy-vote skip)
Verdict: ⚠️ PARTIAL — 4/6 commits validated; 2 reverts have no upstream source; 1 FROMLIST patch still under review

Summary by Commit

# Subject Prefix Lore Link Match Upstream Status qcom-next
1/6 Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC" Revert N/A N/A N/A — revert of internal commit missing
2/6 Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC" Revert N/A N/A N/A — revert of internal commit missing
3/6 UPSTREAM: clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 clocks support on Agatti UPSTREAM v5 3/4 ✅ Identical ✅ ACKed — merged by Bjorn Andersson on Jul 8, 2026 present
4/6 UPSTREAM: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC UPSTREAM v5 1/4 ✅ Identical ✅ ACKed — merged by Bjorn Andersson on Jul 8, 2026 present
5/6 UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node UPSTREAM v6 2/5 ✅ Identical ✅ ACKed — "Applied, thanks!" in thread present
6/6 FROMLIST: clk: qcom: smd-rpm: Skip proxy votes on clocks for QCM2290 FROMLIST v1 ✅ Identical ⏳ Decision Pending — posted Sep 10, 2026; Sashiko AI review + Konrad Dybcio reply on Sep 11; no maintainer decision yet present (in topics)

Commit Message Validation

Commit Subject Body Fixes Tag Authorship Backport Note Status
1/6 ✅ Revert format correct ✅ Rationale clear N/A ✅ Imran Shaik N/A ✅ PASS
2/6 ✅ Revert format correct ✅ Rationale clear N/A ✅ Imran Shaik N/A ✅ PASS
3/6 ✅ Matches lore ✅ Preserved N/A ✅ Imran Shaik (matches lore) N/A ✅ PASS
4/6 ✅ Matches lore ✅ Preserved N/A ✅ Imran Shaik (matches lore) N/A ✅ PASS
5/6 ✅ Matches lore ✅ Preserved N/A ✅ Imran Shaik (matches lore) N/A ✅ PASS
6/6 ✅ Matches lore ✅ Preserved ✅ Present ✅ Imran Shaik (matches lore) N/A ✅ PASS

Diff Comparison

Commits 1-2 (Reverts):

  • Revert commits have no upstream lore source — they remove previously applied FROMLIST patches (v2 series) to make way for the UPSTREAM v5 series.
  • Diff content: clean reverts of commits 521561dfdec5 and 2d56ae2f8658.
  • Status: ✅ PASS — reverts are correctly formatted and justified.

Commit 3/6 (UPSTREAM: RF_CLK1/RF_CLK2):

  • Lore patch: [PATCH v5 3/4] from message-ID 20260608-shikra-gcc-rpmcc-clks-v5-3-94cefe092ee3@oss.qualcomm.com
  • Diff comparison: Identical — all hunks match lore patch exactly (5 added lines in clk-smd-rpm.c).
  • Status: ✅ PASS

Commit 4/6 (UPSTREAM: dt-bindings shikra rpmcc):

  • Lore patch: [PATCH v5 1/4] from message-ID 20260608-shikra-gcc-rpmcc-clks-v5-1-94cefe092ee3@oss.qualcomm.com
  • Diff comparison: Identical — YAML schema changes match lore patch (adds qcom,rpmcc-shikra with qcm2290 fallback).
  • Status: ✅ PASS

Commit 5/6 (UPSTREAM: arm64 dts shikra rpmcc node):

  • Lore patch: [PATCH v6 2/5] from message-ID 20260612-shikra-dt-v6-2-6b6cb58db477@oss.qualcomm.com
  • Diff comparison: Identical — single-line change in shikra.dtsi matches lore patch.
  • Status: ✅ PASS

Commit 6/6 (FROMLIST: skip proxy votes):

  • Lore patch: [PATCH v1] from message-ID 20260910-clk-smd-rpm-skip-proxy-v1-1-1cb5694a99d9@oss.qualcomm.com
  • Diff comparison: Identical — all hunks match lore patch (adds skip_clks_handoff flag for QCM2290).
  • Status: ✅ PASS

Upstream Patch Status

Commit Community Verdict Evidence
3/6 ✅ ACKed — merged into maintainer tree Bjorn Andersson replied "Applied, thanks!" on Jul 8, 2026 to the v5 series cover letter
4/6 ✅ ACKed — merged into maintainer tree Same as 3/6 — part of the same v5 series accepted by Bjorn Andersson
5/6 ✅ ACKed — merged into maintainer tree "Applied, thanks!" found in lore thread for v6 DT series
6/6 ⏳ Decision Pending Posted Sep 10, 2026 (5 days ago); Sashiko AI review on Sep 10; Konrad Dybcio replied Sep 11; no maintainer acceptance/rejection yet

Dependency Check

  • ✅ Commits 3-5 (UPSTREAM) have no missing dependencies — all prerequisite patches from their respective series are either already in qcom-next or included in this PR.
  • ⚠️ Commit 6/6 (FROMLIST) declares a dependency on the crypto driver patch series (v6) — this dependency is not included in this PR. The commit message states: "patch series [1] takes care of the resource voting from the crypto driver side."

qcom-next / topics Presence

Per integration_presence_report.md:

Commit qcom-next topics Final Status
1/6 (Revert) missing missing ❌ missing
2/6 (Revert) missing missing ❌ missing
3/6 (UPSTREAM) present skipped ✅ present
4/6 (UPSTREAM) present skipped ✅ present
5/6 (UPSTREAM) present (exact patch-id match at dd2dd19d8ad3) skipped ✅ present
6/6 (FROMLIST) partial present (exact patch-id match at 5ed31c2650950) ✅ present

Overall: 4/6 commits present in qcom-next/topics; 2/6 (reverts) missing.

Issues Found

  1. Commits 1-2 (Reverts) missing from qcom-next/topics
    The two revert commits are not present in qcom-next or topics. This is expected for reverts of internal commits that were never upstreamed — they exist only in the vendor tree to clean up the v2 FROMLIST series before applying the UPSTREAM v5 series.
    Impact: Low — reverts are internal housekeeping; the net effect (UPSTREAM v5 patches) is present in qcom-next.

  2. Commit 6/6 (FROMLIST) has unmet dependency
    The commit message references a prerequisite crypto driver patch series (v6) that is not included in this PR. The commit states: "patch series [1] takes care of the resource voting from the crypto driver side" and warns that "dropping the proxy votes will impact the bootup" without it.
    Impact: Medium — merging this PR without the crypto driver dependency may cause boot failures on Shikra if the crypto driver relies on proxy votes.

  3. Commit 6/6 (FROMLIST) not yet accepted upstream
    The patch was posted on Sep 10, 2026 (5 days ago) and is still under review. No maintainer has issued an acceptance or rejection decision yet.
    Impact: Low — the patch is present in the topics branch (5ed31c2650950), indicating it has been integrated into the Qualcomm kernel workflow. However, the FROMLIST: prefix is correct since it has not been merged into mainline.

Recommendation

Merge with caution — address dependency concern before merging to production.

Rationale:

  • Commits 1-5 are clean: reverts are justified, and UPSTREAM patches are faithful to their lore sources and have been accepted by the maintainer.
  • Commit 6/6 is technically correct (matches lore, present in topics) but has an unmet dependency on the crypto driver patch series. Verify that the crypto driver patches are either (a) already merged into the target branch, or (b) included in a separate PR that will be merged before this one.
  • If the crypto driver dependency is satisfied, this PR is safe to merge.
  • If not, either (a) include the crypto driver patches in this PR, or (b) defer merging commit 6/6 until the dependency is resolved.

Final Summary

  1. Lore link present: Yes — commits 3-6 have lore links; commits 1-2 are reverts (no lore link expected)
  2. Lore link matches PR commits: Yes — all 4 commits with lore links (3-6) are faithful to their upstream sources; diff content is identical
  3. Upstream patch status:
    • Commits 3-5: ✅ ACKed — merged by Bjorn Andersson (Jul 8, 2026) and DT maintainer
    • Commit 6: ⏳ Decision Pending — posted Sep 10, 2026; under review; no maintainer decision yet
  4. PR present in qcom-next/topics: Partial — 4/6 commits present; 2/6 (reverts) missing (expected for internal reverts)

Deterministic Integration Presence

Integration Presence Report

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

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

Commit Subject qcom-next topics Final
1/6 [PATCH 1/6] Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
2/6 [PATCH 2/6] Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
3/6 [PATCH 3/6] UPSTREAM: clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
4/6 [PATCH 4/6] UPSTREAM: dt-bindings: clock: qcom,rpmcc: Add Qualcomm present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
5/6 [PATCH 5/6] UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node present - exact patch-id match at dd2dd19 skipped - not checked because qcom-next already contains the change present
6/6 [PATCH 6/6] FROMLIST: clk: qcom: smd-rpm: Skip proxy votes on clocks partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 5ed31c2650950dc0d15bacf1c4f6d37d3ef95e54 present

Final Status

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

@qlijarvis

qlijarvis commented Sep 15, 2026

Copy link
Copy Markdown

PR #1076 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ❌ 3 issues: 2 missing Signed-off-by, 1 long line
dt-binding-check ✅ Passed
dtb-check ✅ Passed
sparse-check ✅ Passed
check-uapi-headers ✅ Passed (no UAPI changes)
check-patch-compliance ❌ 4 issues: 2 missing prefix, 1 content mismatch, 1 author mismatch
tag-check ❌ 2 commits missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1076 - Revert and re-apply Shikra RPMCC patches
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34486122977
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ❌ 3 issues: 2 missing Signed-off-by, 1 long line
dt-binding-check ✅ Passed
dtb-check ✅ Passed
sparse-check ✅ Passed
check-uapi-headers ✅ Passed (no UAPI changes)
check-patch-compliance ❌ 4 issues: 2 missing prefix, 1 content mismatch, 1 author mismatch
tag-check ❌ 2 commits missing required prefix

❌ checkpatch

Root cause: Two revert commits are missing Signed-off-by: trailers, and one commit has a line exceeding 100 characters.

Failure details:

Commit c27f38aec001 ("Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"")
ERROR: Missing Signed-off-by: line(s)

Commit 2c88c19a9713 ("Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"")
ERROR: Missing Signed-off-by: line(s)

Commit 613b53fb4e2e ("UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node")
WARNING: line length of 109 exceeds 100 columns
#24: FILE: arch/arm64/boot/dts/qcom/shikra.dtsi:381:
+					compatible = "qcom,rpmcc-shikra", "qcom,rpmcc-qcm2290", "qcom,rpmcc";

Fix:

For commits 1 and 2 (missing Signed-off-by):

git rebase -i 1ca2821f5ed0   # mark commits c27f38aec001 and 2c88c19a9713 as 'edit'
# For each commit:
git commit --amend --signoff --no-edit
git rebase --continue

For commit 5 (long line):

git rebase -i 1ca2821f5ed0   # mark commit 613b53fb4e2e as 'edit'
# Edit arch/arm64/boot/dts/qcom/shikra.dtsi:381 to wrap the compatible line:
#   compatible = "qcom,rpmcc-shikra",
#                "qcom,rpmcc-qcm2290", "qcom,rpmcc";
git add arch/arm64/boot/dts/qcom/shikra.dtsi
git commit --amend --no-edit
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1ca2821f5ed0..90970b94091e

❌ check-patch-compliance

Root cause: Two revert commits lack the required prefix before Revert, one commit has content differences from its upstream link, and one commit has an author mismatch.

Failure details:

Checking commit: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
Commit summary does not start with a required prefix

Checking commit: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"
Commit summary does not start with a required prefix

Checking commit: UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
  Commit author : Imran Shaik <imran.shaik@oss.qualcomm.com>

Fix:

Issue 1 & 2 — Missing prefix on Revert commits:

Revert commits must carry a prefix before the word Revert. Since these are reverting FROMLIST: patches that were previously applied, the correct prefix is UPSTREAM: (if the original patches were merged upstream) or FROMLIST: (if they're still pending).

git rebase -i 1ca2821f5ed0   # mark commits 1 and 2 as 'reword'
# Change subjects to:
#   UPSTREAM: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
#   UPSTREAM: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

Issue 3 — Content mismatch (commit 5):

The patch content differs from the upstream link. Verify the differences:

b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260612-shikra-dt-v6-2-6b6cb58db477@oss.qualcomm.com -o /tmp/out
git format-patch -1 613b53fb4e2e --stdout > /tmp/pr-patch.txt
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch.txt | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

If the differences are legitimate adaptations (e.g., context changes due to tree state), document them in the commit message. If they're unintended, revert and re-apply the correct patch.

Issue 4 — Author mismatch (commit 5):

The upstream patch author is Komal Bajaj <komal.bajaj@oss.qualcomm.com>, but the commit author is Imran Shaik <imran.shaik@oss.qualcomm.com>.

git rebase -i 1ca2821f5ed0   # mark commit 613b53fb4e2e as 'edit'
git commit --amend --author="Komal Bajaj <komal.bajaj@oss.qualcomm.com>" --no-edit
git rebase --continue

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . \
  --base 1ca2821f5ed0 --head 90970b94091e

❌ tag-check

Root cause: Two commits (the Revert commits) do not start with a required subject-line prefix tag.

Failure details:

The PR targets qcom-6.18.y, which is not qcom-next or qcom-next-staging. Therefore, every commit must start its subject line with one of the required prefix tags:

  • FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

Commits missing prefix:

  1. Commit 1: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
    → Subject starts with Revert, not a valid prefix.

  2. Commit 2: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"
    → Subject starts with Revert, not a valid prefix.

Fix:

Add a prefix before Revert:

git rebase -i 1ca2821f5ed0   # mark commits 1 and 2 as 'reword'
# Change subjects to:
#   UPSTREAM: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
#   UPSTREAM: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

Choose the correct prefix based on the revert's origin:

  • If reverting an upstream-merged patch → UPSTREAM:
  • If reverting a patch still on the mailing list → FROMLIST:

Note: This is the same fix as check-patch-compliance Issue 1 & 2 — applying that fix will also resolve tag-check.

Verdict

3 blockers must be fixed before merge:

  1. checkpatch: Add Signed-off-by: to commits 1 and 2; wrap long line in commit 5.
  2. check-patch-compliance: Add prefix to Revert commits (1 & 2); fix author mismatch in commit 5; verify content differences in commit 5.
  3. tag-check: Add prefix to Revert commits (1 & 2) — same fix as check-patch-compliance.

Recommended action sequence:

git rebase -i 1ca2821f5ed0

# Mark commits 1, 2 as 'reword' → change subjects to:
#   UPSTREAM: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
#   UPSTREAM: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

# Mark commits 1, 2 as 'edit' → add Signed-off-by:
git commit --amend --signoff --no-edit
git rebase --continue

# Mark commit 5 as 'edit' → fix author, wrap long line, verify content
git commit --amend --author="Komal Bajaj <komal.bajaj@oss.qualcomm.com>"
# Edit shikra.dtsi to wrap the compatible line
git add arch/arm64/boot/dts/qcom/shikra.dtsi
git commit --amend --no-edit
git rebase --continue

After fixing, re-run checkpatch and check-patch-compliance locally to verify all issues are resolved.

@qlijarvis

qlijarvis commented Sep 15, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #1076

Job 222682 | SoC qcs615-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort during USB DMA
  1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA
  2. Root cause: Synchronous external abort (ESR 0x96000010) during USB device enumeration when xhci-hcd attempted to copy USB descriptor data via swiotlb bounce buffer. The crash occurred in __pi_memcpy_generic while copying from physical address 0x103215ca0 to swiotlb buffer 0x7ffbf000, indicating a hardware bus fault when accessing the source physical address during DMA mapping for a low-speed USB device (device number 2) on the qcs615-ride platform.
  3. Possible fix: This is a hardware/platform-specific issue unrelated to the PR changes (which only modify Shikra RPMCC clock bindings and drivers). The PR does not touch USB, DMA, SWIOTLB, or IOMMU subsystems. Recommended actions: (1) Verify USB device hardware compatibility with qcs615-ride; (2) Check if the physical address 0x103215ca0 falls within valid DRAM ranges for this SoC; (3) Enable CONFIG_IOMMU_DEBUGFS and CONFIG_SWIOTLB_DYNAMIC_DEBUG to capture detailed DMA mapping logs; (4) Re-run the test without the external USB device to confirm the kernel boots successfully; (5) If issue persists, collect SMMU register dumps and check for IOMMU mapping issues specific to the xhci controller on qcs615.
  4. Detail analysis attachment: failed_case_job222682_1_detailed.md
  Case 2: Kernel Crash — Synchronous External Abort during USB enumeration
  1. Failed case: Kernel Crash — Synchronous External Abort during USB enumeration
  2. Root cause: Hardware bus error (synchronous external abort ESR=0x96000010) triggered during DMA memory copy operation (__pi_memcpy_generic) in the SWIOTLB bounce buffer path while enumerating a USB device on the qcs615-ride platform. The crash occurred at ~8.2 seconds into boot when the xHCI USB host controller attempted to map a URB for DMA, indicating either a hardware fault (bad memory region, power/clock issue affecting the USB/DMA subsystem) or a platform-specific IOMMU/SWIOTLB configuration issue on qcs615-ride.
  3. Possible fix: This is a pre-existing platform/hardware issue unrelated to the PR (which only modifies RPMCC clock driver code). Recommended actions: (1) Verify USB host controller power/clock configuration in the qcs615-ride device tree; (2) Check SWIOTLB buffer allocation and IOMMU domain configuration for the xHCI controller; (3) Verify hardware health of the qcs615-ride board (memory integrity, power rails); (4) If reproducible, collect ramdump to inspect the faulting physical address and SMMU/NOC state; (5) Re-run the test on a known-good qcs615-ride board to rule out hardware failure.
  4. Detail analysis attachment: failed_case_job222682_2_detailed.md
  Case 3: Kernel Crash — Synchronous External Abort (USB DMA)
  1. Failed case: Kernel Crash — Synchronous External Abort (USB DMA)
  2. Root cause: Synchronous external abort (ESR 0x96000010) during USB device enumeration when xHCI driver attempted DMA mapping via SWIOTLB bounce buffer copy (__pi_memcpy_generic). The fault occurred at ~8 seconds into boot while probing a low-speed USB device (1-1), indicating a hardware bus fault or IOMMU/memory subsystem issue during DMA buffer access on qcs615-ride.
  3. Possible fix: This is a pre-existing platform/hardware issue unrelated to PR Shikra rpmcc latest changes #1076 (which only reverts Shikra RPMCC clock driver changes). The crash is reproducible on qcs615-ride and requires platform-level investigation: (1) verify IOMMU configuration and SMMU mappings for USB controller (0xa800000), (2) check for NOC/interconnect errors in full logs, (3) validate SWIOTLB buffer allocation and physical address ranges, (4) test with iommu.passthrough=1 or swiotlb=noforce kernel parameters to isolate the fault domain. Re-trigger the CI job to confirm reproducibility; if consistent, escalate to qcs615 platform team for hardware/firmware investigation.
  4. Detail analysis attachment: failed_case_job222682_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: Synchronous external abort (memory access fault) at 8.2 seconds into boot during USB low-speed device enumeration; fault occurred in __pi_memcpy_generic while copying to swiotlb bounce buffer (address 0x103215ca0) during xhci-hcd DMA mapping for USB device descriptor fetch on qcs615-ride.
  3. Possible fix: This is a hardware-level memory access fault during USB DMA operations. Immediate action: disable USB host controller in device tree or kernel config to allow boot to complete. Root fix requires investigation of: (1) IOMMU/SMMU configuration for USB controller on qcs615, (2) swiotlb buffer allocation and mapping correctness, (3) USB DMA address translation setup. The PR changes (Shikra RPMCC clock driver removal) are unrelated to USB/DMA subsystems and did not introduce this failure — this is a pre-existing platform issue or a regression from an unrelated kernel change.
  4. Detail analysis attachment: failed_case_job222682_4_detailed.md
Job 222683 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Four SPMI PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state on lemans-evk, indicating a missing or not-yet-probed dependency (likely thermal zone or IIO ADC provider). The regulatory.db firmware load failure is a known benign false positive (faux_driver is a test/placeholder driver). The Bluetooth firmware load failures are suppressed per Rule 3 (BT_ON_OFF test passed, confirming Bluetooth is functional).
  3. Possible fix: Investigate the temp-alarm driver's dependencies on lemans-evk: check if the required thermal zone or IIO ADC provider is present in the device tree and whether its driver is built and loaded. If the dependency is missing from the DT, add it; if the driver is not built, enable the corresponding kernel config. The test should also be updated to suppress the known benign regulatory.db firmware failure from faux_driver.
  4. Detail analysis attachment: failed_case_job222683_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Video codec device (aa00000.video-codec) on lemans-evk is not attached to any IOMMU group, failing the SMMU test's critical master protection check. The test verified 61 IOMMU groups exist and other critical masters (USB, Display) are properly protected, but the video codec device lacks the required iommu-map or iommus DT property to bind it to an IOMMU group.
  3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/lemans.dtsi (or lemans-evk.dts) to bind the video codec to an appropriate IOMMU group, following the pattern used for other critical masters on this SoC.
  4. Detail analysis attachment: failed_case_job222683_2_detailed.md
  Case 3: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: Two distinct driver probe issues on lemans-evk: (1) Four PMIC temp-alarm devices stuck in deferred probe state (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00), and (2) Video codec device (aa00000.video-codec) missing IOMMU group attachment, causing smmu test failure. These are pre-existing platform issues unrelated to the PR's clock driver changes.
  3. Possible fix: These failures are not introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings and driver code). The temp-alarm deferred probes and video codec IOMMU attachment issue are pre-existing lemans-evk platform configuration problems. No action required on this PR; track platform issues separately in lemans-evk DT/driver enablement work.
  4. Detail analysis attachment: failed_case_job222683_3_detailed.md
Job 222684 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: The Probe_Failure_Check test detected 5 probe/firmware errors in dmesg that are pre-existing platform-specific issues on purwa-evk (Purwa IoT EVK), unrelated to the PR's RPMCC changes for Shikra SoC. The failures are: (1) qcom_qseecom_uefisecapp -EBUSY, (2-3) two qcom-pcie instances -ENODATA, (4) qcom-spmi-lpg -EINVAL, and (5) regulatory.db firmware -ENOENT.
  3. Possible fix: These probe failures are not introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC bindings and driver code, not purwa-evk). The test should either: (1) suppress known benign probe failures for purwa-evk in the test's allowlist, or (2) investigate each failure independently as platform bring-up issues (QSEECOM secure app unavailable, PCIe endpoints not connected, LPG PWM DT mismatch, regulatory.db firmware missing from rootfs).
  4. Detail analysis attachment: failed_case_job222684_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Six devices on purwa-evk are missing IOMMU group attachments: five USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec device (aa00000.video-codec). The SMMU test validates that critical platform devices are protected by IOMMU, and these devices are not bound to any IOMMU group despite being enumerated in the device tree.
  3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR Shikra rpmcc latest changes #1076 (which only modifies RPMCC clock bindings for Shikra SoC). The missing IOMMU attachments indicate either: (1) the device tree nodes for these devices lack iommus properties, or (2) the corresponding drivers do not probe successfully, preventing IOMMU binding. Verify the device tree for purwa-evk includes iommus properties for USB PHY nodes at addresses 0xa0f8800, 0xa2f8800, 0xa4f8800, 0xa6f8800, 0xa8f8800 and video codec at 0xaa00000, and confirm the drivers for these devices probe successfully during boot.
  4. Detail analysis attachment: failed_case_job222684_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: Purwa IoT EVK platform does not provide EL2 (Hypervisor mode) access to the kernel; KVM initialization reports "HYP mode not available" and does not create /dev/kvm device node.
  3. Possible fix: This is expected behavior on platforms without virtualization support or where EL2 is reserved by secure firmware. Either: (1) exclude KVM tests from the Purwa EVK test suite, or (2) enable EL2 access in the platform firmware/bootloader if the SoC supports virtualization extensions.
  4. Detail analysis attachment: failed_case_job222684_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM initialization failed because HYP mode is not available — the platform is running under the Gunyah hypervisor which prevents KVM from accessing EL2, as evidenced by the kernel message "kvm [1]: HYP mode not available" and the Gunyah hypervisor boot banner "Hypervisor cold boot, version: gunyah-mobile-c487961e9".
  3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by the PR. The purwa-evk board is configured to run with the Gunyah hypervisor at EL2, which prevents KVM from initializing. To enable KVM testing on this platform, either: (1) disable the Gunyah hypervisor in the firmware/bootloader configuration to allow Linux to run at EL2, or (2) exclude KVM tests from the CI test suite for platforms that run under a hypervisor, or (3) use a different test platform that does not have a hypervisor enabled.
  4. Detail analysis attachment: failed_case_job222684_4_detailed.md
  Case 5: KVM_Infra — KVM initialization blocked by hypervisor
  1. Failed case: KVM_Infra — KVM initialization blocked by hypervisor
  2. Root cause: Gunyah hypervisor is active and occupying EL2 (Hypervisor mode), preventing KVM from initializing. KVM requires exclusive EL2 access to provide virtualization, but Gunyah is already using EL2 for protected VM management. This is an architectural constraint on ARM64 where only one entity can control EL2.
  3. Possible fix: This is not a bug but a platform configuration choice. To enable KVM on purwa-evk: (1) Disable Gunyah hypervisor in the boot configuration (bootloader/device tree), or (2) Exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) Add a test gate that skips KVM tests when a hypervisor is detected at boot (check for "Hypervisor cold boot" or "HYP mode not available" in dmesg).
  4. Detail analysis attachment: failed_case_job222684_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM initialization failed during kernel boot because the Purwa IoT EVK platform does not support ARM Virtualization Extensions (EL2/HYP mode). The kernel message "kvm [1]: HYP mode not available" at boot time indicates the hardware lacks the required virtualization support, preventing /dev/kvm device node creation.
  3. Possible fix: This is a hardware platform limitation, not a kernel regression. The Purwa EVK does not support KVM virtualization. Either: (1) Skip KVM tests on Purwa EVK in the CI test matrix, or (2) Run KVM tests only on platforms with virtualization support (e.g., boards with EL2 enabled in firmware/bootloader). Update the LAVA job definition to exclude KVM test suite for purwa-evk target.
  4. Detail analysis attachment: failed_case_job222684_6_detailed.md
Job 222685 | SoC shikra-iqs-evk

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

Failed test cases in LAVA job 222685 (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: Revert the skip_clks_handoff = true flag for Shikra in patch 6/6, or implement a more targeted approach that identifies and maintains proxy votes only for clocks critical to boot (PCIe, interconnect, and other early-boot hardware). The original intent was to prevent XO shutdown blocking in idle scenarios, but the implementation is too aggressive and breaks boot. Consider using runtime PM or late_initcall to clear non-critical clock votes after boot completes, rather than skipping all proxy votes unconditionally.
  4. Detail analysis attachment: failed_case_job222685_1_detailed.md
  Case 2: Board Hang — System stopped producing output during boot
  1. Failed case: Board Hang — System stopped producing output during boot
  2. Root cause: PR introduces skip_clks_handoff = true for QCM2290 RPMCC (patch 6/6), and Shikra now uses QCM2290 as fallback compatible (patch 5/6). This skips proxy votes on RPM clocks during handoff, causing critical clocks required by PCIe and other subsystems to be turned off prematurely. The system hangs at 7.3 seconds during PCIe probe when hardware access fails due to clock gating.
  3. Possible fix: Revert patch 6/6 (skip_clks_handoff change) or explicitly exclude Shikra from the skip_clks_handoff behavior by checking the primary compatible string. Alternatively, ensure all critical clocks for Shikra boot (PCIe, interconnect, etc.) have explicit consumers that vote for them before the handoff is skipped.
  4. Detail analysis attachment: failed_case_job222685_2_detailed.md
  Case 3: Complete System Hang — minimal-boot login timeout
  1. Failed case: Complete System Hang — minimal-boot login timeout
  2. Root cause: System hung completely after kernel boot at ~7.3 seconds (last message: PCIe probe retries), preventing login prompt from appearing; LAVA login-action timed out after 3 retry attempts (total ~10 minutes) with no console response to '#' prompts, indicating total loss of forward progress on shikra-iqs-evk after userspace init started.
  3. Possible fix: This is a genuine system hang requiring root-cause investigation. Immediate action: re-trigger the LAVA job to confirm reproducibility. If reproducible, enable additional debug (early_printk, initcall_debug, ignore_loglevel) and collect SDI/ramdump to capture CPU state at hang time. Check for known issues with PCIe driver probe loops or init hangs on shikra-iqs-evk. The PR reverts Shikra RPMCC changes to use QCM2290 fallback — verify clock dependencies for critical boot-path devices (serial console, timers, schedulers) are not affected by the RPMCC revert.
  4. Detail analysis attachment: failed_case_job222685_3_detailed.md
  Case 4: System Hang During Boot — PCIe Initialization Loop
  1. Failed case: System Hang During Boot — PCIe Initialization Loop
  2. Root cause: The qcom-pcie driver (45e8000.pcie) is stuck in an infinite probe retry loop during early boot on shikra-iqs-evk; kernel messages show repeated "supply vdda not found, using dummy regulator" and "host bridge ranges" messages at 5.1s, 5.2s, 5.3s, 7.1s, 7.2s, 7.3s with no forward progress, preventing the system from reaching userspace login prompt and causing LAVA login-action timeout after 200 seconds.
  3. Possible fix: This is a pre-existing kernel/platform issue unrelated to PR Shikra rpmcc latest changes #1076 (which only modifies clock bindings); disable or blacklist the qcom-pcie driver for shikra-iqs-evk in the device tree (set status = "disabled" for the pcie@45e8000 node) or kernel config to allow boot to complete, then investigate the root cause of the PCIe probe failure (missing regulators, incorrect DT configuration, or driver bug).
  4. Detail analysis attachment: failed_case_job222685_4_detailed.md
Job 222686 | SoC qcs9100-ride

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Three pre-existing platform configuration issues on qcs9100-ride: (1) four PMIC temp-alarm devices stuck in deferred probe due to missing thermal zone bindings in DT, (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property (error -22 / -EINVAL), and (3) regulatory.db firmware file not present in rootfs (error -2 / -ENOENT, benign). None of these issues are related to the PR's clock driver changes for Shikra/QCM2290.
  3. Possible fix: Update Probe_Failure_Check test to suppress known benign failures for qcs9100-ride (temp-alarm deferred probe, regulatory.db missing). For proper platform fix: add thermal zone bindings for PMIC temp sensors to qcs9100-ride DT, add firmware-name property to Aquantia PHY DT node or patch driver to treat missing property as non-fatal, and optionally add regulatory.db to rootfs firmware directory.
  4. Detail analysis attachment: failed_case_job222686_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test expects video codec device aa00000.video-codec to be attached to an IOMMU group, but this device does not exist or is not enabled in the device tree for qcs9100-ride (LeMans) platform — the device never probes during boot and is absent from all kernel logs.
  3. Possible fix: Update the SMMU test's critical master list for qcs9100-ride to exclude aa00000.video-codec, or enable the video codec device in the qcs9100-ride device tree if video codec hardware is present on this SoC.
  4. Detail analysis attachment: failed_case_job222686_2_detailed.md
  Case 3: ** USBHost (Test Environment Configuration Issue)
  1. Failed case: ** USBHost (Test Environment Configuration Issue)
  2. Root cause: ** The USBHost test expects at least one functional USB device (keyboard, mouse, storage, etc.) to be physically connected to the qcs9100-ride board's USB ports, but only USB root hubs are present (Bus 001, 002, 003 Device 001). The USB host controller hardware and drivers are functioning correctly; no external USB peripherals are connected to the test board.
  3. Possible fix: This is not a kernel regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies clock bindings for Shikra SoC, unrelated to USB or qcs9100). To resolve: (1) Connect a functional USB device (e.g., USB flash drive, keyboard) to one of the board's USB ports before running the test, OR (2) Mark this test as SKIP for boards in the lab that do not have USB peripherals permanently attached, OR (3) Update the test to distinguish between "USB subsystem broken" (genuine failure) vs "no USB devices connected" (expected/benign for some lab configurations).
  4. Detail analysis attachment: failed_case_job222686_3_detailed.md
  Case 4: Ethernet_Basic_Validation
  1. Failed case: Ethernet_Basic_Validation
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is a pre-existing platform/DT configuration issue on qcs9100-ride, not introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra SoC clock bindings). Add the required firmware-name property to the Aquantia PHY device tree node for qcs9100-ride, or mark this test as expected-fail for this platform until the DT is corrected.
  4. Detail analysis attachment: failed_case_job222686_4_detailed.md
  Case 5: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM cannot initialize because the qcs9100-ride platform does not support ARM Hypervisor (EL2/HYP) mode — kernel reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The KVM test should be skipped on qcs9100-ride (LeMans) targets that do not have virtualization extensions enabled. Add platform detection to the test suite to skip KVM tests when CONFIG_KVM is enabled but /dev/kvm is absent due to "HYP mode not available".
  4. Detail analysis attachment: failed_case_job222686_5_detailed.md
  Case 6: KVM_EL2_DTB — KVM device node unavailable (platform configuration issue)
  1. Failed case: KVM_EL2_DTB — KVM device node unavailable (platform configuration issue)
  2. Root cause: The qcs9100-ride platform firmware boots Linux in EL1 (non-secure supervisor mode) without enabling EL2 (hypervisor mode), causing KVM initialization to fail with "HYP mode not available" at boot. CONFIG_KVM is enabled in the kernel but /dev/kvm cannot be created because the CPU is not running at EL2.
  3. Possible fix: This is a platform firmware/bootloader configuration issue, not a kernel regression. The qcs9100-ride board requires firmware that boots Linux at EL2 or enables VHE (Virtualization Host Extensions) to support KVM. No kernel changes are needed. Mark this test as "expected fail" for qcs9100-ride until firmware is updated to enable EL2 mode.
  4. Detail analysis attachment: failed_case_job222686_6_detailed.md
  Case 7: KVM Infrastructure Test Failure — Platform Limitation
  1. Failed case: KVM Infrastructure Test Failure — Platform Limitation
  2. Root cause: qcs9100-ride platform runs under Gunyah hypervisor which occupies EL2/HYP mode; KVM cannot initialize because EL2 is unavailable (message: "kvm [1]: HYP mode not available" at boot). This is expected behavior on hypervisor-hosted platforms.
  3. Possible fix: Exclude KVM tests from the qcs9100-ride test suite, as this platform does not support KVM due to Gunyah hypervisor occupying EL2. Alternatively, configure the test to skip KVM tests when /dev/kvm is not present (test infrastructure improvement).
  4. Detail analysis attachment: failed_case_job222686_7_detailed.md
  Case 8: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM/virtualization not available on qcs9100-ride (Lemans) platform — kernel reports "HYP mode not available" during boot, preventing /dev/kvm device creation despite CONFIG_KVM being enabled.
  3. Possible fix: This is a platform hardware/firmware limitation, not a PR-introduced regression. The PR changes only affect Shikra RPMCC clock bindings and have no impact on KVM/hypervisor availability. Mark KVM tests as "skip" or "not applicable" for qcs9100-ride platform in the LAVA test suite configuration, or verify that the board firmware/bootloader is configured to boot the kernel in EL2 (hypervisor mode) rather than EL1.
  4. Detail analysis attachment: failed_case_job222686_8_detailed.md
Job 222687 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Two pre-existing probe failures detected during boot: (1) Aquantia AQR115C Ethernet PHY driver failed to probe with error -22 (EINVAL) due to missing firmware-name property in device tree, and (2) cfg80211 regulatory database firmware file (regulatory.db) not found in filesystem (error -2 / ENOENT). Both failures occurred at boot time (timestamp 10-11 seconds) and are unrelated to the PR changes (PR only modifies Shikra RPMCC clock bindings and driver code).
  3. Possible fix: These are pre-existing platform configuration issues on qcs8300-ride, not regressions introduced by PR Shikra rpmcc latest changes #1076. (1) For Aquantia PHY: add firmware-name property to the stmmac-0:08 PHY node in qcs8300-ride device tree, or update the PHY driver to make firmware-name optional if the PHY can operate without custom firmware. (2) For regulatory.db: install wireless-regdb package in the rootfs image or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB if regulatory enforcement is not required for this test platform.
  4. Detail analysis attachment: failed_case_job222687_1_detailed.md
  Case 2: ** USBHost
  1. Failed case: ** USBHost
  2. Root cause: ** Test infrastructure issue — no physical USB device connected to the qcs8300-ride board. The kernel USB subsystem is fully functional (xHCI host controller initialized, USB 2.0 root hub detected with 1 port), but the test expects a functional USB device beyond the root hub. Only Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub is present.
  3. Possible fix: Connect a functional USB device (e.g., USB flash drive, keyboard, or mouse) to the qcs8300-ride board's USB port before running the USBHost test. This is a lab hardware configuration issue, not a kernel or PR-related regression.
  4. Detail analysis attachment: failed_case_job222687_2_detailed.md
  Case 3: Ethernet_Basic_Validation — PHY Driver Probe Failure
  1. Failed case: Ethernet_Basic_Validation — PHY Driver Probe Failure
  2. Root cause: Aquantia AQR115C PHY driver probe failed during boot with error -22 (EINVAL) due to missing firmware-name property in device tree; when the qcom-ethqos Ethernet MAC driver later attempts to bring up eth0, phylink validation of 2500base-x mode fails because the PHY is not attached, resulting in "cannot attach to PHY (error: -EINVAL)".
  3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs8300-ride device tree (arch/arm64/boot/dts/qcom/qcs8300-ride*.dts*); the property should specify the path to the AQR115C firmware file (typically "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld" or similar) that must be present in /lib/firmware/.
  4. Detail analysis attachment: failed_case_job222687_3_detailed.md
  Case 4: KVM_Driver — /dev/kvm device node not created
  1. Failed case: KVM_Driver — /dev/kvm device node not created
  2. Root cause: KVM driver failed to initialize at boot despite CONFIG_KVM=y being enabled; no KVM initialization messages appear in kernel boot log, indicating silent initialization failure likely due to missing hardware virtualization support (EL2/VHE) or platform-specific restrictions on QCS8300 Ride board.
  3. Possible fix: Verify that the QCS8300 SoC and board firmware support ARM virtualization extensions (EL2/VHE) and that the bootloader is not disabling EL2. If virtualization is not supported on this platform, mark KVM tests as "not applicable" for QCS8300 in the CI test matrix. If virtualization should be supported, check bootloader configuration and ensure the kernel is booted at EL2 (not EL1).
  4. Detail analysis attachment: failed_case_job222687_4_detailed.md
  Case 5: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: QCS8300 Ride platform runs as a Gunyah hypervisor guest (EL1), not as a hypervisor host (EL2). KVM requires EL2 (Hyp mode) to function; when the kernel runs as a guest VM under Gunyah, it cannot access EL2, so KVM initialization is skipped and /dev/kvm is never created.
  3. Possible fix: This is a platform architectural limitation, not a bug. KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) should be skipped on platforms running as Gunyah guests. Add a test gate to check for Gunyah guest mode (presence of gunyah-md-region in device tree or absence of EL2 access) and skip KVM tests accordingly.
  4. Detail analysis attachment: failed_case_job222687_5_detailed.md
  Case 6: ** KVM Infrastructure Test Failure — /dev/kvm unavailable
  1. Failed case: ** KVM Infrastructure Test Failure — /dev/kvm unavailable
  2. Root cause: ** QCS8300 (Monaco) SoC does not support KVM/ARM virtualization extensions; the hardware lacks EL2 hypervisor mode support or EL2 is reserved/disabled by firmware, preventing KVM driver initialization despite CONFIG_KVM being enabled in the kernel configuration.
  3. Possible fix: Mark KVM tests as "not applicable" for QCS8300 platform in the LAVA test suite configuration; alternatively, disable CONFIG_KVM in the QCS8300 defconfig since the hardware does not support virtualization.
  4. Detail analysis attachment: failed_case_job222687_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM subsystem failed to initialize during boot on qcs8300-ride platform — CONFIG_KVM is enabled but /dev/kvm device node was never created, with no KVM initialization messages in kernel log, indicating KVM driver did not probe or was silently disabled due to missing hardware virtualization support or incompatible boot configuration (arm64.nopauth in cmdline may interact with KVM requirements).
  3. Possible fix: Verify that the qcs8300 SoC supports hardware virtualization (EL2/VHE) and that the bootloader/firmware enables it; check if arm64.nopauth kernel parameter conflicts with KVM initialization; if KVM is expected to work on this platform, investigate why kvm_init() was not called or why it failed silently without logging; if KVM is not supported on qcs8300-ride, mark these tests as expected-to-skip for this platform in the CI configuration.
  4. Detail analysis attachment: failed_case_job222687_7_detailed.md
Job 222688 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC (Test Script Bug — Not a Kernel Issue)
  1. Failed case: GIC (Test Script Bug — Not a Kernel Issue)
  2. Root cause: The GIC test script incorrectly attempts to validate timer interrupt counts for offline CPUs (6-7) by parsing /proc/interrupts, which only contains columns for online CPUs (0-5). The script's awk/cut logic extracts the string "GICv3" instead of a numeric value for offline CPUs, causing a bash integer comparison error at line 75. The kernel and GIC hardware are functioning correctly — all online CPUs (0-5) show incrementing timer interrupts, and the subsequent hotplug test passed for all controllable CPUs.
  3. Possible fix: Update the GIC test script (run.sh line 75) to skip validation for CPUs that are not in the online CPU list, or modify the parsing logic to handle /proc/interrupts output where the number of columns matches the number of online CPUs rather than possible CPUs. The test should query /sys/devices/system/cpu/online before attempting to validate each CPU's interrupt count.
  4. Detail analysis attachment: failed_case_job222688_1_detailed.md
  Case 2: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Two pre-existing firmware files are missing from the target filesystem: (1) regulatory.db for cfg80211 wireless regulatory subsystem (optional, benign — WiFi functional tests passed), and (2) renesas_usb_fw.mem for an external PCIe Renesas USB 3.0 controller (optional add-on hardware, not required for core functionality). Both failures are -ENOENT (file not found) errors during firmware loading, not driver bugs or PR-introduced regressions.
  3. Possible fix: Install the missing firmware files in the target rootfs: (1) Add regulatory.db from the wireless-regdb package to /lib/firmware/ (optional — suppresses the warning but does not affect WiFi functionality), and (2) Add renesas_usb_fw.mem from the linux-firmware package to /lib/firmware/ if the external Renesas USB controller is intended to be used. Alternatively, update the Probe_Failure_Check test to suppress these two known benign firmware load failures for qcs6490-rb3gen2, as they do not indicate kernel regressions and the affected hardware/features remain functional.
  4. Detail analysis attachment: failed_case_job222688_2_detailed.md
  Case 3: Freq_Scaling
  1. Failed case: Freq_Scaling
  2. Root cause: Test script logic error — the Freq_Scaling test expects 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 has only 6 CPUs (cpu0-cpu5). The test incorrectly reports PASS for cpu6 (which doesn't exist) then fails when checking for cpu7, displaying the generic error "CPUFreq interface not found. Test Failed".
  3. Possible fix: Update the Freq_Scaling test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /sys/devices/system/cpu/present instead of hardcoding a fixed CPU count. The test should iterate only over CPUs that actually exist on the target platform.
  4. Detail analysis attachment: failed_case_job222688_3_detailed.md
  Case 4: USBHost — Firmware Dependency Failure
  1. Failed case: USBHost — Firmware Dependency Failure
  2. Root cause: The Renesas USB 3.0 host controller (xhci-pci-renesas 0001:04:00.0) failed to probe because the required firmware file renesas_usb_fw.mem is missing from the root filesystem, preventing USB host controller initialization and causing zero USB devices to be enumerated.
  3. Possible fix: Add the linux-firmware package (or specifically the renesas_usb_fw.mem firmware file) to the Yocto/build image recipe for qcs6490-rb3gen2. The firmware is available in the upstream linux-firmware repository and must be included in /lib/firmware/ on the target filesystem.
  4. Detail analysis attachment: failed_case_job222688_4_detailed.md
  Case 5: KVM_Driver (Test Environment Limitation — Platform lacks EL2/HYP support)
  1. Failed case: KVM_Driver (Test Environment Limitation — Platform lacks EL2/HYP support)
  2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not support ARM EL2 (Hypervisor mode), which is a mandatory hardware prerequisite for KVM. The kernel correctly detected this limitation during KVM initialization and reported "HYP mode not available" at boot time (line 2963). The test failure is expected behavior on this platform.
  3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as "skip" or "not applicable" for qcs6490-rb3gen2 in the LAVA test suite configuration. These tests should only run on platforms with EL2 support (e.g., platforms with ARM Cortex-A cores that support virtualization extensions and firmware/bootloader configured to boot Linux at EL2).
  4. Detail analysis attachment: failed_case_job222688_5_detailed.md
  Case 6: KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because Gunyah hypervisor owns EL2 (Hypervisor Exception Level), preventing KVM from entering HYP mode required for ARM64 virtualization.
  3. Possible fix: This is a platform architecture limitation, not a bug. On platforms running Gunyah (or any Type-1 hypervisor), KVM cannot function because both require exclusive EL2 access. To enable KVM testing: (1) boot without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use a different test platform that boots Linux directly at EL2 without a hypervisor.
  4. Detail analysis attachment: failed_case_job222688_6_detailed.md
  Case 7: ** KVM_Infra — Platform Limitation (HYP mode not available)
  1. Failed case: ** KVM_Infra — Platform Limitation (HYP mode not available)
  2. Root cause: ** The qcs6490-rb3gen2 platform does not support ARM EL2 (Hypervisor mode), which is required for KVM virtualization. The kernel KVM driver correctly detected this limitation during initialization and reported "HYP mode not available", preventing /dev/kvm device node creation.
  3. Possible fix: This is not a kernel bug or PR-introduced regression. Update the LAVA test definition to check for HYP mode availability before running KVM tests: add a pre-flight check that skips KVM tests with status "SKIP" (not "FAIL") when dmesg | grep -q "HYP mode not available" returns true, or exclude KVM tests entirely from the qcs6490-rb3gen2 test suite.
  4. Detail analysis attachment: failed_case_job222688_7_detailed.md
  Case 8: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM driver detected HYP (EL2) mode is not available on qcs6490-rb3gen2 platform. The firmware/bootloader does not enable EL2 for Linux, preventing KVM initialization. This is a platform capability limitation, not a kernel bug or PR-introduced regression.
  3. Possible fix: Skip KVM tests on qcs6490-rb3gen2 in the LAVA job definition, as this board does not support virtualization. If KVM support is required, update the board firmware/bootloader to boot Linux at EL2 and configure TrustZone to permit EL2 access.
  4. Detail analysis attachment: failed_case_job222688_8_detailed.md
Job 222689 | SoC monaco-evk

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

Failed test cases in LAVA job 222689 (SoC: monaco-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: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). This is a rootfs/build configuration issue, not a kernel regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings and is unrelated to Monaco WiFi).
  4. Detail analysis attachment: failed_case_job222689_1_detailed.md
  Case 2: WiFi_Firmware_Driver
  1. Failed case: WiFi_Firmware_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the missing WCN6855 nfa765 variant firmware files to the Monaco EVK root filesystem image. The firmware package should include ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board data files. Verify the firmware is available in the linux-firmware repository or Qualcomm's firmware distribution, then update the Yocto/build recipe to include these files in the qcom-multimedia-image-iq-8275-evk image.
  4. Detail analysis attachment: failed_case_job222689_2_detailed.md
  Case 3: WiFi_OnOff — Driver Probe Failure
  1. Failed case: WiFi_OnOff — Driver Probe Failure
  2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up timeout during WCN6855 WiFi chip initialization.
  3. Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/), or if the firmware path is incorrect, verify the correct board-specific firmware variant for monaco-evk and update the firmware package accordingly.
  4. Detail analysis attachment: failed_case_job222689_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: WiFi driver (ath11k_pci) probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2: ENOENT), causing MHI power-up timeout (error -110: ETIMEDOUT). This is a pre-existing infrastructure/firmware packaging issue, not introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings and drivers).
  3. Possible fix: Install the missing WiFi firmware package for WCN6855 hardware (nfa765 variant) in the rootfs image used by LAVA CI. The firmware should be placed at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin. Verify the linux-firmware package version includes this variant, or add it to the Yocto/build recipe if building a custom rootfs.
  4. Detail analysis attachment: failed_case_job222689_4_detailed.md
Job 222690 | SoC hamoa-evk

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

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

  Case 1: ** Probe_Failure_Check
  1. Failed case: ** Probe_Failure_Check
  2. Root cause: ** Three pre-existing platform-specific probe failures unrelated to PR changes: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to TrustZone resource conflict, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED device tree "reg" property configuration, (3) regulatory.db firmware file missing from rootfs (-ENOENT).
  3. Possible fix: These are pre-existing platform issues not introduced by this PR (PR only modifies RPMCC clock bindings/driver). Suppress these known hamoa-evk platform probe failures in the Probe_Failure_Check test baseline, or fix individually: (1) verify TZ firmware compatibility for QSEECOM UEFI SecApp, (2) correct the multi-LED "reg" property in hamoa-evk device tree PMIC node, (3) add regulatory.db to the rootfs image.
  4. Detail analysis attachment: failed_case_job222690_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Six USB DWC3 controller instances (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and one video codec instance (aa00000.video-codec) on hamoa-evk are not attached to IOMMU groups, failing the SMMU test's critical master protection validation despite SMMU hardware being functional and 35 other devices being correctly protected.
  3. Possible fix: Add missing iommus properties to the device tree nodes for the six USB DWC3 instances at addresses 0xa0f8800, 0xa2f8800, 0xa4f8800, 0xa6f8800, 0xa8f8800 and the video codec at 0xaa00000 in arch/arm64/boot/dts/qcom/x1e80100.dtsi (or the hamoa-specific overlay), referencing the appropriate SMMU phandle and stream IDs for hamoa-evk platform.
  4. Detail analysis attachment: failed_case_job222690_2_detailed.md
  Case 3: KVM_Driver — /dev/kvm device node missing
  1. Failed case: KVM_Driver — /dev/kvm device node missing
  2. Root cause: KVM driver initialization failed because the Hamoa IoT EVK platform is not running in EL2 (hypervisor mode). The kernel boot log shows kvm [1]: HYP mode not available at boot time, indicating the CPU is running in EL1 (kernel mode) without hypervisor support enabled in the boot chain.
  3. Possible fix: This is a pre-existing platform configuration issue, not a regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings and drivers). The Hamoa IoT EVK board requires bootloader/firmware configuration to enable EL2 mode for KVM support. Either: (1) update the bootloader/ABL to boot the kernel in EL2 mode, or (2) exclude KVM tests from the Hamoa EVK test suite as this platform does not support virtualization in its current configuration.
  4. Detail analysis attachment: failed_case_job222690_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: Kernel booted at Exception Level 1 (EL1) instead of EL2 (hypervisor mode), preventing KVM initialization. The boot log shows "CPU: All CPU(s) started at EL1" and KVM reports "HYP mode not available" at initialization, causing /dev/kvm device node creation to fail. This is a platform/firmware boot configuration issue on hamoa-evk (x7181), not a kernel regression.
  3. Possible fix: Configure the bootloader/firmware (UEFI/ABL) on hamoa-evk to boot the kernel at EL2 instead of EL1. This requires updating the boot chain configuration to enable hypervisor mode entry. Alternatively, if EL2 boot is not supported on this platform, mark KVM tests as expected-to-fail for hamoa-evk in the LAVA test suite configuration.
  4. Detail analysis attachment: failed_case_job222690_4_detailed.md
  Case 5: KVM_Infra — Platform Limitation (KVM requires EL2, system running at EL1 under Gunyah hypervisor)
  1. Failed case: KVM_Infra — Platform Limitation (KVM requires EL2, system running at EL1 under Gunyah hypervisor)
  2. Root cause: Hamoa EVK is running Linux as a guest VM under the Gunyah hypervisor at Exception Level 1 (EL1). KVM requires Exception Level 2 (EL2/HYP mode) to provide virtualization services. The kernel message "kvm [1]: HYP mode not available" confirms KVM initialization failed because the CPU is not running in hypervisor mode, making /dev/kvm unavailable.
  3. Possible fix: This is a platform configuration issue, not a kernel bug. KVM tests should be skipped on platforms running under a hypervisor (Gunyah/protected VMs). Add platform detection logic to the test suite to skip KVM tests when dmesg | grep "HYP mode not available" or when running under Gunyah. Alternatively, run these tests on bare-metal Hamoa configurations where Linux boots at EL2.
  4. Detail analysis attachment: failed_case_job222690_5_detailed.md
  Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is not a kernel bug. If KVM/virtualization is required on Hamoa EVK, update the bootloader (ABL/UEFI) configuration to boot the kernel in EL2. If virtualization is not a requirement for this IoT platform, suppress the KVM_Infra test for Hamoa EVK in the LAVA test suite configuration.
  4. Detail analysis attachment: failed_case_job222690_6_detailed.md

@qcomlnxci

qcomlnxci commented Sep 16, 2026

Copy link
Copy Markdown

Test jobs on 6c563f5

@qcomlnxci

qcomlnxci commented Sep 16, 2026

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ❌ Fail
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ❌ Fail
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ❌ Fail
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 ⚠️ skip ❌ Fail ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail ✅ 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 ✅ 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 ✅ 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

@sgaud-quic
Salendarsingh Gaud (sgaud-quic) merged commit b15f7bd into qualcomm-linux:qcom-6.18.y Sep 16, 2026
6 of 8 checks passed
@qlijarvis

qlijarvis commented Sep 16, 2026

Copy link
Copy Markdown

PR #1076 — validate-patch

PR: #1076

Verdict Issues Detailed Report
❌ 0 Full report

Final Summary

  1. Lore link present: Yes for commits 3-6 (UPSTREAM/FROMLIST); No for commits 1-2 (reverts — no lore link expected or required)
  2. Lore link matches PR commits: Yes — all UPSTREAM/FROMLIST commits match their lore sources exactly (diff content, commit message, authorship all verified)
  3. Upstream patch status: Commits 3-5: ✅ ACKed and merged by Bjorn Andersson; Commit 6: ⏳ Decision Pending (posted Sep 10, 2026, under review)
  4. PR present in qcom-next/topics: Fail - 2/6 commit(s) are missing from both qcom-next and topics
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1076 - Revert Shikra RPMCC v2 and update with UPSTREAM version using QCM2290 fallback compatible
Upstream commits: Multiple lore.kernel.org links (see per-commit analysis)
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream ✅ All UPSTREAM/FROMLIST commits match lore subjects
Body preserves rationale ✅ Key rationale preserved in all commits
Fixes tag present/correct ✅ Commit 6/6 has correct Fixes tag
Authorship preserved ✅ All commits authored by Imran Shaik, matches lore
Backport note (if applicable) N/A No backports, only UPSTREAM/FROMLIST

Diff

File Status Notes
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml ✅ Commit 4/6 matches lore v5 patch 1/4 exactly
drivers/clk/qcom/clk-smd-rpm.c (commit 3) ✅ Commit 3/6 matches lore v5 patch 3/4 exactly
drivers/clk/qcom/clk-smd-rpm.c (commit 6) ✅ Commit 6/6 matches lore v1 patch exactly
arch/arm64/boot/dts/qcom/shikra.dtsi ✅ Commit 5/6 matches lore v6 patch 2/5 exactly

Issues

Critical Issues (❌ FAIL):

  1. Commits 1-2 (Revert commits) missing from integration - The two revert commits are not present in qcom-next or topics branches. Per the validate-patch skill Step 10 requirement, all PR commits must be present in qcom-next or topics before merge. The integration_presence_report.md shows:

    • Commit 1/6: missing - no subject, patch-id, or full tree-content match found
    • Commit 2/6: missing - no subject, patch-id, or full tree-content match found

    These reverts are internal operations that undo previous FROMLIST commits. They have no upstream lore link (which is expected for reverts), but they must still be present in the integration branch before the PR can be merged.

Warnings (⚠️):

  1. Commit 6/6 prefix inconsistency - Commit is marked FROMLIST: but integration_presence_report.md shows it is already present in the topics branch with exact patch-id match at 5ed31c2650950dc0d15bacf1c4f6d37d3ef95e54. Once a patch lands in a maintainer tree (topics), the prefix should be updated to FROMGIT: or UPSTREAM: to reflect its current status.

Upstream Patch Status

Commit Community Verdict
3/6 - clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 ✅ ACKed — part of v5 series accepted by Bjorn Andersson on Jul 8, 2026; multiple Reviewed-by tags
4/6 - dt-bindings: clock: qcom,rpmcc ✅ ACKed — Applied by Bjorn Andersson on Jul 8, 2026 as commit 01cf3e2; Reviewed-by: Krzysztof Kozlowski
5/6 - arm64: dts: qcom: shikra: Update RPMCC node ✅ ACKed — Applied as commits 62eaf92 and 14a9b4b
6/6 - clk: qcom: smd-rpm: Skip proxy votes ⏳ Decision Pending — posted Sep 10, 2026 (6 days ago); no merge/NAK signals yet; very recent submission

Verdict

Do not merge - Two critical issues must be resolved:

  1. Missing revert commits in integration - Commits 1/6 and 2/6 (the revert commits) are not present in qcom-next or topics. All PR commits must be in the integration branch before merge. These reverts need to be applied to qcom-next first, or the PR needs to be restructured to exclude them if they're not needed in the integration flow.

  2. Commit 6/6 prefix - Update FROMLIST: to FROMGIT: or UPSTREAM: since the patch is already in the topics branch.

The UPSTREAM commits (3-5) are correctly formatted, match their lore sources exactly, and have been accepted upstream. Commit 6 matches its lore source but is still pending upstream decision (posted 6 days ago).

Final Summary

  1. Lore link present: Yes for commits 3-6 (UPSTREAM/FROMLIST); No for commits 1-2 (reverts — no lore link expected or required)
  2. Lore link matches PR commits: Yes — all UPSTREAM/FROMLIST commits match their lore sources exactly (diff content, commit message, authorship all verified)
  3. Upstream patch status: Commits 3-5: ✅ ACKed and merged by Bjorn Andersson; Commit 6: ⏳ Decision Pending (posted Sep 10, 2026, under review)
  4. PR present in qcom-next/topics: Fail — 2/6 commits (the revert commits 1-2) are missing from both qcom-next and topics; commits 3-5 present in qcom-next; commit 6 present in topics

Deterministic Integration Presence

Integration Presence Report

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

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

Commit Subject qcom-next topics Final
1/6 [PATCH 1/6] Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
2/6 [PATCH 2/6] Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
3/6 [PATCH 3/6] UPSTREAM: clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
4/6 [PATCH 4/6] UPSTREAM: dt-bindings: clock: qcom,rpmcc: Add Qualcomm present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
5/6 [PATCH 5/6] UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node present - exact patch-id match at dd2dd19 skipped - not checked because qcom-next already contains the change present
6/6 [PATCH 6/6] FROMLIST: clk: qcom: smd-rpm: Skip proxy votes on clocks partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 5ed31c2650950dc0d15bacf1c4f6d37d3ef95e54 present

Final Status

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

@qlijarvis

qlijarvis commented Sep 16, 2026

Copy link
Copy Markdown

PR #1076 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ⚠️ 1 warning: line length exceeds 100 chars
dt-binding-check ✅ Passed
dtb-check ✅ Passed
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 3 failures: 2 missing prefix on Revert commits, 1 content/author mismatch
tag-check ❌ 2 commits missing required prefix before "Revert"

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1076 - Shikra RPMCC and QCM2290 clock updates
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34964288957

Checker Result Summary
checkpatch ⚠️ 1 warning: line length exceeds 100 chars
dt-binding-check ✅ Passed
dtb-check ✅ Passed
sparse-check ✅ Passed
check-uapi-headers ✅ Passed
check-patch-compliance ❌ 3 failures: 2 missing prefix on Revert commits, 1 content/author mismatch
tag-check ❌ 2 commits missing required prefix before "Revert"

❌ checkpatch

Root cause: Line length exceeds 100 characters in DTS compatible string.

Failure details:

Commit 3982f5be67aa ("UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node")
WARNING: line length of 109 exceeds 100 columns
#24: FILE: arch/arm64/boot/dts/qcom/shikra.dtsi:381:
+					compatible = "qcom,rpmcc-shikra", "qcom,rpmcc-qcm2290", "qcom,rpmcc";

Fix: Wrap the compatible string across multiple lines:

git rebase -i <base_sha>   # mark commit 3982f5be67aa as 'edit'
# Edit arch/arm64/boot/dts/qcom/shikra.dtsi:381 to wrap the line:
					compatible = "qcom,rpmcc-shikra",
						     "qcom,rpmcc-qcm2290",
						     "qcom,rpmcc";
git add arch/arm64/boot/dts/qcom/shikra.dtsi
git commit --amend --no-edit
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..3982f5be67aa

❌ check-patch-compliance

Root cause: Two Revert commits lack required prefix before "Revert", and one commit has content/author mismatch with upstream.

Failure details:

Issue 1 & 2: Missing prefix on Revert commits

Checking commit: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
Commit summary does not start with a required prefix

Checking commit: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"
Commit summary does not start with a required prefix

Commits:

  • 0d81461eefd8 - Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
  • b312b67fcb60 - Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

Issue 3: Content and author mismatch

Checking commit: UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
  Commit author : Imran Shaik <imran.shaik@oss.qualcomm.com>

Commit: 3982f5be67aa - UPSTREAM: arm64: dts: qcom: shikra: Update RPMCC node

Fix:

For Issue 1 & 2 (Revert commits):

git rebase -i <base_sha>
# Mark commits 0d81461eefd8 and b312b67fcb60 as 'reword'
# Change subjects to:
UPSTREAM: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
UPSTREAM: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"
git rebase --continue

For Issue 3 (content/author mismatch):

# First, verify the content difference:
b4 am --single-message -C -l -3 <link-from-commit-message> -o /tmp/upstream
git format-patch -1 3982f5be67aa --stdout > /tmp/pr-patch
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')

# If content is legitimately different (e.g., context adaptation), document it in commit message
# Fix author:
git rebase -i <base_sha>   # mark commit 3982f5be67aa as 'edit'
git commit --amend --author="Komal Bajaj <komal.bajaj@oss.qualcomm.com>"
git rebase --continue

Reproduce locally:

cd kernel-checkers
./check-patch-compliance.sh <base_sha> <head_sha>

❌ tag-check

Root cause: Two Revert commits do not start with a required prefix tag.

Failure details:

The PR targets branch qcom-6.18.y, which is not qcom-next or qcom-next-staging. Therefore, every commit must start with a valid prefix tag.

The following commits are missing a prefix before "Revert":

  1. Commit 0d81461
    Subject: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
    ❌ Missing prefix before "Revert"

  2. Commit b312b67
    Subject: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"
    ❌ Missing prefix before "Revert"

Fix:

Revert commits must themselves carry a prefix tag before the word "Revert". Choose the appropriate prefix based on where the revert originated:

git rebase -i <base_sha>
# Mark commits 0d81461eefd8 and b312b67fcb60 as 'reword'

# Change subjects to (choose appropriate prefix):
UPSTREAM: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
UPSTREAM: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

# Or if the revert itself is from a mailing list:
FROMLIST: Revert "FROMLIST: dt-bindings: clock: qcom,rpmcc: Add Qualcomm Shikra SoC RPMCC"
FROMLIST: Revert "FROMLIST: clk: qcom: smd-rpm: Add support for RPM clocks on Qualcomm Shikra SoC"

git rebase --continue

Valid prefix tags:

  • FROMLIST: - Patch posted to mailing list
  • FROMGIT: - Patch from maintainer git tree
  • UPSTREAM: - Patch merged into Linus's mainline
  • BACKPORT: - Upstream patch backported with modifications
  • QCLINUX: - Vendor-only change
  • PENDING: - Work-in-progress
  • WORKAROUND: - Temporary fix

Note: This is the same issue flagged by check-patch-compliance. Fixing the prefix will resolve both failures.

Verdict

3 blockers must be fixed before merge:

  1. Checkpatch warning (non-blocking but should fix): Wrap long line in arch/arm64/boot/dts/qcom/shikra.dtsi:381
  2. Missing prefix on Revert commits (blocking): Add UPSTREAM: or FROMLIST: prefix before "Revert" on commits 0d81461eefd8 and b312b67fcb60
  3. Author mismatch (blocking): Fix author on commit 3982f5be67aa to match upstream author Komal Bajaj <komal.bajaj@oss.qualcomm.com>
  4. Content mismatch (investigate): Verify if commit 3982f5be67aa content legitimately differs from upstream; if so, document the adaptation in the commit message

Priority: Fix the Revert commit prefixes and author mismatch first (blocking issues), then address the checkpatch line length warning and investigate the content mismatch.

@qlijarvis

qlijarvis commented Sep 16, 2026

Copy link
Copy Markdown

LAVA Failed Case Triage Summary

PR: #1076

Job 227667 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Test detected two genuine probe failures on qcs9100-ride: (1) Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state, likely due to missing thermal zone bindings or IIO channel dependencies; (2) Aquantia AQR115C Ethernet PHY (stmmac-0:08) probe failed with -EINVAL due to missing or malformed firmware-name property in device tree. The regulatory.db firmware load failure is benign (cfg80211 falls back to built-in regulatory rules). These are pre-existing platform issues unrelated to the PR's Shikra RPMCC clock changes.
  3. Possible fix: For temp-alarm deferred probes: verify qcs9100-ride device tree includes thermal-zones with correct phandle references to the PMIC temp-alarm nodes, and confirm qcom-spmi-temp-alarm driver dependencies (IIO channels, nvmem cells) are satisfied. For Aquantia PHY: add or correct the firmware-name property in the stmmac-0:08 PHY node in qcs9100-ride.dtsi to point to a valid Aquantia firmware file path, or remove the property if firmware loading is not required for this PHY configuration.
  4. Detail analysis attachment: failed_case_job227667_1_detailed.md
  Case 2: ** smmu (test expectation failure — not a kernel crash or SMMU fault)
  1. Failed case: ** smmu (test expectation failure — not a kernel crash or SMMU fault)
  2. Root cause: ** The SMMU test script checks that critical master device aa00000.video-codec (Venus video codec) is attached to an IOMMU group. On qcs9100-ride, this device either (1) is not present in the device tree, (2) lacks iommus property binding, or (3) failed to probe, resulting in no IOMMU group attachment. The test script treats this as a failure even though the kernel booted successfully, SMMU is functional (54 IOMMU groups present, no SMMU errors in dmesg), and all other critical masters (UFS, Display, Ethernet, GPU, USB) are correctly protected.
  3. Possible fix: Verify the qcs9100-ride device tree includes the aa00000.video-codec node with correct iommus property. If the device is intentionally disabled or not present on this board variant, update the SMMU test script's critical master list to exclude aa00000.video-codec for qcs9100-ride, or mark it as optional. If the device should be present, check for probe deferral or missing dependencies (clocks, regulators, firmware) preventing the video codec driver from probing.
  4. Detail analysis attachment: failed_case_job227667_2_detailed.md
  Case 3: USBHost (Test Infrastructure Issue — No External USB Devices Connected)
  1. Failed case: USBHost (Test Infrastructure Issue — No External USB Devices Connected)
  2. Root cause: The USBHost test expects functional USB devices to be physically connected to the qcs9100-ride board but only USB root hubs are present (Bus 001, 002, 003 Device 001: Linux Foundation root hubs), indicating no external USB devices are plugged into any USB port. The kernel USB subsystem is functioning correctly (xhci-hcd driver loaded, 3 USB buses enumerated, IOMMU protection active), but the test fails because it requires at least one non-hub USB device for validation.
  3. Possible fix: This is not a kernel regression. The test failure is caused by missing test hardware. Recommended actions: (1) Connect a USB device (e.g., USB flash drive, keyboard, or mouse) to one of the qcs9100-ride USB ports before running the test suite, OR (2) Update the USBHost test logic to SKIP (rather than FAIL) when only root hubs are detected and no external devices are available, OR (3) Document this as a known limitation for boards without permanently attached USB peripherals and suppress this failure in CI when hardware is unavailable.
  4. Detail analysis attachment: failed_case_job227667_3_detailed.md
  Case 4: Ethernet_Basic_Validation
  1. Failed case: Ethernet_Basic_Validation
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the firmware-name device tree property to the Aquantia AQR115C PHY node under the stmmac-0 MDIO bus in arch/arm64/boot/dts/qcom/qcs9100-ride.dts (or the appropriate qcs9100 board DTS file), specifying the correct Aquantia firmware file path (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld"; or the appropriate firmware for this PHY revision).
  4. Detail analysis attachment: failed_case_job227667_4_detailed.md
  Case 5: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM cannot initialize on qcs9100-ride because the board is running Gunyah hypervisor (not KVM/Linux-native EL2), preventing KVM from accessing EL2 (HYP mode). The kernel message "kvm [1]: HYP mode not available" at boot confirms KVM detected it cannot run under the current hypervisor configuration.
  3. Possible fix: This is not a regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies clock drivers). KVM tests are expected to fail on qcs9100-ride when Gunyah hypervisor is active. Either: (1) exclude KVM tests from qcs9100-ride CI runs when Gunyah is enabled, or (2) configure the board to boot without Gunyah if KVM testing is required.
  4. Detail analysis attachment: failed_case_job227667_5_detailed.md
  Case 6: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM initialization failed because HYP (EL2) mode is not available on qcs9100-ride (Lemans Ride Rev3) platform — the kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running in a virtualization-capable mode, preventing /dev/kvm device node creation.
  3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (PR Shikra rpmcc latest changes #1076 only modifies Shikra RPMCC clock bindings/drivers, unrelated to KVM/virtualization). KVM requires EL2 hypervisor support which is either disabled in firmware/bootloader or not supported by the qcs9100-ride hardware configuration. To enable KVM: (1) verify the platform supports virtualization extensions, (2) ensure bootloader/firmware boots Linux at EL2 or enables nested virtualization, (3) check if Gunyah hypervisor configuration conflicts with KVM (log shows "non-Gunyah hypervisor" but Gunyah-based bootup), (4) if this is expected behavior for this platform, mark KVM tests as not applicable for qcs9100-ride in the CI test matrix.
  4. Detail analysis attachment: failed_case_job227667_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 a platform architecture limitation, not a kernel bug. KVM and Gunyah are mutually exclusive — only one can run at EL2. To enable KVM on qcs9100-ride, the platform must be configured to boot without Gunyah (requires bootloader/firmware changes to disable Gunyah and allow Linux to run at EL2). Alternatively, mark KVM tests as "not applicable" for Gunyah-based platforms in the CI test matrix.
  4. Detail analysis attachment: failed_case_job227667_7_detailed.md
  Case 8: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: Platform does not support EL2 (hypervisor mode) - kernel reports "HYP mode not available" at boot, preventing /dev/kvm device creation. This is a hardware/firmware limitation of the qcs9100-ride platform, not a kernel regression.
  3. Possible fix: Skip KVM tests on qcs9100-ride platform in the LAVA test definition, as this SoC does not support virtualization. Add platform detection logic to the test suite to automatically skip KVM tests when EL2 is unavailable.
  4. Detail analysis attachment: failed_case_job227667_8_detailed.md
Job 227668 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k_pci probe timeout
  1. Failed case: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k_pci probe timeout
  2. Root cause: ath11k_pci PCIe WiFi driver probe failed with -ETIMEDOUT (-110) during MHI firmware load for WCN6855 hw2.1 on monaco-evk; firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from rootfs, causing MHI initialization timeout. Bluetooth firmware failures (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) are benign as BT_ON_OFF test passed. regulatory.db failure is benign (cfg80211 falls back to built-in regulatory rules).
  3. Possible fix: Add missing WiFi firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin and board file) to the rootfs firmware directory (/lib/firmware/). The firmware package linux-firmware-ath11k or equivalent Qualcomm WiFi firmware package must be installed in the Yocto image recipe or copied manually to the target rootfs.
  4. Detail analysis attachment: failed_case_job227668_1_detailed.md
  Case 2: WiFi_Firmware_Driver
  1. Failed case: WiFi_Firmware_Driver
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the missing ath11k WCN6855 firmware files to the monaco-evk rootfs image. The required firmware path is ath11k/WCN6855/hw2.1/nfa765/amss.bin (and associated board/regdb files). This is a rootfs packaging issue, not a kernel regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings and has no impact on Monaco WiFi).
  4. Detail analysis attachment: failed_case_job227668_2_detailed.md
  Case 3: WiFi_OnOff — ath11k_pci driver probe failure
  1. Failed case: WiFi_OnOff — ath11k_pci driver probe failure
  2. Root cause: The ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the MHI firmware load failed (mhi mhi0: Direct firmware load for ath11k/WCN6855/hw2.1/nfa765/amss.bin failed with error -2), causing the MHI power-up sequence to timeout. This is a pre-existing firmware packaging issue unrelated to the PR changes (which only modify Shikra RPMCC clock bindings and driver code).
  3. Possible fix: Ensure the WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is present in the rootfs /lib/firmware/ directory. If the firmware is packaged under a different board variant path, add a symlink or update the ath11k driver's firmware search path for the monaco-evk board configuration.
  4. Detail analysis attachment: failed_case_job227668_3_detailed.md
  Case 4: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: Pre-existing WiFi driver probe failure on monaco-evk due to missing WCN6855 firmware files in the rootfs image. The ath11k_pci driver probe timed out (-ETIMEDOUT, error -110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is not present in the filesystem, preventing MHI initialization and WiFi hardware bringup.
  3. Possible fix: Add the missing WCN6855 firmware files to the monaco-evk rootfs image. Install the linux-firmware package or manually copy the required files from linux-firmware.git: ath11k/WCN6855/hw2.1/nfa765/amss.bin, ath11k/WCN6855/hw2.1/nfa765/m3.bin, and board data files. This is a rootfs/image build issue, not a kernel regression introduced by PR Shikra rpmcc latest changes #1076.
  4. Detail analysis attachment: failed_case_job227668_4_detailed.md
Job 227669 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Five driver probe failures detected during boot on purwa-evk (Shikra SoC): (1) qcom_qseecom_uefisecapp failed with -EBUSY due to secure world resource conflict, (2) two qcom-pcie instances (1bf8000, 1bd0000) failed with -ENODATA due to PHY power-on failure indicating missing/unpopulated PCIe slots, (3) qcom-spmi-lpg failed with -EINVAL due to invalid multi-LED device tree "reg" property, and (4) regulatory.db firmware missing (-ENOENT) which is a known benign WiFi regulatory database issue. These are pre-existing platform-specific hardware limitations and device tree configuration issues, not regressions introduced by PR Shikra rpmcc latest changes #1076 (which only updates RPMCC clock bindings).
  3. Possible fix: Suppress this test failure as "known platform limitations" — the probe failures are expected on purwa-evk hardware where PCIe slots are unpopulated (no endpoint devices), QSEECOM secure app conflicts with firmware configuration, and LPG multi-LED DT node has incorrect binding. The PR changes (RPMCC clock updates) do not affect these subsystems. To eliminate false positives, update the Probe_Failure_Check test to exclude known-benign probe failures for purwa-evk: add platform-specific suppression rules for qcom-pcie -ENODATA (unpopulated slots), qcom_qseecom_uefisecapp -EBUSY (secure world config), qcom-spmi-lpg -EINVAL (DT binding issue), and regulatory.db -ENOENT (optional firmware).
  4. Detail analysis attachment: failed_case_job227669_1_detailed.md
  Case 2: SMMU Test — Missing IOMMU Group Attachments
  1. Failed case: SMMU Test — Missing IOMMU Group Attachments
  2. Root cause: Six critical DMA masters (five USB controllers and one video codec) on purwa-evk are not attached to any IOMMU group, indicating missing or incomplete device tree iommus properties for these devices, which violates the platform's SMMU protection requirements.
  3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video codec aa00000.video-codec in the purwa-evk device tree, referencing the appropriate SMMU instance and stream IDs.
  4. Detail analysis attachment: failed_case_job227669_2_detailed.md
  Case 3: ** KVM_Driver (Platform Capability Limitation — KVM Unavailable)
  1. Failed case: ** KVM_Driver (Platform Capability Limitation — KVM Unavailable)
  2. Root cause: ** KVM initialization failed because HYP (EL2) mode is not available to the Linux kernel on the purwa-evk platform. The Gunyah hypervisor is running at EL2 and has not delegated nested virtualization capability to the kernel. Boot log shows: kvm [1]: HYP mode not available at timestamp 5.779536s. CONFIG_KVM is enabled but cannot create /dev/kvm device node without EL2 access.
  3. Possible fix: This is a known platform limitation, not a regression. The purwa-evk with Gunyah hypervisor does not support nested virtualization (KVM running under a hypervisor). To enable KVM: (1) Boot without the Gunyah hypervisor (native EL2 mode), OR (2) Wait for Gunyah hypervisor to implement nested virtualization support (VHE - Virtualization Host Extensions), OR (3) Exclude KVM tests from the purwa-evk test suite as this platform is not expected to support KVM. The PR (clock driver changes for Shikra SoC) is unrelated to this failure.
  4. Detail analysis attachment: failed_case_job227669_3_detailed.md
  Case 4: KVM_EL2_DTB (Pre-existing Platform Limitation)
  1. Failed case: KVM_EL2_DTB (Pre-existing Platform Limitation)
  2. Root cause: The purwa-evk platform does not support KVM virtualization because the bootloader boots the kernel at EL1 (kernel mode) instead of EL2 (hypervisor mode), resulting in "HYP mode not available" during KVM initialization and the absence of /dev/kvm device node.
  3. Possible fix: This is not a kernel bug or PR regression. To enable KVM on purwa-evk: (1) verify hardware supports ARM virtualization extensions, (2) configure bootloader/firmware to boot kernel at EL2 or enable EL2 access, (3) if hardware does not support virtualization, mark KVM tests as "not applicable" for this platform in CI configuration.
  4. Detail analysis attachment: failed_case_job227669_4_detailed.md
  Case 5: 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: Purwa EVK platform does not support EL2 (hypervisor mode); KVM initialization fails with "HYP mode not available" at boot, preventing /dev/kvm device node creation.
  3. Possible fix: Exclude KVM tests from Purwa EVK CI pipeline as this platform lacks hardware/firmware support for virtualization (EL2). If EL2 support is expected, verify bootloader/firmware configuration enables hypervisor mode and check if SoC variant supports virtualization extensions.
  4. Detail analysis attachment: failed_case_job227669_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM infrastructure test failed because the Purwa EVK platform does not support KVM virtualization — the kernel detected "HYP mode not available" at boot, preventing creation of /dev/kvm device node despite CONFIG_KVM being enabled.
  3. Possible fix: Mark KVM_Infra test as expected-fail or skip for purwa-evk platform in the LAVA test suite configuration, as this SoC/board does not boot with EL2/HYP mode enabled and cannot support KVM virtualization.
  4. Detail analysis attachment: failed_case_job227669_6_detailed.md
Job 227670 | SoC shikra-iqs-evk

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

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

  Case 1: http-download
  1. Failed case: http-download
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Re-trigger the CI job. If the issue recurs, investigate network connectivity between the LAVA worker and AWS S3 us-west-2 region (check for bandwidth throttling, packet loss, or firewall issues). As a temporary mitigation, increase the http-download timeout from 2398s (00:39:58) to 3600s (01:00:00) in the LAVA job definition to allow completion of slow downloads.
  4. Detail analysis attachment: failed_case_job227670_1_detailed.md
  Case 2: ** Build Load Failure — HTTP download timeout
  1. Failed case: ** Build Load Failure — HTTP download timeout
  2. Root cause: ** Result: Build Load Failure. The HTTP download of the 976 MB build artifact (qcom-multimedia-image-shikra-evk.rootfs.qcomflash.tar.gz) from AWS S3 stalled at 55% progress (536 MB transferred) and timed out after 2398 seconds. The error type Infrastructure indicates a LAVA worker network issue, not a problem with the build artifact or PR changes.
  3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2398s (~40min) to 3600s (60min) and the download-retry block timeout from 00:40:00 to 01:00:00 in the LAVA job definition. Additionally, investigate network path stability between the LAVA worker and AWS S3 (us-west-2 region) — check for bandwidth throttling, packet loss, or intermittent connectivity issues on the worker node.
  4. Detail analysis attachment: failed_case_job227670_2_detailed.md
  Case 3: ** Build Load Failure — HTTP download timeout
  1. Failed case: ** Build Load Failure — HTTP download timeout
  2. Root cause: ** Result: Build Load Failure. The HTTP download of the 976 MB build artifact (qcom-multimedia-image-shikra-evk.rootfs.qcomflash.tar.gz) from AWS S3 stalled at 55% (536 MB) and timed out after 2398 seconds. The LAVA worker's network connection to AWS S3 us-west-2 experienced sustained degradation or interruption mid-transfer, preventing completion within the 40-minute timeout window. This is a LAVA infrastructure issue (error_type: Infrastructure), not a kernel or build problem.
  3. Possible fix: Re-trigger the CI job. If the issue recurs, increase the http-download action timeout from 2398s (~40min) to 3600s (60min) in the LAVA job definition to accommodate slow/unstable network paths to AWS S3. Additionally, investigate the LAVA worker's network connectivity to AWS S3 us-west-2 region — check for bandwidth throttling, packet loss, or routing issues between the lab and S3.
  4. Detail analysis attachment: failed_case_job227670_3_detailed.md
  Case 4: ** Build Load Failure — HTTP download timeout
  1. Failed case: ** Build Load Failure — HTTP download timeout
  2. Root cause: ** Result: Build Load Failure. The LAVA dispatcher's HTTP download action timed out after 2398 seconds (39 minutes 58 seconds) while downloading a 976 MB build artifact from AWS S3. The download stalled at 55% (536 MB) and did not complete within the configured 40-minute timeout. This is a LAVA infrastructure issue, not a kernel or PR-introduced regression.
  3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2398s (~40min) to 3600s (60min) and the download-retry block timeout from 00:40:00 to 01:00:00 in the LAVA job definition to accommodate the large artifact size and potential network variability between the LAVA worker and AWS S3.
  4. Detail analysis attachment: failed_case_job227670_4_detailed.md
Job 227671 | SoC qcs615-ride

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

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

  Case 1: smmu (Test Validation Failure — Video Codec Child Device IOMMU Group Expectation)
  1. Failed case: smmu (Test Validation Failure — Video Codec Child Device IOMMU Group Expectation)
  2. Root cause: The smmu test expects video-decoder and video-encoder child devices of aa00000.video-codec to have individual IOMMU group attachments, but the qcom-venus driver uses a non-legacy binding where only the parent device (aa00000.video-codec) is attached to IOMMU group 7. The child devices (video-decoder, video-encoder) are V4L2 video device nodes created by the driver, not separate platform devices requiring IOMMU attachment.
  3. Possible fix: Update the smmu test validation logic to recognize that qcom-venus "non legacy binding" creates V4L2 video device children that inherit IOMMU protection from the parent device, rather than requiring separate IOMMU group attachments. The test should pass if the parent video-codec device is properly attached to an IOMMU group.
  4. Detail analysis attachment: failed_case_job227671_1_detailed.md
  Case 2: BT_FW_KMD_Service (Bluetooth Driver Initialization Failure)
  1. Failed case: BT_FW_KMD_Service (Bluetooth Driver Initialization Failure)
  2. Root cause: WCN6855 Bluetooth hardware on qcs615-ride fails to respond to HCI initialization commands with repeated command timeout errors (-110 ETIMEDOUT), preventing firmware load and controller initialization. The failure pattern (command 0xfc00 timeout when reading QCA version information) indicates the Bluetooth hardware is not receiving proper clock/power supply, likely due to a clock dependency regression introduced by PR Shikra rpmcc latest changes #1076's RPMCC clock driver changes affecting RF_CLK or LN_BB_CLK clock availability.
  3. Possible fix: Do not merge PR Shikra rpmcc latest changes #1076 until the Bluetooth regression is resolved. Investigate qcs615-ride WCN6855 clock dependencies (RF_CLK1, RF_CLK2, LN_BB_CLK2) and verify the PR's clock driver changes do not break clock availability for Bluetooth hardware. Add debug logging to confirm all required clocks are available and enabled during WCN6855 initialization. If a clock is missing, restore it in the qcs615 RPMCC driver or update the device tree to correctly reference available clocks.
  4. Detail analysis attachment: failed_case_job227671_2_detailed.md
  Case 3: ** BT_ON_OFF
  1. Failed case: ** BT_ON_OFF
  2. Root cause: ** Bluetooth hardware (WCN6855) on QCS615 Ride board fails to respond to driver initialization commands with persistent timeout errors (-ETIMEDOUT). The QCA Bluetooth controller does not respond to version query command (0xfc00), preventing adapter from acquiring a valid BD address. This is a board/hardware/firmware issue, NOT a regression introduced by PR Shikra rpmcc latest changes #1076 (which modifies clock code for a different SoC - Shikra).
  3. Possible fix: Re-trigger the CI job on a different QCS615 board to rule out hardware failure. If issue persists across boards: (1) verify Bluetooth firmware is present in rootfs at /lib/firmware/qca/ for WCN6855, (2) check UART pinmux and clock configuration in QCS615 device tree for bluetooth node under serial interface, (3) verify BT chip power/enable GPIO is properly configured and toggled during boot, (4) check kernel config has CONFIG_BT_HCIUART_QCA=y and CONFIG_BT_QCA=y enabled.
  4. Detail analysis attachment: failed_case_job227671_3_detailed.md
  Case 4: ** BT_SCAN — Bluetooth Runtime Initialization Failure (Driver Dependency Issue)
  1. Failed case: ** BT_SCAN — Bluetooth Runtime Initialization Failure (Driver Dependency Issue)
  2. Root cause: ** Bluetooth WCN6855 chip communication timeout (-ETIMEDOUT) caused by missing RF clock enablement. PR patch 6/6 introduces skip_clks_handoff = true for QCM2290 clocks, which prevents proxy voting on RPM clocks during boot. The Bluetooth driver (btqca/hci_qca) does not explicitly request RF_CLK1/RF_CLK2, relying on the handoff proxy vote to keep these clocks active. Without the proxy vote, the Bluetooth chip remains unclocked, causing all UART communication attempts to time out during QCA version information read.
  3. Possible fix: Revert the skip_clks_handoff = true change in patch 6/6, OR update the Bluetooth driver (drivers/bluetooth/btqca.c or drivers/bluetooth/hci_qca.c) to explicitly request and enable the required RF clock (RF_CLK1 or RF_CLK2) via the clock framework before attempting communication with the WCN6855 chip. The proper upstream fix is the latter — drivers must explicitly manage their clock dependencies rather than relying on proxy votes.
  4. Detail analysis attachment: failed_case_job227671_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: This is not a bug — it is the expected behavior on QCS615 Ride when running under Gunyah hypervisor. The KVM_Driver test should be skipped on platforms that boot with a Type-1 hypervisor (Gunyah, Xen, etc.) at EL2. Add a platform-specific test gate to skip KVM tests when dmesg | grep -q "Hypervisor cold boot.*gunyah" returns true, or when /sys/hypervisor/type indicates a Type-1 hypervisor is present.
  4. Detail analysis attachment: failed_case_job227671_5_detailed.md
  Case 6: ** KVM Driver Initialization Failure — HYP mode not available
  1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
  2. Root cause: ** QCS615 Ride platform does not provide EL2 (Hypervisor) mode access to Linux; KVM driver initialization fails with "HYP mode not available" at boot, preventing /dev/kvm device creation and causing all KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail.
  3. Possible fix: This is a pre-existing platform limitation unrelated to PR Shikra rpmcc latest changes #1076 (clock driver changes). To enable KVM on qcs615-ride: (1) verify bootloader/firmware boots Linux at EL2 or provides EL2 access via HVC, (2) confirm SoC supports virtualization extensions (check ARM core variant), (3) if EL2 is reserved for proprietary hypervisor, KVM cannot be used on this platform. Mark KVM tests as "not applicable" for qcs615-ride in CI configuration.
  4. Detail analysis attachment: failed_case_job227671_6_detailed.md
  Case 7: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM driver initialization failed because HYP (EL2) mode is not available to Linux on QCS615 Ride platform — the Gunyah hypervisor is running but does not expose EL2 virtualization extensions to the Linux kernel, preventing /dev/kvm device creation.
  3. Possible fix: This is a platform limitation, not a kernel regression. The QCS615 Ride platform runs Gunyah hypervisor in a configuration that reserves EL2 for the hypervisor itself and does not expose nested virtualization to Linux. To enable KVM support, either: (1) reconfigure the Gunyah hypervisor to expose EL2 to Linux (if supported by the platform), or (2) mark KVM tests as expected-to-skip on QCS615 Ride in the LAVA test suite configuration.
  4. Detail analysis attachment: failed_case_job227671_7_detailed.md
  Case 8: KVM_Infra (No applicable CoT — Platform Hardware Limitation)
  1. Failed case: KVM_Infra (No applicable CoT — Platform Hardware Limitation)
  2. Root cause: QCS615 SoC does not support ARM EL2 (Hypervisor mode), which is a mandatory hardware requirement for KVM; kernel correctly reports "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm creation.
  3. Possible fix: Update the LAVA test suite to skip KVM tests on platforms without EL2 support by adding a pre-flight capability check; mark as SKIP instead of FAIL when /dev/kvm is absent due to hardware limitations rather than kernel bugs.
  4. Detail analysis attachment: failed_case_job227671_8_detailed.md
Job 227672 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Suppress these known benign failures in the Probe_Failure_Check test for hamoa-evk platform, or fix the underlying issues: (1) adjust QSEECOM UEFI secure app expectations for hamoa-evk, (2) correct the c42d000.spmi:pmic@1:pwm DT node multi-LED reg property, (3) add regulatory.db to rootfs firmware directory (optional).
  4. Detail analysis attachment: failed_case_job227672_1_detailed.md
  Case 2: smmu
  1. Failed case: smmu
  2. Root cause: Test validation failure — six critical DMA masters (five USB PHY devices at a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and video codec at aa00000) are missing IOMMU group attachments on hamoa-evk, indicating incomplete device tree IOMMU bindings for these peripherals; this is a pre-existing platform configuration issue unrelated to the PR's clock controller changes.
  3. Possible fix: Add missing iommus properties to the device tree nodes for USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) in arch/arm64/boot/dts/qcom/hamoa*.dtsi, referencing the appropriate SMMU phandle and stream IDs; verify attachment by checking /sys/kernel/iommu_groups after reboot.
  4. Detail analysis attachment: failed_case_job227672_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: KVM driver initialization determined that HYP (Hypervisor) mode is not available on the hamoa-evk platform, preventing /dev/kvm device node creation; kernel message "kvm [1]: HYP mode not available" at boot indicates the ARM CPU is not running at EL2 or virtualization extensions are disabled in firmware/bootloader.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies Shikra RPMCC clock bindings unrelated to KVM). If KVM support is required on hamoa-evk: (1) verify the SoC supports ARM virtualization extensions, (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 instead of EL1, (3) check that secure firmware (TZ) allows HYP mode. If KVM is not expected on this platform, exclude KVM tests from the hamoa-evk LAVA test suite.
  4. Detail analysis attachment: failed_case_job227672_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: This is a platform limitation, not a kernel bug. If KVM support is required on Hamoa IoT EVK, update the bootloader/firmware to boot the kernel at EL2 or enable EL2 access. If KVM is not a requirement for this platform, exclude KVM tests from the Hamoa test suite.
  4. Detail analysis attachment: failed_case_job227672_4_detailed.md
  Case 5: KVM Infrastructure Failure — KVM not available (HYP mode not supported on platform)
  1. Failed case: KVM Infrastructure Failure — KVM not available (HYP mode not supported on platform)
  2. Root cause: The hamoa-evk platform does not support ARM Virtualization Extensions (VHE/nVHE) required for KVM. The kernel reports "kvm [1]: HYP mode not available" at boot (line 3980), indicating the CPU is not running at EL2 or the platform firmware has not enabled virtualization support. CONFIG_KVM is enabled in the kernel configuration, but the hardware/firmware prerequisite for KVM operation is missing.
  3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The KVM test suite should be excluded from the hamoa-evk CI test plan, or the test should be updated to skip gracefully when HYP mode is unavailable. If KVM support is required for hamoa-evk, verify that: (1) the SoC supports ARM Virtualization Extensions, (2) the bootloader/firmware enables EL2, and (3) the device tree does not disable virtualization.
  4. Detail analysis attachment: failed_case_job227672_5_detailed.md
  Case 6: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM cannot initialize on Hamoa EVK because Gunyah hypervisor is running at EL2, preventing kernel access to HYP mode required for KVM operation (kernel message: "kvm [1]: HYP mode not available").
  3. Possible fix: This is expected behavior for Hamoa EVK with Gunyah hypervisor enabled. To enable KVM testing: (1) disable Gunyah hypervisor in firmware/bootloader configuration to allow kernel direct EL2 access, or (2) mark KVM tests as "skip" for Hamoa EVK in the LAVA test definition, or (3) use nested virtualization support if/when Gunyah adds KVM passthrough capability.
  4. Detail analysis attachment: failed_case_job227672_6_detailed.md
Job 227673 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — Deferred Probe (SPMI PMIC temp-alarm devices)
  1. Failed case: Probe_Failure_Check — Deferred Probe (SPMI PMIC temp-alarm devices)
  2. Root cause: Four SPMI PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state on lemans-evk (SA8775P), indicating missing thermal zone bindings or incomplete PMIC thermal driver dependencies in the device tree for this SoC.
  3. Possible fix: Add thermal zone bindings for the four SPMI PMICs in the lemans-evk device tree, mapping each temp-alarm device to its corresponding thermal zone, following the pattern used in other SA8775P-based platforms; verify /sys/class/thermal/thermal_zone*/ entries are created for all four PMICs after the fix.
  4. Detail analysis attachment: failed_case_job227673_1_detailed.md
  Case 2: smmu (Test Expectation Failure — Video Codec IOMMU Attachment Missing)
  1. Failed case: smmu (Test Expectation Failure — Video Codec IOMMU Attachment Missing)
  2. Root cause: The smmu test expects the video codec device aa00000.video-codec to be attached to an IOMMU group for memory protection, but the device tree configuration for lemans-evk does not include the required iommus property for this device, resulting in no IOMMU group attachment. This is a pre-existing platform configuration issue, not a kernel crash or SMMU fault, and is unrelated to the PR's clock driver changes.
  3. Possible fix: Add the iommus property to the video-codec device tree node in arch/arm64/boot/dts/qcom/sa8775p.dtsi (or the lemans-specific overlay) to attach the video codec to the appropriate SMMU context bank. The test will pass once the DT is updated to include IOMMU protection for the video codec device.
  4. Detail analysis attachment: failed_case_job227673_2_detailed.md
  Case 3: LAVA Test Infrastructure Failure — Test runner marked as incomplete
  1. Failed case: LAVA Test Infrastructure Failure — Test runner marked as incomplete
  2. Root cause: LAVA test orchestration detected "unfinished test run" after the test runner script result_parse.sh completed and exited with <LAVA_TEST_RUNNER EXIT>. All individual test cases passed successfully (including the last test qcom_hwrng), but LAVA's test shell wrapper marked the overall test definition as failed because it expected additional test signals or a clean completion marker that was not received.
  3. Possible fix: This is a LAVA test infrastructure/orchestration issue, not a kernel regression. The test plan completed all scheduled tests successfully. Re-trigger the CI job to confirm reproducibility. If the issue persists, investigate the result_parse.sh script and LAVA test definition to ensure proper test completion signaling. The PR changes (clock driver updates for Shikra/QCM2290) are unrelated to this LAVA orchestration failure.
  4. Detail analysis attachment: failed_case_job227673_3_detailed.md
Job 227674 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check
  1. Failed case: Probe_Failure_Check
  2. Root cause: Two pre-existing probe failures unrelated to PR changes: (1) xhci-hcd probe timeout (-ETIMEDOUT) indicating USB controller hardware not responding on qcs8300-ride platform, and (2) regulatory.db firmware file missing from rootfs (benign - cfg80211 falls back to built-in certificates).
  3. Possible fix: These are pre-existing platform/infrastructure issues not introduced by this PR. The xhci-hcd failure requires hardware/DT/power investigation specific to qcs8300-ride USB subsystem. The regulatory.db warning is cosmetic and does not affect WiFi functionality (WiFi tests passed). No action required for this PR; failures existed before these clock driver changes.
  4. Detail analysis attachment: failed_case_job227674_1_detailed.md
  Case 2: ** Driver Probe Failure — xHCI Host Controller (USB)
  1. Failed case: ** Driver Probe Failure — xHCI Host Controller (USB)
  2. Root cause: ** xHCI host controller hardware setup timed out (error -110 ETIMEDOUT) during driver probe on qcs8300-ride platform. The controller did not respond to initialization commands within the 18-second window, preventing USB bus registration and device enumeration. This is a pre-existing platform issue unrelated to the PR's clock changes for Shikra SoC.
  3. Possible fix: This is a known hardware/platform limitation on qcs8300-ride requiring board-level investigation. For CI purposes: suppress USBHost test failures on qcs8300-ride until the platform USB controller initialization sequence is debugged. Investigate bootloader USB handoff state, xHCI controller power/clock dependencies, and firmware compatibility. The PR should not be blocked by this pre-existing qcs8300 platform issue.
  4. Detail analysis attachment: failed_case_job227674_2_detailed.md
  Case 3: KVM_Driver
  1. Failed case: KVM_Driver
  2. Root cause: QCS8300 Ride boots under Gunyah hypervisor with Linux running as a guest VM without EL2 access; KVM requires EL2 (hypervisor privilege level) to initialize and cannot run in nested virtualization mode on this platform configuration.
  3. Possible fix: Mark KVM tests as "not applicable" for QCS8300 Ride platform in the LAVA test suite, or configure the platform to boot Linux at EL2 (bare-metal mode without Gunyah) if KVM support is required for testing.
  4. Detail analysis attachment: failed_case_job227674_3_detailed.md
  Case 4: KVM_EL2_DTB
  1. Failed case: KVM_EL2_DTB
  2. Root cause: KVM driver did not initialize on qcs8300-ride platform running under Gunyah hypervisor — /dev/kvm device node not created despite CONFIG_KVM=y. This is a pre-existing platform limitation: QCS8300 (Monaco) SoC running under Gunyah hypervisor does not support KVM (nested virtualization not enabled or not supported on this SoC/hypervisor combination).
  3. Possible fix: This is not a PR-introduced regression. The PR changes only RPMCC clock driver code for Shikra/QCM2290, which is completely unrelated to KVM functionality. No fix required for this PR. If KVM support is needed on qcs8300-ride, investigate platform/hypervisor configuration to enable nested virtualization support, or mark KVM tests as expected-fail/skip for this platform.
  4. Detail analysis attachment: failed_case_job227674_4_detailed.md
  Case 5: KVM_Infra — /dev/kvm device node missing
  1. Failed case: KVM_Infra — /dev/kvm device node missing
  2. Root cause: KVM device node /dev/kvm is not created despite CONFIG_KVM being enabled in the kernel configuration. The QCS8300 Ride platform (Monaco target) does not have functional KVM support — the ARM KVM driver failed to initialize during boot, preventing the creation of the /dev/kvm character device required for virtualization.
  3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies RPMCC clock bindings). The failure is expected on QCS8300 until KVM/virtualization support is enabled for this SoC. To resolve: (1) verify the platform's hypervisor configuration allows nested virtualization or KVM operation, (2) check if the SoC requires specific device tree properties or firmware to enable EL2/VHE features, (3) if KVM is not supported on this platform, mark these tests as expected failures or skip them in the CI configuration for qcs8300-ride.
  4. Detail analysis attachment: failed_case_job227674_5_detailed.md
  Case 6: 0_qcom-next-ci-premerge-tests
  1. Failed case: 0_qcom-next-ci-premerge-tests
  2. Root cause: LAVA test runner marked the test suite as "unfinished" despite all tests completing normally; the test suite contained 5 genuine test failures (Probe_Failure_Check, USBHost, KVM_Driver, KVM_EL2_DTB, KVM_Infra) which caused LAVA to report the overall suite result as failed.
  3. Possible fix: Investigate the 5 failed test cases individually to determine if they are PR-introduced regressions or pre-existing issues; the "unfinished" marking is a LAVA infrastructure artifact that occurs when any test within the suite fails, and does not indicate a build load or kernel crash issue.
  4. Detail analysis attachment: failed_case_job227674_6_detailed.md
Job 227675 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC (Test Script Bug)
  1. Failed case: GIC (Test Script Bug)
  2. Root cause: The GIC test script incorrectly assumes all possible CPUs (0-7) will have entries in /proc/interrupts, but CPUs 6-7 are offline on qcs6490-rb3gen2 and therefore have no interrupt counters. The script's bash integer comparison at line 75 fails when it encounters "GICv3" instead of a numeric value, causing false failures for offline CPUs.
  3. Possible fix: Update the GIC test script to only validate timer interrupts for online CPUs by checking /sys/devices/system/cpu/online before parsing /proc/interrupts, or handle the case where a CPU column is missing from the interrupt line.
  4. Detail analysis attachment: failed_case_job227675_1_detailed.md
  Case 2: Probe_Failure_Check — Pre-existing Infrastructure Issues (Not PR-Introduced)
  1. Failed case: Probe_Failure_Check — Pre-existing Infrastructure Issues (Not PR-Introduced)
  2. Root cause: The Probe_Failure_Check test detected two pre-existing probe failures unrelated to the PR changes: (1) regulatory.db firmware missing from rootfs (cfg80211 wireless regulatory database), and (2) xhci-pci-renesas USB controller firmware (renesas_usb_fw.mem) missing from rootfs. Additionally, five audio-related devices remain in deferred probe state due to missing pinctrl dependencies on qcs6490-rb3gen2, which is a known board-specific DT configuration issue unrelated to the RPMCC clock changes in this PR.
  3. Possible fix: These are pre-existing board/rootfs configuration issues, not regressions introduced by this PR. The PR only modifies Shikra RPMCC bindings and does not touch qcs6490, audio, pinctrl, USB, or wireless subsystems. Recommended actions: (1) Add regulatory.db and renesas_usb_fw.mem firmware files to the rootfs image for rb3gen2-core-kit, (2) Review and fix the qcs6490 audio pinctrl DT configuration to resolve the deferred probe chain for sound/soundwire/codec devices, (3) Consider updating the Probe_Failure_Check test to distinguish between PR-introduced regressions and pre-existing board issues.
  4. Detail analysis attachment: failed_case_job227675_2_detailed.md
  Case 3: Freq_Scaling — Test Infrastructure Bug (CPU Count Mismatch)
  1. Failed case: Freq_Scaling — Test Infrastructure Bug (CPU Count Mismatch)
  2. Root cause: The Freq_Scaling test is hardcoded to check cpufreq interfaces for cpu0-cpu7 (8 CPUs), but qcs6490-rb3gen2 has only 6 successfully booted CPUs (cpu0-cpu5). CPU6 and CPU7 failed to boot during kernel initialization with error -22 (EINVAL). When the test attempts to verify the cpufreq interface for cpu7, it fails because cpu7 never booted, causing the test to report "CPUFreq interface not found. Test Failed". This is a pre-existing platform issue unrelated to the PR changes (RPMCC clock driver updates for Shikra SoC).
  3. Possible fix: Update the Freq_Scaling test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /sys/devices/system/cpu/present instead of hardcoding the CPU count. The test should only check cpufreq interfaces for CPUs that are actually online. Additionally, investigate why CPU6 and CPU7 fail to boot on qcs6490-rb3gen2 (error -22 suggests invalid configuration in device tree or firmware) — this is a separate platform-specific issue that should be tracked independently.
  4. Detail analysis attachment: failed_case_job227675_3_detailed.md
  Case 4: USBHost
  1. Failed case: USBHost
  2. Root cause: Could not be determined confidently from available logs.
  3. Possible fix: Add the linux-firmware package (or linux-firmware-renesas on Debian/Ubuntu-based images) to the LAVA rootfs build recipe to include /lib/firmware/renesas_usb_fw.mem. This is a test infrastructure fix, not a kernel code fix. PR Shikra rpmcc latest changes #1076 (clock changes) is not the cause and should not be blocked by this failure.
  4. Detail analysis attachment: failed_case_job227675_4_detailed.md
  Case 5: KVM_Driver — Platform Capability Limitation
  1. Failed case: KVM_Driver — Platform Capability Limitation
  2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not support KVM virtualization because HYP (EL2 Hypervisor) mode is not available on this hardware/firmware configuration, as evidenced by kernel message "kvm [1]: HYP mode not available" at boot time.
  3. Possible fix: Mark KVM tests as expected-skip for qcs6490-rb3gen2 in the LAVA test suite configuration, or add a platform capability check to skip KVM tests when /dev/kvm is unavailable due to missing HYP mode support.
  4. Detail analysis attachment: failed_case_job227675_5_detailed.md
  Case 6: KVM_EL2_DTB — KVM Initialization Failure (Platform Configuration Issue)
  1. Failed case: KVM_EL2_DTB — KVM Initialization Failure (Platform Configuration Issue)
  2. Root cause: KVM driver cannot initialize because the CPU is not running in EL2 (hypervisor) mode. Boot log shows kvm [1]: HYP mode not available at kernel initialization, which means the bootloader/firmware did not configure the CPU to boot into EL2. Without EL2 mode, /dev/kvm device node cannot be created, causing all KVM tests to fail.
  3. Possible fix: This is a pre-existing platform/firmware limitation on qcs6490-rb3gen2, not a regression introduced by PR Shikra rpmcc latest changes #1076 (which only modifies clock driver code unrelated to KVM). To enable KVM: (1) Update the bootloader/firmware to boot the kernel in EL2 mode, or (2) Mark KVM tests as "expected to fail" or "skip" for this platform in the LAVA job definition until firmware support is available. No kernel code changes are required.
  4. Detail analysis attachment: failed_case_job227675_6_detailed.md
  Case 7: KVM Infrastructure Test Failure — KVM/ARM HYP mode unavailable on qcs6490-rb3gen2
  1. Failed case: KVM Infrastructure Test Failure — KVM/ARM HYP mode unavailable on qcs6490-rb3gen2
  2. Root cause: KVM cannot initialize because the Gunyah hypervisor has claimed EL2 (HYP mode), preventing KVM from operating. The kernel message "kvm [1]: HYP mode not available" indicates that when KVM attempted to initialize, it detected that EL2 was already in use by another hypervisor (Gunyah), making /dev/kvm unavailable. This is a platform configuration issue specific to qcs6490-rb3gen2 (Kodiak) where Gunyah hypervisor is enabled in the boot chain.
  3. Possible fix: This is not a PR-introduced regression — the PR changes only clock driver code (RPMCC) and does not touch KVM, hypervisor, or virtualization subsystems. The failure is a pre-existing platform limitation: qcs6490-rb3gen2 boots with Gunyah hypervisor enabled, which prevents KVM from claiming EL2. To enable KVM on this platform, either: (1) disable Gunyah hypervisor in the bootloader/firmware configuration and reboot, or (2) mark KVM tests as "not applicable" for qcs6490-rb3gen2 in the LAVA test suite, since this SoC is configured to run Gunyah, not KVM.
  4. Detail analysis attachment: failed_case_job227675_7_detailed.md
  Case 8: KVM_Infra
  1. Failed case: KVM_Infra
  2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on qcs6490-rb3gen2 platform — kernel log shows kvm [1]: HYP mode not available at boot, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.
  3. Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression. The qcs6490-rb3gen2 board firmware does not enable EL2 (hypervisor mode), which is required for KVM functionality. To enable KVM: (1) verify bootloader/TZ firmware supports EL2 entry, (2) ensure secure boot configuration allows EL2, or (3) if EL2 is not supported on this platform, mark KVM tests as expected-fail/skip for qcs6490-rb3gen2 in the CI test matrix.
  4. Detail analysis attachment: failed_case_job227675_8_detailed.md

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

Reviewers

@Komal-Bajaj Komal Bajaj (Komal-Bajaj) Komal-Bajaj approved these changes
@shashim-quic Shiraz Hashim (shashim-quic) shashim-quic approved these changes
@ndechesne Nicolas Dechesne (ndechesne) Awaiting requested review from ndechesne ndechesne was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@aiquny aiquny Awaiting requested review from aiquny aiquny was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@jingyiwang42 jingyiwang42 Awaiting requested review from jingyiwang42 jingyiwang42 was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
+1 more reviewer
@taniyadas20 Taniya Das (taniyadas20) taniyadas20 approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

qli-2.1 pull-request freeze

Development

Successfully merging this pull request may close these issues.

7 participants

@imrashai @qcomlnxci @qlijarvis @Komal-Bajaj @shashim-quic @taniyadas20 @sgaud-quic