BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property

[kotarake]

Remove the 'allow-set-time' property from the rtc node because APPS is prohibited from setting the hardware RTC time.

Reviewed-by: Konrad Dybcio konrad.dybcio@oss.qualcomm.com
Link: https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/
CRs-Fixed: 4146945

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

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

Entities:

• kernel.qli.2.0

CR: 4146945

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

[qswat-orbit-external]

Dev Completion validation failed

CR: 4146945
Change Task: kernel.qli.2.0
Error: GenAI Assisted field must be set before moving change tasks to Development Complete. Please provide GenAI information.

The change task for this CR could not be moved to Dev Complete because of the error above. Please resolve the issue in Orbit and re-run the failed Orbit check.

[qlijarvis]

PR #1131 — validate-patch

PR: #1131

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/
2. Lore link matches PR commits: No — lore patch modifies qcs8300-pmics.dtsi but PR modifies monaco-pmics.dtsi (different files for different SoCs)
3. Upstream patch status: Upstreamed — merged as commit 4654433409914017618233daccfbf79876b2adfe by Bjorn Andersson on 2025-10-27
4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1131 - BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property
Upstream commit: https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	⚠️	Subject line matches but file path in subject (qcs8300) does not match actual file changed (monaco)
Body preserves rationale	✅	Commit message body is identical to upstream
Fixes tag present/correct	N/A	No Fixes tag in upstream patch
Authorship preserved	❌	CRITICAL: PR From: is Rakesh Kota but upstream author is Tingguo Cheng. For BACKPORT: prefix, original author must be preserved in From: field
Backport note (if applicable)	❌	No backport note present (e.g., [ upstream commit 4654433409914017618233daccfbf79876b2adfe ])

Diff

File	Status	Notes
monaco-pmics.dtsi vs qcs8300-pmics.dtsi	❌	CRITICAL FILE MISMATCH: PR modifies arch/arm64/boot/dts/qcom/monaco-pmics.dtsi but upstream patch modifies arch/arm64/boot/dts/qcom/qcs8300-pmics.dtsi. These are completely different files for different SoCs

Issues

Critical Issues:

1. Wrong file modified: The PR claims to be a BACKPORT: of the upstream patch but modifies a completely different file:

   • Upstream: arch/arm64/boot/dts/qcom/qcs8300-pmics.dtsi (QCS8300 SoC)
   • PR: arch/arm64/boot/dts/qcom/monaco-pmics.dtsi (Monaco SoC)

   While the change itself (removing allow-set-time property) is semantically identical, this is not a backport — it's an adaptation of the same fix to a different platform.

2. Incorrect authorship: The PR has From: Rakesh Kota but the upstream patch author is Tingguo Cheng. For BACKPORT: commits, the original author must be preserved in the From: field. The submitter should be added as a second Signed-off-by: only.

3. Missing backport note: The commit message lacks a backport note indicating the upstream commit SHA (e.g., [ upstream commit 4654433409914017618233daccfbf79876b2adfe ]).

4. Misleading subject line: The subject says qcs8300: pmic: but the actual file changed is monaco-pmics.dtsi, not qcs8300-pmics.dtsi.

Verdict

Do not merge. This PR has multiple critical issues:

1. The BACKPORT: prefix is incorrect — this is not a backport of the upstream patch but rather an adaptation of the same fix to a different SoC (Monaco instead of QCS8300).

2. The correct approach is to either:

   • Option A (Recommended): Change the prefix to FROMLIST: or UPSTREAM: (if the Monaco change was also posted/merged upstream separately), update the subject to say monaco-pmics: instead of qcs8300-pmics:, and verify the lore link points to the Monaco-specific patch (not the QCS8300 one).
   • Option B: If this is genuinely a Monaco-specific adaptation inspired by the QCS8300 fix, use QCLINUX: prefix and remove the lore link, or add a note like "Similar to upstream commit 4654433 for QCS8300".

3. Fix the authorship: From: should be Tingguo Cheng (or the Monaco patch author if different), not Rakesh Kota.

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/
2. Lore link matches PR commits: No — lore patch modifies qcs8300-pmics.dtsi but PR modifies monaco-pmics.dtsi (different files for different SoCs)
3. Upstream patch status: Upstreamed — merged as commit 4654433409914017618233daccfbf79876b2adfe by Bjorn Andersson on 2025-10-27
4. PR present in qcom-next/topics: Fail — 1/1 commit is missing from both qcom-next and topics (per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

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

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

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

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

[qlijarvis]

PR #1131 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	✅	DTB validation passed
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	Invalid lore link (b4-ty URL)
tag-check	✅	Valid BACKPORT: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1131 - BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/35191694998
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	✅	DTB validation passed
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	Invalid lore link (b4-ty URL)
tag-check	✅	Valid BACKPORT: prefix

---

❌ check-patch-compliance

Root cause: The Link: trailer points to a b4 thank-you message, not the actual patch submission.

Failure details:

Checking commit: BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property
Something seems wrong with the provided link. Please verify it
Try below command to run locally-
b4 am --single-message -C -l -3 https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/

The link https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/ is a b4 thank-you acknowledgment (indicated by b4-ty in the message ID), not the original patch submission. The checker cannot fetch the patch content from this URL because it's not a patch message.

Fix: Replace the Link: trailer with the actual lore.kernel.org URL of the original patch submission.

1. Search for the original patch on lore.kernel.org:

   • Go to https://lore.kernel.org/all/
   • Search for: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property
   • Or search by author: Tingguo Cheng

2. Once you find the original patch thread, copy the message-ID URL (it should NOT contain b4-ty)

3. Update the commit:

   git rebase -i 6cc7b3cbf67264d3f4ebec661d4a86e75f724f23
   # mark commit bbe3534e2f61f53afcd55eace2fc375a7e21eede as 'edit'
   git commit --amend
   # Replace the Link: line with the correct lore URL
   git rebase --continue

Reproduce locally:

cd /path/to/kernel
b4 am --single-message -C -l -3 https://lore.kernel.org/all/176160465183.73268.13666964053987809637.b4-ty@kernel.org/
# This will fail because it's a b4-ty message, not a patch

Note: A b4 thank-you message is sent by maintainers to acknowledge patch acceptance. It references the original patch but is not itself a patch. The Link: trailer must point to the original patch submission, not the thank-you message.

---

Verdict

1 blocker to fix before merge: Replace the b4-ty link with the actual patch submission URL from lore.kernel.org.

All other checkers passed or were correctly skipped. The patch itself is clean (checkpatch ✅, dtb-check ✅), has the correct BACKPORT: prefix for the qcom-6.18.y target branch, and makes a valid DTS change. Only the Link trailer needs correction.

[qcomlnxci]

Test jobs on bbe3534

• multimedia Job 228608 on hamoa-iot-evk
• multimedia Job 228607 on lemans-evk
• multimedia Job 228605 on monaco-evk
• multimedia Job 228609 on purwa-iot-evk
• multimedia Job 228602 on qcs615-ride
• multimedia Job 228603 on qcs6490-rb3gen2
• multimedia Job 228610 on qcs8300-ride
• multimedia Job 228606 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 228604 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1131

Job 228602 | SoC qcs615-ride

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

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

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

1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA
2. Root cause: Hardware memory access fault (synchronous external abort) triggered during USB device enumeration when SWIOTLB bounce buffer attempted to copy from invalid physical address 0x110af07a0. The crash occurred in __pi_memcpy_generic called from swiotlb_bounce during usb_get_device_descriptor for a newly connected low-speed USB device. This indicates either an IOMMU/SMMU mapping failure producing an invalid DMA physical address, or a hardware bus error when accessing the computed bounce buffer location. The failure is specific to qcs615-ride platform USB/DMA subsystem interaction and is NOT introduced by PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 (which only modifies monaco-pmics.dtsi RTC property for qcs8300).
3. Possible fix: This is a pre-existing platform/infra issue unrelated to the PR changes. Re-trigger the CI job on a different qcs615-ride board or with a different USB device configuration. If the issue persists across multiple boards, investigate qcs615 IOMMU/SMMU DT configuration for the USB controller (xhci-hcd at 0x0a800000) — verify iommus property, SMMU stream-id mapping, and DMA address constraints. Check if USB controller requires specific dma-ranges or SWIOTLB pool size adjustments for qcs615 platform.
4. Detail analysis attachment: failed_case_job228602_1_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort during USB enumeration
2. Root cause: Synchronous external abort (0x96000010) in __pi_memcpy_generic during USB device descriptor fetch via SWIOTLB bounce buffer, triggered when xHCI controller attempted DMA mapping for USB device enumeration at 7.739s; the crash occurred during memcpy from physical address 0x90af07a0 to SWIOTLB bounce buffer at 0x7ff7f000, indicating a hardware bus fault accessing an invalid or unmapped physical address on qcs615-ride.
3. Possible fix: This is a hardware/platform-specific DMA addressing issue unrelated to the PR (which only removes an RTC DT property for monaco/qcs8300, not qcs615). The crash is a pre-existing qcs615-ride platform issue where USB DMA buffers are allocated in a physical address range (0x90af07a0) that triggers external abort when accessed. Recommended actions: (1) verify qcs615 DMA memory carveouts and reserved-memory DT nodes are correctly configured for USB controller; (2) check if USB controller IOMMU mappings are valid; (3) compare with known-good qcs615 kernel config/DT to identify missing memory reservations; (4) re-run the test on a different qcs615-ride board to rule out hardware fault.
4. Detail analysis attachment: failed_case_job228602_2_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort during USB DMA mapping
2. Root cause: Kernel panic due to synchronous external abort (memory access fault) at address 0x0000000110af07a0 during USB device enumeration. The crash occurred in __pi_memcpy_generic while copying data for SWIOTLB bounce buffer during USB hub event processing. The fault address (0x0000000110af07a0) appears to be an invalid physical address accessed during DMA mapping for a low-speed USB device (device number 2). This is a pre-existing platform issue on qcs615-ride, unrelated to the PR changes (which modify monaco-pmics.dtsi for Monaco platform, not QCS615).
3. Possible fix: This is NOT a PR-introduced regression. The PR modifies Device Tree for Monaco platform (monaco-pmics.dtsi), while the crash occurs on qcs615-ride platform during USB initialization. The crash is a pre-existing hardware/firmware/DT configuration issue on qcs615-ride. Recommended actions: (1) Mark this test failure as "Known Issue — qcs615-ride USB DMA fault (pre-existing, not PR-related)"; (2) Re-run the test on a different qcs615-ride board to rule out hardware failure; (3) If reproducible across boards, investigate qcs615-ride Device Tree USB/IOMMU/SMMU configuration and compare with working platforms; (4) Check if USB device connected to the board is faulty or incompatible; (5) Approve the PR as the failure is platform-specific and unrelated to the monaco-pmics.dtsi changes.
4. Detail analysis attachment: failed_case_job228602_3_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort (DMA/SWIOTLB)
2. Root cause: Synchronous external abort during USB device enumeration on qcs615-ride when SWIOTLB bounce buffer attempted to copy data from an invalid physical address (0xffff000090af07a0 → 0xffff00007ff7f000), indicating a DMA mapping or IOMMU configuration issue causing access to unmapped or inaccessible memory during USB hub event processing.
3. Possible fix: Investigate USB DMA buffer allocation and IOMMU domain configuration for qcs615-ride USB controller; verify SWIOTLB buffer pool initialization and physical address validity; check if recent device tree changes (PR modifies monaco-pmics.dtsi RTC node) inadvertently affected memory reservations or IOMMU mappings; enable CONFIG_DMA_API_DEBUG and CONFIG_IOMMU_DEBUGFS to trace DMA mapping operations during USB enumeration.
4. Detail analysis attachment: failed_case_job228602_4_detailed.md

Job 228603 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the GIC test script to query /sys/devices/system/cpu/online and only test CPUs that are currently online. Add input validation before integer comparison: if [[ "$count" =~ ^[0-9]+$ ]] to handle non-numeric fields. Skip offline CPUs with [SKIP] CPU X: offline, not tested log messages. This is a test infrastructure fix, not a kernel fix. PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 is not the cause and should be approved—it only modifies RTC properties in monaco-pmics.dtsi, unrelated to GIC or CPU topology.
4. Detail analysis attachment: failed_case_job228603_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform firmware/driver issues unrelated to PR changes — regulatory.db firmware file missing from rootfs (benign, WiFi functional via built-in regulatory rules) and Renesas USB controller firmware missing (benign, platform USB controllers functional, external PCIe USB controller not required for CI validation).
3. Possible fix: Suppress this test failure as a known benign infrastructure issue — both failures are pre-existing platform limitations (missing optional firmware files) that do not affect functional validation of the PR (which modifies only monaco-pmics.dtsi RTC node). If strict probe-failure-free validation is required, add regulatory.db and renesas_usb_fw.mem to the rootfs image.
4. Detail analysis attachment: failed_case_job228603_2_detailed.md

  Case 3: Test Infrastructure Issue — Offline CPU Check

1. Failed case: Test Infrastructure Issue — Offline CPU Check
2. Root cause: The Freq_Scaling test script checks for cpufreq interface on all CPUs 0-7 without first verifying which CPUs are online. On qcs6490-rb3gen2, CPU7 failed to boot during kernel initialization (psci: failed to boot CPU7 (-22) at boot time), leaving only CPUs 0-6 online. The test passes for cpu0-cpu6 but fails when checking cpu7, which has no cpufreq interface because it is offline. This is a pre-existing platform/firmware issue unrelated to PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 (which only modifies monaco-pmics.dtsi RTC property for a different SoC).
3. Possible fix: Update the Freq_Scaling test script to check only online CPUs by reading /sys/devices/system/cpu/online before iterating through CPU cpufreq interfaces. The test should skip offline CPUs or explicitly verify CPU online status before checking for cpufreq sysfs nodes.
4. Detail analysis attachment: failed_case_job228603_3_detailed.md

  Case 4: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** The qcs6490-rb3gen2 platform boots with the Gunyah hypervisor running at EL2, preventing KVM from initializing because KVM requires direct EL2 access which is already occupied by Gunyah.
3. Possible fix: This is not a kernel bug or PR-introduced regression—it is the expected behavior on platforms with a hypervisor at EL2. The KVM_Driver test should be skipped or marked as expected-fail for qcs6490-rb3gen2 (and other Gunyah-enabled platforms) in the LAVA test suite configuration.
4. Detail analysis attachment: failed_case_job228603_4_detailed.md

  Case 5: ** KVM_EL2_DTB (also KVM_Driver, KVM_Infra)

1. Failed case: ** KVM_EL2_DTB (also KVM_Driver, KVM_Infra)
2. Root cause: ** Platform limitation — qcs6490-rb3gen2 boots under Gunyah hypervisor at EL1, preventing KVM initialization which requires EL2. The kernel correctly detects "HYP mode not available" and skips KVM device creation. This is not a kernel bug or PR-introduced regression; it is the expected behavior on Gunyah-enabled platforms.
3. Possible fix: Suppress KVM tests on qcs6490-rb3gen2 (and other Gunyah-enabled platforms) in the LAVA test suite, or configure the platform firmware to boot Linux at EL2 without Gunyah if KVM functionality is required. The PR patch (RTC property change) is unrelated and does not need modification.
4. Detail analysis attachment: failed_case_job228603_5_detailed.md

  Case 6: KVM Infrastructure Test Failure — KVM Not Available (Pre-existing Platform Limitation)

1. Failed case: KVM Infrastructure Test Failure — KVM Not Available (Pre-existing Platform Limitation)
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the platform is running under the Gunyah hypervisor in a configuration that does not expose EL2/HYP mode to the Linux kernel. The kernel message "kvm [1]: HYP mode not available" indicates KVM's initialization check failed because it cannot access the required CPU virtualization extensions (EL2 exception level). This is a platform/firmware configuration issue, not a kernel regression.
3. Possible fix: This is not a PR-introduced regression (the PR only modifies RTC DT properties for monaco/qcs8300, unrelated to qcs6490 or KVM). The KVM tests should be skipped or marked as expected-fail for qcs6490-rb3gen2 when running under Gunyah in this configuration. To enable KVM on this platform, the Gunyah hypervisor configuration would need to be changed to allow nested virtualization or the board would need to boot without Gunyah (native EL2 mode). For CI purposes, add a platform-specific test skip rule for KVM tests on qcs6490-rb3gen2 under Gunyah.
4. Detail analysis attachment: failed_case_job228603_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM/virtualization is not available on qcs6490-rb3gen2 (Kodiak) because the platform does not support HYP mode (EL2 hypervisor exception level). The kernel message "kvm [1]: HYP mode not available" at boot time indicates the hardware/firmware does not provide EL2 virtualization support, preventing /dev/kvm device creation.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR only modifies RTC device tree properties for monaco-pmics.dtsi and does not affect KVM functionality. The test should be skipped on platforms without HYP mode support, or the test suite should be updated to mark this as an expected skip rather than a failure on non-virtualization-capable platforms like qcs6490-rb3gen2.
4. Detail analysis attachment: failed_case_job228603_7_detailed.md

Job 228604 | SoC shikra-iqs-evk

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

No failed cases detected from the LAVA results section.

Job 228605 | SoC monaco-evk

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

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

  Case 1: ** Probe_Failure_Check — ath11k_pci driver probe failure

1. Failed case: ** Probe_Failure_Check — ath11k_pci driver probe failure
2. Root cause: ** ath11k_pci PCIe WiFi driver probe failed with -ETIMEDOUT (-110) during MHI power-up because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory, causing MHI initialization to time out waiting for the firmware to load.
3. Possible fix: Add the missing ath11k WCN6855 firmware files to the rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin, m3.bin, and regdb.bin. These firmware files are available in the linux-firmware repository or from Qualcomm's firmware package for WCN6855 hardware.
4. Detail analysis attachment: failed_case_job228605_1_detailed.md

  Case 2: Driver Probe Failure — WiFi_Firmware_Driver

1. Failed case: Driver Probe Failure — WiFi_Firmware_Driver
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image. The MHI (Modem Host Interface) subsystem failed to load the firmware (error -2 / -ENOENT), causing the WiFi chip power-up sequence to timeout. This is a pre-existing infrastructure/image packaging issue, not introduced by PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 (which only modifies an RTC DT property in monaco-pmics.dtsi).
3. Possible fix: Add the missing WCN6855 nfa765 variant firmware files to the Yocto/buildroot recipe that packages /lib/firmware/ath11k/ for monaco-evk images. Specifically, ensure ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files are included in the linux-firmware package or equivalent firmware deployment mechanism for this target.
4. Detail analysis attachment: failed_case_job228605_2_detailed.md

  Case 3: WiFi_OnOff — WiFi driver probe failure

1. Failed case: WiFi_OnOff — WiFi driver probe failure
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image (firmware load failed with error -2 = ENOENT), causing MHI (Modem Host Interface) power-up to timeout during driver initialization at boot.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image build recipe (Yocto/meta-qcom layer) for monaco-evk target, or verify that the linux-firmware package version includes this firmware variant and is correctly installed in the image.
4. Detail analysis attachment: failed_case_job228605_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA marked the test run as failed due to "unfinished test run" — the test suite completed all individual tests (including passes and failures), but LAVA's test runner detected that the overall test definition did not complete successfully. The actual root cause is three genuine test failures: (1) Probe_Failure_Check failed due to ath11k_pci WiFi driver probe failure with error -110 (timeout), (2) WiFi_Firmware_Driver failed due to the same ath11k_pci probe failure, and (3) WiFi_OnOff failed due to the same ath11k_pci probe failure. All three failures stem from a single hardware/firmware issue: the ath11k WiFi PCIe device (WCN6855) failed to initialize during boot on the monaco-evk platform.
3. Possible fix: This is NOT a PR-introduced regression — the PR only removes the 'allow-set-time' property from the RTC node in monaco-pmics.dtsi, which is unrelated to WiFi/PCIe functionality. The ath11k_pci probe failure is a pre-existing platform/firmware/hardware issue on the monaco-evk board. Recommended action: (1) Verify WiFi firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin and related) are present in the rootfs, (2) Check PCIe link training and MHI state machine logs for the WCN6855 device, (3) Verify the board's PCIe slot and WiFi module hardware are functioning, (4) Re-trigger the CI job to rule out transient hardware failure. If the issue persists across multiple runs, escalate to the monaco-evk platform maintainers as a board-specific WiFi bring-up issue, not a kernel regression.
4. Detail analysis attachment: failed_case_job228605_4_detailed.md

Job 228606 | SoC qcs9100-ride

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

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

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** Three pre-existing platform configuration issues on qcs9100-ride: (1) Four PMIC temp-alarm devices (pmic@0/2/4/6:temp-alarm@a00) stuck in deferred probe due to missing thermal zone definitions in device tree, (2) Aquantia AQR115C Ethernet PHY probe failure (error -22) due to missing firmware-name property in PHY device tree node, (3) regulatory.db firmware file not found (error -2, benign fallback to built-in rules).
3. Possible fix: For CI: Update Probe_Failure_Check test to suppress benign failures (temp-alarm deferred probes and regulatory.db) while keeping PHY failure visible. For platform: Add thermal zone definitions for all four PMIC temp-alarm sensors in qcs9100-ride device tree, add firmware-name = "Rhe-05.06-Candidate9-AQR_CIG_WF-1.8.3-XENPAK.cld" property to Aquantia PHY node at MDIO address 0x8, and optionally add regulatory.db to rootfs firmware directory. PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 is not responsible for these failures (modifies Monaco PMIC RTC, not qcs9100 platform).
4. Detail analysis attachment: failed_case_job228606_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — the video codec device aa00000.video-codec is not attached to any IOMMU group on qcs9100-ride-sx, causing the smmu test's critical master protection check to fail; this is a pre-existing platform configuration issue unrelated to the PR (which only modifies RTC properties in monaco-pmics.dtsi).
3. Possible fix: This is a pre-existing platform/DT configuration issue on qcs9100-ride-sx where the video codec device tree node lacks proper iommus property binding; the PR changes (RTC property removal in monaco-pmics.dtsi) are unrelated and should not block merge; recommend filing a separate issue to add IOMMU binding for the video codec device in qcs9100-ride-sx.dts.
4. Detail analysis attachment: failed_case_job228606_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: "failed to read firmware-name: -22". Error -22 is EINVAL, indicating a DT property validation failure. This matches "Possibility 2: Driver initialization failures (probe hard-fails)" and "Possibility 3: Driver not loading because of dependencies" from the CoT.
3. Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY device tree node in the qcs9100-ride DTS/DTSI file, specifying the correct firmware filename (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld";), and ensure the corresponding firmware file is present in the rootfs under /lib/firmware/.
4. Detail analysis attachment: failed_case_job228606_3_detailed.md

  Case 4: ** KVM_Driver — Platform Capability Limitation (EL2 Not Available)

1. Failed case: ** KVM_Driver — Platform Capability Limitation (EL2 Not Available)
2. Root cause: ** The qcs9100-ride (LeMans) platform does not support ARM EL2 (Hypervisor mode), which is a mandatory hardware requirement for KVM. The kernel correctly detects this limitation during KVM initialization and reports "kvm [1]: HYP mode not available" (log line with timestamp 2026-09-17T08:14:21.582534). As a result, the KVM driver does not create /dev/kvm, causing the test to fail. This is expected behavior for platforms without virtualization extensions, not a kernel bug.
3. Possible fix: Exclude KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the CI test suite for qcs9100-ride and other LeMans-based platforms that lack EL2 support. Update the LAVA job definition to skip virtualization tests on platforms without hardware virtualization capabilities. Alternatively, mark these tests as "expected to skip" for this platform in the test framework.
4. Detail analysis attachment: failed_case_job228606_4_detailed.md

  Case 5: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: qcs9100-ride platform does not support ARM Virtualization Extensions (HYP mode/EL2). Kernel boot message shows kvm [1]: HYP mode not available, causing KVM driver to skip /dev/kvm device creation. This is a hardware/firmware platform limitation, not a kernel software bug.
3. Possible fix: Skip KVM tests for qcs9100-ride in the LAVA test definition by adding platform detection logic that checks for "Lemans Ride" in /sys/firmware/devicetree/base/model and marks KVM_EL2_DTB, KVM_Driver, and KVM_Infra as skipped rather than failed. This is not a PR-introduced regression - the PR only modifies RTC device tree for monaco/qcs8300 SoC and has no relationship to KVM functionality.
4. Detail analysis attachment: failed_case_job228606_5_detailed.md

  Case 6: KVM Infrastructure Test Failure — Platform Architecture Limitation

1. Failed case: KVM Infrastructure Test Failure — Platform Architecture Limitation
2. Root cause: KVM driver initialization failed because qcs9100-ride platform runs with Gunyah hypervisor at EL2, making HYP mode unavailable to the Linux kernel. KVM requires direct EL2 access which is not available when a hypervisor is already running.
3. Possible fix: Disable KVM tests for qcs9100-ride platform in CI configuration, or configure the platform to boot without hypervisor when KVM testing is required. This is not a kernel bug - it's an expected architectural constraint.
4. Detail analysis attachment: failed_case_job228606_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize because Gunyah hypervisor is running at EL2 on qcs9100-ride-sx, making HYP mode unavailable to KVM. The kernel correctly reports "kvm [1]: HYP mode not available" and does not create /dev/kvm. This is a platform configuration issue, not a kernel bug.
3. Possible fix: Either (1) disable Gunyah hypervisor in the boot configuration if KVM testing is required, or (2) skip KVM tests on platforms configured with Gunyah hypervisor, or (3) use a nested virtualization configuration if Gunyah supports it. This is not a PR-introduced issue — the PR only modifies an RTC property unrelated to virtualization.
4. Detail analysis attachment: failed_case_job228606_7_detailed.md

Job 228607 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in deferred probe state at test time, and three benign Bluetooth firmware load failures (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv, regulatory.db) are flagged by the test despite Bluetooth functionality being confirmed working (BT_ON_OFF test passed).
3. Possible fix: The Bluetooth firmware failures are false positives (suppressed per lava-known-benign-failures.md Rule 3 — BT_ON_OFF passed). The temp-alarm deferred probes are a pre-existing platform issue on lemans-evk unrelated to this PR (which only modifies monaco-pmics.dtsi RTC node). Adjust the Probe_Failure_Check test to suppress known-benign firmware failures and exclude temp-alarm deferred probes for lemans-evk, or investigate why the qcom_spmi_temp_alarm driver is not completing probe for these four PMIC devices.
4. Detail analysis attachment: failed_case_job228607_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device node aa00000.video-codec in the lemans-evk device tree lacks the required iommus property, preventing IOMMU group attachment during kernel boot; this is a pre-existing DT configuration gap unrelated to the PR (which only modifies RTC properties in monaco-pmics.dtsi).
3. Possible fix: Add the iommus property to the aa00000.video-codec node in the lemans-evk device tree (arch/arm64/boot/dts/qcom/sa8775p.dtsi or board-specific overlay) referencing the appropriate SMMU instance and stream ID, following the pattern used by other video subsystem devices (iris_non_pixel, iris_pixel) which are correctly attached to IOMMU groups 25 and 26.
4. Detail analysis attachment: failed_case_job228607_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Test suite marked as incomplete/failed due to two pre-existing test failures (Probe_Failure_Check and smmu) that are unrelated to the PR changes. The PR modifies monaco-pmics.dtsi (Monaco SoC RTC node) but the test ran on lemans-evk (Le Mans SoC), making the patch completely orthogonal to the test failures.
3. Possible fix: Re-trigger the CI job. The failures are pre-existing infrastructure/test issues not introduced by this PR: (1) Probe_Failure_Check fails due to deferred probe warnings for PMIC temp-alarm devices and missing firmware files (regulatory.db, Bluetooth firmware) which are known benign issues on this platform; (2) smmu test fails because video-codec device (aa00000.video-codec) is missing IOMMU group attachment, a pre-existing device tree or driver issue on lemans-evk unrelated to Monaco RTC changes.
4. Detail analysis attachment: failed_case_job228607_3_detailed.md

Job 228608 | SoC hamoa-evk

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

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

  Case 1: ** Probe_Failure_Check — Pre-existing Driver Probe Failures (Not PR-Introduced)

1. Failed case: ** Probe_Failure_Check — Pre-existing Driver Probe Failures (Not PR-Introduced)
2. Root cause: ** The test detected three pre-existing probe failures on the hamoa-evk platform: (1) qcom_qseecom_uefisecapp fails with -EBUSY due to secure world resource contention or firmware limitation, (2) qcom-spmi-lpg fails with -EINVAL due to invalid multi-LED device tree configuration in the platform DT, and (3) regulatory.db firmware file is missing from rootfs (benign — WiFi functional tests pass). None of these failures are introduced by PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131, which only removes the RTC allow-set-time property from monaco-pmics.dtsi.
3. Possible fix: Mark this test case as a false positive for PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131. The three probe failures are pre-existing platform issues unrelated to the RTC property change. To resolve the underlying issues: (1) investigate QSEECOM secure app resource allocation with TZ firmware team, (2) correct the LPG multi-LED reg property in the hamoa platform device tree, (3) optionally add regulatory.db to rootfs or suppress this benign warning (WiFi already functional).
4. Detail analysis attachment: failed_case_job228608_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — the smmu test expects USB wrapper devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec device (aa00000.video-codec) to have IOMMU group attachments, but these devices either do not exist in the hamoa-evk device tree or are wrapper devices that do not receive IOMMU groups (the actual USB controllers at a000000.usb, a200000.usb, a400000.usb, a600000.usb, a800000.usb do have IOMMU groups 10, 11, 12, 9, 13 respectively).
3. Possible fix: Update the smmu test script to check for the actual USB controller devices (a000000.usb, a200000.usb, etc.) instead of their wrapper devices (a0f8800.usb, a2f8800.usb, etc.), and make the video codec check conditional based on platform — the hamoa-evk platform does not include a video codec device at aa00000, so this check should be skipped or the test should verify the device exists in the device tree before requiring IOMMU attachment.
4. Detail analysis attachment: failed_case_job228608_2_detailed.md

  Case 3: KVM_Driver — Platform Capability Limitation (EL2/Hypervisor Mode Not Available)

1. Failed case: KVM_Driver — Platform Capability Limitation (EL2/Hypervisor Mode Not Available)
2. Root cause: The Hamoa IoT EVK platform does not support ARM EL2 (hypervisor mode), which is required for KVM. During kernel boot, KVM initialization detected HYP mode not available and aborted, preventing /dev/kvm device node creation. This is a platform hardware/firmware limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Mark KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) as SKIP for Hamoa IoT EVK in the LAVA test suite configuration. Update the test runner to check platform capabilities and automatically skip KVM tests on platforms without EL2 support. Document the platform KVM support matrix to prevent future false-positive failures.
4. Detail analysis attachment: failed_case_job228608_3_detailed.md

  Case 4: KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)

1. Failed case: KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)
2. Root cause: KVM initialization failed during kernel boot because the Hamoa IoT EVK platform does not support ARM EL2 (Hypervisor) mode, which is a hardware prerequisite for KVM virtualization. The kernel message "kvm [1]: HYP mode not available" at boot time (6.391598s) indicates the CPU is not running with virtualization extensions enabled or the platform firmware does not configure EL2 access.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. The KVM tests should be skipped on Hamoa IoT EVK in the CI test suite, as this platform does not support virtualization. Add platform-specific test filtering to exclude KVM tests for hamoa-evk in the LAVA job definition.
4. Detail analysis attachment: failed_case_job228608_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on Hamoa IoT EVK because the Gunyah hypervisor is running at EL2, preventing KVM from accessing HYP mode. The kernel correctly reports "HYP mode not available" and does not create /dev/kvm.
3. Possible fix: This is a platform architectural limitation, not a kernel bug. To enable KVM testing on Hamoa: (1) boot without the Gunyah hypervisor, or (2) use nested virtualization if Gunyah supports it, or (3) exclude KVM tests from the Hamoa test suite as the platform is configured for Gunyah-based virtualization, not KVM.
4. Detail analysis attachment: failed_case_job228608_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM subsystem failed to initialize because the CPU is not running in HYP (EL2/hypervisor) mode on the hamoa-evk platform; kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by the PR (which only modifies RTC device tree properties for monaco-pmics). The hamoa-evk board firmware does not boot the kernel in EL2 mode, which is a prerequisite for KVM. To enable KVM on this platform, the bootloader/firmware must be configured to boot the kernel at EL2 instead of EL1, or the test should be skipped on platforms without hypervisor support.
4. Detail analysis attachment: failed_case_job228608_6_detailed.md

Job 228609 | SoC purwa-evk

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

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

  Case 1: Probe_Failure_Check — Pre-existing Driver Probe Failures (Not PR-Introduced)

1. Failed case: Probe_Failure_Check — Pre-existing Driver Probe Failures (Not PR-Introduced)
2. Root cause: The Probe_Failure_Check test detected 5 pre-existing driver probe failures on purwa-evk (Monaco/iq-x5121-evk): qcom_qseecom_uefisecapp (-EBUSY), two qcom-pcie instances (-ENODATA), qcom-spmi-lpg (-EINVAL), and regulatory.db firmware (-ENOENT). These failures are unrelated to PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131, which only removes the 'allow-set-time' property from the RTC node in monaco-pmics.dtsi and does not touch any of the failing drivers or their dependencies.
3. Possible fix: These are baseline platform issues that existed before this PR. The PR should not be blocked by this test failure. Recommended actions: (1) Add these known probe failures to the platform-specific baseline suppression list for purwa-evk, or (2) File separate issues to investigate each probe failure: qcom_qseecom_uefisecapp resource conflict, PCIe controller configuration (likely board-specific — no PCIe devices populated), qcom-spmi-lpg DT binding mismatch, and missing regulatory.db firmware file in rootfs.
4. Detail analysis attachment: failed_case_job228609_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Six critical DMA masters (five USB controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800, and video codec aa00000) are missing IOMMU group attachments in the purwa-evk device tree, causing the SMMU validation test to fail despite no runtime SMMU/IOMMU errors in dmesg.
3. Possible fix: Add missing iommus properties to the device tree nodes for USB controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb, and video-codec aa00000.video-codec in the purwa-evk DTS file, referencing the appropriate SMMU phandle and stream IDs.
4. Detail analysis attachment: failed_case_job228609_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM tests from the purwa-evk test suite, as this platform uses Gunyah hypervisor and does not support KVM. Alternatively, if KVM support is required, boot without Gunyah hypervisor (requires firmware/bootloader configuration change to not load Gunyah).
4. Detail analysis attachment: failed_case_job228609_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM initialization failure (HYP mode not available)

1. Failed case: KVM_EL2_DTB — KVM initialization failure (HYP mode not available)
2. Root cause: The purwa-evk target is running as a guest VM under the Gunyah hypervisor (confirmed by "Hypervisor cold boot, version: gunyah-mobile-ad1fb25c6" at boot), and KVM requires exclusive access to EL2 (hypervisor mode) which is already occupied by Gunyah. Nested virtualization is not supported in this configuration.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The test expectation is incorrect for this platform configuration. Either: (1) skip KVM tests on purwa-evk when running under Gunyah hypervisor, or (2) run purwa-evk in bare-metal mode (without Gunyah) if KVM testing is required. Update the LAVA job definition to conditionally skip KVM tests when hypervisor presence is detected.
4. Detail analysis attachment: failed_case_job228609_4_detailed.md

  Case 5: KVM Infrastructure Failure — /dev/kvm unavailable (KVM disabled by hypervisor)

1. Failed case: KVM Infrastructure Failure — /dev/kvm unavailable (KVM disabled by hypervisor)
2. Root cause: The purwa-evk platform boots under the Gunyah hypervisor (gunyah-mobile-ad1fb25c6), which does not expose EL2/HYP mode to the Linux kernel. KVM initialization fails with "kvm [1]: HYP mode not available" at boot time because Gunyah reserves EL2 for its own use and does not provide nested virtualization support to the primary VM. CONFIG_KVM is enabled in the kernel configuration, but the /dev/kvm device node is never created because the KVM subsystem cannot initialize without access to EL2.
3. Possible fix: This is a platform architecture limitation, not a kernel bug or PR-introduced regression. The PR (RTC property removal in monaco-pmics.dtsi) is unrelated to KVM/virtualization. To enable KVM on purwa-evk, either: (1) configure Gunyah to expose nested virtualization support (if supported by the hypervisor version), or (2) boot the platform without Gunyah (bare-metal mode) if KVM testing is required. For CI purposes, mark KVM tests as "expected skip" on Gunyah-based platforms, or exclude purwa-evk from KVM test suites until nested virtualization support is available.
4. Detail analysis attachment: failed_case_job228609_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not created; kernel reports kvm [1]: HYP mode not available during boot, indicating the platform (purwa-evk) does not provide EL2 (hypervisor) privilege level access to Linux, which is a prerequisite for KVM functionality.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by the PR (which only modifies RTC DT properties for monaco-pmics). If KVM support is required on purwa-evk, verify that: (1) the bootloader/firmware is configured to boot Linux at EL2 or provide virtualization extensions, (2) the SoC hardware supports virtualization extensions, and (3) the secure firmware (TrustZone) allows EL2 access. If KVM is not expected to work on this platform, mark the KVM tests as expected failures or skip them in the CI configuration for purwa-evk.
4. Detail analysis attachment: failed_case_job228609_6_detailed.md

Job 228610 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing, platform-specific probe failures unrelated to PR BACKPORT: arm64: dts: qcom: qcs8300: pmic: Remove 'allow-set-time' property #1131 (RTC DT property change): (1) cfg80211 regulatory.db firmware file missing from rootfs (error -2 / -ENOENT), and (2) Aquantia AQR115C Ethernet PHY driver failing to read required DT property firmware-name (error -22 / -EINVAL) on qcs8300-ride platform.
3. Possible fix: These are pre-existing platform/configuration issues, not regressions introduced by this PR. (1) Add regulatory.db firmware file to the rootfs image or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB if regulatory enforcement is not required. (2) Add the missing firmware-name property to the Aquantia PHY DT node in qcs8300-ride device tree, or verify the PHY hardware revision does not require firmware and update the driver's DT binding requirements accordingly.
4. Detail analysis attachment: failed_case_job228610_1_detailed.md

  Case 2: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Ethernet PHY (Aquantia AQR115C at MDIO address stmmac-0:08) probe failed with -EINVAL because the device tree PHY node is missing the required firmware-name property, preventing the qcom-ethqos Ethernet driver from attaching to the PHY and bringing up the eth0 interface.
3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs8300-ride device tree (arch/arm64/boot/dts/qcom/qcs8300-ride.dts or qcs8300.dtsi), specifying the correct Aquantia firmware file path (typically "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld" or similar for AQR115C), then rebuild the DTB and retest.
4. Detail analysis attachment: failed_case_job228610_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver failed to initialize and create /dev/kvm device node despite CONFIG_KVM being enabled in kernel config. The qcs8300-ride (Monaco) platform either lacks hardware virtualization support (VHE/nVHE), has hypervisor mode disabled in firmware/bootloader, or the KVM ARM driver failed to probe due to missing CPU feature flags or EL2 unavailability.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only modifies RTC DT property). Verify: (1) CPU supports ARM virtualization extensions (check /proc/cpuinfo for "vhe" or EL2 capability), (2) bootloader/firmware enables EL2 mode, (3) check dmesg for KVM initialization errors during early boot. If qcs8300-ride does not support KVM, mark these tests as "not applicable" for this platform in CI configuration.
4. Detail analysis attachment: failed_case_job228610_3_detailed.md

  Case 4: KVM_EL2_DTB — /dev/kvm not available (platform configuration issue)

1. Failed case: KVM_EL2_DTB — /dev/kvm not available (platform configuration issue)
2. Root cause: The qcs8300-ride platform is running Linux as a guest under the Gunyah hypervisor (EL1), not at EL2 (hypervisor mode). KVM requires the kernel to run at EL2 to provide virtualization capabilities. The /dev/kvm device node is not created because the KVM driver cannot initialize when Linux lacks EL2 access. This is a pre-existing platform/firmware configuration issue, not a regression introduced by the PR (which only removes an RTC DT property).
3. Possible fix: This is not a PR-introduced failure and does not block merge. To enable KVM on this platform: (1) reconfigure the boot firmware to boot Linux directly at EL2 instead of under Gunyah, OR (2) skip KVM tests on platforms configured with Gunyah hypervisor, OR (3) if nested virtualization support is required, enable it in the Gunyah hypervisor configuration (if supported by the platform).
4. Detail analysis attachment: failed_case_job228610_4_detailed.md

  Case 5: KVM Infrastructure Test — /dev/kvm device unavailable (pre-existing platform configuration issue, not PR-introduced)

1. Failed case: KVM Infrastructure Test — /dev/kvm device unavailable (pre-existing platform configuration issue, not PR-introduced)
2. Root cause: KVM driver did not initialize because the QCS8300 Ride platform is running as a guest under Gunyah hypervisor (version gunyah-cdfb73831). KVM on ARM requires EL2 (hypervisor exception level) access to provide virtualization services, but when running as a guest under Gunyah, the Linux kernel operates at EL1 (kernel mode) only. ARM architecture does not support nested virtualization, so KVM cannot function in this configuration. CONFIG_KVM=y is enabled, but the driver silently skips initialization when EL2 is unavailable, resulting in no /dev/kvm device node creation.
3. Possible fix: This is expected behavior, not a bug. The PR (RTC property removal) did not cause this failure. Recommended actions: (1) Skip KVM tests on Gunyah-based platform configurations in CI, OR (2) Test KVM functionality on bare-metal or VHE-enabled configurations where the kernel has direct EL2 access. To implement option 1, add platform detection logic to the LAVA test definition to skip KVM tests when "Gunyah based bootup" is detected in boot logs.
4. Detail analysis attachment: failed_case_job228610_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA Test Framework Issue)
2. Root cause: LAVA test runner completed all tests but failed to properly signal completion to the LAVA dispatcher, causing LAVA to mark the test definition as "unfinished" and fail the overall job despite the test runner successfully completing (<LAVA_TEST_RUNNER EXIT> present at line 6349).
3. Possible fix: This is a LAVA test framework/infrastructure issue, not a kernel regression. The PR changes (removing 'allow-set-time' from RTC DT node) are unrelated to this failure. Re-trigger the LAVA job. If the issue persists, investigate the LAVA test runner's completion signaling mechanism — specifically why lava_test_shell reported "ok: lava_test_shell seems to have completed" but LAVA still marked it as "unfinished". Check if the test definition's exit handler or result aggregation script is missing a required LAVA signal.
4. Detail analysis attachment: failed_case_job228610_6_detailed.md