FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs by ggiriprasad · Pull Request #828 · qualcomm-linux/kernel

ggiriprasad · 2026-07-14T13:59:24Z

ufs_qcom_enable_lane_clks() and ufs_qcom_disable_lane_clks() currently use clk_bulk_prepare_enable()/clk_bulk_disable_unprepare() on the entire host->clks array obtained from devm_clk_bulk_get_all(). This array contains all device clocks, not just lane symbol clocks.

Since the UFS core framework already manages the non-lane clocks via the setup_clocks callback, the bulk enable/disable in the lane clock APIs resulted in duplicate reference count increments on those shared clocks. The extra enable counts were never balanced by a corresponding disable from the framework's clock gating path, preventing the clock reference counts from reaching zero and ultimately blocking CXO shutdown during low-power states.

Fix this by restricting the lane clock APIs to only prepare/enable and disable/unprepare the three lane symbol clocks (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk), leaving the handling of all other clocks to the UFS core framewore.

Link: https://lore.kernel.org/linux-scsi/20260909053944.2827968-1-nitin.rawat@oss.qualcomm.com/T/#u

CRs-Fixed: 4574726

qswat-orbit-external · 2026-07-14T13:59:32Z

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

Salendarsingh Gaud (sgaud-quic) · 2026-07-16T09:22:05Z

PR #828 — validate-patch

PR: #828

Verdict	Issues	Detailed Report
⚠️	1	Full report

Final Summary

Lore link present: Yes — commit has Link: https://lore.kernel.org/linux-scsi/20260713173434.883386-1-nitin.rawat@oss.qualcomm.com/
Lore link matches PR commits: Yes — PR diff matches the fetched lore patch with context-only line/index differences.
Upstream patch status: In review — local lore mbox contains the posting/thread evidence, with no definitive applied/queued/merged or NAK signal available from the inspected local evidence.
PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: [PATCH] FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828
Upstream commit: https://lore.kernel.org/linux-scsi/20260713173434.883386-1-nitin.rawat@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

Commit Message

Check Status Note

Subject matches upstream ✅ Upstream subject is adapted with FROMLIST; wording matches.

Body preserves rationale ✅ Rationale is preserved, including the lane-clock-only fix explanation.

Fixes tag present/correct ✅ No Fixes: tag exists in the lore posting; none was dropped.

Authorship preserved ✅ FROMLIST author rule is satisfied: lore author Nitin Rawat <nitin.rawat@oss.qualcomm.com> is present as author and Signed-off-by.

Backport note (if applicable) N/A Not a BACKPORT commit.

Diff

File Status Notes

drivers/ufs/host/ufs-qcom.c ✅ Lore hunk content matches; only context line numbers/indexes differ.

drivers/ufs/host/ufs-qcom.h ✅ Lore hunk content matches; only context line numbers/indexes differ.

Issues

qcom-next/topics presence is only partial: integration_presence_report.md reports present_commits: 0/1, partial_commits: 1/1, and topics missing. Per the provided rule, lack of full qcom-next/topics presence prevents a clean pass.

Verdict

Diff and commit metadata are faithful to the lore patch, but request follow-up because integration presence is only partial rather than fully verified in qcom-next/topics.

Final Summary

Lore link present: Yes — commit has Link: https://lore.kernel.org/linux-scsi/20260713173434.883386-1-nitin.rawat@oss.qualcomm.com/

Lore link matches PR commits: Yes — PR diff matches the fetched lore patch with context-only line/index differences.

Upstream patch status: In review — local lore mbox contains the posting/thread evidence, with no definitive applied/queued/merged or NAK signal available from the inspected local evidence.

PR present in qcom-next/topics: Partial — integration_presence_report.md says qcom-next has only partial evidence and topics has no subject, patch-id, or full tree-content match.

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: a5cf3debd8c3c660711ad586ad4bb84e9ca42635
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final

1/1 [PATCH] FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane partial - subject or partial tree evidence found, but full change was not verified missing - no subject, patch-id, or full tree-content match found partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

qswat-orbit-external · 2026-07-27T09:08:20Z

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4563277 on any of the following entities:

Entities:

kernel.qli.2.0

CR: 4563277

Please ensure the CR has a change task associated with at least one of the entities for this branch.

nitinrawat123 · 2026-08-07T09:38:18Z

Change LGTM.

qcomlnxci · 2026-08-07T12:48:53Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	◻️
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	◻️
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	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	❌ Fail	✅ 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	◻️
remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

qcomlnxci · 2026-08-07T12:48:54Z

Test jobs on 49827d4

Salendarsingh Gaud (sgaud-quic) · 2026-08-10T10:35:45Z

ggiriprasad are the comments on upstream change addressed ?

qcomlnxci · 2026-08-27T07:58:41Z

Test jobs on 49827d4

qcomlnxci · 2026-08-27T07:58:43Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ 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	⚠️ skip	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ 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	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	◻️	✅ 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 · 2026-08-28T17:31:57Z

Test jobs on 49827d4

qcomlnxci · 2026-08-28T17:32:02Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ 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	❌ Fail	❌ 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	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ 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

qcomlnxci · 2026-08-29T13:00:06Z

Test jobs on 50105fa

qcomlnxci · 2026-08-29T13:00:07Z

Test Matrix

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

qswat-orbit-external · 2026-09-07T11:24:47Z

Merge Check Failed: CR Not Eligible for Merge

CR 4574726 is not eligible for merge.

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

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

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

qswat-orbit-external · 2026-09-07T13:40:03Z

Merge Check Failed: CR Not Eligible for Merge

CR 4574726 is not eligible for merge.

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

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

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

qcomlnxci · 2026-09-07T16:52:38Z

Test jobs on 10af067

qcomlnxci · 2026-09-09T17:53:23Z

Test Matrix

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

qcomlnxci · 2026-09-09T17:53:32Z

Test jobs on 35c2034

qcomlnxci · 2026-09-10T03:27:09Z

Test Matrix

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

qcomlnxci · 2026-09-10T03:27:11Z

Test jobs on 35c2034

ggiriprasad · 2026-09-10T06:06:46Z

qli-2.1 pull-request freeze · Milestone #4 · qualcomm-linux/kernel

…APIs ufs_qcom_enable_lane_clks() and ufs_qcom_disable_lane_clks() currently use clk_bulk_prepare_enable()/clk_bulk_disable_unprepare() on the entire host->clks array obtained from devm_clk_bulk_get_all(). This array contains all device clocks, not just lane symbol clocks. Since the UFS core framework already manages the non-lane clocks via the setup_clocks callback, the bulk enable/disable in the lane clock APIs resulted in duplicate reference count increments on those shared clocks. The extra enable counts were never balanced by a corresponding disable from the framework's clock gating path, preventing the clock reference counts from reaching zero and ultimately blocking CXO shutdown during low-power states. Fix this by restricting the lane clock APIs to only prepare/enable and disable/unprepare the three lane symbol clocks (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk), leaving the handling of all other clocks to the UFS core framework. The lane clocks are now acquired individually via devm_clk_get() instead of being looked up in the bulk clock array. Link: https://lore.kernel.org/linux-scsi/20260909053944.2827968-1-nitin.rawat@oss.qualcomm.com/T/#meb440ffd6fd2965505bbc86a944250f47a68def5 Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com> Signed-off-by: Giri Prasad Goriparthi <giri.goriparthi@oss.qualcomm.com>

ggiriprasad · 2026-09-10T08:27:10Z

qli-2.1 pull-request freeze

qcomlnxci · 2026-09-10T09:11:37Z

Test jobs on 867e4eb

qcomlnxci · 2026-09-10T09:11:40Z

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

qcomlnxci · 2026-09-10T09:49:48Z

Test Matrix

Test Case	hamoa-iot-evk-multimedia	lemans-evk-multimedia	monaco-evk-multimedia	purwa-iot-evk-multimedia	qcs615-ride-multimedia	qcs6490-rb3gen2-multimedia	qcs8300-ride-multimedia	qcs9100-ride-r3-multimedia	shikra-iqs-evk-multimedia
Audio_Card_Registration	✅ Pass	◻️	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	⚠️ skip	⚠️ skip	◻️
BT_FW_KMD_Service	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_ON_OFF	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
BT_SCAN	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPUFreq_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
CPU_affinity	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
DSP_AudioPD	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Ethernet_Basic_Validation	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ 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	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
KVM_Infra	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
OpenCV	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
PCIe	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
Probe_Failure_Check	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	◻️
RMNET	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
UFS_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
USBHost	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	◻️
WiFi_Firmware_Driver	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
WiFi_OnOff	✅ Pass	◻️	❌ Fail	✅ Pass	✅ 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	⚠️ skip	⚠️ 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	◻️	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️

qcomlnxci · 2026-09-10T09:49:48Z

Test jobs on 6cefcd1

qcomlnxci · 2026-09-10T10:24:04Z

Test jobs on 5be7bbb

qcomlnxci · 2026-09-10T10:24:05Z

Test Matrix

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

qcomlnxci · 2026-09-10T10:32:55Z

Test jobs on bfa8e0f

qcomlnxci · 2026-09-10T10:32:56Z

Test Matrix

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

qcomlnxci · 2026-09-10T10:35:07Z

Test jobs on 21d1d6f

qcomlnxci · 2026-09-10T10:35:09Z

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	⚠️ skip	❌ 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	✅ Pass	◻️
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	◻️	⚠️ skip	✅ Pass	✅ Pass	◻️
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	❌ Fail	◻️
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	◻️

qcomlnxci · 2026-09-10T10:54:39Z

Test jobs on dd274ae

qcomlnxci · 2026-09-10T10:54:39Z

Test Matrix

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

…comm-linux#828) scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs

qlijarvis · 2026-09-15T12:05:05Z

LAVA Failed Case Triage Summary

PR: #828

Job 222511 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: The test detected 6 probe/firmware-related errors in dmesg, but only 1 is a genuine failure: ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin and subsequent MHI power-up timeout. The other 5 errors are benign: cpufreq-dt error -17 (EEXIST, driver already registered), regulatory.db missing (optional), and Bluetooth firmware fallback attempts (BT_ON_OFF test passed, confirming BT is functional). This is a pre-existing platform/firmware packaging issue on monaco-evk (iq-8275-evk), not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 which only modifies UFS clock handling in drivers/ufs/host/ufs-qcom.c.

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/) in the build image for monaco-evk, or update the Probe_Failure_Check test to suppress known benign probe failures (cpufreq-dt -17, optional regulatory.db, and ath11k WiFi on platforms where WiFi hardware is not populated or firmware is intentionally excluded).

Detail analysis attachment: failed_case_job222511_1_detailed.md

Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure (driver/module issue)

Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure (driver/module issue)

Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (Direct firmware load ... failed with error -2 = -ENOENT). The MHI (Modem Host Interface) power-up sequence timed out waiting for firmware to load, causing the entire probe chain to fail. This is a pre-existing infrastructure/build issue unrelated to PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which modifies UFS clock management only).

Possible fix: Add the missing WCN6855 WiFi firmware files for the nfa765 board variant to the rootfs image. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin (and associated board data files) are included in the Yocto/build recipe for monaco-evk. Verify the firmware package (linux-firmware-ath11k or equivalent) is installed and includes the nfa765 variant files. If the firmware is proprietary/not yet upstreamed, obtain it from the board vendor and add to the build artifacts.

Detail analysis attachment: failed_case_job222511_2_detailed.md

Case 3: WiFi_OnOff — Driver Probe Failure (Firmware Dependency)

Failed case: WiFi_OnOff — Driver Probe Failure (Firmware Dependency)

Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) during MHI power-up because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. The MHI bus controller attempted to load the firmware for the WCN6855 hw2.1 WiFi chip but received error -2 (ENOENT), causing the MHI power-on sequence to time out after 15 seconds, which propagated as -110 through the ath11k_pci probe path. This is a pre-existing platform/image configuration issue unrelated to the PR (which modifies only UFS lane clock handling in drivers/ufs/host/ufs-qcom.c).

Possible fix: Add the missing WCN6855 hw2.1 firmware files to the rootfs image under /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ (specifically amss.bin, m3.bin, and regdb.bin). These firmware files are typically provided by the linux-firmware package or Qualcomm's proprietary firmware distribution. Alternatively, if the nfa765 board-specific firmware variant is not available, create a symlink from the nfa765 directory to the default hw2.1 firmware directory as a temporary workaround: ln -s /lib/firmware/ath11k/WCN6855/hw2.1 /lib/firmware/ath11k/WCN6855/hw2.1/nfa765.

Detail analysis attachment: failed_case_job222511_3_detailed.md

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

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

Root cause: LAVA test framework marked the overall test definition as failed because two WiFi sub-tests (WiFi_Firmware_Driver and WiFi_OnOff) failed due to ath11k_pci probe timeout (error -110: ETIMEDOUT) during WiFi driver initialization. The kernel booted successfully and all other tests passed. The WiFi probe failure is unrelated to the PR changes (UFS clock management) and appears to be a pre-existing platform/firmware issue on monaco-evk.

Possible fix: Investigate the ath11k_pci probe timeout on monaco-evk platform — check WiFi firmware availability (ath11k/WCN6855/hw2.1/nfa765/amss.bin), PCIe link stability, and power sequencing. The PR itself does not introduce this failure; consider re-running the test or checking if this is a known monaco-evk WiFi hardware/firmware issue.

Detail analysis attachment: failed_case_job222511_4_detailed.md

Job 222512 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Three pre-existing platform-specific probe failures unrelated to the PR changes (UFS lane clock refactoring): (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) due to secure firmware dependency, (2) qcom-spmi-lpg probe failed with -EINVAL (-22) due to invalid multi-LED DT configuration, (3) regulatory.db firmware file missing (-ENOENT/-2) which is a known benign userspace configuration issue.

Possible fix: These failures are not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (UFS lane clock changes). The PR modifies only UFS host controller lane clock management and does not touch QSEECOM, SPMI-LPG, or regulatory subsystems. No action required for this PR. For the underlying issues: (1) QSEECOM failure is expected when secure app is not available in TZ firmware, (2) SPMI-LPG DT needs multi-LED "reg" property fix in device tree, (3) regulatory.db should be installed in /lib/firmware if wireless regulatory enforcement is needed.

Detail analysis attachment: failed_case_job222512_1_detailed.md

Case 2: smmu

Failed case: smmu

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

Possible fix: Add missing iommus properties to the device tree nodes for USB controllers at addresses 0xa0f8800, 0xa2f8800, 0xa4f8800, 0xa6f8800, 0xa8f8800 and video codec at 0xaa00000 in the hamoa (x1e80100) device tree, referencing the appropriate SMMU instance and stream IDs.

Detail analysis attachment: failed_case_job222512_2_detailed.md

Case 3: ** KVM_Driver — /dev/kvm device node unavailable

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

Root cause: ** KVM driver initialization failed because the hamoa-evk (x7181/x1e80100) platform does not support or have EL2 (hypervisor mode) enabled in firmware. The kernel message kvm [1]: HYP mode not available at boot confirms the CPU is not running in EL2 or EL2 is not accessible, which is a hardware/firmware prerequisite for KVM on ARM64.

Possible fix: This is a pre-existing platform limitation, not a regression from PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies UFS clock handling). If KVM support is required on hamoa-evk, the bootloader/firmware must be configured to enable EL2 and boot the kernel in EL2 mode. Otherwise, exclude KVM tests from the hamoa-evk test suite as this platform does not support virtualization.

Detail analysis attachment: failed_case_job222512_3_detailed.md

Case 4: KVM_EL2_DTB — Platform Configuration Limitation (Not a Kernel Bug)

Failed case: KVM_EL2_DTB — Platform Configuration Limitation (Not a Kernel Bug)

Root cause: KVM initialization failed with "HYP mode not available" because the Gunyah hypervisor is already running at EL2 on hamoa-evk, preventing KVM from taking control of the hypervisor layer. This is expected behavior on platforms with a pre-loaded hypervisor.

Possible fix: Mark KVM tests as "not applicable" for hamoa-evk in the LAVA job definition, or add a platform capability check to skip KVM tests when Gunyah hypervisor is detected. This is not a kernel regression — the PR changes UFS clock management and does not affect virtualization support.

Detail analysis attachment: failed_case_job222512_4_detailed.md

Case 5: KVM Infrastructure Test Failure — HYP mode unavailable

Failed case: KVM Infrastructure Test Failure — HYP mode unavailable

Root cause: KVM driver initialization fails because HYP mode (EL2 virtualization) is not available on the hamoa-evk platform; the board is running under a hypervisor or secure boot configuration that prevents Linux KVM from taking control of EL2, resulting in /dev/kvm never being created.

Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies UFS clock handling). If KVM support is required on hamoa-evk, the platform firmware/hypervisor configuration must be changed to allow Linux to run in EL2. For CI purposes, either: (1) skip KVM tests on hamoa-evk, or (2) use a different test platform that supports native KVM virtualization.

Detail analysis attachment: failed_case_job222512_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM is configured in the kernel (CONFIG_KVM=y) but the Hamoa IoT EVK platform does not support EL2/HYP mode, preventing KVM initialization and /dev/kvm device node creation. The kernel message "kvm [1]: HYP mode not available" at boot confirms the hardware does not provide the virtualization extensions required for KVM.

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR modifies UFS lane clock handling and is unrelated to KVM/virtualization. To resolve: either (1) disable CONFIG_KVM in the kernel config for Hamoa IoT EVK since the platform lacks EL2 support, or (2) mark KVM tests as expected-to-skip for this SoC in the LAVA test definition, or (3) verify the bootloader/firmware configuration allows EL2 access (check if Gunyah hypervisor is blocking Linux KVM from accessing EL2).

Detail analysis attachment: failed_case_job222512_6_detailed.md

Job 222513 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: These are pre-existing platform/configuration issues unrelated to the UFS clock management changes in PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828. (1) Add firmware-name property to Aquantia PHY DT node in qcs9100-ride.dts if custom firmware is required, or update driver to handle missing property gracefully; (2) Include regulatory.db in rootfs firmware directory if regulatory domain enforcement is needed; (3) Investigate PMIC temp-alarm deferred probe by checking thermal zone DT bindings and SPMI PMIC driver probe order. The PR should not be blocked by these failures as they are not regressions introduced by the UFS changes.

Detail analysis attachment: failed_case_job222513_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on qcs9100-ride platform; the SMMU test expects all critical masters (Display, GPU, USB, Ethernet, Video) to be protected by IOMMU, but the video codec device is missing from the IOMMU group list, indicating the video codec driver did not probe successfully or the device is not properly configured in the device tree for this SoC.

Possible fix: This is a pre-existing platform configuration issue unrelated to PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies UFS clock management). Investigate why the video codec driver is not probing on qcs9100-ride: check if CONFIG_VIDEO_QCOM_IRIS or equivalent video codec driver config is enabled, verify the device tree node at aa00000.video-codec has correct iommus property, check kernel log for video codec probe failures or deferred probe reasons, and confirm the video codec firmware is present. If the video codec is not supported on qcs9100-ride, update the SMMU test's critical master list to exclude video codec for this platform.

Detail analysis attachment: failed_case_job222513_2_detailed.md

Case 3: ** USBHost (Test Infrastructure Issue — No External USB Devices Connected)

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

Root cause: ** The USBHost test expects external USB devices (e.g., USB storage, keyboard, mouse) to be physically connected to the qcs9100-ride board's USB ports. The test detected 3 USB root hubs (Bus 001, 002, 003) functioning correctly, but no downstream USB devices were enumerated. This is a hardware setup or test infrastructure configuration issue, not a kernel regression. The USB subsystem is working as expected: xhci-hcd controllers probed successfully, USB core registered, and root hubs are operational.

Possible fix: Connect at least one functional USB device (USB storage, keyboard, or mouse) to one of the board's USB ports before running the USBHost test. If this is a CI/lab environment, verify the test fixture includes USB device connectivity or update the test to skip when no devices are expected. This is not a kernel issue and does not require a code fix.

Detail analysis attachment: failed_case_job222513_3_detailed.md

Case 4: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

Root cause: Aquantia AQR115C PHY driver probe failure on qcs9100-ride (error -22 / -EINVAL) due to missing firmware-name property in device tree, preventing PHY attachment to qcom-ethqos MAC driver for end0 interface (23040000.ethernet).

Possible fix: Add the required firmware-name property to the Aquantia AQR115C PHY device tree node under the stmmac-0 MDIO bus for qcs9100-ride. The property should specify the correct Aquantia firmware file path (typically "Rhe07508.cld" or similar for AQR115C). Verify the firmware file exists in /lib/firmware/ and is included in the rootfs image.

Detail analysis attachment: failed_case_job222513_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization failed because the kernel was booted at EL1 (non-hypervisor exception level) instead of EL2 (hypervisor exception level), preventing KVM from accessing ARM virtualization extensions required to create /dev/kvm.

Possible fix: Configure the bootloader (XBL/ABL) to boot the kernel at EL2 instead of EL1, or enable a hypervisor stub that allows KVM to drop from EL2 to EL1 while retaining virtualization capabilities; verify the qcs9100-ride platform firmware supports EL2 boot mode.

Detail analysis attachment: failed_case_job222513_5_detailed.md

Case 6: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

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

Possible fix: Skip KVM tests on Gunyah-enabled platforms, or configure the platform to boot without Gunyah if KVM testing is required. Add platform detection to the test suite to mark KVM tests as "not applicable" when running under a hypervisor.

Detail analysis attachment: failed_case_job222513_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: qcs9100-ride (LeMans) platform boots in EL1 (kernel mode) instead of EL2 (hypervisor mode), preventing KVM initialization. Kernel message at boot time (line 3126): "kvm [1]: HYP mode not available". This is a platform firmware/bootloader configuration issue, not a kernel regression.

Possible fix: This is a pre-existing platform limitation, not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies UFS clock management). To enable KVM on qcs9100-ride: (1) Configure the bootloader/firmware to boot the kernel in EL2 mode with VHE (Virtualization Host Extensions) enabled, or (2) If the platform does not support EL2 boot, mark KVM tests as "not applicable" for this SoC in the LAVA test suite configuration.

Detail analysis attachment: failed_case_job222513_7_detailed.md

Case 8: KVM_Infra (also KVM_Driver, KVM_EL2_DTB - same root cause)

Failed case: KVM_Infra (also KVM_Driver, KVM_EL2_DTB - same root cause)

Root cause: KVM virtualization is unavailable because the qcs9100-ride platform does not have HYP (EL2 hypervisor) mode available; kernel message shows "kvm [1]: HYP mode not available" during boot, preventing /dev/kvm device node creation.

Possible fix: This is a pre-existing platform limitation unrelated to PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (UFS clock management changes). The qcs9100-ride board requires firmware/bootloader configuration to enable EL2 mode, or KVM tests should be skipped on platforms without virtualization support. No kernel code fix needed; either enable HYP mode in the platform firmware or mark KVM tests as "not applicable" for this SoC.

Detail analysis attachment: failed_case_job222513_8_detailed.md

Job 222514 | SoC shikra-iqs-evk

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

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

Case 1: GIC (Test Infrastructure Bug)

Failed case: GIC (Test Infrastructure Bug)

Root cause: The GIC test script (run.sh line 75) has a parsing bug when reading /proc/interrupts — it attempts to compare non-numeric fields ("GICv3", "Level", "arch_timer") as integers, causing bash "[: integer expected" errors. The script then incorrectly reports failures for CPUs 4-7, which do not exist on shikra-iqs-evk (4-core platform with CPUs 0-3 only). All actual CPUs (0-3) show correctly incrementing arch_timer interrupt counts (CPU0: 13145→21475, CPU1: 14841→22173, CPU2: 15237→17672, CPU3: 9814→10195), proving GIC functionality is correct.

Possible fix: Update the GIC test script to correctly parse /proc/interrupts by extracting only the numeric interrupt count fields (columns 2 through N before the controller name), and dynamically detect the number of online CPUs from /sys/devices/system/cpu/online instead of hardcoding CPU count assumptions. The script should skip non-existent CPUs rather than reporting false failures.

Detail analysis attachment: failed_case_job222514_1_detailed.md

Case 2: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Pre-existing probe failures unrelated to PR828 (UFS lane clock changes). The test detected 7 probe/firmware errors: coresight-etm4x ETM0-3 probe failures (-EINVAL), regulatory.db firmware missing (-ENOENT), cpufreq-dt duplicate probe (-EEXIST), lt9611c I2C bridge probe failure (-EIO), and 3 deferred probe entries (sound codec, I2C device 3-0010, va_macro mclk). None of these failures involve UFS or storage subsystem; PR828 modifies only ufs-qcom lane clock handling and does not touch coresight, audio, display bridge, or cpufreq drivers.

Possible fix: Suppress this test failure as a false positive for PR828 validation. The probe failures are board/infra-specific issues (missing firmware files, DT/clock mismatches, coresight ETM configuration errors) that exist independently of the UFS changes. To address the underlying issues: (1) add regulatory.db to rootfs, (2) fix coresight ETM DT bindings for shikra-iqs-evk (error -22 suggests invalid DT property), (3) resolve audio codec clock dependencies, (4) debug lt9611c I2C communication on shikra-iqs-evk.

Detail analysis attachment: failed_case_job222514_2_detailed.md

Case 3: USBHost

Failed case: USBHost

Root cause: USB host controller driver (dwc3/xhci) did not probe during boot on shikra-iqs-evk; no USB devices enumerated because the USB host stack never initialized. The device tree defines usb@4e00000 and assigns it to IOMMU group 5, but no dwc3 or xhci probe messages appear in dmesg, indicating the USB host driver module is either missing from the kernel config, not loaded, or failed to probe silently.

Possible fix: This is a test infrastructure/board configuration issue, not a PR-introduced regression. The PR modifies UFS lane clock handling and does not touch USB subsystem code. To resolve: (1) verify CONFIG_USB_DWC3_QCOM and CONFIG_USB_XHCI_HCD are enabled in the kernel config; (2) check if USB host driver modules are present in the rootfs and loaded by udev; (3) confirm USB PHY clocks/regulators are available and not gated; (4) if the shikra-iqs-evk board does not have functional USB host hardware or requires external USB peripherals to be physically connected for the test to pass, update the test to SKIP on this platform or ensure test setup includes a USB device.

Detail analysis attachment: failed_case_job222514_3_detailed.md

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

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

Root cause: Bluetooth scan test failed because no discoverable Bluetooth devices were present in the LAVA test environment; the Bluetooth hardware, firmware, and driver are functional (BT_ON_OFF test passed, hci0 adapter operational, power on/off successful, discovery mode entered successfully), but the scan returned zero devices after 3 attempts with multiple fallback strategies.

Possible fix: This is not a kernel regression — it is a test infrastructure issue. To resolve: (1) ensure at least one discoverable Bluetooth device (phone, speaker, beacon) is powered on and in range of the shikra-iqs-evk board during the test run, or (2) update the BT_SCAN test to skip gracefully when no target device is specified and no devices are in range, or (3) configure a dedicated Bluetooth beacon in the LAVA lab for consistent scan validation.

Detail analysis attachment: failed_case_job222514_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM device node /dev/kvm is not present because the kernel detected "HYP mode not available" during boot (line 2724: kvm [1]: HYP mode not available). The Shikra IQS EVK platform does not support EL2/Hypervisor mode, which is a prerequisite for KVM functionality on ARM64.

Possible fix: This is a platform/firmware limitation, not a kernel regression. The test should be skipped on platforms without EL2 support. To resolve: (1) Update the LAVA test suite to check for HYP mode availability before running KVM tests, or (2) exclude KVM tests from the Shikra IQS EVK test matrix, or (3) update the platform firmware to enable EL2 if the hardware supports it.

Detail analysis attachment: failed_case_job222514_5_detailed.md

Case 6: KVM_EL2_DTB — /dev/kvm not available (platform limitation, not a test failure)

Failed case: KVM_EL2_DTB — /dev/kvm not available (platform limitation, not a test failure)

Root cause: The KVM_EL2_DTB test failed because /dev/kvm is not present on the target. This is not a genuine test failure but an expected outcome: the kernel log shows "kvm [1]: HYP mode not available" at boot, indicating the Shikra IQS EVK platform does not support EL2 hypervisor mode (likely running under a hypervisor or firmware that does not expose EL2 to Linux). CONFIG_KVM is enabled in the kernel, but the KVM driver cannot create /dev/kvm when HYP mode is unavailable. The test correctly detects this condition and reports it as a failure, but this is a platform/firmware limitation, not a kernel regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which modifies UFS clock management, unrelated to KVM).

Possible fix: Mark KVM_EL2_DTB (and related KVM_Driver, KVM_Infra) as expected failures or skip them on Shikra IQS EVK in the LAVA test definition, since this platform does not support KVM/EL2. Add a platform capability check to the test suite to automatically skip KVM tests when "HYP mode not available" is detected in dmesg. The PR itself does not require any fix — it is unrelated to this test failure.

Detail analysis attachment: failed_case_job222514_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: The KVM_Infra test failed because /dev/kvm is not present on the system. However, this is NOT the root cause of the LAVA job failure. The job actually failed due to a subsequent kernel panic in the qcom_hwrng test: a synchronous external abort (ESR 0x96000010) occurred when the qcom_rng driver attempted to read from hardware RNG MMIO registers at qcom_rng_read+0xc4, indicating the RNG hardware was not responding (likely unpowered/unclocked). This crash is potentially related to the PR's UFS clock management changes which enable CXO shutdown during idle, and the RNG driver may not properly manage its clock dependencies.

Possible fix: The KVM_Infra test failure itself is a configuration issue — verify KVM driver module is loaded and EL2 support is available. However, the critical fix needed is for the kernel panic: investigate and fix the qcom_rng driver's clock/power management to ensure RNG hardware clocks are enabled before MMIO access, especially in the context of the UFS clock refcount fix that now allows CXO gating. Short-term: revert the UFS clock PR to confirm correlation. Long-term: add explicit clock enable/disable calls in qcom_rng driver probe and runtime paths, or ensure RNG hardware clock domain is properly managed independently of UFS/CXO gating.

Detail analysis attachment: failed_case_job222514_7_detailed.md

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

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

Root cause: Kernel crash (synchronous external abort) in qcom_rng driver during hardware RNG read operation, unrelated to the PR's UFS lane clock changes; the crash triggered a panic and warm reboot, causing the LAVA test suite to timeout after 2400 seconds when the board failed to complete remaining tests.

Possible fix: This is a pre-existing hardware RNG driver issue on shikra-iqs-evk, not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies UFS clock handling). The crash occurs at qcom_rng_read+0xc4 when accessing an invalid physical address (0x000000ed7e447638). Recommended actions: (1) Skip or disable the qcom_hwrng test on shikra-iqs-evk until the RNG driver/hardware issue is resolved; (2) Investigate whether the RNG hardware base address mapping is correct for this SoC variant; (3) The PR itself is not at fault and should not be blocked by this failure.

Detail analysis attachment: failed_case_job222514_8_detailed.md

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

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

Root cause: Hardware random number generator (qcom_rng) driver attempted to read from an unmapped or inaccessible hardware register during the qcom_hwrng test, triggering a synchronous external abort at PC qcom_rng_read+0xc4. This is a pre-existing platform/firmware issue unrelated to the PR's UFS clock management changes.

Possible fix: This is not a PR-introduced regression. The qcom_rng driver crash indicates a platform-specific hardware access issue on shikra-iqs-evk. Recommended actions: (1) verify qcom_rng device tree configuration for shikra platform includes correct register base addresses and clock/power dependencies; (2) confirm qcom_rng hardware block is powered and clocked before driver access; (3) consider disabling qcom_hwrng test on shikra-iqs-evk until platform support is validated; (4) check if qcom_rng driver requires platform-specific quirks or initialization sequence for this SoC.

Detail analysis attachment: failed_case_job222514_9_detailed.md

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

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

Root cause: The qcom_hwrng test triggered a synchronous external abort at PC qcom_rng_read+0xc4 when reading from the hardware RNG device. The abort indicates a bus-level access fault (likely unmapped/unpowered MMIO region or clock/power domain issue). After the panic, the system entered EDL mode as expected, but LAVA timed out waiting for the test shell to complete (2400s timeout). This is a pre-existing kernel driver bug, not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which modifies UFS clock management).

Possible fix: Debug the qcom_rng driver's MMIO access at offset +0xc4 in qcom_rng_read(). Verify that: (1) the RNG hardware block is powered and clocked before access, (2) the MMIO region is correctly mapped in the device tree for shikra-iqs-evk, (3) runtime PM state is correct. Add error handling for external aborts or gate RNG access behind a platform capability check. For immediate CI unblocking, skip the qcom_hwrng test on shikra-iqs-evk until the driver is fixed.

Detail analysis attachment: failed_case_job222514_10_detailed.md

Case 11: Test Timeout — qcom_hwrng test triggered kernel crash (synchronous external abort in qcom_rng driver)

Failed case: Test Timeout — qcom_hwrng test triggered kernel crash (synchronous external abort in qcom_rng driver)

Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware access fault) at PC qcom_rng_read+0xc4 when reading from the hardware RNG device. The crash occurred during a memory-mapped I/O read operation (b940035c = ldr w28, [x26]), indicating the hardware register at the mapped address was not accessible. This is unrelated to the PR changes (UFS lane clock management) and represents a pre-existing platform/firmware issue where the qcom_rng hardware block is either not powered, not clocked, or not properly mapped on the shikra-iqs-evk platform.

Possible fix: This is a pre-existing platform configuration issue, not introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828. The PR changes only affect UFS driver clock management and do not touch RNG, power domains, or clock controllers. To resolve: (1) verify qcom_rng device node in shikra DT includes correct clocks/power-domains, (2) confirm RNG hardware block is powered and clocked during test execution, (3) consider skipping qcom_hwrng test on shikra-iqs-evk until platform support is validated, or (4) re-trigger the CI job to confirm this is not a transient hardware/board state issue.

Detail analysis attachment: failed_case_job222514_11_detailed.md

Job 222515 | SoC qcs8300-ride

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

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

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

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

Root cause: ** Three pre-existing probe failures on qcs8300-ride platform: (1) cpufreq-dt duplicate registration (-EEXIST) — benign, cpufreq functional (CPUFreq_Validation PASSED); (2) regulatory.db firmware missing (-ENOENT) — benign, WiFi functional (ath11k loaded successfully); (3) Aquantia AQR115C PHY firmware-name DT property missing (-EINVAL) — causes Ethernet bring-up failure. None are introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (UFS lane clock fix).

Possible fix: Suppress the Probe_Failure_Check test failure for this PR — all three probe failures are pre-existing platform issues unrelated to the UFS driver changes in PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828. For long-term platform health: (1) add firmware-name property to Aquantia PHY DT node in qcs8300-ride.dts to fix Ethernet; (2) include regulatory.db in rootfs firmware directory; (3) investigate cpufreq-dt duplicate registration (likely harmless race during parallel probe).

Detail analysis attachment: failed_case_job222515_1_detailed.md

Case 2: USBHost

Failed case: USBHost

Root cause: Test infrastructure issue — no external USB devices physically connected to the qcs8300-ride board's USB host port during test execution; only the USB 2.0 root hub (Bus 001 Device 001: ID 1d6b:0002) is enumerated, indicating the USB host controller initialized correctly but no peripheral devices are attached.

Possible fix: This is not a kernel regression — the PR modifies only UFS clock management code and does not touch USB subsystem; verify USB device is physically connected to the board's USB host port in the LAVA lab setup; if the test requires a specific USB device (e.g., USB storage, USB-to-serial adapter), ensure it is connected and powered before test execution; alternatively, update the test to skip or mark as expected-fail when running on boards without USB peripherals attached.

Detail analysis attachment: failed_case_job222515_2_detailed.md

Case 3: Ethernet_Basic_Validation — PHY Driver Probe Failure

Failed case: Ethernet_Basic_Validation — PHY Driver Probe Failure

Root cause: Aquantia AQR115C PHY driver probe failed with -EINVAL because the device tree node for the PHY is missing the required firmware-name property, preventing the qcom-ethqos MAC driver from attaching to the PHY when bringing up the eth0 interface.

Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY device tree node in arch/arm64/boot/dts/qcom/qcs8300-ride.dtsi (or the appropriate board DTS file). The property should specify the path to the Aquantia PHY firmware file, typically firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld"; or the appropriate firmware file for this PHY model. This is a platform-specific device tree fix, not a kernel driver issue, and is unrelated to PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (UFS clock management changes).

Detail analysis attachment: failed_case_job222515_3_detailed.md

Case 4: ** KVM_Driver — Missing /dev/kvm device node

Failed case: ** KVM_Driver — Missing /dev/kvm device node

Root cause: ** QCS8300 Ride platform does not support KVM virtualization. The ARM KVM driver requires EL2 (hypervisor mode) to be available to the Linux kernel, but on this platform EL2 is either not present, disabled in the boot chain, or reserved by a proprietary hypervisor (likely Gunyah for automotive safety partitioning). CONFIG_KVM=y is enabled in the kernel config, but the KVM driver silently skips initialization when EL2 is unavailable, resulting in no /dev/kvm device node creation. This is a platform hardware/firmware limitation, not a kernel driver bug.

Possible fix: This is not a bug to fix — it is expected behavior for this platform. The KVM test should be skipped on QCS8300 (Monaco) targets that do not support EL2 virtualization. Update the LAVA test suite to add a platform exclusion rule: skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests on qcs8300-ride. Alternatively, if KVM support is required, the bootloader/firmware must be configured to boot Linux at EL2 and not reserve EL2 for a proprietary hypervisor.

Detail analysis attachment: failed_case_job222515_4_detailed.md

Case 5: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM subsystem did not initialize on QCS8300 (Monaco) platform — CONFIG_KVM is enabled but /dev/kvm device node was never created because the KVM driver did not probe or initialize during boot (no KVM-related kernel messages in dmesg). This is a pre-existing platform limitation, not a regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (UFS lane clock management changes).

Possible fix: This is not a PR-introduced failure. The UFS driver changes in PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 affect only UFS clock management and have no impact on KVM/virtualization subsystem initialization. No action required for this PR. If KVM support is required on QCS8300, investigate platform-specific KVM enablement requirements (hypervisor mode support, device tree configuration, or SoC-specific virtualization limitations).

Detail analysis attachment: failed_case_job222515_5_detailed.md

Case 6: KVM_Infra — KVM Device Node Missing

Failed case: KVM_Infra — KVM Device Node Missing

Root cause: The qcs8300-ride target is running as a guest VM under the Gunyah hypervisor (boot log shows "Hypervisor cold boot, version: gunyah-cdfb73831"). KVM requires direct access to ARM EL2 (hypervisor exception level) to create /dev/kvm, but when Linux runs as a guest under Gunyah, EL2 is owned by the Gunyah hypervisor and not accessible to the guest kernel. CONFIG_KVM is enabled in the kernel config, but the KVM driver cannot initialize because nested virtualization is not supported in this configuration.

Possible fix: This is a platform configuration issue, not a kernel regression. The KVM_Infra test should be skipped on qcs8300-ride when running under Gunyah hypervisor, or the test infrastructure should provision a bare-metal (non-virtualized) qcs8300-ride target for KVM testing. To implement: add a test gate that checks for Gunyah presence (via /sys/firmware/devicetree/base/reserved-memory/gunyah-md-region or hypervisor boot messages) and skips KVM tests when detected.

Detail analysis attachment: failed_case_job222515_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: Pre-existing platform limitation — qcs8300-ride does not support KVM virtualization; /dev/kvm device node is not created because KVM cannot initialize on this platform (likely running under a hypervisor or lacking EL2 virtualization support).

Possible fix: Mark KVM tests as expected-to-fail or skip them on qcs8300-ride platform; this is not a PR-introduced regression but a known platform constraint.

Detail analysis attachment: failed_case_job222515_7_detailed.md

Job 222516 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Five driver probe failures detected during boot on purwa-evk platform: (1) qcom_qseecom_uefisecapp failed with -EBUSY indicating TrustZone secure app resource conflict, (2) qcom-spmi-lpg PWM driver failed with -EINVAL due to invalid device tree configuration, (3) two qcom-pcie instances failed with -ENODATA indicating missing PCIe endpoint data or link training failure, and (4) regulatory.db firmware file missing from rootfs causing cfg80211 regulatory database load failure. These are pre-existing platform/configuration issues unrelated to the PR's UFS driver changes.

Possible fix: These probe failures are expected on purwa-evk and do not indicate a kernel regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828. The PR only modifies UFS lane clock handling in drivers/ufs/host/ufs-qcom.c and does not touch qseecom, lpg, pcie, or cfg80211 subsystems. The Probe_Failure_Check test should be updated to suppress these known platform-specific probe failures for purwa-evk, or the platform configuration should be fixed: (1) resolve TZ secure app resource allocation for qseecom, (2) correct PWM device tree node properties for lpg, (3) verify PCIe endpoint presence and link training for the two PCIe controllers, and (4) add regulatory.db firmware file to the rootfs image.

Detail analysis attachment: failed_case_job222516_1_detailed.md

Case 2: smmu (test validation failure — missing IOMMU attachments for USB PHY and video codec devices)

Failed case: smmu (test validation failure — missing IOMMU attachments for USB PHY and video codec devices)

Root cause: Test expects USB PHY devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec (aa00000.video-codec) to be attached to IOMMU groups, but purwa-evk device tree does not define iommus properties for these devices; this is a platform-specific DT configuration gap, not a kernel functional failure.

Possible fix: Add iommus properties to the USB PHY and video codec device tree nodes in arch/arm64/boot/dts/qcom/purwa.dtsi (or the appropriate purwa-evk overlay), referencing the correct SMMU phandle and stream IDs for these devices, following the pattern used for other critical masters like UFS (1d84000.ufshc) and GPU (3d00000.gpu).

Detail analysis attachment: failed_case_job222516_2_detailed.md

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

Failed case: KVM_Driver — /dev/kvm not available (platform limitation)

Root cause: KVM requires ARM EL2 (Hypervisor mode) support, but the purwa-evk platform does not provide EL2 access. The kernel message "kvm [1]: HYP mode not available" at boot time confirms that the CPU is not running in or cannot access EL2, preventing KVM initialization and /dev/kvm device node creation.

Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. Exclude KVM tests from the purwa-evk CI test suite, or enable EL2 support in the platform firmware/bootloader if the hardware supports it. The PR patch (UFS clock management) is unrelated and does not cause this failure.

Detail analysis attachment: failed_case_job222516_3_detailed.md

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

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

Root cause: The Purwa IoT EVK platform does not support EL2 (Hypervisor Exception Level), preventing KVM from initializing; kernel booted at EL1 instead of EL2, causing KVM to abort initialization with "HYP mode not available" and /dev/kvm device node was never created.

Possible fix: Skip KVM tests on Purwa IoT EVK platform in LAVA CI configuration (add platform-specific test exclusion); if EL2 support is required, work with Qualcomm firmware team to enable EL2 entry in UEFI/bootloader for this platform.

Detail analysis attachment: failed_case_job222516_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM cannot initialize because the platform is running under the Gunyah hypervisor in non-nested virtualization mode — kernel message "kvm [1]: HYP mode not available" indicates the CPU is not in EL2 (hypervisor exception level), preventing KVM from creating /dev/kvm.

Possible fix: This is not a PR-introduced regression. The purwa-evk platform runs under Gunyah hypervisor by design (boot log shows "Hypervisor cold boot, version: gunyah-mobile-c487961e9"). To enable KVM on this platform, either: (1) configure Gunyah to support nested virtualization (if supported by the hypervisor version), or (2) exclude KVM tests from the purwa-evk LAVA job definition, as KVM is inherently incompatible with non-nested hypervisor configurations.

Detail analysis attachment: failed_case_job222516_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM virtualization is not available on the purwa-evk platform because the hardware does not support HYP (Hypervisor) mode, as indicated by the kernel message "kvm [1]: HYP mode not available" at boot time.

Possible fix: This is a platform limitation, not a kernel regression. The purwa-evk board does not have EL2 (Exception Level 2) hypervisor support enabled in its firmware/bootloader configuration. To enable KVM on this platform: (1) verify the SoC supports virtualization extensions, (2) ensure the bootloader (ABL/XBL) is configured to boot the kernel at EL1 with EL2 available (not disabled), and (3) check that secure firmware (TZ) allows non-secure EL2 access. If the hardware fundamentally lacks virtualization support, exclude KVM tests from the purwa-evk CI test suite.

Detail analysis attachment: failed_case_job222516_6_detailed.md

Job 222517 | SoC lemans-evk

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

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

Case 1: System Hang During Boot — UFS Driver Initialization

Failed case: System Hang During Boot — UFS Driver Initialization

Root cause: System completely stopped producing console output at kernel timestamp [6.216769] during ufshcd-qcom driver probe after printing regulator messages. The PR changes UFS lane clock acquisition from bulk clk_bulk_get_all() to individual devm_clk_get() calls for tx_lane0_sync_clk, rx_lane0_sync_clk, and rx_lane1_sync_clk. On lemans-evk, the device tree likely does not define these specific clock names, causing devm_clk_get() to fail during ufs_qcom_init_lane_clks(), which would trigger dev_err_probe() and abort the probe. However, the abort appears to have caused a system-level hang rather than a clean probe failure, suggesting the UFS controller was left in an inconsistent state that wedged the boot process.

Possible fix: Verify that the lemans-evk device tree (arch/arm64/boot/dts/qcom/sa8775p.dtsi or board-specific overlay) defines clock-names = "tx_lane0_sync_clk", "rx_lane0_sync_clk", "rx_lane1_sync_clk" in the UFS controller node. If missing, add these clock definitions matching the hardware. If the clocks genuinely don't exist on this platform, the driver needs a fallback path or the patch should be conditioned on clock availability. Short-term: revert this PR for lemans-evk until DT is updated. Long-term: ensure all target device trees are updated before merging this change.

Detail analysis attachment: failed_case_job222517_1_detailed.md

Case 2: Boot Hang — UFS Driver Probe Failure (Driver/Module Issue)

Failed case: Boot Hang — UFS Driver Probe Failure (Driver/Module Issue)

Root cause: System hung during UFS driver probe at 6.2 seconds after boot. The PR changes UFS lane clock acquisition from bulk API (devm_clk_bulk_get_all) to individual devm_clk_get() calls for three specific lane clocks (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk). On lemans-evk, one or more of these clock names are likely missing or misnamed in the device tree, causing devm_clk_get() to block indefinitely or return a deferred probe that never resolves, preventing the UFS driver from completing probe and blocking the boot process before the login prompt appears.

Possible fix: Verify the lemans-evk device tree (arch/arm64/boot/dts/qcom/sa8775p*.dts*) contains clock-names entries for tx_lane0_sync_clk, rx_lane0_sync_clk, and rx_lane1_sync_clk in the UFS controller node (ufshc@1d84000). If missing, add them to match the driver's expectations. If present but misnamed, align the DT clock-names with the driver code. Alternatively, modify the driver to use devm_clk_get_optional() instead of devm_clk_get() for these clocks to allow graceful fallback if the clocks are not defined in older device trees, or add a platform-specific check to skip lane clock acquisition on lemans-evk if the hardware does not require explicit lane clock management.

Detail analysis attachment: failed_case_job222517_2_detailed.md

Case 3: Boot Hang — UFS Driver Initialization

Failed case: Boot Hang — UFS Driver Initialization

Root cause: System hung during UFS driver probe at 6.2 seconds after boot. The PR changes UFS lane clock acquisition from bulk devm_clk_bulk_get_all() to individual devm_clk_get() calls for specific clock names (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk). The hang occurs immediately after UFS driver starts probing, suggesting either: (1) one or more of the named clocks do not exist in the device tree for lemans-evk, causing devm_clk_get() to block or return an error that is not properly handled, or (2) the clock enable sequence is deadlocking due to missing clock dependencies or circular clock relationships.

Possible fix: Verify that the lemans-evk device tree defines all three required UFS lane clock names (tx_lane0_sync_clk, rx_lane0_sync_clk, rx_lane1_sync_clk) in the UFS controller node. If any clock name is missing or differs from the driver's expectations, either: (1) update the device tree to use the correct clock names, or (2) modify the driver to handle missing clocks gracefully (e.g., make rx_lane1_sync_clk optional for single-lane configurations). Add error handling in ufs_qcom_init_lane_clks() to ensure probe failures are logged clearly rather than hanging silently.

Detail analysis attachment: failed_case_job222517_3_detailed.md

Case 4: Boot Hang — UFS initialization stall

Failed case: Boot Hang — UFS initialization stall

Root cause: System hangs during UFS host controller initialization at boot time (last kernel message at [6.216769] shows ufshcd-qcom probe); PR828 changes UFS lane clock management from bulk clock operations to individual clock handling, causing the UFS controller to stall during probe on lemans-evk where UFS is the boot device.

Possible fix: Revert the lane clock changes in drivers/ufs/host/ufs-qcom.c or add proper error handling and clock sequencing for the individual lane clock enable/disable paths; verify that tx_lane0_sync_clk, rx_lane0_sync_clk, and rx_lane1_sync_clk are all successfully acquired and enabled before UFS link startup on lemans-evk.

Detail analysis attachment: failed_case_job222517_4_detailed.md

Job 222518 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Two pre-existing firmware load failures unrelated to the PR: (1) cfg80211 regulatory.db missing (benign — WiFi functional tests passed), (2) Renesas USB 3.0 controller firmware renesas_usb_fw.mem missing (board-specific — causes USBHost test failure but not a kernel regression).

Possible fix: For production: add renesas_usb_fw.mem firmware to the rootfs firmware directory (/lib/firmware/) to enable the Renesas USB 3.0 PCIe controller on qcs6490-rb3gen2. For CI: suppress Probe_Failure_Check when only these two known benign/board-specific firmware errors are present, or update the test to exclude optional firmware loads from failure criteria.

Detail analysis attachment: failed_case_job222518_1_detailed.md

Case 2: USBHost Test Failure — Missing USB Host Controller Firmware

Failed case: USBHost Test Failure — Missing USB Host Controller Firmware

Root cause: The Renesas xHCI USB 3.0 host controller (PCI device 0001:04:00.0) failed to probe because the required firmware file renesas_usb_fw.mem is missing from the target rootfs (error -2 = ENOENT). This is the only USB host controller on qcs6490-rb3gen2, so no USB devices can be enumerated. This is a pre-existing test infrastructure issue unrelated to PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828, which only modifies UFS clock management.

Possible fix: Install the linux-firmware package (or equivalent containing renesas_usb_fw.mem) in the rootfs image used for qcs6490-rb3gen2 CI runs. The firmware file should be placed in /lib/firmware/renesas_usb_fw.mem. Alternatively, if USB host functionality is not required for this platform, mark the USBHost test as SKIP for qcs6490-rb3gen2 in the LAVA job definition.

Detail analysis attachment: failed_case_job222518_2_detailed.md

Case 3: KVM_Driver — Platform Limitation (HYP Mode Not Available)

Failed case: KVM_Driver — Platform Limitation (HYP Mode Not Available)

Root cause: KVM initialization failed because the qcs6490-rb3gen2 platform does not support ARM EL2 (Hypervisor) mode, which is required for KVM virtualization. The kernel log shows "kvm [1]: HYP mode not available" at boot time, preventing /dev/kvm device node creation despite CONFIG_KVM being enabled.

Possible fix: This is a platform hardware limitation, not a kernel bug or PR-introduced regression. The qcs6490-rb3gen2 SoC does not provide EL2 support. Recommended actions: (1) Mark KVM tests as "skip" or "not applicable" for qcs6490-rb3gen2 in the LAVA test suite configuration; (2) If KVM support is required, use a different platform that supports ARM virtualization extensions (e.g., platforms with Cortex-A cores that implement EL2); (3) Update test expectations to reflect platform capabilities.

Detail analysis attachment: failed_case_job222518_3_detailed.md

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

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

Root cause: ** KVM initialization failed at boot with "HYP mode not available" because the qcs6490-rb3gen2 (Kodiak) platform does not support ARM EL2 (hypervisor exception level). CONFIG_KVM is enabled in the kernel, but the hardware/firmware does not provide EL2 access, preventing /dev/kvm creation and making all KVM functionality unavailable.

Possible fix: This is a platform limitation, not a kernel bug. The KVM tests should be skipped on qcs6490-rb3gen2 targets. Add platform-specific test filtering in the LAVA job definition to exclude KVM tests for boards without EL2 support, or update the test suite to detect and skip KVM tests when "HYP mode not available" is present in dmesg.

Detail analysis attachment: failed_case_job222518_4_detailed.md

Case 5: KVM_Infra — KVM driver probe failure (HYP/EL2 mode not available)

Failed case: KVM_Infra — KVM driver probe failure (HYP/EL2 mode not available)

Root cause: qcs6490-rb3gen2 bootloader boots the kernel in EL1 (kernel mode) instead of EL2 (hypervisor mode). KVM/ARM requires EL2 to enable virtualization extensions. The KVM driver detects this at init (line 2962: "HYP mode not available"), aborts initialization, and never creates /dev/kvm. This is a pre-existing platform/firmware limitation, not a regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which only modifies the UFS driver).

Possible fix: This is not a kernel bug. To enable KVM on qcs6490-rb3gen2, the bootloader firmware must be updated to boot the kernel in EL2 mode. If KVM support is not required for this platform, mark the KVM tests as "expected to skip" in the LAVA test definition for qcs6490-rb3gen2. PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 is safe to merge — it does not affect KVM functionality.

Detail analysis attachment: failed_case_job222518_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the qcs6490-rb3gen2 platform — kernel message at boot: kvm [1]: HYP mode not available. This is a platform/firmware limitation, not a kernel regression introduced by the PR.

Possible fix: This is not a PR-introduced regression. The UFS clock management changes in PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 do not affect KVM/virtualization subsystem. The qcs6490-rb3gen2 platform either: (1) boots without EL2 access due to firmware/bootloader configuration, or (2) runs under a hypervisor that does not expose EL2 to Linux. To enable KVM on this platform, verify the bootloader/firmware configuration allows Linux to run at EL2, or use a different test platform that supports nested virtualization if running under a hypervisor.

Detail analysis attachment: failed_case_job222518_6_detailed.md

Job 222519 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check — regulatory.db firmware load failure

Failed case: Probe_Failure_Check — regulatory.db firmware load failure

Root cause: The cfg80211 wireless regulatory subsystem attempted to load the regulatory.db firmware file during initialization but the file is not present in the rootfs firmware directory (/lib/firmware/), resulting in error -2 (ENOENT). This is a known benign failure on systems where regulatory.db is not packaged; cfg80211 falls back to built-in regulatory rules (compiled-in X.509 certificates loaded successfully as shown in logs). WiFi functionality is unaffected — WiFi_Firmware_Driver and WiFi_OnOff tests both passed.

Possible fix: This is a false positive test failure. The Probe_Failure_Check test should be updated to exclude regulatory.db firmware load failures from its failure criteria, as this is a known benign condition when cfg80211 has built-in regulatory data. Alternatively, package regulatory.db in the rootfs if strict firmware presence validation is required. No kernel or PR changes needed — the PR (UFS lane clock fix) is unrelated to this failure.

Detail analysis attachment: failed_case_job222519_1_detailed.md

Case 2: smmu — Test Expectation Mismatch (Video Codec Child Devices)

Failed case: smmu — Test Expectation Mismatch (Video Codec Child Devices)

Root cause: The smmu test expects video-decoder and video-encoder to exist as separate platform devices with individual IOMMU group attachments, but the qcom-venus driver on qcs615-ride uses the "non legacy binding" model where these are handled as video4linux devices within the parent aa00000.video-codec device (which IS correctly attached to IOMMU group 7). This is a test script issue, not a kernel regression.

Possible fix: Update the smmu test script to recognize that Venus video codec devices using "non legacy binding" do not create separate platform device children for encoder/decoder. The test should verify only the parent video-codec device's IOMMU attachment, or skip the child device check when "non legacy binding" is detected in dmesg.

Detail analysis attachment: failed_case_job222519_2_detailed.md

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

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

Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the QCS615 platform. The kernel log shows "kvm [1]: HYP mode not available" at boot time, indicating the CPU/firmware does not support or enable virtualization extensions (EL2). CONFIG_KVM is enabled in the kernel config, but the hardware/firmware prerequisite for KVM (EL2 mode) is missing, preventing /dev/kvm creation.

Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by the PR. The PR modifies UFS clock handling (drivers/ufs/host/ufs-qcom.c) and is unrelated to KVM/virtualization. No kernel fix is possible — KVM requires EL2 support from the SoC/firmware. If virtualization is required on QCS615, verify the firmware/bootloader configuration enables EL2, or use a different platform with EL2 support. For CI purposes, suppress KVM tests on QCS615 or mark them as expected-fail for this SoC.

Detail analysis attachment: failed_case_job222519_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM initialization failed because EL2 (hypervisor mode) is not available on the qcs615-ride platform — kernel message kvm [1]: HYP mode not available at boot indicates the bootloader/firmware did not enter the kernel at EL2, preventing KVM from creating /dev/kvm.

Possible fix: This is a platform/firmware limitation, not a kernel regression. The qcs615-ride board firmware does not boot the kernel in EL2 mode. To enable KVM: (1) verify the bootloader/firmware supports EL2 entry and is configured to boot Linux at EL2, or (2) exclude KVM-dependent tests from the qcs615-ride test suite if EL2 support is not available on this hardware revision.

Detail analysis attachment: failed_case_job222519_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM initialization failed with "HYP mode not available" at boot time (line 2907: [3.192854][T1] kvm [1]: HYP mode not available). The QCS615 SoC (Kryo 260 CPUs, MIDR 0x51df805e) does not support ARM virtualization extensions (EL2/hypervisor mode), preventing /dev/kvm device node creation and causing all KVM test cases (KVM_Driver, KVM_EL2_DTB, KVM_Infra) to fail with "SKIP - /dev/kvm is not present".

Possible fix: This is a hardware limitation, not a software bug. The QCS615 platform does not support KVM/virtualization. Either: (1) skip KVM tests on qcs615-ride in the CI test suite configuration, or (2) run KVM tests only on platforms with EL2 support (e.g., SM8450, SM8550, SA8775P). The PR (UFS clock management) is unrelated and did not introduce this failure.

Detail analysis attachment: failed_case_job222519_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM infrastructure test failed because /dev/kvm device node is not present — the qcs615-ride platform does not support hardware virtualization (HYP mode). Kernel log shows kvm [1]: HYP mode not available at boot, indicating the SoC/firmware does not provide EL2 (hypervisor) support required for KVM operation.

Possible fix: This is not a regression introduced by PR FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs #828 (which modifies UFS lane clock handling). The failure is a pre-existing platform limitation — qcs615-ride does not support KVM/virtualization. Either: (1) exclude KVM tests from the qcs615-ride test suite, or (2) run KVM tests only on platforms with HYP mode support (e.g., sm8450, sm8550, sa8775p).

Detail analysis attachment: failed_case_job222519_6_detailed.md

ggiriprasad requested review from a team, Komal Bajaj (Komal-Bajaj), Mukesh Ojha (mukeshojha-linux) and Shivendra Pratap (quicAspratap) July 14, 2026 13:59

nitinrawat123 approved these changes Aug 7, 2026

View reviewed changes

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

View reviewed changes

ggiriprasad dismissed Komal Bajaj (Komal-Bajaj)’s stale review via 50105fa August 29, 2026 10:18

qcomlnxci requested review from a team and yijiyang August 29, 2026 10:19

ggiriprasad force-pushed the qcom-6.18.y branch from 50105fa to 49827d4 Compare September 7, 2026 11:24

ggiriprasad changed the title ~~FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs~~ FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs Milestone #4 Sep 7, 2026

ggiriprasad changed the title ~~FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs Milestone #4~~ FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs Sep 7, 2026

ggiriprasad force-pushed the qcom-6.18.y branch from 49827d4 to 10af067 Compare September 7, 2026 13:39

ggiriprasad changed the title ~~FROMLIST scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs~~ FROMLIST: scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs Sep 7, 2026

ggiriprasad force-pushed the qcom-6.18.y branch from 35c2034 to 867e4eb Compare September 10, 2026 06:00

ggiriprasad force-pushed the qcom-6.18.y branch 4 times, most recently from bfa8e0f to 21d1d6f Compare September 10, 2026 07:23

ggiriprasad force-pushed the qcom-6.18.y branch from 21d1d6f to dd274ae Compare September 10, 2026 07:42

Tingwei Zhang (quic-tingweiz) approved these changes Sep 10, 2026

View reviewed changes

Salendarsingh Gaud (sgaud-quic) added this to the qli-2.1 pull-request freeze milestone Sep 10, 2026

Salendarsingh Gaud (sgaud-quic) merged commit 4d6b63a into qualcomm-linux:qcom-6.18.y Sep 10, 2026
6 of 9 checks passed

mohsRafi pushed a commit to mohsRafi/kernel that referenced this pull request Sep 11, 2026

scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs (qual…

ffaae59

…comm-linux#828) scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs

Uh oh!

Conversation

ggiriprasad commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qswat-orbit-external Bot commented Jul 14, 2026

Uh oh!

Salendarsingh Gaud (sgaud-quic) commented Jul 16, 2026

PR #828 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Issues

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qswat-orbit-external Bot commented Jul 27, 2026

Uh oh!

nitinrawat123 commented Aug 7, 2026

Uh oh!

qcomlnxci commented Aug 7, 2026

Test Matrix

Uh oh!

qcomlnxci commented Aug 7, 2026

Test jobs on 49827d4

Uh oh!

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

Uh oh!

qcomlnxci commented Aug 27, 2026

Test jobs on 49827d4

Uh oh!

qcomlnxci commented Aug 27, 2026

Test Matrix

Uh oh!

qcomlnxci commented Aug 28, 2026

Test jobs on 49827d4

Uh oh!

qcomlnxci commented Aug 28, 2026

Test Matrix

Uh oh!

qcomlnxci commented Aug 29, 2026

Test jobs on 50105fa

Uh oh!

qcomlnxci commented Aug 29, 2026

Test Matrix

Uh oh!

qswat-orbit-external Bot commented Sep 7, 2026

Uh oh!

qswat-orbit-external Bot commented Sep 7, 2026

Uh oh!

qcomlnxci commented Sep 7, 2026

Test jobs on 10af067

Uh oh!

qcomlnxci commented Sep 9, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 9, 2026

Test jobs on 35c2034

Uh oh!

qcomlnxci commented Sep 10, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 10, 2026

Test jobs on 35c2034

Uh oh!

ggiriprasad commented Sep 10, 2026

Uh oh!

ggiriprasad commented Sep 10, 2026

Uh oh!

qcomlnxci commented Sep 10, 2026

Test jobs on 867e4eb

Uh oh!

qcomlnxci commented Sep 10, 2026

Test Matrix

Uh oh!

qcomlnxci commented Sep 10, 2026

ggiriprasad commented Jul 14, 2026 •

edited

Loading