Add stats compatible and config for Shikra by smankad-oss · Pull Request #833 · qualcomm-linux/kernel

smankad-oss · 2026-07-16T08:06:33Z

SoC LPM stats are present in RPM MSGRAM and subsystem LPM stats are
present in SMEM for Shikra.

For earlier targets using RPM processor like msm8974, rpm_master_stat.c was
used for subsystem LPM stats since those stats were populated in RPM
MSGRAM.

qcom_stats.c supports both the configurations for shikra, reading subsystem
LPM stats from SMEM and reading SoC LPM stats from RPM MSGRAM.

A generic "qcom,rpm-stats" compatible only reads SoC LPM stats like vmin
and vlow. Add shikra rpm compatible and config to read subsystem LPM
stats too along with SoC LPM stats.

CRs-Fixed: 4539405

qlijarvis · 2026-07-16T08:59:07Z

PR #833 — validate-patch

PR: #833

Verdict	Issues	Detailed Report
❌	3	Full report

Final Summary

Lore link present: No — no lore.kernel.org Link tags found in any of the 3 commits
Lore link matches PR commits: N/A — no lore link to compare against
Upstream patch status: Unknown — cannot determine without lore link; however, presence of Reviewed-by tags from upstream maintainers (Konrad Dybcio) suggests these may have been posted to a mailing list
PR present in qcom-next/topics: Fail - 2/3 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #833 - Add Shikra rpm-stats support (3 commits)
Upstream commit: N/A
Verdict: ❌ FAIL

Commit Message

Check Status Note

Subject matches upstream N/A No lore link to compare against

Body preserves rationale N/A No lore link to compare against

Fixes tag present/correct ✅ No Fixes tag needed (new feature)

Authorship preserved N/A No lore link to compare against

Backport note (if applicable) N/A Not a backport

Diff

File Status Notes

Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml ⚠️ Cannot verify against upstream - no lore link

drivers/soc/qcom/qcom_stats.c ⚠️ Cannot verify against upstream - no lore link

arch/arm64/boot/dts/qcom/shikra.dtsi ⚠️ Cannot verify against upstream - no lore link

Issues

Critical:

No lore.kernel.org link found in any of the 3 commit messages. This skill only validates patches against a lore.kernel.org source.

No commit prefix (UPSTREAM:, FROMLIST:, BACKPORT:, QCLINUX:, etc.) to indicate the source or status of these changes.

Integration presence check failed: 2/3 commits are completely missing from both qcom-next and topics branches; 1/3 commit shows only partial evidence.

Observations:

All three commits have proper sign-offs and review tags (Reviewed-by: Konrad Dybcio, Maulik Shah)

Commit messages are well-structured with clear rationale

Changes appear to be new Shikra-specific functionality for rpm-stats

Verdict

Do not merge without correction. These commits lack the required upstream attribution. Each commit must include either:

A Link: https://lore.kernel.org/r/<message-id> tag if posted to a mailing list (use FROMLIST: prefix), or

A Link: https://git.kernel.org/... tag if merged upstream (use UPSTREAM: or BACKPORT: prefix), or

A QCLINUX: prefix if this is vendor-only code not intended for upstream

Additionally, the integration presence check shows these changes are not yet in qcom-next or topics, which is inconsistent with the presence of upstream review tags.

Final Summary

Lore link present: No — no lore.kernel.org Link tags found in any of the 3 commits

Lore link matches PR commits: N/A — no lore link to compare against

Upstream patch status: Unknown — cannot determine without lore link; however, presence of Reviewed-by tags from upstream maintainers (Konrad Dybcio) suggests these may have been posted to a mailing list

PR present in qcom-next/topics: Fail — 2/3 commits are missing from both qcom-next and topics; 1/3 shows only partial evidence (per integration_presence_report.md)

Recommendation

Add appropriate Link: tags and commit prefixes to all three commits:

If posted to linux-kernel mailing list: add FROMLIST: prefix and Link: https://lore.kernel.org/r/<message-id>

If merged to mainline: add UPSTREAM: prefix and Link: https://git.kernel.org/.../commit/?id=<sha>

If vendor-only: add QCLINUX: prefix (no link required)

Then re-run validation.

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/3 [PATCH 1/3] dt-bindings: soc: qcom: stats: Add compatible for Shikra missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing

2/3 [PATCH 2/3] soc: qcom: stats: Add stats compatible and config for 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

3/3 [PATCH 3/3] arm64: dts: qcom: shikra: Update rpm-stats compatible to 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/3
partial_commits: 1/3
missing_commits: 2/3
topics_checked_for_commits: 3/3
final_summary: PR present in qcom-next/topics: Fail - 2/3 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-16T08:59:08Z

PR #833 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	All commits pass style checks
dt-binding-check	✅	Binding schema validation passed
dtb-check	❌	Compatible array too long (schema mismatch)
sparse-check	✅	No sparse warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Missing required subject prefix on all 3 commits
tag-check	❌	Missing required subject prefix on all 3 commits

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #833 - Add Shikra rpm-stats support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/29482364177
Target branch: qcom-6.18.y

Checker Result Summary

checkpatch ✅ All commits pass style checks

dt-binding-check ✅ Binding schema validation passed

dtb-check ❌ Compatible array too long (schema mismatch)

sparse-check ✅ No sparse warnings

check-uapi-headers ✅ No UAPI changes

check-patch-compliance ❌ Missing required subject prefix on all 3 commits

tag-check ❌ Missing required subject prefix on all 3 commits

❌ dtb-check

Root cause: The binding schema only allows a single compatible string, but the DTS uses a 2-element array with a fallback compatible.

Failure details:
shikra-cqm-evk.dtb: sram@4690000 (qcom,shikra-rpm-stats): compatible: 
  ['qcom,shikra-rpm-stats', 'qcom,rpm-stats'] is too long
  from schema $id: http://devicetree.org/schemas/soc/qcom/qcom-stats.yaml#
This error appears for all 6 Shikra DTB files (cqm-evk, cqs-evk, iqs-evk, and their camera variants).

Analysis:

The DTS patch (3/3) changes the compatible from:
compatible = "qcom,rpm-stats";
to:
compatible = "qcom,shikra-rpm-stats", "qcom,rpm-stats";
This is a valid pattern (SoC-specific compatible with generic fallback), but the binding schema in patch 1/3 doesn't declare support for this. The schema currently has:
properties:
  compatible:
    items:
      - enum:
          - qcom,msm8226-rpm-stats
          - qcom,msm8916-rpm-stats
          - qcom,msm8974-rpm-stats
          - qcom,shikra-rpm-stats
This schema structure implicitly allows only maxItems: 1. To support the fallback pattern, the binding needs:
properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
      - items:
          - const: qcom,shikra-rpm-stats
          - const: qcom,rpm-stats
Or more simply, if all SoC-specific compatibles can use qcom,rpm-stats as fallback:
properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
      - items:
          - enum:
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
          - const: qcom,rpm-stats
Fix:

Update patch 1/3 to allow the fallback compatible pattern. Modify Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml:
properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
      - items:
          - const: qcom,shikra-rpm-stats
          - const: qcom,rpm-stats
Reproduce locally:
make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/shikra-cqm-evk.dtb
❌ check-patch-compliance

Root cause: All three commits lack the required subject-line prefix (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).

Failure details:
Checking commit: dt-bindings: soc: qcom: stats: Add compatible for Shikra
Commit summary does not start with a required prefix

Checking commit: soc: qcom: stats: Add stats compatible and config for Shikra
Commit summary does not start with a required prefix

Checking commit: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific
Commit summary does not start with a required prefix
Fix:

The check-patch-compliance checker enforces that commits must start with one of:

FROMLIST: — patch posted to mailing list (lore.kernel.org)

FROMGIT: — patch taken from a maintainer git tree

UPSTREAM: — patch merged into Linus's mainline tree

BACKPORT: — upstream patch backported with modifications

For each commit, amend the subject to add the appropriate prefix:
git rebase -i <base_sha>   # mark each commit as 'edit'

# For commit 1/3:
git commit --amend -m "FROMLIST: dt-bindings: soc: qcom: stats: Add compatible for Shikra"

# For commit 2/3:
git commit --amend -m "FROMLIST: soc: qcom: stats: Add stats compatible and config for Shikra"

# For commit 3/3:
git commit --amend -m "FROMLIST: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific"

git rebase --continue
If these patches have been posted to a mailing list, also add a Link: trailer pointing to the lore.kernel.org URL in each commit message body.

Note: The checker only accepts upstream-linkable prefixes. If these are vendor-only changes with no upstream equivalent, use QCLINUX: instead, but be aware that check-patch-compliance will still fail (this is a known limitation for vendor-only commits).

❌ tag-check

Root cause: All three commits lack the required subject-line prefix tag.

Applies because: The target branch is qcom-6.18.y, which is not qcom-next or qcom-next-staging. All branches except those two require every commit to start with a valid prefix tag.

Required prefix tags:

FROMLIST: — Patch posted to mailing list (lore.kernel.org)

FROMGIT: — Patch taken from a maintainer git tree

UPSTREAM: — Patch merged into Linus's mainline tree

BACKPORT: — Upstream patch backported with modifications

QCLINUX: — Vendor-only change with no upstream equivalent

PENDING: — Work-in-progress, not yet posted upstream

WORKAROUND: — Temporary fix not suitable for upstream

Failure details:

All three commits are missing a prefix:

30343a2420fd — "dt-bindings: soc: qcom: stats: Add compatible for Shikra"

a974768fde64 — "soc: qcom: stats: Add stats compatible and config for Shikra"

2599a9ae2751 — "arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific"

Fix:

Same as check-patch-compliance fix above — add the appropriate prefix to each commit subject. Choose the correct prefix based on the patch origin:

If posted to lore but not yet merged → FROMLIST:

If in a maintainer tree → FROMGIT:

If merged into Linus's tree → UPSTREAM:

If backported with modifications → BACKPORT:

If vendor-only, no upstream → QCLINUX:

Verdict

3 blockers must be fixed before merge:

dtb-check failure — Update the binding schema (patch 1/3) to allow the fallback compatible pattern used in the DTS (patch 3/3).

check-patch-compliance failure — Add required subject prefix (FROMLIST:, UPSTREAM:, etc.) to all three commits.

tag-check failure — Same as Adding Email Checker #2 (both checks enforce the same requirement for the qcom-6.18.y branch).

Recommended action:

Amend patch 1/3 to update the binding schema to support compatible = "qcom,shikra-rpm-stats", "qcom,rpm-stats";

Rebase all three commits to add the appropriate subject prefix (likely FROMLIST: if these are being upstreamed)

If posted upstream, add Link: trailers pointing to the lore.kernel.org URLs

Re-run CI to verify all checkers pass

qlijarvis · 2026-07-17T11:04:13Z

PR #833 — validate-patch

PR: #833

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

Lore link present: Yes — all 3 commits have valid lore.kernel.org links in Link: trailers
Lore link matches PR commits: Yes — all diffs are faithful to lore (patch 3/3 has context-only line number delta due to tree differences, but code change is identical)
Upstream patch status: ⏳ Decision Pending — posted Jul 13, 2026 (v3); all have Reviewed-by tags from subsystem reviewers; no maintainer merge/NAK signal yet
PR present in qcom-next/topics: Fail - 2/3 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #833 - Add subsystem LPM stats support for Shikra (3 commits)
Upstream commits:

Patch 1/3: https://lore.kernel.org/r/20260713-shikra_stats-v3-1-4be17121729d@oss.qualcomm.com

Patch 2/3: https://lore.kernel.org/r/20260713-shikra_stats-v3-2-4be17121729d@oss.qualcomm.com

Patch 3/3: https://lore.kernel.org/r/20260713-shikra_stats-v3-3-4be17121729d@oss.qualcomm.com
Verdict: ❌ FAIL

Commit Message

Check Patch 1/3 Patch 2/3 Patch 3/3 Note

Subject matches upstream ✅ ✅ ✅ All subjects match lore (with FROMLIST: prefix added)

Body preserves rationale ✅ ✅ ✅ All commit bodies faithfully preserve lore content

Fixes tag present/correct N/A N/A N/A No Fixes tags in upstream patches

Authorship preserved ✅ ✅ ✅ FROMLIST: original author Sneh Mankad <sneh.mankad@oss.qualcomm.com> present in Signed-off-by

Backport note (if applicable) N/A N/A N/A FROMLIST: prefix used correctly

Reviewed-by tags preserved ✅ ✅ ✅ All upstream review tags present

Diff

File Status Notes

Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml ✅ Patch 1/3: Identical to lore - adds qcom,shikra-rpm-stats compatible

drivers/soc/qcom/qcom_stats.c ✅ Patch 2/3: Identical to lore - adds rpm_data_shikra config and of_device_id entry

arch/arm64/boot/dts/qcom/shikra.dtsi ✅ Patch 3/3: Context-only delta (line 1510 in PR vs 535 in lore) - code change identical

Upstream Patch Status

Commit Community Verdict

Patch 1/3: dt-bindings: soc: qcom: stats: Add compatible for Shikra ⏳ Decision Pending — posted Jul 13, 2026; Reviewed-by from Maulik Shah; no merge/NAK signal found in thread

Patch 2/3: soc: qcom: stats: Add stats compatible and config for Shikra ⏳ Decision Pending — posted Jul 13, 2026; Reviewed-by from Konrad Dybcio and Maulik Shah; no merge/NAK signal found in thread

Patch 3/3: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific ⏳ Decision Pending — posted Jul 13, 2026; Reviewed-by from Konrad Dybcio; no merge/NAK signal found in thread

Analysis: All three patches were posted to lore.kernel.org on July 13, 2026 (v3 revision). Each has received formal Reviewed-by: tags from subsystem reviewers (Konrad Dybcio, Maulik Shah), which are positive signals. However, no maintainer has issued an applied, queued, or merged confirmation, and the patches are not yet present in torvalds/linux or stable trees. The series is under active review but not yet accepted into any maintainer tree.

Integration Presence (qcom-next/topics)

Per integration_presence_report.md (authoritative source):

Commit qcom-next topics Final Status

Patch 1/3: dt-bindings ❌ missing ❌ missing ❌ missing

Patch 2/3: soc: qcom: stats ⚠️ partial ❌ missing ⚠️ partial

Patch 3/3: arm64: dts ❌ missing ❌ missing ❌ missing

Overall: ❌ FAIL — 2/3 commits are missing from both qcom-next and topics; 1/3 has partial evidence only.

Issues

Integration presence failure: The PR commits are not present in the qcom-next integration branch or kernel-topics branches. Per the integration_presence_report.md:

Patch 1/3 (dt-bindings): missing from both qcom-next and topics

Patch 2/3 (soc driver): partial evidence in qcom-next (subject or partial tree match), but full change not verified; missing from topics

Patch 3/3 (dts): missing from both qcom-next and topics

Upstream status: All three patches are still under review on the mailing list (Decision Pending). While they have received Reviewed-by: tags from subsystem reviewers, no maintainer has confirmed acceptance or merge. The FROMLIST: prefix is appropriate for this state, but the patches should not be merged into qcom-next until they are accepted upstream or the prefix is changed to reflect their actual status.

Verdict

Do not merge. The PR commits are not present in qcom-next or topics, indicating they have not been integrated into the Qualcomm kernel tree. The FROMLIST: prefix is correct (patches posted to lore but not yet merged upstream), but the integration presence check failed. The patches should be integrated into qcom-next first before being accepted in this PR, or this PR should be the mechanism for adding them to qcom-next (in which case the integration check failure is expected and acceptable).

Recommendation: Clarify the intended workflow:

If this PR is meant to add these patches to qcom-next for the first time → the integration check failure is expected; verify that the patches are ready for integration (have sufficient review, no outstanding concerns).

If these patches should already be in qcom-next → investigate why they are missing and sync with the integration branch before merging this PR.

Final Summary

Lore link present: Yes — all 3 commits have valid lore.kernel.org links in Link: trailers

Lore link matches PR commits: Yes — all diffs are faithful to lore (patch 3/3 has context-only line number delta due to tree differences, but code change is identical)

Upstream patch status: ⏳ Decision Pending — posted Jul 13, 2026 (v3); all have Reviewed-by tags from subsystem reviewers; no maintainer merge/NAK signal yet

PR present in qcom-next/topics: No — FAIL: 2/3 commits missing from both qcom-next and topics; 1/3 has partial evidence only (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: a5cf3debd8c3c660711ad586ad4bb84e9ca42635
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final

1/3 [PATCH 1/3] FROMLIST: dt-bindings: soc: qcom: stats: Add compatible missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing

2/3 [PATCH 2/3] FROMLIST: soc: qcom: stats: Add stats compatible and 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

3/3 [PATCH 3/3] FROMLIST: arm64: dts: qcom: shikra: Update rpm-stats 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/3
partial_commits: 1/3
missing_commits: 2/3
topics_checked_for_commits: 3/3
final_summary: PR present in qcom-next/topics: Fail - 2/3 commit(s) are missing from both qcom-next and topics

qlijarvis · 2026-07-17T11:04:14Z

PR #833 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	Passed
dt-binding-check	✅	Passed
dtb-check	❌	Compatible array too long
sparse-check	✅	Passed (build errors are pre-existing)
check-uapi-headers	✅	Passed
check-patch-compliance	✅	Passed
tag-check	✅	All commits have FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #833 - FROMLIST: dt-bindings: soc: qcom: stats: Add compatible for Shikra (+ driver and DTS updates)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/29572317712

Checker Result Summary

checkpatch ✅ Passed

dt-binding-check ✅ Passed

dtb-check ❌ Compatible array too long

sparse-check ✅ Passed (build errors are pre-existing)

check-uapi-headers ✅ Passed

check-patch-compliance ✅ Passed

tag-check ✅ All commits have FROMLIST: prefix

❌ dtb-check

Root cause: The binding schema qcom-stats.yaml only allows a single compatible string (maxItems: 1 implicit), but the DTS patch adds a fallback compatible creating a 2-element array ["qcom,shikra-rpm-stats", "qcom,rpm-stats"].

Failure details:
/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dtb: 
  sram@4690000 (qcom,shikra-rpm-stats): compatible: ['qcom,shikra-rpm-stats', 'qcom,rpm-stats'] is too long
  from schema $id: http://devicetree.org/schemas/soc/qcom/qcom-stats.yaml#
This error appears for all 6 shikra DTB files:

shikra-cqm-evk.dtb

shikra-cqm-evk-imx577-camera.dtb

shikra-cqs-evk.dtb

shikra-cqs-evk-imx577-camera.dtb

shikra-iqs-evk.dtb

shikra-iqs-evk-imx577-camera.dtb

Analysis:

The PR consists of 3 patches:

Patch 1/3: Adds qcom,shikra-rpm-stats to the binding's enum list

Patch 2/3: Adds driver support for qcom,shikra-rpm-stats

Patch 3/3: Updates DTS to use compatible = "qcom,shikra-rpm-stats", "qcom,rpm-stats";

The binding schema in qcom-stats.yaml currently has:
properties:
  compatible:
    items:
      - enum:
          - qcom,apq8084-rpm-stats
          - qcom,msm8226-rpm-stats
          - qcom,msm8916-rpm-stats
          - qcom,msm8974-rpm-stats
          - qcom,shikra-rpm-stats    # Added by patch 1/3
This schema structure (items: - enum:) defines a single-item array — it only allows one compatible string. However, patch 3/3 uses a fallback compatible pattern with two strings.

Fix: Update patch 1/3 to allow the fallback compatible pattern. The binding schema should be:
properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - qcom,apq8084-rpm-stats
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
      - items:
          - const: qcom,shikra-rpm-stats
          - const: qcom,rpm-stats
Or more simply, if all SoC-specific compatibles should allow qcom,rpm-stats as fallback:
properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - qcom,apq8084-rpm-stats
              - qcom,msm8226-rpm-stats
              - qcom,msm8916-rpm-stats
              - qcom,msm8974-rpm-stats
              - qcom,shikra-rpm-stats
      - items:
          - enum:
              - qcom,shikra-rpm-stats
          - const: qcom,rpm-stats
Reproduce locally:
make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/shikra-cqm-evk.dtb
Alternative fix (if fallback is not needed):

If the fallback compatible is not actually required, simply remove it from patch 3/3:
-			compatible = "qcom,shikra-rpm-stats", "qcom,rpm-stats";
+			compatible = "qcom,shikra-rpm-stats";
However, based on the commit message stating "Keep 'qcom,rpm-stats' as fallback compatible", the intent is clearly to support the fallback pattern, so the binding schema fix is the correct approach.

Verdict

1 blocker must be fixed before merge:

The binding schema in patch 1/3 must be updated to allow the two-element compatible array used in patch 3/3. The current schema only permits a single compatible string, causing dtb-check validation failures across all shikra DTB files.

All other checkers passed successfully. The commits are properly formatted with FROMLIST: prefixes and include upstream lore.kernel.org links.

qswat-orbit-external · 2026-07-20T09:18:41Z

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.

qswat-orbit-external · 2026-07-20T09:45:02Z

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.

qcomlnxci · 2026-07-28T07:51:09Z

Test jobs on 57cc790

qcomlnxci · 2026-07-28T07:51:12Z

Test Matrix

Test Case	hamoa-iot-evk	lemans-evk	monaco-evk	qcs615-ride	qcs6490-rb3gen2	qcs8300-ride	qcs9100-ride-r3
BT_FW_KMD_Service	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	◻️	✅ Pass	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	◻️	✅ Pass	✅ Pass	⚠️ skip	✅ 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	◻️	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip
Freq_Scaling	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
IPA	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
OpenCV	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	◻️	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
RMNET	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
USBHost	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	◻️	✅ Pass	❌ Fail	⚠️ skip	✅ Pass	✅ Pass	✅ Pass
adsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
cdsp_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	◻️	✅ 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
remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
rngtest	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	◻️	❌ Fail	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
watchdog	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

Salendarsingh Gaud (sgaud-quic) · 2026-07-28T11:55:57Z

smankad-oss please check below dtb-check failure :

❌ dtb-check
Root cause: The binding schema qcom-stats.yaml only allows a single compatible string (maxItems: 1 implicit), but the DTS patch adds a fallback compatible creating a 2-element array ["qcom,shikra-rpm-stats", "qcom,rpm-stats"].

qlijarvis · 2026-08-10T10:21:07Z

PR #833 — validate-patch

PR: #833

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

Lore link present: Yes — all three commits have valid lore.kernel.org v3 links
Lore link matches PR commits: Partial — patches 1/3 and 2/3 are identical; patch 3/3 has intentional deviation to fix dtschema validation error reported on lore
Upstream patch status: ⏳ Decision Pending — all three patches have Reviewed-by tags; patch 3/3 has outstanding dtschema validation error that this PR correctly fixes
PR present in qcom-next/topics: Partial - 1/3 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #833 - Add subsystem LPM stats support for Shikra (3 commits)
Upstream commits: https://lore.kernel.org/r/20260713-shikra_stats-v3-0-4be17121729d@oss.qualcomm.com
Verdict: ⚠️ PARTIAL — Patch 3/3 has intentional deviation from lore to fix dtschema validation error

Commit 1/3: dt-bindings: soc: qcom: stats: Add compatible for Shikra

Lore link: https://lore.kernel.org/r/20260713-shikra_stats-v3-1-4be17121729d@oss.qualcomm.com

Check Status Note

Subject matches upstream ✅ Identical (with FROMLIST: prefix added)

Body preserves rationale ✅ Identical

Fixes tag present/correct N/A No Fixes tag in upstream

Authorship preserved ✅ From: Sneh Mankad matches lore author; Signed-off-by present

Backport note N/A FROMLIST: prefix used correctly

Diff comparison:

File Status Notes

Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml ✅ Identical — adds qcom,shikra-rpm-stats compatible

Commit 2/3: soc: qcom: stats: Add stats compatible and config for Shikra

Lore link: https://lore.kernel.org/r/20260713-shikra_stats-v3-2-4be17121729d@oss.qualcomm.com

Check Status Note

Subject matches upstream ✅ Identical (with FROMLIST: prefix added)

Body preserves rationale ✅ Identical — includes detailed table and example output

Fixes tag present/correct N/A No Fixes tag in upstream

Authorship preserved ✅ From: Sneh Mankad matches lore author; Signed-off-by present

Backport note N/A FROMLIST: prefix used correctly

Diff comparison:

File Status Notes

drivers/soc/qcom/qcom_stats.c ✅ Identical — adds rpm_data_shikra config and of_device_id entry

Commit 3/3: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific

Lore link: https://lore.kernel.org/r/20260713-shikra_stats-v3-3-4be17121729d@oss.qualcomm.com

Check Status Note

Subject matches upstream ✅ Identical (with FROMLIST: prefix added)

Body preserves rationale ⚠️ Missing sentence: "Keep 'qcom,rpm-stats' as fallback compatible."

Fixes tag present/correct N/A No Fixes tag in upstream

Authorship preserved ✅ From: Sneh Mankad matches lore author; Signed-off-by present

Backport note N/A FROMLIST: prefix used correctly

Diff comparison:

File Status Notes

arch/arm64/boot/dts/qcom/shikra.dtsi ⚠️ Intentional deviation — PR removes fallback compatible to fix dtschema validation error

Diff detail:

Lore patch (v3):
-			compatible = "qcom,rpm-stats";
+			compatible = "qcom,shikra-rpm-stats", "qcom,rpm-stats";
PR patch:
-			compatible = "qcom,rpm-stats";
+			compatible = "qcom,shikra-rpm-stats";
Rationale for deviation: Komal Bajaj replied on lore (2026-07-28) reporting a dtschema validation error:

"arch/arm64/boot/dts/qcom/shikra-cqm-evk.dtb: sram@4690000 (qcom,shikra-rpm-stats): compatible: ['qcom,shikra-rpm-stats', 'qcom,rpm-stats'] is too long"

The PR correctly removes the fallback compatible to avoid this validation failure. The commit message should have documented this change.

Issues Found

Patch 3/3 commit message incomplete — The sentence "Keep 'qcom,rpm-stats' as fallback compatible." should be removed or replaced with "Remove fallback compatible to fix dtschema validation error (reported by Komal Bajaj on lore)."

Patch 3/3 diff intentionally differs from lore — The fallback compatible string is removed to fix a dtschema validation error discovered after the v3 posting. This is a legitimate fix but should be documented in the commit message.

Upstream Patch Status

All three patches in the series have been posted to lore.kernel.org as v3 on 2026-07-13.

Commit Community Verdict

1/3 dt-bindings ⏳ Decision Pending — Reviewed-by: Maulik Shah, no merge signal yet

2/3 soc: qcom: stats ⏳ Decision Pending — Reviewed-by: Konrad Dybcio, Maulik Shah; no merge signal yet

3/3 arm64: dts ⏳ Decision Pending — Reviewed-by: Konrad Dybcio; dtschema validation error reported by Komal Bajaj on 2026-07-28

Evidence: All three patches have formal Reviewed-by: tags from subsystem reviewers (Konrad Dybcio, Maulik Shah), indicating positive review. However, no maintainer has issued an "applied" or "queued" confirmation, and patch 3/3 has an outstanding validation error that needs to be addressed in a v4 revision.

Expected next step: Author should post v4 with the fallback compatible removed (matching this PR) and update the commit message to document the dtschema fix.

Integration Presence (from integration_presence_report.md)

Commit qcom-next topics Final

1/3 dt-bindings missing ✅ present (patch-id 505bb9ac6b0b) ✅ present

2/3 soc: qcom: stats partial ✅ present (patch-id b19d2ec290c8) ✅ present

3/3 arm64: dts missing partial ⚠️ partial

Overall integration status: PARTIAL — 2/3 commits fully present in topics, 1/3 commit has partial evidence.

Verdict

⚠️ PARTIAL — Merge with minor commit message fix

The PR faithfully represents the lore upstream for patches 1/3 and 2/3. Patch 3/3 has an intentional and correct deviation to fix a dtschema validation error discovered after the v3 posting. The code change is correct, but the commit message should document the reason for removing the fallback compatible.

Recommended action:
Amend commit 3/3 message to replace "Keep 'qcom,rpm-stats' as fallback compatible." with:
Remove fallback compatible to fix dtschema validation error:
"compatible: ['qcom,shikra-rpm-stats', 'qcom,rpm-stats'] is too long"
(Reported-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>)
Merge after commit message fix — The code is correct and addresses a real validation issue.

Upstream coordination — Author should post v4 to lore with this fix so the upstream and downstream versions converge.
Final Summary

Lore link present: Yes — all three commits have valid lore.kernel.org v3 links

Lore link matches PR commits: Partial — patches 1/3 and 2/3 are identical; patch 3/3 has intentional deviation to fix dtschema validation error reported on lore

Upstream patch status: ⏳ Decision Pending — all three patches have Reviewed-by tags; patch 3/3 has outstanding dtschema validation error that this PR correctly fixes

PR present in qcom-next/topics: Partial — 2/3 commits fully present in topics branch, 1/3 commit has partial integration evidence

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

Commit Subject qcom-next topics Final

1/3 [PATCH 1/3] FROMLIST: dt-bindings: soc: qcom: stats: Add compatible missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 505bb9a present

2/3 [PATCH 2/3] FROMLIST: soc: qcom: stats: Add stats compatible and partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at b19d2ec present

3/3 [PATCH 3/3] FROMLIST: arm64: dts: qcom: shikra: Update rpm-stats missing - no subject, patch-id, or full tree-content match found partial - subject or partial tree evidence found, but full change was not verified partial

Final Status

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

qlijarvis · 2026-08-10T10:21:09Z

PR #833 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	Passed
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed (no UAPI changes)
check-patch-compliance	❌	Content mismatch on commit 3/3
tag-check	✅	All commits have valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

Let me output the report directly:

🤖 Kernel Checker CI Failure Analysis

PR: #833
Run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31374803022
Target branch: qcom-6.18.y

Checker Result Summary

checkpatch ✅ Passed

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed (no UAPI changes)

check-patch-compliance ❌ Content mismatch on commit 3/3

tag-check ✅ All commits have valid FROMLIST: prefix

❌ check-patch-compliance

Root cause: Commit 3/3 ("FROMLIST: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific") has content differences from the upstream patch linked in the commit message.

Failure details:
Checking commit: FROMLIST: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific
Change is different from the one mentioned in Link
Analysis:

The checker detected that the patch content in the PR differs from the upstream patch at:
https://lore.kernel.org/r/20260713-shikra_stats-v3-3-4be17121729d@oss.qualcomm.com

This can happen for several reasons:

Context-only differences — surrounding lines differ due to tree state (not a real issue)

Legitimate adaptation — patch was modified for the target tree (should be documented)

Missing/extra hunks — incomplete backport or additional changes bundled in

Wrong Link — the Link: tag points to a different version of the patch

Fix:
Fetch the upstream patch and compare:
b4 am --single-message -C -l -3 \
  https://lore.kernel.org/r/20260713-shikra_stats-v3-3-4be17121729d@oss.qualcomm.com \
  -o /tmp/upstream

# Compare the actual diff content (ignoring context)
git format-patch -1 d7ed419b61752429a0c77eb7771a013f1c911a65 --stdout | \
  awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]' > /tmp/pr_changes.txt

awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | \
  grep -E '^[+-][^+-]' > /tmp/upstream_changes.txt

diff /tmp/pr_changes.txt /tmp/upstream_changes.txt
Classify the difference:
If context-only (no +/- line differences) → this is a false positive; the checker is overly strict
If legitimate adaptation → add a note in the commit message explaining why:
[ Adapted for qcom-6.18.y: adjusted context due to <reason> ]
If missing hunks → cherry-pick the complete upstream patch

If extra changes → split into separate commits or remove if unintended
If the Link is wrong (points to v2 instead of v3, etc.):
git rebase -i <base_sha>   # mark commit as 'edit'
git commit --amend         # update the Link: line
git rebase --continue
Reproduce locally:
cd <kernel-tree>
git checkout qcom-6.18.y
# Apply the PR commits
bash kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base <base_sha> \
  --head <head_sha>
✅ Other Checkers

All other checkers passed:

checkpatch — No coding style issues detected

dt-binding-check — DT binding YAML validation passed for qcom-stats.yaml

dtb-check — No new DTB validation errors introduced

sparse-check — No sparse warnings (no C code changes in this PR)

check-uapi-headers — No UAPI changes detected

tag-check — All three commits correctly use FROMLIST: prefix (required for qcom-6.18.y branch)

Verdict

1 blocker to fix before merge:

The content mismatch in commit 3/3 must be resolved. This is a hard blocker because it indicates the PR patch differs from the upstream version, which violates the FROMLIST: contract.

Recommended action:

Fetch the upstream patch with b4 am and compare line-by-line

If the difference is context-only → document this in the commit message or request a checker exception

If the difference is substantive → either:

Revert to the exact upstream version, or

Document the adaptation reason in the commit message with [ Adapted for qcom-6.18.y: ... ]

Once the content mismatch is resolved, all checkers should pass cleanly.

[/CHECKER_LOG_REPORT]

SoC LPM stats are present in RPM MSGRAM and subsystem LPM stats are present in SMEM for Shikra. A generic "qcom,rpm-stats" compatible only reads SoC LPM stats like vmin and vlow. Document shikra rpm compatible to read subsystem LPM stats too along with SoC LPM stats. Keep "qcom,rpm-stats" as a fallback for RPM targets, so that SoC level stats are still shown even without subsystem level stats support. A plain enum can't express that, since it caps compatible at one item. Add a oneOf branch with items for this pattern. Link: https://lore.kernel.org/all/20260907-shikra_stats-v4-1-3825351f9740@oss.qualcomm.com Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>

SoC LPM stats are present in RPM MSGRAM and subsystem LPM stats are present in SMEM for Shikra. For earlier targets using RPM processor like msm8974, rpm_master_stat.c was used for subsystem LPM stats since those stats were populated in RPM MSGRAM. Here is a brief summary of previous targets and their stats configuration, along with the drivers used to display them. +---------------|----------------------------|---------------------------+ | SoC | subsystem LPM stats | SoC LPM stats | |---------------|----------------------------|---------------------------| | msm8974, | RPM processor MSGRAM | RPM processor MSGRAM | | msm8226 | (rpm_master_stat.c) | (qcom_stats.c) | |---------------|----------------------------|---------------------------| | sm6350, | SMEM (DDR) | AOP processor MSGRAM | | sdm845, etc. | (qcom_stats.c) | (qcom_stats.c) | |---------------|----------------------------|---------------------------| | Shikra | SMEM (DDR) | RPM processor MSGRAM | | | (qcom_stats.c) | (qcom_stats.c) | +---------------|----------------------------|---------------------------+ qcom_stats.c supports both the configurations for shikra, reading subsystem LPM stats from SMEM and reading SoC LPM stats from RPM MSGRAM. A generic "qcom,rpm-stats" compatible only reads SoC LPM stats like vmin and vlow. Add shikra rpm compatible and config to read subsystem LPM stats too along with SoC LPM stats. Below is an example showing LPM stats for "apss" subsystem with this change: cat /sys/kernel/debug/qcom_stats/apss Count: 2192 Last Entered At: 5498618336 Last Exited At: 5498708046 Accumulated Duration: 2046572620. Link: https://lore.kernel.org/all/20260907-shikra_stats-v4-2-3825351f9740@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>

qcomlnxci · 2026-09-11T05:40:29Z

Test Matrix

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

qcomlnxci · 2026-09-11T05:40:30Z

Test jobs on 82c8c7d

…C specific A generic "qcom,rpm-stats" compatible only reads stats for SoC level LPM stats like vmin and vlow. Shikra SoC specific compatible allows reading individual subsystem level LPM stats along with SoC level LPM stats. Change it. Keep "qcom,rpm-stats" as fallback compatible. Link: https://lore.kernel.org/all/20260907-shikra_stats-v4-3-3825351f9740@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>

qcomlnxci · 2026-09-13T09:13:39Z

Test jobs on 2303c1b

qcomlnxci · 2026-09-13T09:14:15Z

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	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	◻️	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	◻️	✅ Pass	❌ Fail	❌ 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	✅ Pass	❌ 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	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	◻️	❌ Fail	✅ Pass	⚠️ skip	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	◻️	✅ Pass	⚠️ skip	⚠️ 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	◻️	✅ Pass	❌ Fail	❌ 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-09-15T14:25:58Z

Test jobs on 2303c1b

qcomlnxci · 2026-09-15T14:25:59Z

Test Matrix

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

qlijarvis · 2026-09-15T21:43:44Z

LAVA Failed Case Triage Summary

PR: #833

Job 223438 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Two pre-existing probe failures unrelated to PR833 changes: (1) regulatory.db firmware missing from rootfs (cfg80211 regulatory database, error -2 / -ENOENT), and (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property (error -22 / -EINVAL). PR833 modifies only qcom-stats driver and shikra DT rpm-stats node; neither change affects cfg80211 regulatory or Aquantia PHY driver probe paths.

Possible fix: These are known board/rootfs configuration issues, not kernel regressions. (1) Add regulatory.db firmware file to rootfs at /lib/firmware/regulatory.db, or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB if unsigned DB is acceptable. (2) Add "firmware-name" property to the Aquantia PHY DT node in arch/arm64/boot/dts/qcom/qcs8300-ride.dts, or update the PHY driver to make firmware-name optional if the PHY can operate without custom firmware. The Probe_Failure_Check test correctly identified these issues but they are not introduced by this PR.

Detail analysis attachment: failed_case_job223438_1_detailed.md

Case 2: ** USBHost — Test Infrastructure Issue (No External USB Device Connected)

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

Root cause: ** The USBHost test expects to enumerate external USB devices connected to the board's USB host port, but only the USB root hub (Bus 001 Device 001: ID 1d6b:0002) is present. The USB host controller (xhci-hcd) is functioning correctly and successfully registered at boot (timestamp 7.862805s). The test failure is caused by missing test hardware (no USB device physically connected to the board), not a kernel regression. The PR changes (dt-bindings and driver updates for Shikra RPM stats) are unrelated to USB functionality.

Possible fix: Connect a USB device (e.g., USB flash drive, keyboard, or hub) to the qcs8300-ride board's USB host port before running the USBHost test. If the test is intended to validate USB host controller presence only (not external device enumeration), update the test script to pass when only the root hub is detected. This is a LAVA lab infrastructure issue, not a kernel bug.

Detail analysis attachment: failed_case_job223438_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 during boot with -EINVAL due to missing firmware-name property in the qcs8300-ride device tree MDIO PHY node (stmmac-0:08). When the Ethernet test attempts to bring up eth0, the MAC driver cannot attach to the PHY because the PHY driver never successfully initialized, resulting in phylink validation failure for 2500base-x mode.

Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY device tree node in the qcs8300-ride DTS file. The property should specify the correct Aquantia firmware file path (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_CIG_WF-1.8.0-A_ID45824_VER1630.cld";). This is a pre-existing platform configuration issue in the qcs8300-ride device tree, NOT introduced by PR Add stats compatible and config for Shikra #833 (which only modifies RPM stats driver/binding).

Detail analysis attachment: failed_case_job223438_3_detailed.md

Case 4: KVM Driver Initialization Failure

Failed case: KVM Driver Initialization Failure

Root cause: KVM driver failed to initialize on QCS8300 Ride because the kernel is not running at EL2 (Hyp mode). The platform either boots the kernel at EL1 under a hypervisor, or the SoC firmware does not enable ARM Virtualization Extensions. CONFIG_KVM=y is set but the driver's early initialization check (EL2 availability) failed silently, preventing /dev/kvm creation.

Possible fix: This is a platform configuration issue, not a kernel regression. If KVM support is required on QCS8300 Ride: (1) verify bootloader is launching kernel at EL2, not EL1; (2) confirm ARM Virtualization Extensions are enabled in SoC firmware/TrustZone; (3) if a hypervisor is present, check if nested virtualization is supported and enabled. If KVM is not expected on this platform, mark the KVM_Driver test as SKIP for QCS8300 targets in the LAVA test definition.

Detail analysis attachment: failed_case_job223438_4_detailed.md

Case 5: KVM_EL2_DTB — KVM device node unavailable (platform configuration issue)

Failed case: KVM_EL2_DTB — KVM device node unavailable (platform configuration issue)

Root cause: QCS8300 Ride platform is running under Gunyah hypervisor (version gunyah-cdfb73831), which occupies EL2. KVM requires exclusive EL2 access to create /dev/kvm and cannot initialize when another hypervisor is already running at EL2.

Possible fix: This is a platform configuration issue, not a kernel regression. The KVM tests are not applicable to this platform configuration. Either: (1) skip KVM tests on Gunyah-enabled platforms, or (2) use a firmware/boot configuration without Gunyah if KVM functionality is required for testing.

Detail analysis attachment: failed_case_job223438_5_detailed.md

Case 6: KVM Infrastructure Failure — /dev/kvm device node not created

Failed case: KVM Infrastructure Failure — /dev/kvm device node not created

Root cause: KVM driver failed to initialize on QCS8300 (Monaco) platform running under Gunyah hypervisor. The platform boots with Gunyah as the EL2 hypervisor ("Hypervisor cold boot, version: gunyah-cdfb73831"), which prevents Linux KVM from taking control of EL2. Additionally, the platform has heterogeneous CPUs with unsupported feature variations ("CPU features: Unsupported CPU feature variation detected"), which KVM requires to be uniform across all cores. CONFIG_KVM is enabled in the kernel configuration, but the KVM driver never probes or creates /dev/kvm because it cannot operate under an existing hypervisor.

Possible fix: This is not a PR-introduced regression — the PR only modifies dt-bindings and soc/qcom/stats driver for LPM stats on Shikra, with no KVM-related changes. The failure is a pre-existing platform limitation: QCS8300-ride boots with Gunyah hypervisor occupying EL2, making nested virtualization (Linux KVM under Gunyah) unavailable. To enable KVM on this platform, either: (1) boot without Gunyah hypervisor (requires firmware/bootloader changes to allow Linux to run at EL2 directly), or (2) exclude KVM tests from the QCS8300-ride CI test suite as KVM is not supported on Gunyah-based platforms. Recommended immediate action: mark KVM tests as "not applicable" for QCS8300-ride in the LAVA job definition.

Detail analysis attachment: failed_case_job223438_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM device node /dev/kvm is not created despite CONFIG_KVM being enabled in the kernel configuration on qcs8300-ride platform; KVM ARM driver failed to initialize or probe during boot, preventing character device creation.

Possible fix: Investigate KVM ARM driver initialization in kernel boot log for probe failures or missing dependencies (check for hypervisor mode availability, EL2 support, and ARM virtualization extensions); if KVM is built as a module, ensure it is loaded; verify platform supports ARM virtualization extensions and EL2 is accessible; this is a pre-existing platform/kernel issue unrelated to the PR changes (dt-bindings/stats).

Detail analysis attachment: failed_case_job223438_7_detailed.md

Job 223439 | SoC purwa-evk

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

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

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 bring-up issues on purwa-evk, not regressions introduced by PR Add stats compatible and config for Shikra #833. The PR modifies only Shikra SoC RPM stats driver/DT/bindings and does not touch any of the failing drivers (qseecom, pcie, lpg, or regulatory). Recommend: (1) suppress this test failure for purwa-evk until platform DT/firmware is complete, or (2) update the Probe_Failure_Check test to exclude known platform-specific probe failures that do not indicate kernel regressions.

Detail analysis attachment: failed_case_job223439_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Six critical USB and Video masters (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb, aa00000.video-codec) are missing IOMMU group attachments on purwa-evk due to absent or incomplete iommus properties in the device tree, leaving them unprotected by the SMMU.

Possible fix: Add iommus properties to the six affected device nodes in arch/arm64/boot/dts/qcom/purwa.dtsi (or the appropriate purwa/x5121 device tree file), referencing the correct SMMU phandle and stream IDs for each device, then rebuild the DTB and retest.

Detail analysis attachment: failed_case_job223439_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization failed because HYP (Hypervisor) mode (EL2) is not available on the Purwa IoT EVK platform — kernel message "kvm [1]: HYP mode not available" at boot time prevents /dev/kvm device node creation.

Possible fix: This is a platform limitation, not a PR-introduced regression. The Purwa IoT EVK does not support KVM virtualization because it does not boot into EL2 (HYP mode). Either: (1) skip KVM tests on this platform in the CI test matrix, or (2) enable EL2 in the bootloader/firmware if the hardware supports it but firmware is not configured correctly.

Detail analysis attachment: failed_case_job223439_3_detailed.md

Case 4: ** KVM Driver Initialization Failure — /dev/kvm not available (HYP mode not available)

Failed case: ** KVM Driver Initialization Failure — /dev/kvm not available (HYP mode not available)

Root cause: ** KVM driver initialization failed during boot because EL2 (Hypervisor Exception Level) is not available on the Purwa IoT EVK platform. The kernel message "kvm [1]: HYP mode not available" at boot time (5.777s) indicates the CPU/firmware does not support or enable virtualization extensions, preventing KVM from initializing and creating the /dev/kvm device node.

Possible fix: Update the LAVA test suite configuration to skip KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) for the purwa-evk platform, as this is an IoT board that does not support virtualization. Add platform capability detection: if [ "$DEVICE_TYPE" = "purwa-evk" ]; then skip_kvm_tests; fi in the test runner, or mark these tests as "not applicable" for Purwa in the LAVA job definition.

Detail analysis attachment: failed_case_job223439_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM initialization failed because the kernel is running at Exception Level 1 (EL1) instead of EL2 (hypervisor mode). The Purwa EVK board boots with a hypervisor firmware (hypvm.mbn) that takes control of EL2, preventing the Linux kernel from accessing HYP mode. The kernel log shows "kvm [1]: HYP mode not available" and "CPU: All CPU(s) started at EL1", confirming EL2 is unavailable to Linux.

Possible fix: This is a platform configuration issue, not a kernel regression. The Purwa EVK board is configured to boot with a hypervisor at EL2, which is incompatible with native KVM (which requires Linux to run at EL2). To enable KVM: (1) remove or disable the hypervisor firmware (hypvm.mbn) from the boot chain, allowing Linux to boot directly at EL2, OR (2) use nested virtualization if the hypervisor supports it, OR (3) mark KVM tests as "not applicable" for this board configuration. The PR changes (rpm-stats driver) are unrelated to this failure.

Detail analysis attachment: failed_case_job223439_5_detailed.md

Case 6: KVM_Infra (and related: KVM_Driver, KVM_EL2_DTB)

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

Root cause: KVM driver initialization failed because the purwa-evk platform does not support ARM HYP mode (EL2 hypervisor exception level), which is required for KVM virtualization. The kernel message kvm [1]: HYP mode not available indicates the CPU is not running with EL2 enabled or the firmware/bootloader did not preserve EL2 for the kernel.

Possible fix: This is a platform/firmware limitation, not a kernel regression. The purwa-evk board either: (1) does not have EL2 support in hardware, (2) has firmware/bootloader that drops to EL1 before booting Linux, or (3) requires specific bootloader configuration to preserve EL2. To resolve: verify purwa-evk hardware supports virtualization extensions, check bootloader configuration to ensure it boots Linux at EL2 (not EL1), or exclude KVM tests from the CI test suite for this platform if EL2 is not available.

Detail analysis attachment: failed_case_job223439_6_detailed.md

Job 223440 | SoC hamoa-evk

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

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

Case 1: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** Three pre-existing driver probe failures unrelated to PR Add stats compatible and config for Shikra #833 changes. The PR modifies only shikra.dtsi (Shikra SoC), while the test runs on hamoa-evk (Hamoa/X7181 SoC). The failures are: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) due to secure world resource conflict or initialization race; (2) qcom-spmi-lpg probe failed with -EINVAL (-22) due to invalid multi-LED "reg" property in device tree; (3) regulatory.db firmware load failed with -ENOENT (-2) because the file is not present in the rootfs firmware directory — a known benign failure for WiFi regulatory database on development builds.

Possible fix: These are pre-existing platform-specific issues not introduced by this PR. No action required for PR Add stats compatible and config for Shikra #833 merge. For future cleanup: (1) investigate qcom_qseecom_uefisecapp probe timing or TrustZone app availability on Hamoa; (2) fix the PMIC multi-LED device tree "reg" property in arch/arm64/boot/dts/qcom/hamoa*.dts*; (3) add regulatory.db to the rootfs firmware package or suppress this benign failure in CI test filtering.

Detail analysis attachment: failed_case_job223440_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: SMMU test validation failure — six critical hardware masters (USB PHY controllers a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb and video codec aa00000.video-codec) are missing IOMMU group attachments on hamoa-evk platform, indicating incomplete device tree iommus property configuration for these devices.

Possible fix: Add missing iommus properties to the device tree nodes for the five USB PHY controllers (a0f8800, a2f8800, a4f8800, a6f8800, a8f8800) and video codec (aa00000) in arch/arm64/boot/dts/qcom/hamoa.dtsi or the appropriate SoC-level DTSI, referencing the correct SMMU phandle and stream IDs for hamoa-evk platform.

Detail analysis attachment: failed_case_job223440_2_detailed.md

Case 3: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization failed because the platform is running under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-mobile-c487961e9"), which prevents KVM from entering HYP mode. The kernel message "kvm [1]: HYP mode not available" at line 3111 confirms KVM cannot initialize when a hypervisor is already active at EL2. This is a platform configuration issue, not a kernel regression.

Possible fix: This is not a bug introduced by PR Add stats compatible and config for Shikra #833 (which only modifies LPM stats bindings and driver code). The KVM_Driver test is not applicable to hamoa-evk when running under Gunyah hypervisor. Recommended action: exclude KVM tests from the hamoa-evk CI test suite when Gunyah hypervisor is present, or configure the platform to boot without Gunyah if KVM testing is required.

Detail analysis attachment: failed_case_job223440_3_detailed.md

Case 4: ** KVM_EL2_DTB

Failed case: ** KVM_EL2_DTB

Root cause: ** KVM cannot initialize on Hamoa IoT EVK because the platform runs Qualcomm Gunyah hypervisor at EL2, preventing the Linux kernel from accessing HYP mode. KVM requires direct EL2 access to function, but Gunyah occupies EL2 and the kernel runs at EL1. This is a fundamental architectural limitation of running KVM on a Gunyah-based platform, not a kernel bug or PR-introduced regression.

Possible fix: Skip KVM tests on Gunyah-based platforms (hamoa-evk, hamoa-iot-evk) in the LAVA CI test definition by adding platform detection: if dmesg | grep -q "Gunyah based bootup"; then echo "[SKIP] KVM not supported on Gunyah platforms"; exit 0; fi. For long-term KVM validation, run KVM test suite on non-Gunyah platforms (RB5, RB3Gen2) where Linux boots directly at EL2.

Detail analysis attachment: failed_case_job223440_4_detailed.md

Case 5: ** KVM_Infra — Platform Configuration Issue (Gunyah Hypervisor EL2 Conflict)

Failed case: ** KVM_Infra — Platform Configuration Issue (Gunyah Hypervisor EL2 Conflict)

Root cause: ** The hamoa-evk platform boots with Gunyah hypervisor running at EL2 (Exception Level 2), which prevents KVM from accessing HYP mode. KVM requires direct EL2 access to provide virtualization capabilities. When KVM initializes during kernel boot, it detects that EL2 is already owned by Gunyah and reports "HYP mode not available", preventing creation of the /dev/kvm device node.

Possible fix: This is a platform firmware/bootloader configuration issue, not a kernel bug. To enable KVM on hamoa-evk: (1) Disable Gunyah hypervisor in the bootloader/firmware configuration, OR (2) Use nested virtualization support if available in future Gunyah versions, OR (3) Accept that KVM tests are not applicable on Gunyah-enabled platforms and exclude them from the test suite for hamoa-evk. The PR changes (power management stats for Shikra) are unrelated and do not cause this failure.

Detail analysis attachment: failed_case_job223440_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM infrastructure unavailable on Hamoa IoT EVK — kernel KVM driver detected "HYP mode not available" at boot (EL2/hypervisor mode not enabled or supported on this platform), preventing /dev/kvm device creation.

Possible fix: This is a platform configuration issue, not a kernel regression. Either: (1) Enable EL2/HYP mode in the bootloader/firmware for Hamoa IoT EVK if the hardware supports it, or (2) Skip KVM tests on platforms without virtualization support by adding a platform capability check to the LAVA job definition.

Detail analysis attachment: failed_case_job223440_6_detailed.md

Job 223441 | SoC qcs6490-rb3gen2

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

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

Case 1: GIC Test Script Bug — Offline CPU Parsing Error

Failed case: GIC Test Script Bug — Offline CPU Parsing Error

Root cause: The GIC test script attempts to parse and compare arch_timer interrupt counts for all CPUs in /proc/interrupts without checking if CPUs are online. On qcs6490-rb3gen2, CPUs 6-7 are present but offline (only CPUs 0-5 are online). When the script parses the interrupt line for offline CPUs, it encounters "GICv3" text instead of an integer count, causing a bash integer comparison error at line 75: [: GICv3: integer expected. This is a test infrastructure bug, not a kernel regression.

Possible fix: Update the GIC test script to skip offline CPUs by checking /sys/devices/system/cpu/cpu*/online before attempting to parse interrupt counts, or filter the interrupt line parsing to only extract numeric fields corresponding to online CPUs.

Detail analysis attachment: failed_case_job223441_1_detailed.md

Case 2: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: Mark this test failure as a known benign / pre-existing issue for qcs6490-rb3gen2. The audio deferred probe is a known DT/platform configuration gap (missing pinctrl states in upstream DT), and the firmware failures are expected on this test infrastructure (regulatory.db and Renesas USB firmware not provisioned). The PR (stats driver changes for Shikra) does not introduce or affect these probe behaviors. No action required for PR merge.

Detail analysis attachment: failed_case_job223441_2_detailed.md

Case 3: Freq_Scaling

Failed case: Freq_Scaling

Root cause: Pre-existing platform/firmware issue where CPUs 6-7 fail PSCI boot with error -22 (EINVAL), causing the Freq_Scaling test to fail when checking for cpufreq interface on the expected but offline CPU7. The PR changes (LPM stats compatible string) are unrelated to this failure.

Possible fix: This is a known platform limitation on qcs6490-rb3gen2 where CPUs 6-7 do not boot. Update the Freq_Scaling test to dynamically detect online CPUs instead of assuming all 8 CPUs are present, or mark this test as expected-fail for qcs6490-rb3gen2 until the firmware/platform issue is resolved.

Detail analysis attachment: failed_case_job223441_3_detailed.md

Case 4: USBHost

Failed case: USBHost

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

Possible fix: Add the Renesas USB firmware package to the Yocto/build recipe for qcs6490-rb3gen2 test images. The firmware file renesas_usb_fw.mem must be installed to /lib/firmware/ in the rootfs. Alternatively, if the USB host controller is not required for this platform's test suite, suppress the USBHost test for qcs6490-rb3gen2 in the LAVA job definition.

Detail analysis attachment: failed_case_job223441_4_detailed.md

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

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

Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not have EL2 (HYP mode) enabled or available, preventing the KVM driver from initializing and creating /dev/kvm. The kernel reports "kvm [1]: HYP mode not available" at boot time. This is a platform/firmware limitation, not a kernel bug.

Possible fix: This is not a PR-introduced failure. The PR only modifies stats driver code and DT bindings for Shikra, which are unrelated to KVM. To resolve: (1) Verify the qcs6490-rb3gen2 platform supports virtualization extensions in hardware, (2) Ensure the bootloader (ABL/XBL) is configured to enable EL2 and boot Linux at EL2 or allow EL2 access, (3) If the platform does not support EL2, mark KVM tests as "not applicable" for this board in the CI test matrix.

Detail analysis attachment: failed_case_job223441_5_detailed.md

Case 6: ** KVM Device Unavailable — HYP Mode Not Available

Failed case: ** KVM Device Unavailable — HYP Mode Not Available

Root cause: ** The qcs6490-rb3gen2 platform bootloader boots Linux in EL1 (kernel mode) instead of EL2 (hypervisor mode), preventing KVM driver from accessing ARM virtualization extensions. KVM driver correctly detects "HYP mode not available" at boot and does not create /dev/kvm, causing all KVM tests to fail.

Possible fix: This is a platform/firmware limitation, not a kernel regression. To enable KVM on qcs6490-rb3gen2: (1) Update ABL/UEFI firmware to boot Linux in EL2 mode, or (2) Exclude KVM tests from the CI test suite for this platform until firmware support is available.

Detail analysis attachment: failed_case_job223441_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is not a bug to fix but a platform design choice. To enable KVM on qcs6490-rb3gen2, the platform must be reconfigured to boot without the Gunyah hypervisor (remove hypvm.mbn from the flash image and update bootloader configuration to boot Linux directly at EL2). Alternatively, suppress KVM tests on platforms configured with Gunyah hypervisor, as the two are mutually exclusive by design.

Detail analysis attachment: failed_case_job223441_7_detailed.md

Case 8: ** KVM_Infra (Driver Initialization Failure)

Failed case: ** KVM_Infra (Driver Initialization Failure)

Root cause: ** KVM driver initialization failed because HYP mode (EL2) is not available on qcs6490-rb3gen2. The kernel message kvm [1]: HYP mode not available indicates the bootloader/firmware did not preserve EL2 for Linux KVM use, or a hypervisor is already running at EL2.

Possible fix: This is a pre-existing platform configuration issue unrelated to the PR (which only modifies LPM stats for Shikra). To enable KVM on rb3gen2: (1) verify bootloader (ABL/XBL) configuration preserves EL2 for Linux, (2) ensure no conflicting hypervisor is loaded at EL2, (3) confirm firmware supports KVM mode. The PR should not be blocked by this failure — suppress this test for rb3gen2 until platform support is enabled, or run KVM tests only on platforms with verified EL2 support.

Detail analysis attachment: failed_case_job223441_8_detailed.md

Job 223442 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Four PMIC temp-alarm devices remain in deferred probe state (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and three firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) are detected; however, WiFi_OnOff and BT_ON_OFF functional tests both passed, confirming WiFi and Bluetooth firmware loaded successfully at runtime — the firmware failures are known false positives per lava-known-benign-failures.md Rule 2 and Rule 3. The deferred probe devices are non-critical thermal monitoring sensors that do not block system functionality on lemans-evk.

Possible fix: Suppress the WiFi and Bluetooth firmware load failures as known benign per lava-known-benign-failures.md (WiFi_OnOff and BT_ON_OFF tests passed). For the PMIC temp-alarm deferred probe: investigate missing dependency (likely IIO thermal driver or PMIC regulator) in the lemans-evk device tree or kernel config; if thermal monitoring is required, add the missing dependency; if not critical for this platform, update the Probe_Failure_Check test to exclude these devices from the failure criteria for lemans-evk.

Detail analysis attachment: failed_case_job223442_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device aa00000.video-codec at address 0xaa00000 is not attached to any IOMMU group, while other critical masters (GPU, USB, Display, UFS, Ethernet) are properly protected; this is a pre-existing platform configuration or driver probe issue on lemans-evk, not introduced by PR Add stats compatible and config for Shikra #833 (which only modifies stats bindings and driver).

Possible fix: Investigate why the video codec device is not attaching to an IOMMU group on lemans-evk: (1) verify the video codec DT node includes correct iommus property, (2) check if the video codec driver (qcom_iris) is probing successfully or deferring, (3) confirm IOMMU domain allocation succeeds during driver probe, (4) check for any probe errors in dmesg for the video codec driver; this is a platform-specific issue unrelated to the stats driver changes in this PR.

Detail analysis attachment: failed_case_job223442_2_detailed.md

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

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

Root cause: LAVA test framework marked the test definition as failed with "Marking unfinished test run as failed" despite the test runner completing normally (<LAVA_TEST_RUNNER EXIT> present). Two individual test cases failed: (1) smmu test failed because video codec device aa00000.video-codec is missing IOMMU group attachment on lemans-evk — a pre-existing platform configuration issue unrelated to the PR's Shikra RPM stats changes; (2) Probe_Failure_Check test failed due to missing firmware files (regulatory.db, bluetooth firmware) — also a pre-existing infrastructure issue.

Possible fix: The PR changes (adding Shikra RPM stats support) are not the cause of this failure. For the smmu test failure: investigate why the video codec device tree node on lemans-evk is not configured with IOMMU bindings — check arch/arm64/boot/dts/qcom/lemans*.dts* for the aa00000.video-codec node and ensure it has iommus = <&apps_smmu ...> property. For the Probe_Failure_Check failure: add missing firmware files to the test rootfs or suppress these known benign firmware load failures in the test configuration. For the LAVA "unfinished" marking: review the test runner script to ensure it sends the expected LAVA completion signal before exiting.

Detail analysis attachment: failed_case_job223442_3_detailed.md

Job 223443 | SoC shikra-iqs-evk

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

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

Case 1: GIC Test Script Bug — False Failure

Failed case: GIC Test Script Bug — False Failure

Root cause: The GIC test script incorrectly assumes 8 CPUs exist and fails to parse /proc/interrupts output correctly. The shikra-iqs-evk board has only 4 CPUs (0-3), but the test script attempts to validate timer interrupt counts for CPUs 4-7, resulting in bash integer comparison errors ("[: GICv3: integer expected", "[: Level: integer expected", "[: arch_timer: integer expected") when parsing non-existent CPU columns. The actual GIC/timer functionality is working correctly — CPUs 0-3 all show incrementing timer counts.

Possible fix: Update the GIC test script (run.sh:75) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an 8-CPU assumption. The script should iterate only over CPUs that actually exist on the target platform.

Detail analysis attachment: failed_case_job223443_1_detailed.md

Case 2: Probe_Failure_Check — Pre-existing Platform Driver Probe Failures

Failed case: Probe_Failure_Check — Pre-existing Platform Driver Probe Failures

Root cause: The Probe_Failure_Check test detected 7 pre-existing probe failures on shikra-iqs-evk that are unrelated to the PR changes (qcom-stats driver DT binding update). The failures include: coresight-etm4x (4 instances, -EINVAL), cpufreq-dt (-EEXIST, duplicate registration), lt9611c display bridge (-EIO, I2C communication failure), and regulatory.db firmware (-ENOENT, missing file). None of these failures are caused by the PR's changes to the rpm-stats compatible string.

Possible fix: Mark this test case as expected-fail for shikra-iqs-evk until the underlying platform issues are resolved. The PR changes are safe to merge — they only update DT bindings and driver compatible matching for the qcom-stats driver, which successfully probed and is unrelated to the reported failures.

Detail analysis attachment: failed_case_job223443_2_detailed.md

Case 3: USBHost

Failed case: USBHost

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

Possible fix: If USB host functionality is required on shikra-iqs-evk: (1) Update the device tree dr_mode property for the USB node at 4e00000.usb from "peripheral" to "host" or "otg", (2) Ensure USB host hardware (USB-A port or OTG adapter) is physically connected to the board, (3) Verify xhci_hcd or dwc3 host controller driver probes successfully after reboot. If USB host is not supported on this board variant, mark the USBHost test as SKIP for shikra-iqs-evk in the LAVA test definition.

Detail analysis attachment: failed_case_job223443_3_detailed.md

Case 4: BT_SCAN — Test Infrastructure / Environment Issue

Failed case: BT_SCAN — Test Infrastructure / Environment Issue

Root cause: Bluetooth scan test failed because no discoverable Bluetooth devices are present in the LAVA test environment. The Bluetooth hardware (hci0 adapter) is fully functional (BT_ON_OFF test passed, power on/off works, firmware loaded successfully), but the scan discovered zero devices after multiple attempts including interactive fallback. The test framework expects at least one discoverable BT device in RF range, but the lab environment has none available.

Possible fix: This is not a kernel regression introduced by PR Add stats compatible and config for Shikra #833 (which only modifies RPM stats driver/DT for power management). Verify that the LAVA lab has a discoverable Bluetooth device (phone, beacon, or dedicated BT test device) powered on and in range of the shikra-iqs-evk board. If this is a new test or board deployment, provision a BT test beacon. If the test previously passed on this board, check whether the BT test device was removed or powered off. Consider making BT_SCAN a non-blocking test or adding environment validation before running it.

Detail analysis attachment: failed_case_job223443_4_detailed.md

Case 5: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM device node /dev/kvm not created despite CONFIG_KVM and CONFIG_VIRTUALIZATION being enabled in kernel config, indicating KVM driver initialization failure on Shikra IQS EVK platform.

Possible fix: Verify KVM ARM64 hardware virtualization support is available on Shikra (check CPU features for EL2/VHE support); if hardware supports it, investigate why KVM driver probe/initialization is failing by checking dmesg for KVM-related errors during boot; if hardware doesn't support virtualization, mark KVM tests as expected-to-skip for this platform.

Detail analysis attachment: failed_case_job223443_5_detailed.md

Case 6: Kernel Crash — Synchronous External Abort in qcom_rng driver (KVM_EL2_DTB is a consequence of the crash)

Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver (KVM_EL2_DTB is a consequence of the crash)

Root cause: Hardware register access fault in qcom_rng_read+0xc4/0x228 during /dev/hwrng read operation on Shikra IQS EVK. The synchronous external abort (bus error 0x96000010) indicates the RNG hardware block is either unpowered, unclocke d, or the MMIO mapping is incorrect for this SoC.

Possible fix: Verify qcom_rng device tree node for Shikra: confirm MMIO base address matches hardware spec, ensure required clocks/regulators are present and enabled, and check if RNG block requires explicit power domain or interconnect vote. This is a pre-existing platform/hardware configuration issue, not introduced by PR Add stats compatible and config for Shikra #833 (which only touches qcom-stats bindings/driver).

Detail analysis attachment: failed_case_job223443_6_detailed.md

Case 7: KVM_Infra — Missing KVM Device Node (Platform Limitation)

Failed case: KVM_Infra — Missing KVM Device Node (Platform Limitation)

Root cause: KVM driver initialization failed because HYP (EL2) mode is not available on the Shikra IQS EVK platform; kernel log shows "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm character device creation.

Possible fix: This is a platform hardware limitation, not a kernel bug. Either: (1) Skip KVM tests on Shikra IQS EVK in the CI test plan, or (2) Verify that the bootloader/firmware is configured to boot the kernel in EL2 mode if the hardware supports it, or (3) If virtualization is required, use a platform with EL2/VHE support.

Detail analysis attachment: failed_case_job223443_7_detailed.md

Case 8: 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 triggered a synchronous external abort at PC qcom_rng_read+0xc4 when attempting to read from MMIO register at address 0x002a704087996800. The abort indicates the hardware block was either not powered/clocked correctly, or the MMIO mapping is invalid for the shikra-iqs-evk platform. After the crash, the kernel panicked and entered EDL/ramdump mode but never recovered, causing the LAVA test to timeout after 2400 seconds.

Possible fix: Verify the qcom_rng device tree node for shikra-iqs-evk has correct reg property, clock/power-domain bindings, and that the RNG hardware block is properly enabled in firmware. If the hardware block is not present or not functional on this board variant, disable the qcom_rng node in the device tree with status = "disabled". As a short-term workaround, blacklist the qcom_rng module or skip the qcom_hwrng test on shikra-iqs-evk until the hardware configuration is confirmed.

Detail analysis attachment: failed_case_job223443_8_detailed.md

Case 9: lava-test-shell

Failed case: lava-test-shell

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

Possible fix: This is a pre-existing platform/firmware issue, not introduced by PR Add stats compatible and config for Shikra #833 (which only adds DT bindings and stats driver changes for Shikra). The qcom_rng driver is encountering a hardware access fault specific to the Shikra IQS EVK board. Recommended actions: (1) Verify qcom_rng device tree node MMIO address ranges match Shikra hardware specification; (2) Check if EFI runtime services memory mappings are correctly configured in firmware for Shikra; (3) Add qcom_rng to the test exclusion list for Shikra until the platform MMIO/firmware issue is resolved; (4) Re-run the CI job to verify other tests pass.

Detail analysis attachment: failed_case_job223443_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: Hardware access fault in qcom_rng_read+0xc4/0x228 during /dev/hwrng read operation. The qcom_rng driver attempted to read from an unmapped or inaccessible hardware register (address 0x000000ec83e75e99 in x0), triggering a synchronous external abort. This is a hardware access violation, not related to the PR changes (which only modify dt-bindings and stats driver for LPM stats). The crash occurred during the qcom_hwrng test when userspace (dd command, PID 10666) read from /dev/hwrng, causing the kernel to panic and enter ramdump/EDL mode, which then timed out the LAVA test after 2400 seconds.

Possible fix: This is a pre-existing kernel or hardware configuration issue unrelated to PR Add stats compatible and config for Shikra #833. The qcom_rng driver is accessing invalid hardware addresses. Recommended actions: (1) Verify qcom_rng device tree configuration for shikra-iqs-evk includes correct register base addresses and clocks; (2) Check if qcom_rng driver probe succeeded without errors earlier in boot; (3) Verify hardware RNG block is powered and clocked correctly on this SoC; (4) Consider disabling the qcom_hwrng test for shikra-iqs-evk until the RNG hardware access issue is resolved, as this is a board/firmware-level issue, not a regression introduced by this PR.

Detail analysis attachment: failed_case_job223443_10_detailed.md

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

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

Root cause: Hardware bus error (synchronous external abort 0x96000010) during qcom_rng_read register access at PC+0xc4, indicating the RNG hardware block was inaccessible (powered off, clock-gated, or unmapped) when the qcom_hwrng test attempted to read random data from /dev/hwrng on Shikra IQS EVK.

Possible fix: Verify RNG hardware block power/clock configuration in Shikra device tree and firmware: ensure qcom_rng DT node has correct clock/power-domain bindings, check if RNG block requires explicit power-on sequence, and confirm MMIO register base address matches hardware specification. Short-term: skip qcom_hwrng test on Shikra until RNG hardware access is fixed. Proper fix: add missing clock/power-domain properties to qcom_rng DT node or fix firmware power sequencing for RNG block on Shikra.

Detail analysis attachment: failed_case_job223443_11_detailed.md

Job 223444 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: Add regulatory.db firmware file to the LAVA test rootfs image, or update the Probe_Failure_Check test to suppress firmware load failures when the corresponding functional tests pass (similar to existing WiFi/BT firmware suppression rules in lava-known-benign-failures.md).

Detail analysis attachment: failed_case_job223444_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Test validation logic expects IOMMU group attachments for Venus video codec child devices (video-decoder, video-encoder), but these child devices inherit DMA operations from the parent device (aa00000.video-codec) and do not have separate iommu_group symlinks — this is correct kernel behavior, not a bug.

Possible fix: Update the smmu test script to exclude child devices of video-codec from the critical master IOMMU group attachment check, or verify IOMMU protection at the parent device level only. The parent device aa00000.video-codec is correctly attached to IOMMU group 7.

Detail analysis attachment: failed_case_job223444_2_detailed.md

Case 3: KVM_Driver — Platform Virtualization Not Supported

Failed case: KVM_Driver — Platform Virtualization Not Supported

Root cause: KVM cannot initialize on qcs615-ride because ARM Virtualization Extensions (HYP mode / EL2) are not available on this platform. Boot log shows kvm [1]: HYP mode not available at line 2907. CONFIG_KVM is enabled in kernel config, but the hardware/firmware does not support virtualization, preventing /dev/kvm device creation.

Possible fix: Skip KVM tests on qcs615-ride in CI configuration by adding a platform capability check in the test runner to detect /dev/kvm presence before running tests. This is a pre-existing platform limitation, NOT a regression introduced by PR Add stats compatible and config for Shikra #833 (which only modifies LPM stats for Shikra SoC).

Detail analysis attachment: failed_case_job223444_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 qcs615-ride platform does not have EL2/HYP mode enabled or available in the firmware/bootloader configuration. The KVM driver successfully loads but detects during initialization that the CPU is not running in or cannot access EL2 (Hypervisor) mode, which is a mandatory requirement for KVM on ARM64. The kernel message "kvm [1]: HYP mode not available" at boot time (line 2907) indicates this hardware/firmware limitation. This is NOT a PR-introduced regression — the PR changes only dt-bindings and soc stats driver for Shikra, with no KVM-related modifications.

Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM on qcs615-ride: (1) Verify the bootloader (ABL/XBL) is configured to boot the kernel in EL2 mode or enable EL2 access; (2) Check if the platform's TrustZone/secure firmware allows EL2 virtualization extensions; (3) If the hardware does not support virtualization extensions, KVM tests should be skipped for this platform in the CI configuration. For immediate CI health: add qcs615-ride to the KVM test skip list, as this platform does not support KVM host functionality.

Detail analysis attachment: failed_case_job223444_4_detailed.md

Case 5: KVM_Infra — KVM unavailable (HYP mode not available)

Failed case: KVM_Infra — KVM unavailable (HYP mode not available)

Root cause: KVM initialization failed with "HYP mode not available" because the qcs615-ride platform is running Gunyah hypervisor at EL2. KVM requires exclusive access to EL2 (HYP mode) to provide virtualization, but Gunyah is already occupying that privilege level. This is a platform configuration issue, not a kernel regression.

Possible fix: This is expected behavior on qcs615-ride with Gunyah hypervisor enabled. To enable KVM testing: (1) disable Gunyah hypervisor in the boot configuration and rebuild the firmware/bootloader, OR (2) exclude KVM tests from the CI test suite for platforms running Gunyah, OR (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes). The PR changes (rpm-stats driver for Shikra) are unrelated and do not cause this failure.

Detail analysis attachment: failed_case_job223444_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; kernel reports "kvm [1]: HYP mode not available" during boot, indicating the QCS615 platform does not support ARM virtualization extensions (EL2/HYP mode).

Possible fix: This is not a regression introduced by PR Add stats compatible and config for Shikra #833 (which only modifies LPM stats bindings/driver). The QCS615-ride platform lacks hardware virtualization support. Either: (1) skip KVM tests on qcs615-ride in the CI job definition, or (2) run KVM tests only on platforms with confirmed EL2 support (e.g., SM8450, SM8550).

Detail analysis attachment: failed_case_job223444_6_detailed.md

Job 223445 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k_pci probe timeout

Failed case: Probe_Failure_Check — WiFi/BT firmware load failures and ath11k_pci probe timeout

Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) for PCIe WiFi device 0000:01:00.0 (WCN6855), preceded by firmware load failures for regulatory.db, Bluetooth firmware (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv), and WiFi firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin). This is a pre-existing platform/firmware issue on monaco-evk, not introduced by the PR (PR only modifies qcom_stats driver for Shikra SoC).

Possible fix: Verify firmware files are present in rootfs at /lib/firmware/ for the required paths; check PCIe link training and MHI state machine for WCN6855; confirm board-specific DT wiring for PCIe, clocks, regulators, and resets; if firmware files are missing, add them to the build image; if PCIe link fails, check hardware connections and power sequencing on monaco-evk.

Detail analysis attachment: failed_case_job223445_1_detailed.md

Case 2: WiFi_Firmware_Driver

Failed case: WiFi_Firmware_Driver

Root cause: ath11k_pci driver probe timeout (error -110, ETIMEDOUT) on Monaco EVK due to missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image. The MHI (Modem Host Interface) subsystem failed to load the firmware (error -2, ENOENT), preventing the WCN6855 PCIe WiFi device from powering up and completing initialization. This is a pre-existing board/infrastructure issue unrelated to the PR changes (which only modify qcom-stats for Shikra LPM stats).

Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the Monaco EVK rootfs image under /lib/firmware/. The firmware should be sourced from the linux-firmware repository or Qualcomm's firmware package for WCN6855 hw2.1 nfa765 variant. Rebuild the rootfs image and re-flash the board to verify WiFi probe succeeds.

Detail analysis attachment: failed_case_job223445_2_detailed.md

Case 3: WiFi_OnOff — Driver Probe Failure (ath11k_pci)

Failed case: WiFi_OnOff — Driver Probe Failure (ath11k_pci)

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 (firmware load failed with -ENOENT/-2), preventing MHI power-up and device initialization on monaco-evk (WCN6855 hw2.1 PCIe WiFi card).

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs /lib/firmware/ directory in the Yocto build recipe; verify the linux-firmware package or vendor firmware package includes WCN6855 hw2.1 nfa765 variant firmware; rebuild the rootfs image and re-test.

Detail analysis attachment: failed_case_job223445_3_detailed.md

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

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

Root cause: WiFi driver (ath11k_pci) probe failure due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image, causing MHI power-up timeout (error -110). This is a pre-existing infrastructure issue unrelated to the PR changes (LPM stats for Shikra).

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs image build configuration for monaco-evk. The firmware package should include the nfa765 variant firmware for WCN6855 hw2.1 WiFi chipset.

Detail analysis attachment: failed_case_job223445_4_detailed.md

Job 223446 | SoC qcs9100-ride

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

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

Case 1: ** Probe_Failure_Check

Failed case: ** Probe_Failure_Check

Root cause: ** The test detected two probe failures and four deferred probes that are pre-existing platform configuration issues, not introduced by PR Add stats compatible and config for Shikra #833. (1) Aquantia AQR115C Ethernet PHY probe fails with -EINVAL because the qcs9100-ride device tree is missing the required firmware-name property for the PHY node at stmmac-0:08. (2) cfg80211 regulatory.db firmware load fails with -ENOENT because the file is missing from rootfs, but this is a known benign failure since WiFi functional tests passed. (3) Four PMIC temp-alarm devices remain in deferred probe, which is expected transient behavior waiting for thermal zone registration.

Possible fix: For the Aquantia PHY failure: Add the firmware-name property to the Aquantia PHY node in arch/arm64/boot/dts/qcom/qcs9100-ride.dts (or the appropriate qcs9100 DTSI), specifying the correct firmware file (e.g., firmware-name = "Rhe-05.06-Candidate7-AQR_CIG_WF-1.8.2-20220805.cld";). For the regulatory.db: Install the wireless-regdb package in the rootfs or suppress this known benign failure in the test. For temp-alarm deferred probe: No action needed — this is expected transient behavior. Note: Since PR Add stats compatible and config for Shikra #833 does not introduce these failures, they should be fixed separately in the qcs9100-ride platform support, not blocked on this PR.

Detail analysis attachment: failed_case_job223446_1_detailed.md

Case 2: smmu

Failed case: smmu

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

Possible fix: Add iommus property to the aa00000.video-codec DT node in arch/arm64/boot/dts/qcom/qcs9100.dtsi referencing the appropriate SMMU instance, or investigate why the video codec driver is not requesting IOMMU attachment during probe.

Detail analysis attachment: failed_case_job223446_2_detailed.md

Case 3: ** USBHost (Test Infrastructure Issue)

Failed case: ** USBHost (Test Infrastructure Issue)

Root cause: ** The USBHost test expects external USB devices to be physically connected to the qcs9100-ride board's USB ports, but only USB root hubs (Bus 001, 002, 003) are enumerated. The test validation logic fails when no functional USB devices (storage, keyboard, mouse, etc.) are detected beyond the root hubs. This is a LAVA lab hardware setup issue, not a kernel driver or PR-introduced regression.

Possible fix: Connect at least one functional USB device (e.g., USB flash drive, keyboard, or mouse) to one of the qcs9100-ride board's USB ports before running the LAVA job. If the test is intended to validate USB controller functionality only (not external device presence), update the test script to pass when USB root hubs are successfully enumerated and the xhci-hcd driver is operational.

Detail analysis attachment: failed_case_job223446_3_detailed.md

Case 4: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

Root cause: qcom-ethqos driver for end0 (23040000.ethernet) fails to attach PHY with -EINVAL error during interface bring-up, indicating a device tree PHY configuration issue (missing or incorrect phy-handle/phy-mode property) or PHY driver not probed successfully for the qcs9100-ride platform.

Possible fix: Verify the device tree node for 23040000.ethernet contains correct phy-handle phandle pointing to a valid PHY node in the MDIO bus, confirm phy-mode property matches hardware (rgmii/sgmii), and ensure the PHY driver for the connected PHY chip is built into the kernel or loaded as a module before the Ethernet interface is brought up.

Detail analysis attachment: failed_case_job223446_4_detailed.md

Case 5: KVM_Driver — Platform Hardware Limitation (EL2 Not Available)

Failed case: KVM_Driver — Platform Hardware Limitation (EL2 Not Available)

Root cause: The qcs9100-ride platform does not support ARM EL2 (hypervisor mode), which is required for KVM. Kernel message: kvm [1]: HYP mode not available. This is a pre-existing platform limitation, not a regression introduced by PR Add stats compatible and config for Shikra #833 (which only modifies qcom-stats LPM infrastructure for Shikra).

Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as SKIP (not FAIL) for qcs9100-ride in the LAVA test suite, since this platform does not support virtualization. If EL2 support is required, investigate whether: (1) the SoC hardware supports EL2 but firmware/bootloader disables it, or (2) a hypervisor (Gunyah) is already running at EL2 for safety partitioning, preventing Linux KVM usage.

Detail analysis attachment: failed_case_job223446_5_detailed.md

Case 6: KVM_EL2_DTB — KVM Unavailable (Pre-existing Platform Limitation)

Failed case: KVM_EL2_DTB — KVM Unavailable (Pre-existing Platform Limitation)

Root cause: KVM initialization failed at boot with "HYP mode not available" because the qcs9100-ride platform runs under the Gunyah hypervisor in a non-nested virtualization configuration, preventing the host kernel from accessing EL2/HYP mode required for KVM operation.

Possible fix: This is a pre-existing platform configuration issue unrelated to PR Add stats compatible and config for Shikra #833 (which only modifies qcom-stats driver). If KVM support is required on qcs9100-ride, enable nested virtualization in the Gunyah hypervisor configuration to expose EL2 to the Linux host, or exclude KVM tests from the qcs9100-ride CI test suite as this platform does not support KVM in its current configuration.

Detail analysis attachment: failed_case_job223446_6_detailed.md

Case 7: Driver Initialization Failure — KVM (HYP mode not available)

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

Root cause: KVM driver initialization fails on qcs9100-ride because the platform does not provide EL2 (Hypervisor Exception Level) access to Linux. The kernel message "kvm [1]: HYP mode not available" at boot time indicates the CPU is not running in EL2 and cannot switch to it, which is a platform/firmware configuration limitation on this automotive SoC.

Possible fix: This is a pre-existing platform limitation, not a kernel regression. Exclude KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the qcs9100-ride CI test suite or mark them as expected-fail until the platform firmware is configured to provide EL2 access to Linux. If KVM support is required, work with the platform team to configure the bootloader to boot Linux at EL2.

Detail analysis attachment: failed_case_job223446_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM module initialization failed during kernel boot with "kvm [1]: HYP mode not available" — the qcs9100-ride platform does not support EL2/HYP mode required for KVM virtualization, making /dev/kvm unavailable at runtime.

Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR Add stats compatible and config for Shikra #833 (which only modifies RPM stats for Shikra SoC). The KVM_Infra test should be skipped on qcs9100-ride or the test should be updated to gracefully handle platforms without HYP mode support. No kernel fix is required.

Detail analysis attachment: failed_case_job223446_8_detailed.md

smankad-oss requested review from a team, Mukesh Ojha (mukeshojha-linux), Rajendra (rrnayak) and Salendarsingh Gaud (sgaud-quic) July 16, 2026 08:06

smankad-oss force-pushed the shikra_stats_qli2.0 branch from 2599a9a to 57cc790 Compare July 17, 2026 10:04

Komal Bajaj (Komal-Bajaj) previously approved these changes Jul 28, 2026

View reviewed changes

smankad-oss dismissed Komal Bajaj (Komal-Bajaj)’s stale review via d7ed419 August 10, 2026 09:27

smankad-oss force-pushed the shikra_stats_qli2.0 branch from 57cc790 to d7ed419 Compare August 10, 2026 09:27

qcomlnxci requested a review from a team August 10, 2026 09:29

smankad-oss force-pushed the shikra_stats_qli2.0 branch from d7ed419 to 93c43bd Compare September 7, 2026 14:20

smankad-oss added 2 commits September 9, 2026 12:22

smankad-oss force-pushed the shikra_stats_qli2.0 branch from 93c43bd to 82c8c7d Compare September 9, 2026 06:55

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

Shiraz Hashim (shashim-quic) previously approved these changes Sep 11, 2026

View reviewed changes

smankad-oss dismissed Shiraz Hashim (shashim-quic)’s stale review via 2303c1b September 12, 2026 12:50

smankad-oss force-pushed the shikra_stats_qli2.0 branch from 82c8c7d to 2303c1b Compare September 12, 2026 12:50

qcomlnxci requested a review from a team September 12, 2026 12:52

maulik-k-shah approved these changes Sep 13, 2026

View reviewed changes

Komal Bajaj (Komal-Bajaj) approved these changes Sep 13, 2026

View reviewed changes

Shiraz Hashim (shashim-quic) approved these changes Sep 16, 2026

View reviewed changes

Conversation

smankad-oss commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qlijarvis commented Jul 16, 2026

PR #833 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Issues

Verdict

Final Summary

Recommendation

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 16, 2026

PR #833 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ dtb-check

❌ check-patch-compliance

❌ tag-check

Verdict

Uh oh!

qlijarvis commented Jul 17, 2026

PR #833 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Upstream Patch Status

Integration Presence (qcom-next/topics)

Issues

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Jul 17, 2026

PR #833 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ dtb-check

Verdict

Uh oh!

qswat-orbit-external Bot commented Jul 20, 2026

Uh oh!

qswat-orbit-external Bot commented Jul 20, 2026

Uh oh!

qcomlnxci commented Jul 28, 2026

Test jobs on 57cc790

Uh oh!

qcomlnxci commented Jul 28, 2026

Test Matrix

Uh oh!

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

Uh oh!

qlijarvis commented Aug 10, 2026

PR #833 — validate-patch

Final Summary

🔍 Patch Validation

Commit 1/3: dt-bindings: soc: qcom: stats: Add compatible for Shikra

Commit 2/3: soc: qcom: stats: Add stats compatible and config for Shikra

Commit 3/3: arm64: dts: qcom: shikra: Update rpm-stats compatible to SoC specific

Issues Found

Upstream Patch Status

Integration Presence (from integration_presence_report.md)

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Aug 10, 2026

PR #833 — checker-log-analyzer

🤖 Kernel Checker CI Failure Analysis

❌ check-patch-compliance

✅ Other Checkers

smankad-oss commented Jul 16, 2026 •

edited

Loading