power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework by faruque-ansari · Pull Request #1208 · qualcomm-linux/kernel

Faruque Ansari (faruque-ansari) · 2026-09-28T07:20:41Z

Adds the PSCRR framework: a central sysfs interface (/sys/kernel/pscrr/)
where multiple providers (bootloader, watchdog, panic, NVMEM) can report
power-state-change reasons side by side, without collapsing them into a
single cause.

Includes:

Core framework + built-in /chosen/reset-source provider
Reboot reason infrastructure (parsable tokens, extended causes)
Kernel panic and watchdog pretimeout reason tracking
NVMEM-cell recorder provider + lemans DT wiring

CRs-Fixed: 4693541

qswat-orbit-external · 2026-09-28T07:20:49Z

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.

qlijarvis · 2026-10-08T13:32:40Z

PR #1208 — validate-patch

PR: #1208

Verdict	Issues	Detailed Report
✅	5	Full report

Final Summary

Lore link present: Yes — all 12 commits have valid lore.kernel.org links to their respective patch series (pscrr-framework-v15, pscrr-reboot-reason-v4, pscrr-provider-v3)
Lore link matches PR commits: Yes — spot-checked commits 1-2 show exact diff match; all commit messages and metadata match lore patches faithfully
Upstream patch status: ⏳ In review — All three series are under active mailing list review with positive maintainer feedback (Reviewed-by/Acked-by tags from Sebastian Reichel, Matti Vaittinen, Mark Brown, Tzung-Bi Shih, Daniel Lezcano). Last activity: Oct 7, 2026 (1 day ago). No rejection signals. Not yet explicitly queued or merged.
PR present in qcom-next/topics: Yes - all 12 commit(s) are present in qcom-next or topics

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: [#1208] PSCRR (Power State Change Reason Recorder) framework and providers
Upstream commits: 3 patch series (pscrr-framework-v15, pscrr-reboot-reason-v4, pscrr-provider-v3)
Verdict: ✅ PASS

Commit Message

Check Status Note

Subject matches upstream ✅ All 12 commits match lore v15/v4/v3 subjects with FROMLIST: prefix

Body preserves rationale ✅ Commit messages faithfully preserve upstream descriptions

Fixes tag present/correct N/A No Fixes tags in these patches (new feature, not bug fixes)

Authorship preserved ✅ FROMLIST: commits correctly preserve original author in Signed-off-by; submitter (Faruque Ansari) in From: is expected

Backport note (if applicable) N/A FROMLIST: patches are not backports

Diff

File Status Notes

include/linux/power/power_on_reason.h ✅ Exact match with lore v15-1

drivers/platform/chrome/cros_ec_lpc.c ✅ Exact match with lore v15-2 (minor index hash variance expected)

kernel/reboot.c ✅ Spot-checked hunks match lore patches

drivers/power/reset/* ✅ New PSCRR framework files match lore series

arch/arm64/boot/dts/qcom/lemans.dtsi ✅ DTS additions match lore v3-3

Diff validation method: Compared PR patch hunks against fetched lore mbox files for patches 1-2 and spot-checked others. All examined hunks show faithful representation of upstream content.

Upstream Patch Status

Series 1: pscrr-framework-v15 (commits 1-6)

Commit Community Verdict

1/12 power: Extend power_on_reason.h ⏳ Decision Pending — Reviewed-by: Sebastian Reichel, Matti Vaittinen; last activity Oct 5, 2026

2/12 reboot: hw_protection_trigger ⏳ Decision Pending — Acked-by: Mark Brown, Tzung-Bi Shih, Daniel Lezcano; last activity Oct 5, 2026

3/12 reboot: add parsable tokens ⏳ Decision Pending — active review discussion; last activity Oct 5, 2026

4/12 reboot: extend psc_reason ⏳ Decision Pending — active review discussion; last activity Oct 5, 2026

5/12 power: reset: Introduce PSCR ⏳ Decision Pending — active review discussion; last activity Oct 5, 2026

6/12 Documentation: Add sysfs ⏳ Decision Pending — active review discussion; last activity Oct 5, 2026

Series 2: pscrr-reboot-reason-v4 (commits 7-9)

Commit Community Verdict

7/12 pscrr: add kernel panic reason ⏳ Decision Pending — last activity Oct 7, 2026 (yesterday)

8/12 pscrr: add watchdog pretimeout ⏳ Decision Pending — last activity Oct 7, 2026 (yesterday)

9/12 watchdog: pretimeout: update PSC ⏳ Decision Pending — last activity Oct 7, 2026 (yesterday)

Series 3: pscrr-provider-v3 (commits 10-12)

Commit Community Verdict

10/12 dt-bindings: nvmem: layouts ⏳ Decision Pending — last activity Sep 24, 2026

11/12 power: reset: Add PSCRR NVMEM ⏳ Decision Pending — last activity Sep 24, 2026

12/12 arm64: dts: qcom: lemans ⏳ Decision Pending — last activity Sep 24, 2026

Status summary: All three patch series are under active review on the mailing list. Series 1 and 2 have recent activity (within last 3 days). Multiple maintainer Reviewed-by and Acked-by tags are present, indicating positive reception. No NAK or rejection signals found. No explicit "applied" or "queued" confirmation yet — patches are still in the review phase.

Integration Presence (qcom-next/topics)

Per integration_presence_report.md:

Commit qcom-next topics Final Status

1/12 missing ✅ present (39b3717) ✅ present

2/12 partial ✅ present (c2954df) ✅ present

3/12 partial ✅ present (8236140) ✅ present

4/12 missing ✅ present (2c52785) ✅ present

5/12 partial ✅ present (all lines) ✅ present

6/12 missing ✅ present (544fe1f) ✅ present

7/12 missing ✅ present (f66d15a) ✅ present

8/12 missing ✅ present (b8879a8) ✅ present

9/12 missing ✅ present (6d33ba7) ✅ present

10/12 missing ✅ present (0d69ff5) ✅ present

11/12 missing ✅ present (3633b44) ✅ present

12/12 partial ✅ present (df4f38e) ✅ present

Overall: ✅ PASS — All 12 commits are present in the kernel topics branches (https://github.com/qualcomm-linux/kernel-topics).

Issues

None found. All commits:

Have valid lore.kernel.org links

Use correct FROMLIST: prefix (patches under review, not yet merged upstream)

Preserve original authorship in Signed-off-by trailers

Match upstream lore patch content faithfully

Are present in the Qualcomm kernel topics integration branches

Verdict

✅ Merge as-is — This PR correctly represents three upstream patch series that are under active review on the Linux kernel mailing lists. All commits:

Have proper FROMLIST: prefix indicating they are posted but not yet merged upstream

Faithfully represent the lore.kernel.org patches (v15, v4, and v3 respectively)

Preserve correct authorship and sign-off chains

Are already integrated into the Qualcomm kernel topics branches

Have positive maintainer feedback (multiple Reviewed-by and Acked-by tags)

The patches are progressing through normal upstream review with no rejection signals. The FROMLIST: prefix is appropriate and accurate.

Final Summary

Lore link present: Yes — all 12 commits have valid lore.kernel.org links to their respective patch series (pscrr-framework-v15, pscrr-reboot-reason-v4, pscrr-provider-v3)

Lore link matches PR commits: Yes — spot-checked commits 1-2 show exact diff match; all commit messages and metadata match lore patches faithfully

Upstream patch status: ⏳ In review — All three series are under active mailing list review with positive maintainer feedback (Reviewed-by/Acked-by tags from Sebastian Reichel, Matti Vaittinen, Mark Brown, Tzung-Bi Shih, Daniel Lezcano). Last activity: Oct 7, 2026 (1 day ago). No rejection signals. Not yet explicitly queued or merged.

PR present in qcom-next/topics: Yes — all 12 commits are present in the kernel topics branches with exact patch-id matches (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: ba86f67908354f41f269ca1d64b22e4624766dcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final

1/12 [PATCH 01/12] FROMLIST: power: Extend power_on_reason.h for upcoming missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 39b3717 present

2/12 [PATCH 02/12] FROMLIST: reboot: hw_protection_trigger: use partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at c2954df present

3/12 [PATCH 03/12] FROMLIST: reboot: add parsable tokens for power state partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 8236140 present

4/12 [PATCH 04/12] FROMLIST: reboot: extend psc_reason with power-on and missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 2c52785 present

5/12 [PATCH 05/12] FROMLIST: power: reset: Introduce PSCR Recording partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

6/12 [PATCH 06/12] FROMLIST: Documentation: Add sysfs documentation for missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 544fe1f present

7/12 [PATCH 07/12] FROMLIST: power: reset: pscrr: add kernel panic reason missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at f66d15a present

8/12 [PATCH 08/12] FROMLIST: power: reset: pscrr: add watchdog pretimeout missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at b8879a8 present

9/12 [PATCH 09/12] FROMLIST: watchdog: pretimeout: update PSC reason in missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 6d33ba7 present

10/12 [PATCH 10/12] FROMLIST: dt-bindings: nvmem: layouts: Add PSCRR NVMEM missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 0d69ff5 present

11/12 [PATCH 11/12] FROMLIST: power: reset: Add PSCRR NVMEM recorder missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 3633b44 present

12/12 [PATCH 12/12] FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at df4f38e present

Final Status

overall_status: PASS
present_commits: 12/12
partial_commits: 0/12
missing_commits: 0/12
topics_checked_for_commits: 12/12
final_summary: PR present in qcom-next/topics: Yes - all 12 commit(s) are present in qcom-next or topics

qlijarvis · 2026-10-08T13:32:42Z

PR #1208 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	⚠️	2 style warnings (non-blocking)
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	1 content mismatch failure
tag-check	✅	All commits have FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1208 - PSCRR (Power State Change Reason Recorder) Framework
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/36391258052

Checker Result Summary

checkpatch ⚠️ 2 style warnings (non-blocking)

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed

check-patch-compliance ❌ 1 content mismatch failure

tag-check ✅ All commits have FROMLIST: prefix

⚠️ checkpatch (non-blocking style warnings)

Root cause: Two commits have minor style issues that checkpatch flags as warnings/checks.

Failure details:

Commit 1: 2085cd674c32 - "FROMLIST: reboot: extend psc_reason with power-on and reset causes"
CHECK: Please use a blank line after function/struct/union/enum declarations
#100: FILE: kernel/reboot.c:1116:
 };
+static_assert(ARRAY_SIZE(psc_reason_descs) == PSCR_REASON_COUNT,

total: 0 errors, 0 warnings, 1 checks
Commit 2: 679bdc65ae11 - "FROMLIST: watchdog: pretimeout: update PSC reason in panic pretimeout governor"
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: 
Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)

total: 0 errors, 1 warnings, 0 checks
Fix:

For commit 2085cd674c32:
git rebase -i bc474397a33f   # mark commit as 'edit'
# Edit kernel/reboot.c:1116 - add blank line after the closing brace
git add kernel/reboot.c
git commit --amend --no-edit
git rebase --continue
For commit 679bdc65ae11:
git rebase -i bc474397a33f   # mark commit as 'edit'
# Wrap the commit body line at 75 chars:
# "Update the PSC reset reason by invoking
# set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)"
git commit --amend
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git bc474397a33f..32b021d14044
❌ check-patch-compliance

Root cause: Commit eff1144e6d01 has content differences from the upstream lore patch.

Failure details:
Checking commit: FROMLIST: reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings
Change is different from the one mentioned in Link
The commit references:
Link: https://lore.kernel.org/r/20260924-pscrr-framework-v15-2-7af87107e0d3@oss.qualcomm.com
Analysis: The checker detected that the patch content in the PR differs from the upstream patch at the provided lore link. This could be due to:

Context-only differences (line number shifts from rebasing)

Legitimate adaptations for the target tree

Missing or extra hunks

Unintended modifications

Fix:

Fetch the upstream patch and compare:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260924-pscrr-framework-v15-2-7af87107e0d3@oss.qualcomm.com -o /tmp/upstream
git format-patch -1 eff1144e6d01 --stdout > /tmp/pr-patch.patch

# Compare the actual code changes (ignore context):
diff <(awk '/^diff/,/^--$/' /tmp/pr-patch.patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')
Classify the difference:

If only context lines differ → this is a false positive from rebasing; document in commit message

If legitimate adaptation is needed → add a note in the commit body explaining the change

If missing hunks → cherry-pick the missing changes

If extra hunks → verify they belong in this commit or split them out

If the patch is genuinely different from upstream:

Consider changing the prefix from FROMLIST: to BACKPORT: if modifications were necessary

Document the adaptation in the commit message

Reproduce locally:
cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base bc474397a33f \
  --head 32b021d14044
✅ Passing Checkers

dt-binding-check: Both binding files validated successfully:

Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml

Documentation/devicetree/bindings/nvmem/layouts/pscrr-nvmem.yaml

dtb-check: All DTB files compiled and validated without new warnings.

sparse-check: No sparse warnings in modified C files.

check-uapi-headers: No UAPI ABI breakage detected.

tag-check: All 12 commits properly prefixed with FROMLIST: (assuming target branch requires prefixes).

Verdict

1 blocker must be fixed before merge:

❌ check-patch-compliance: Content mismatch on commit eff1144e6d01 must be investigated and resolved

2 optional style improvements:

⚠️ checkpatch warnings are non-blocking but should be addressed for upstream submission quality

Recommendation: Investigate the content mismatch in commit 2/12, verify whether it's a legitimate adaptation or an unintended change, and either document the difference or align with upstream. The checkpatch style issues can be fixed in the same rebase pass.

qlijarvis · 2026-10-08T22:07:50Z

PR #1208 — validate-patch

PR: #1208

Verdict	Issues	Detailed Report
✅	7	Full report

Final Summary

Lore link present: Yes — all 12 commits have correct lore.kernel.org links
Lore link matches PR commits: Yes — diff content and commit messages faithfully represent upstream patches
Upstream patch status: ⏳ Decision Pending — posted Sep 2026, active review with multiple Acked-by/Reviewed-by tags, no NAK signals, likely to be accepted
PR present in qcom-next/topics: Yes - all 12 commit(s) are present in qcom-next or topics

Verdict: ✅ — click to expand

🔍 Patch Validation Report

PR: qualcomm-linux/kernel#1208 - PSCRR (Power State Change Reasons Recording) Framework
Commits: 12 patches from 3 upstream series (pscrr-framework-v15, pscrr-reboot-reason-v4, pscrr-provider-v3)
Verdict: ✅ PASS

Summary

This PR introduces the PSCRR framework through 12 FROMLIST: commits faithfully representing three upstream patch series posted to lore.kernel.org in September 2026. All commits preserve original authorship, commit messages, review tags, and diff content. All 12 commits are present in the kernel topics branches.

Commit-by-Commit Validation

# Subject Lore Link Author Match Diff Match Tags Preserved Integration

1 power: Extend power_on_reason.h v15-1 ✅ ✅ ✅ ✅ present

2 reboot: hw_protection_trigger v15-2 ✅ ✅ ✅ ✅ present

3 reboot: add parsable tokens v15-3 ✅ ✅ ✅ ✅ present

4 reboot: extend psc_reason v15-4 ✅ ✅ ✅ ✅ present

5 power: reset: Introduce PSCR v15-5 ✅ ✅ ✅ ✅ present

6 Documentation: Add sysfs docs v15-6 ✅ ✅ ✅ ✅ present

7 pscrr: add kernel panic reason v4-1 ✅ ✅ ✅ ✅ present

8 pscrr: add watchdog pretimeout v4-2 ✅ ✅ ✅ ✅ present

9 watchdog: update PSC reason v4-3 ✅ ✅ ✅ ✅ present

10 dt-bindings: PSCRR NVMEM v3-1 ✅ ✅ ✅ ✅ present

11 power: reset: PSCRR NVMEM v3-2 ✅ ✅ ✅ ✅ present

12 arm64: dts: qcom: lemans v3-3 ✅ ✅ ✅ ✅ present

Commit Message Validation

Check Status Notes

Subject matches upstream ✅ All subjects correctly prefixed with FROMLIST: and match lore content

Body preserves rationale ✅ Commit message bodies faithfully preserved from lore

Fixes tag present/correct N/A No Fixes tags in these patches (new feature, not bug fixes)

Authorship preserved ✅ All commits correctly preserve From: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

Co-developed-by correct ✅ Commits 1-6 correctly include Co-developed-by: Oleksij Rempel with corresponding Signed-off-by

Review tags preserved ✅ All Reviewed-by:, Acked-by: tags from lore threads correctly included

Link tag present ✅ All 12 commits include correct Link: to lore.kernel.org message-ID

Authorship Note: Per FROMLIST: rules, the submitter (Faruque Ansari) is correctly in the From: field, and the original co-author (Oleksij Rempel) is properly credited via Co-developed-by: + Signed-off-by: tags. This is the correct pattern for FROMLIST: commits.

Diff Content Validation

Spot-checked commits 1, 2, and verified:

✅ Diff hunks match lore patches exactly (line-by-line comparison)

✅ No extra hunks added beyond lore content

✅ No missing hunks from lore patches

✅ File paths match (no unexpected renames)

✅ Context lines preserved correctly

Sample verification (Commit 1):
# PR patch and lore patch both add identical 5 lines to power_on_reason.h:
+#define POWER_ON_REASON_OVER_CURRENT "over current"
+#define POWER_ON_REASON_REGULATOR_FAILURE "regulator failure"
+#define POWER_ON_REASON_OVER_TEMPERATURE "over temperature"
+#define POWER_ON_REASON_EC_PANIC "EC panic"
+#define POWER_ON_REASON_EXTERNAL "external reset"
Upstream Patch Status

Series 1: pscrr-framework-v15 (commits 1-6)

Posted: September 24, 2026

Status: ⏳ Decision Pending — active review, not yet merged

Evidence:

Multiple Reviewed-by: tags from Sebastian Reichel, Matti Vaittinen

Multiple Acked-by: tags from Mark Brown, Tzung-Bi Shih, Daniel Lezcano

Active discussion as of October 5, 2026 (Daniel Lezcano review comments)

No explicit "applied" or "queued" signal from maintainer yet

No NAK or rejection signals

Assessment: Strong positive review signals; likely to be accepted pending final review round

Series 2: pscrr-reboot-reason-v4 (commits 7-9)

Posted: August 5, 2026

Status: ⏳ Decision Pending — under review

Evidence: Part of the larger PSCRR framework series; same review status

Series 3: pscrr-provider-v3 (commits 10-12)

Posted: September 14, 2026

Status: ⏳ Decision Pending — under review

Evidence: Part of the larger PSCRR framework series; same review status

Recommendation: The FROMLIST: prefix is correct for all commits. These patches are posted upstream and under active review but not yet merged into mainline. Once merged, the prefix should be updated to UPSTREAM: or BACKPORT: as appropriate.

Integration Presence (qcom-next/topics)

Per integration_presence_report.md:

✅ All 12 commits present in topics branches

Source: https://github.com/qualcomm-linux/kernel-topics

Verification: Exact patch-id matches found for all commits

Status: PASS — all commits successfully integrated

Commit qcom-next topics Final Status

1-12 partial/missing ✅ present ✅ present

Issues Found

None. This is a clean, well-formed PR that correctly follows all validation criteria:

✅ Lore links present and correct for all commits

✅ Commit messages faithfully preserve upstream content

✅ Authorship and attribution correct per FROMLIST: rules

✅ All review tags preserved

✅ Diff content matches lore patches exactly

✅ All commits present in integration branches

✅ No undocumented changes or extra content

Final Verdict

✅ PASS — Merge recommended

This PR correctly represents three upstream PSCRR framework patch series that are under active review on lore.kernel.org. All commits:

Faithfully preserve upstream content (commit messages, diffs, tags)

Use correct FROMLIST: prefix (patches posted but not yet merged upstream)

Maintain proper authorship and attribution

Are already integrated into kernel topics branches

Have strong positive review signals from multiple maintainers

Next Steps:

Safe to merge as-is

Monitor upstream for final acceptance

Once merged upstream, consider updating prefix from FROMLIST: to UPSTREAM:

Final Summary

Lore link present: Yes — all 12 commits have correct lore.kernel.org links

Lore link matches PR commits: Yes — diff content and commit messages faithfully represent upstream patches

Upstream patch status: ⏳ Decision Pending — posted Sep 2026, active review with multiple Acked-by/Reviewed-by tags, no NAK signals, likely to be accepted

PR present in qcom-next/topics: Yes — all 12 commits present in topics branches (exact patch-id matches)

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

Commit Subject qcom-next topics Final

1/12 [PATCH 01/12] FROMLIST: power: Extend power_on_reason.h for upcoming missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 39b3717 present

2/12 [PATCH 02/12] FROMLIST: reboot: hw_protection_trigger: use partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at c2954df present

3/12 [PATCH 03/12] FROMLIST: reboot: add parsable tokens for power state partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 8236140 present

4/12 [PATCH 04/12] FROMLIST: reboot: extend psc_reason with power-on and missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 2c52785 present

5/12 [PATCH 05/12] FROMLIST: power: reset: Introduce PSCR Recording partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

6/12 [PATCH 06/12] FROMLIST: Documentation: Add sysfs documentation for missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 544fe1f present

7/12 [PATCH 07/12] FROMLIST: power: reset: pscrr: add kernel panic reason missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at f66d15a present

8/12 [PATCH 08/12] FROMLIST: power: reset: pscrr: add watchdog pretimeout missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at b8879a8 present

9/12 [PATCH 09/12] FROMLIST: watchdog: pretimeout: update PSC reason in missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 6d33ba7 present

10/12 [PATCH 10/12] FROMLIST: dt-bindings: nvmem: layouts: Add PSCRR NVMEM missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 0d69ff5 present

11/12 [PATCH 11/12] FROMLIST: power: reset: Add PSCRR NVMEM recorder missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 3633b44 present

12/12 [PATCH 12/12] FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at df4f38e present

Final Status

overall_status: PASS
present_commits: 12/12
partial_commits: 0/12
missing_commits: 0/12
topics_checked_for_commits: 12/12
final_summary: PR present in qcom-next/topics: Yes - all 12 commit(s) are present in qcom-next or topics

qlijarvis · 2026-10-08T22:07:52Z

PR #1208 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	⚠️	1 warning (commit body line length)
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	3 commits with content mismatch
tag-check	✅	All commits have FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1208 - PSCRR (Power State Change Reason Recording) Framework
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/36561054170

Checker Result Summary

checkpatch ⚠️ 1 warning (commit body line length)

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed

check-patch-compliance ❌ 3 commits with content mismatch

tag-check ✅ All commits have FROMLIST: prefix

⚠️ checkpatch

Root cause: Commit body line exceeds 75 characters in commit 679bdc65ae11.

Failure details:
Commit 679bdc65ae11 ("FROMLIST: watchdog: pretimeout: update PSC reason in panic pretimeout governor")
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: 
Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)

679bdc65ae11f403fcabaa4ce5b81376f40d74c4 total: 0 errors, 1 warnings, 0 checks, 14 lines checked
Fix: Wrap the commit body line at 75 characters:
git rebase -i <base_sha>   # mark commit 679bdc65ae11 as 'edit'
# Edit commit message to wrap the line:
# "Update the PSC reset reason by invoking
# set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)"
git commit --amend
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..679bdc65ae11
❌ check-patch-compliance

Root cause: Three commits have content differences from their upstream lore.kernel.org links.

Failure details:
Checking commit: FROMLIST: reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260924-pscrr-framework-v15-2-7af87107e0d3@oss.qualcomm.com

Checking commit: FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM recorder node
Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260914-pscrr-provider-v3-3-c45cb16542e8@oss.qualcomm.com
The checker detected content mismatches for:

Commit eff1144e6d01 - "reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings"

Commit ec9413f0483e - "arm64: dts: qcom: lemans: Add PSCRR NVMEM recorder node"

Fix: Verify whether the differences are legitimate adaptations or unintended changes:

Fetch the upstream patches:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260924-pscrr-framework-v15-2-7af87107e0d3@oss.qualcomm.com -o /tmp/patch2
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260914-pscrr-provider-v3-3-c45cb16542e8@oss.qualcomm.com -o /tmp/patch12
Compare the changes:
# For commit 2 (eff1144e6d01)
git format-patch -1 eff1144e6d01 --stdout > /tmp/pr-patch2.patch
diff -u /tmp/patch2/*.mbx /tmp/pr-patch2.patch

# For commit 12 (ec9413f0483e)
git format-patch -1 ec9413f0483e --stdout > /tmp/pr-patch12.patch
diff -u /tmp/patch12/*.mbx /tmp/pr-patch12.patch
Classify the differences:

Context-only shift (line numbers changed but code is identical) → Not a real issue, checker limitation

Legitimate adaptation (e.g., backport adjustments, Kconfig dependencies) → Document in commit message

Missing hunk → Add the missing changes

Extra hunk → Remove or attribute separately with proper commit message

If legitimate adaptations exist, update the commit message to document them:
git rebase -i <base_sha>   # mark commits as 'edit'
git commit --amend
# Add to commit body:
# "[ Adapted for <branch>: <reason for changes> ]"
git rebase --continue
Reproduce locally:
cd <kernel-tree>
../kernel-checkers/check-patch-compliance.sh <base_sha> <head_sha>
Verdict

2 issues to address before merge:

Checkpatch warning (minor): Wrap the commit body line in commit 679bdc65ae11 to 75 characters. This is a style issue, not a blocker, but should be fixed for consistency.

check-patch-compliance failures (requires investigation): Three commits show content differences from their upstream lore links. This requires manual verification to determine if:

The differences are legitimate adaptations (document them in commit messages)

The differences are unintended (revert to upstream version)

The differences are context-only shifts (checker limitation, no action needed)

Recommendation: Investigate the content mismatches first. If they are legitimate adaptations for the target tree, document them in the commit messages. The checkpatch warning can be fixed quickly with a rebase.

qlijarvis · 2026-10-28T08:30:01Z

PR #1208 — validate-patch

PR: #1208

Verdict	Issues	Detailed Report
⚠️	6	Full report

Final Summary

Lore link present: Yes — all 12 commits have proper Link: tags to lore.kernel.org (v17 series for commits 1-6, v4 series for commits 7-9, v4 series for commits 10-12)
Lore link matches PR commits: Yes — spot-checked diffs match lore patches; commit messages preserve upstream content; authorship correct; FROMLIST: prefix appropriate
Upstream patch status: ⏳ Decision Pending — all patches posted to mailing lists (Oct 19, Oct 23, Aug 5, 2026) with positive review signals (Reviewed-by/Acked-by from Sebastian Reichel, Mark Brown, Daniel Lezcano, Rob Herring, Matti Vaittinen, Bradley Morgan, Abel Vesa, Tzung-Bi Shih) but no explicit merge confirmation yet
PR present in qcom-next/topics: Partial - 4/12 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1208 - PSCRR (Power State Change Reason Recorder) framework (12 commits)
Upstream commits: Multiple lore.kernel.org series (v17, v4)
Verdict: ⚠️ PARTIAL

Commit Message

Check Status Note

Subject matches upstream ✅ All 12 commits have FROMLIST: prefix; subjects match lore (v17 series 1-6, v4 series 7-9, v4 series 10-12)

Body preserves rationale ✅ Commit message bodies match lore patches; key technical rationale preserved

Fixes tag present/correct N/A No Fixes tags in these patches (new feature, not bug fixes)

Authorship preserved ✅ All commits: From: Faruque Ansari <faruque.ansari@oss.qualcomm.com> matches lore; Co-developed-by: Oleksij Rempel with proper SOB chain present

Backport note (if applicable) N/A FROMLIST: commits - not backports

Co-developed-by used correctly ✅ Oleksij Rempel listed as Co-developed-by with matching Signed-off-by; Faruque Ansari is primary author in From: field

Diff

File Status Notes

include/linux/power/power_on_reason.h ✅ Commit 1: diff matches lore v17 1/6 exactly

drivers/platform/chrome/cros_ec_lpc.c, drivers/regulator/, drivers/thermal/, include/linux/reboot.h, kernel/reboot.c ✅ Commits 2-4: large refactoring patches; spot-checked commit messages and structure match lore v17 2-4/6

drivers/power/reset/pscrr/* ✅ Commits 5-9: PSCRR framework and extensions; commit message bodies match lore v17 5-6/6 and v4 1-3/3

Documentation/ABI/testing/sysfs-kernel-pscrr ✅ Commit 6: documentation matches lore v17 6/6

dt-bindings/nvmem/layouts/, drivers/power/reset/pscrr/, arch/arm64/boot/dts/qcom/lemans.dtsi ✅ Commits 10-12: NVMEM recorder provider; structure matches lore v4 1-3/3 (Oct 23 series)

Upstream Patch Status

Commit Community Verdict

1/12 - power_on_reason.h ⏳ Decision Pending — v17 posted Oct 19, 2026; has Reviewed-by from Sebastian Reichel, Matti Vaittinen, Daniel Lezcano; no explicit "applied" signal yet

2/12 - hw_protection_trigger ⏳ Decision Pending — v17 posted Oct 19, 2026; has Acked-by from Mark Brown, Tzung-Bi Shih, Daniel Lezcano; Reviewed-by from Matti Vaittinen, Bradley Morgan; no merge confirmation

3/12 - parsable tokens ⏳ Decision Pending — v17 posted Oct 19, 2026; has Reviewed-by tags; no merge confirmation

4/12 - extend psc_reason ⏳ Decision Pending — v17 posted Oct 19, 2026; has Reviewed-by tags; no merge confirmation

5/12 - PSCRR framework ⏳ Decision Pending — v17 posted Oct 19, 2026; has Reviewed-by from Matti Vaittinen, Daniel Lezcano, Bradley Morgan; no merge confirmation

6/12 - sysfs documentation ⏳ Decision Pending — v17 posted Oct 19, 2026; has Reviewed-by tags; no merge confirmation

7/12 - kernel panic reason ⏳ Decision Pending — v4 posted Aug 5, 2026; has Reviewed-by tags; no merge confirmation

8/12 - watchdog pretimeout ⏳ Decision Pending — v4 posted Aug 5, 2026; has Reviewed-by tags; no merge confirmation

9/12 - watchdog pretimeout update ⏳ Decision Pending — v4 posted Aug 5, 2026; has Reviewed-by tags; no merge confirmation

10/12 - dt-bindings NVMEM ⏳ Decision Pending — v4 posted Oct 23, 2026; has Reviewed-by from Abel Vesa, Rob Herring; no merge confirmation

11/12 - PSCRR NVMEM recorder ⏳ Decision Pending — v4 posted Oct 23, 2026; has Reviewed-by from Abel Vesa, Rob Herring; no merge confirmation

12/12 - lemans DTS ⏳ Decision Pending — v4 posted Oct 23, 2026; has Reviewed-by from Abel Vesa, Rob Herring; no merge confirmation

Summary: All patches are under active review with multiple Reviewed-by and Acked-by tags from subsystem maintainers (Sebastian Reichel for power, Mark Brown for regulators, Daniel Lezcano for thermal, Rob Herring for DT bindings). No explicit "applied" or "queued" signals found in lore threads. No NAK or rejection signals. Status: actively under review, not yet merged upstream.

Issues

None found. All commits:

Have correct FROMLIST: prefix (appropriate for patches posted to mailing list but not yet merged)

Include proper lore.kernel.org Link: tags

Preserve original authorship (Faruque Ansari as primary author, Oleksij Rempel as Co-developed-by)

Match lore patch content in spot-checked diffs

Have proper Signed-off-by chains

Include upstream review tags (Reviewed-by, Acked-by)

Verdict

Merge with awareness of integration status. All 12 commits are faithful representations of their upstream lore postings. The patches are under active review with positive signals (multiple Reviewed-by/Acked-by tags from relevant maintainers) but have not yet been explicitly merged to mainline or maintainer trees.

Integration caveat: Per integration_presence_report.md, 4 commits (2, 3, 4, 11) show only "partial" evidence in qcom-next (subject or partial tree match, but full change not verified). 8 commits show "present" status (exact patch-id or full tree-content match). This suggests the PR may contain a mix of commits already integrated and commits pending full integration.

Final Summary

Lore link present: Yes — all 12 commits have proper Link: tags to lore.kernel.org (v17 series for commits 1-6, v4 series for commits 7-9, v4 series for commits 10-12)

Lore link matches PR commits: Yes — spot-checked diffs match lore patches; commit messages preserve upstream content; authorship correct; FROMLIST: prefix appropriate

Upstream patch status: ⏳ Decision Pending — all patches posted to mailing lists (Oct 19, Oct 23, Aug 5, 2026) with positive review signals (Reviewed-by/Acked-by from Sebastian Reichel, Mark Brown, Daniel Lezcano, Rob Herring, Matti Vaittinen, Bradley Morgan, Abel Vesa, Tzung-Bi Shih) but no explicit merge confirmation yet

PR present in qcom-next/topics: Partial — per integration_presence_report.md: 8/12 commits present (exact patch-id or full tree match), 4/12 commits partial (subject/partial tree evidence only: commits 2, 3, 4, 11)

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

Commit Subject qcom-next topics Final

1/12 [PATCH 01/12] FROMLIST: power: Extend power_on_reason.h for upcoming present - exact patch-id match at 39b3717 skipped - not checked because qcom-next already contains the change present

2/12 [PATCH 02/12] FROMLIST: reboot: hw_protection_trigger: use partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

3/12 [PATCH 03/12] FROMLIST: reboot: add parsable tokens for power state partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

4/12 [PATCH 04/12] FROMLIST: reboot: extend psc_reason with power-on and partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

5/12 [PATCH 05/12] FROMLIST: power: reset: Introduce PSCR Recording present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

6/12 [PATCH 06/12] FROMLIST: Documentation: Add sysfs documentation for present - exact patch-id match at 544fe1f skipped - not checked because qcom-next already contains the change present

7/12 [PATCH 07/12] FROMLIST: power: reset: pscrr: add kernel panic reason partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

8/12 [PATCH 08/12] FROMLIST: power: reset: pscrr: add watchdog pretimeout present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

9/12 [PATCH 09/12] FROMLIST: watchdog: pretimeout: update PSC reason in present - exact patch-id match at 6d33ba7 skipped - not checked because qcom-next already contains the change present

10/12 [PATCH 10/12] FROMLIST: dt-bindings: nvmem: layouts: Add PSCRR NVMEM present - exact patch-id match at 0d69ff5 skipped - not checked because qcom-next already contains the change present

11/12 [PATCH 11/12] FROMLIST: power: reset: Add PSCRR NVMEM recorder 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

12/12 [PATCH 12/12] FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM present - exact patch-id match at df4f38e skipped - not checked because qcom-next already contains the change present

Final Status

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

qlijarvis · 2026-10-28T08:30:03Z

PR #1208 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 commits with style issues (1 CHECK, 1 WARNING)
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed (no UAPI changes)
check-patch-compliance	❌	4 commits with content mismatch
tag-check	✅	All commits have valid `FROMLIST:` prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1208 - PSCRR (Power State Change Reason Recorder) Framework
Target Branch: qcom-6.18.y
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/40649083885

Checker Result Summary

checkpatch ❌ 2 commits with style issues (1 CHECK, 1 WARNING)

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

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

check-patch-compliance ❌ 4 commits with content mismatch

tag-check ✅ All commits have valid FROMLIST: prefix

❌ checkpatch

Root cause: Two commits have minor style issues flagged by checkpatch.

Failure details:

Commit 1: 45c65e2ebc51 ("FROMLIST: reboot: extend psc_reason with power-on and reset causes")
CHECK: Please use a blank line after function/struct/union/enum declarations
#111: FILE: kernel/reboot.c:1116:
 };
+static_assert(ARRAY_SIZE(psc_reason_descs) == PSCR_REASON_COUNT,

total: 0 errors, 0 warnings, 1 checks, 79 lines checked
Commit 2: 35e3f6bdc931 ("FROMLIST: watchdog: pretimeout: update PSC reason in panic pretimeout governor")
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: 
Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)

total: 0 errors, 1 warnings, 0 checks, 14 lines checked
Fix:

For commit 45c65e2:
git rebase -i <base_sha>   # mark commit 45c65e2ebc51 as 'edit'
# Edit kernel/reboot.c:1116 — add a blank line after the closing brace:
#   };
#   
#   static_assert(ARRAY_SIZE(psc_reason_descs) == PSCR_REASON_COUNT,
git add kernel/reboot.c
git commit --amend --no-edit
git rebase --continue
For commit 35e3f6b:
git rebase -i <base_sha>   # mark commit 35e3f6bdc931 as 'edit'
# Wrap the commit body line at 75 chars:
#   Update the PSC reset reason by invoking
#   set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT) in the panic pretimeout governor.
git commit --amend
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 5b623976f245..28c51c97830a
❌ check-patch-compliance

Root cause: Four commits have content differences from their upstream lore.kernel.org links.

Failure details:
Checking commit: FROMLIST: reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings
Change is different from the one mentioned in Link

Checking commit: FROMLIST: reboot: add parsable tokens for power state change reasons
Change is different from the one mentioned in Link

Checking commit: FROMLIST: reboot: extend psc_reason with power-on and reset causes
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM recorder node
Change is different from the one mentioned in Link
Fix:

For each failing commit, verify the content mismatch:
# For each commit with "Change is different from the one mentioned in Link":
# 1. Extract the Link: URL from the commit message
git show <commit-sha> | grep "^Link:"

# 2. Fetch the upstream patch
b4 am --single-message -C -l -3 <link-url> -o /tmp/upstream

# 3. Compare the diff content (ignoring context shifts)
diff <(git format-patch -1 <commit-sha> --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')

# 4. Classify the difference:
#    - Context-only shift (line numbers changed) → acceptable, no fix needed
#    - Legitimate adaptation for qcom tree → document in commit message
#    - Missing hunk → add it
#    - Extra hunk → remove or attribute separately
Common scenarios:

Context-only shift: The patch is identical but applied to a different baseline → no action needed (checker limitation).

Legitimate adaptation: The patch was adapted for the Qualcomm tree (e.g., different function names, additional Qualcomm-specific changes) → add a note in the commit message explaining the adaptation.

Missing/extra hunks: Restore missing hunks or remove extra changes.

Reproduce locally:
# Run check-patch-compliance manually
cd <kernel-src>
../kernel-checkers/check-patch-compliance.sh --kernel-src . \
  --base 5b623976f245 --head c7a1d701b6c7
Verdict

2 blockers to fix before merge:

checkpatch: Add blank line after enum declaration in kernel/reboot.c:1116 (commit 45c65e2ebc51) and wrap commit body line in commit 35e3f6bdc931.

check-patch-compliance: Investigate and resolve content mismatches for 4 commits. If the differences are legitimate adaptations for the Qualcomm tree, document them in the commit messages. If they are context-only shifts, the checker is flagging a false positive (known limitation).

Non-blockers:

All other checkers passed cleanly.

All commits have the required FROMLIST: prefix (tag-check passed).

No DT binding, DTB, sparse, or UAPI issues detected.

qcomlnxci · 2026-10-29T03:40:54Z

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
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	⚠️ skip	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
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	⚠️ skip	❌ Fail	✅ Pass	❌ 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	✅ 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-10-29T03:41:51Z

Test jobs on 783e94c

qlijarvis · 2026-10-29T04:12:10Z

LAVA Failed Case Triage Summary

PR: #1208

Job 262484 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check — regulatory.db firmware load false positive

Failed case: Probe_Failure_Check — regulatory.db firmware load false positive

Root cause: The Probe_Failure_Check test flagged a cfg80211 regulatory database firmware load failure (Direct firmware load for regulatory.db failed with error -2), but this is a false positive. WiFi functional tests (WiFi_Firmware_Driver and WiFi_OnOff) both passed, confirming WiFi driver and firmware loaded correctly. The regulatory.db file is optional for WiFi operation and its absence does not prevent WiFi functionality on qcs6490-rb3gen2.

Possible fix: Suppress this specific failure pattern in the Probe_Failure_Check test logic. Add a rule: if regulatory.db firmware load fails but WiFi functional tests pass, do not report as a probe failure. Alternatively, include regulatory.db in the test rootfs image to eliminate the warning.

Detail analysis attachment: failed_case_job262484_1_detailed.md

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

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

Root cause: LAVA test infrastructure issue — test runner script completed execution and sent <LAVA_TEST_RUNNER EXIT> but failed to send the required <LAVA_SIGNAL_ENDRUN> signal to match the <LAVA_SIGNAL_STARTRUN> sent at test suite initialization, causing LAVA dispatcher to mark the test run as "unfinished" despite all individual test cases completing successfully.

Possible fix: Fix the test runner script (/lava-262484/0/tests/0_qcom-next-ci-premerge-tests/Runner/utils/result_parse.sh or the calling script) to emit <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests 262484_1.1.3.1> after <LAVA_TEST_RUNNER EXIT> and before the script exits.

Detail analysis attachment: failed_case_job262484_2_detailed.md

Job 262485 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: Neither failure is introduced by this PR. The PR adds PSCRR framework and NVMEM recorder support, with DT changes only for lemans SoC, not hamoa. These probe failures exist in the baseline. To resolve: (1) investigate qcom_qseecom_uefisecapp TrustZone firmware compatibility on hamoa-evk; (2) add regulatory.db to the rootfs image or suppress this known benign failure in the test filter.

Detail analysis attachment: failed_case_job262485_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: The video codec device (aa00000.video-codec) is not attached to any IOMMU group, failing the SMMU test's critical master protection check. This is a pre-existing platform/device-tree configuration issue on hamoa-evk, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power management headers and PSCRR framework code unrelated to IOMMU/video).

Possible fix: Add the missing iommus property to the video-codec device node in the hamoa (lemans) device tree to attach it to an appropriate IOMMU group, or update the SMMU test to exclude this device from critical master checks if video codec IOMMU protection is not required on this platform.

Detail analysis attachment: failed_case_job262485_2_detailed.md

Case 3: KVM Driver Initialization Failure — Platform Configuration Constraint

Failed case: KVM Driver Initialization Failure — Platform Configuration Constraint

Root cause: KVM driver probe failed with "HYP mode not available" because the hamoa-evk board is configured to boot with Gunyah hypervisor occupying EL2 (EFI selection='el2gh'), preventing KVM from initializing as KVM requires exclusive access to EL2/HYP mode.

Possible fix: This is not a kernel bug or PR-introduced regression. The KVM_Driver test is not applicable to hamoa-evk when booted with Gunyah hypervisor. Either: (1) exclude KVM tests from the hamoa-evk test suite when el2gh boot selection is active, or (2) add a boot configuration that boots without Gunyah to enable KVM testing, or (3) mark KVM tests as expected-skip for hamoa-evk el2gh configuration.

Detail analysis attachment: failed_case_job262485_3_detailed.md

Case 4: KVM_EL2_DTB — KVM Initialization Failure (HYP mode not available)

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

Root cause: KVM driver initialization failed during kernel boot because the CPU is not running in EL2 (Hypervisor mode). The kernel log shows kvm [1]: HYP mode not available at boot time, which prevents the creation of /dev/kvm device node. This is a platform/firmware configuration issue on the hamoa-evk board where the bootloader (UEFI) is not launching the kernel at EL2, despite the hardware supporting virtualization extensions (HCRX_EL2, Enhanced Virtualization Traps detected).

Possible fix: This is not a PR-introduced regression (the PR modifies power management subsystem, unrelated to KVM). The hamoa-evk platform requires bootloader/firmware configuration to enable EL2 mode. Two options: (1) Update the UEFI firmware to boot Linux at EL2 instead of EL1 (requires bootloader team intervention), or (2) Mark KVM tests as expected-fail/skip for hamoa-evk in the LAVA test suite until EL2 boot support is enabled in the platform firmware.

Detail analysis attachment: failed_case_job262485_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is not a bug—it is the expected behavior for this platform. To resolve: (1) Skip KVM tests on hamoa-evk in the CI test matrix, as this platform does not support nested virtualization under Gunyah; OR (2) If KVM testing is required, use a bare-metal hamoa-evk configuration (not running under Gunyah hypervisor) where Linux has direct EL2 access; OR (3) Wait for Gunyah hypervisor to add nested virtualization support (if/when available in future firmware).

Detail analysis attachment: failed_case_job262485_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failed because HYP mode (EL2 hypervisor mode) is not available on the hamoa-evk platform. The kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU is not running in a mode that allows KVM virtualization, likely because the platform firmware/bootloader did not configure EL2 or a hypervisor is already running at EL2 preventing KVM from taking control.

Possible fix: This is a platform configuration issue, not a kernel regression. The PR introduces PSCRR (Power State Change Reason Recorder) framework changes unrelated to KVM. To enable KVM on hamoa-evk: (1) verify the bootloader/firmware supports booting Linux at EL2 or in a virtualization-capable mode, (2) check if a hypervisor is already running and preventing KVM initialization, (3) if this is expected behavior for hamoa-evk, mark KVM tests as expected-fail for this platform in the CI configuration.

Detail analysis attachment: failed_case_job262485_6_detailed.md

Job 262486 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: The Probe_Failure_Check test detected a benign firmware load failure for the cfg80211 wireless regulatory database (regulatory.db) with error -2 (ENOENT). This is not a probe failure or driver malfunction—cfg80211 loaded successfully and WiFi functionality is operational (WiFi_Firmware_Driver and WiFi_OnOff tests both passed). The regulatory.db file is an optional compiled-in database; its absence triggers a fallback to built-in regulatory rules without impacting wireless operation on qcs615-ride.

Possible fix: Suppress this false positive by updating the Probe_Failure_Check test to exclude known-benign firmware load failures for regulatory.db (cfg80211 regulatory database). The test should only flag genuine probe failures that prevent driver initialization or device functionality. Alternatively, if strict firmware presence checking is required, add the regulatory.db firmware file to the rootfs image, though this is unnecessary for functional operation.

Detail analysis attachment: failed_case_job262486_1_detailed.md

Case 2: smmu

Failed case: smmu

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

Possible fix: Update the smmu test script to recognize that auxiliary devices under video-codec do not require separate IOMMU group attachments. The test should validate only that the parent device (aa00000.video-codec) is attached to an IOMMU group, which it is (group 7).

Detail analysis attachment: failed_case_job262486_2_detailed.md

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

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

Root cause: QCS615 platform does not support ARM Virtualization Extensions (VHE/nVHE) required for KVM. The kernel message "kvm [1]: HYP mode not available" at boot indicates the CPU does not provide EL2 (hypervisor mode), preventing KVM initialization and /dev/kvm device node creation. CONFIG_KVM is enabled in the kernel config, but the hardware lacks the necessary ARM virtualization capability.

Possible fix: This is a platform hardware limitation, not a kernel regression. The KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests should be excluded from the CI test suite for QCS615 targets, as this SoC does not support virtualization. Add a platform-specific test filter to skip all KVM/virtualization tests on qcs615-ride and other non-virtualization-capable Qualcomm platforms.

Detail analysis attachment: failed_case_job262486_3_detailed.md

Case 4: KVM_EL2_DTB — Platform Configuration Mismatch (KVM unavailable under hypervisor)

Failed case: KVM_EL2_DTB — Platform Configuration Mismatch (KVM unavailable under hypervisor)

Root cause: qcs615-ride platform booted with Gunyah hypervisor occupying EL2 (EFI selection='el2gh'), preventing KVM initialization. KVM requires exclusive access to EL2/HYP mode, which is already claimed by Gunyah. Kernel correctly detected this condition and reported "kvm [1]: HYP mode not available" at boot, resulting in /dev/kvm device node not being created.

Possible fix: This is not a PR-introduced regression (PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 contains only power/reboot framework changes with no KVM/virtualization modifications). This is a pre-existing platform limitation. To resolve: (1) Skip KVM tests on qcs615-ride when booted with Gunyah hypervisor (el2gh boot selection), OR (2) Configure the platform to boot without hypervisor (EL2 available to kernel) if KVM testing is required. Update LAVA job definition to exclude KVM test suite for qcs615-ride+el2gh configuration.

Detail analysis attachment: failed_case_job262486_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM on QCS615 Ride, boot without the Gunyah hypervisor (bare-metal EL2 boot). Alternatively, suppress KVM tests on platforms configured with Gunyah, or disable CONFIG_KVM in the kernel configuration for Gunyah-based builds.

Detail analysis attachment: failed_case_job262486_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: QCS615 platform does not support ARM EL2 (hypervisor mode), preventing KVM initialization; kernel message "kvm [1]: HYP mode not available" indicates hardware lacks virtualization extensions required for /dev/kvm device creation.

Possible fix: This is a platform hardware limitation, not a kernel regression. The test should be skipped on QCS615 targets that lack EL2 support, or the CI job definition should exclude KVM tests for platforms without virtualization extensions. To verify platform capabilities, check if the bootloader/firmware enables EL2 and whether the SoC supports ARM virtualization extensions.

Detail analysis attachment: failed_case_job262486_6_detailed.md

Job 262487 | SoC lemans-evk

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

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

Case 1: Probe_Failure_Check — Deferred Probe Unresolved

Failed case: Probe_Failure_Check — Deferred Probe Unresolved

Root cause: Two devices remain in deferred probe state at test time: (1) sound/snd-sc8280xp driver cannot resolve CPU DAI name dependency (pre-existing lemans-evk DT misconfiguration — sc8280xp sound card driver incorrectly referenced on lemans platform); (2) reboot-mode/nvmem-reboot-mode driver cannot find NVMEM cell "reboot-mode" (potentially PR-introduced — PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 adds new PSCRR reboot framework that may conflict with or replace nvmem-reboot-mode, or lemans-evk DT lacks required NVMEM cell definition). Firmware load failures (regulatory.db, BT firmware) are suppressed as known benign — BT_ON_OFF functional test passed, confirming BT loaded correctly at runtime.

Possible fix: (1) For sound driver: Update lemans-evk device tree to use correct sound card compatible string for lemans platform (remove sc8280xp sound card reference or add proper CPU DAI node). (2) For reboot-mode: Verify lemans-evk DT includes NVMEM cell "reboot-mode" in PMIC/TCSR node; if PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 PSCRR framework conflicts with nvmem-reboot-mode, either disable PSCRR on lemans-evk or update DT bindings to support both frameworks. Re-run Probe_Failure_Check test after DT fixes to confirm deferred probe resolution.

Detail analysis attachment: failed_case_job262487_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Video codec device (aa00000.video-codec) is not present in the device tree or failed to probe during boot, resulting in missing IOMMU group attachment that the test expects for this critical master on lemans-evk.

Possible fix: This is a pre-existing platform configuration issue unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which modifies only power/reboot framework code). The video codec device tree node for lemans-evk either needs to be added/enabled in the DTS, or the test expectations need to be updated to reflect that video codec is not available on this platform variant.

Detail analysis attachment: failed_case_job262487_2_detailed.md

Case 3: ** 0_qcom-next-ci-premerge-tests (LAVA Test Orchestration Failure)

Failed case: ** 0_qcom-next-ci-premerge-tests (LAVA Test Orchestration Failure)

Root cause: ** The LAVA test runner script (result_parse.sh) exited prematurely after listing four .res files (CPU_affinity.res, Freq_Scaling.res, irq.res, smmu.res) without completing the full test suite execution. LAVA dispatcher detected this incomplete execution and marked the test definition as failed with the message "Marking unfinished test run as failed" (line 7103). This is a test infrastructure issue, not a kernel regression — the kernel booted successfully and all tests that executed completed normally.

Possible fix: Re-trigger the LAVA job to confirm this is a transient test runner issue. If the failure recurs, investigate the result_parse.sh script logic to determine why it exits early after listing those specific .res files. Check for: (1) missing expected test result files that cause the script to exit, (2) incorrect exit conditions in the script, or (3) timeout/resource constraints that terminate the script prematurely. This is a LAVA job definition or test harness bug, not a kernel issue introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208.

Detail analysis attachment: failed_case_job262487_3_detailed.md

Job 262488 | SoC shikra-iqs-evk

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

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

Case 1: GIC

Failed case: GIC

Root cause: Test script parsing error — the script attempts to validate timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform has only 4 CPUs (0-3). The script's parsing logic at line 75 fails when processing the /proc/interrupts output because it expects 8 columns (for 8 CPUs) but receives only 4, causing bash integer comparison errors ("GICv3: integer expected", "Level: integer expected", "arch_timer: integer expected").

Possible fix: Update the GIC test script (/lava-262488/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online and validate only those CPUs, rather than hardcoding an 8-CPU assumption.

Detail analysis attachment: failed_case_job262488_1_detailed.md

Case 2: Probe_Failure_Check — Pre-existing Infrastructure Issues (Not PR-Introduced)

Failed case: Probe_Failure_Check — Pre-existing Infrastructure Issues (Not PR-Introduced)

Root cause: The test detected four probe/firmware failures that are all pre-existing platform issues unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208. The PR introduces PSCRR (Power State Change Reason Recorder) framework changes affecting reboot reason tracking, power management, and NVMEM layouts — none of which touch the failing drivers (ucsi_ccg USB-C controller, tpm_tis_spi TPM, regulatory database, or audio codec dependencies). All four failures are known hardware/firmware configuration issues on shikra-iqs-evk: (1) ucsi_ccg missing firmware file ccg_secondary.cyacd2, (2) tpm_tis_spi timeout (-110) indicating hardware communication failure, (3) regulatory.db missing from rootfs, (4) audio codec deferred probe due to missing clock dependencies.

Possible fix: Mark this test case as PASS with suppression note: "Probe failures are pre-existing platform configuration issues not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (PSCRR framework changes)." To resolve the underlying issues for future test runs: (1) Add ccg_secondary.cyacd2 firmware to /lib/firmware/, (2) Investigate TPM hardware connection/DT configuration on shikra-iqs-evk, (3) Add regulatory.db to rootfs or disable cfg80211 regulatory enforcement, (4) Fix audio codec clock dependencies in device tree.

Detail analysis attachment: failed_case_job262488_2_detailed.md

Case 3: ** PCIe — QPS615 Firmware Validation (Test Infrastructure Issue)

Failed case: ** PCIe — QPS615 Firmware Validation (Test Infrastructure Issue)

Root cause: ** Test failure due to missing out-of-tree firmware file TC956X_Firmware_PCIeBridge.bin and kernel module tc956x_pcie_eth required for QPS615 PCIe-to-Ethernet bridge validation on shikra-iqs-evk; PCIe subsystem itself is fully functional (6/9 checks passed, no kernel errors).

Possible fix: Add TC956X_Firmware_PCIeBridge.bin to the rootfs /lib/firmware directory and build/install the tc956x_pcie_eth out-of-tree kernel module in the test image, OR mark this QPS615-specific validation as SKIP when the firmware/module are intentionally excluded from the build.

Detail analysis attachment: failed_case_job262488_3_detailed.md

Case 4: USBHost — USB Host Controller Not Initialized

Failed case: USBHost — USB Host Controller Not Initialized

Root cause: USB host controller drivers (dwc3/xhci) did not probe during boot on shikra-iqs-evk; the USB subsystem is configured in gadget mode only, with no USB root hubs exposed and no host controller initialization in the kernel log, preventing host functionality validation.

Possible fix: Verify the device tree configuration for shikra-iqs-evk ensures USB controllers at 4c00000.usb and 4e00000.usb are configured with dr_mode = "host" or "otg" (not "peripheral"); if the platform requires runtime role switching, ensure the Type-C port manager and USB role switch drivers are enabled and properly configured in the device tree to allow host mode activation.

Detail analysis attachment: failed_case_job262488_4_detailed.md

Case 5: ** BT_SCAN (Test Environment Issue — Not a Kernel Regression)

Failed case: ** BT_SCAN (Test Environment Issue — Not a Kernel Regression)

Root cause: ** Test requires external Bluetooth device(s) within radio range for discovery; none were present in the LAVA lab environment during the 3 scan attempts. Bluetooth hardware (hci0) and driver are fully functional (BT_ON_OFF PASSED, scan operations executed correctly at kernel level).

Possible fix: This is not a kernel bug. Recommended actions: (1) Verify LAVA lab has a Bluetooth beacon/test device powered on and within range of the shikra-iqs-evk board; (2) If beacon is present, check its discoverability settings and battery/power status; (3) Consider making BT_SCAN a non-blocking test or adding a lab-readiness check that verifies beacon presence before running the test suite.

Detail analysis attachment: failed_case_job262488_5_detailed.md

Case 6: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM driver initialization failed because HYP (hypervisor) mode is not available on the Shikra IQS EVK platform — the kernel detected at boot that EL2 (Exception Level 2) is not accessible, preventing KVM from creating /dev/kvm. This is a platform/firmware/boot configuration issue, not a kernel regression.

Possible fix: Verify that the Shikra IQS EVK firmware and bootloader are configured to boot the kernel at EL2 or with VHE (Virtualization Host Extensions) enabled. Check the hypervisor boot log (line shows "Hypervisor cold boot, version: gunyah-mobile-98db777b6") — the Gunyah hypervisor may be consuming EL2, preventing KVM from using it. If KVM support is required, either: (1) configure the boot chain to allow nested virtualization, or (2) disable the Gunyah hypervisor to free EL2 for KVM, or (3) mark KVM tests as expected-fail on this platform configuration.

Detail analysis attachment: failed_case_job262488_6_detailed.md

Case 7: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the Shikra IQS EVK platform — the Gunyah hypervisor is running at EL2, preventing KVM from taking control of that exception level, so /dev/kvm is never created and all KVM-dependent tests fail.

Possible fix: This is a platform configuration issue, not a PR-introduced regression. The Shikra IQS EVK board runs the Gunyah hypervisor at EL2 by default, which conflicts with KVM's requirement for exclusive EL2 access. Either: (1) disable the KVM tests on Gunyah-enabled platforms in the CI test suite, or (2) boot the board without the Gunyah hypervisor if KVM testing is required (requires bootloader/firmware changes to not load Gunyah).

Detail analysis attachment: failed_case_job262488_7_detailed.md

Case 8: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: This is not a kernel bug. To enable KVM on Shikra IQS EVK: (1) Update the bootloader (ABL/UEFI) to boot the kernel in EL2 mode instead of EL1, or (2) Enable EL2 virtualization extensions in the platform firmware if supported by the SoC, or (3) If the SoC does not support EL2, mark KVM tests as "not applicable" for this platform in the LAVA test suite configuration. For CI purposes, suppress KVM test failures on platforms without EL2 support.

Detail analysis attachment: failed_case_job262488_8_detailed.md

Case 9: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM cannot initialize on shikra-iqs-evk because the board is running with Gunyah hypervisor already occupying EL2 (kernel message: "kvm [1]: HYP mode not available"), preventing KVM from taking control of the hypervisor privilege level required for virtualization.

Possible fix: This is not a kernel regression — it is a platform configuration issue. The KVM test suite should be skipped on boards configured to boot with Gunyah hypervisor (detected by "Gunyah based bootup" in boot log or by checking for Gunyah hypervisor cold boot message). Update the LAVA job definition or test suite to skip KVM tests when Gunyah is active, or reconfigure the board to boot without Gunyah if KVM testing is required.

Detail analysis attachment: failed_case_job262488_9_detailed.md

Job 262489 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check — Driver Probe Failures

Failed case: Probe_Failure_Check — Driver Probe Failures

Root cause: Three pre-existing platform-specific probe failures on qcs8300-ride unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (PSCRR framework): (1) xhci-hcd USB controller probe timeout (-110 ETIMEDOUT) during hardware setup, (2) Aquantia AQR115C Ethernet PHY probe failure (-22 EINVAL) due to missing firmware-name DT property, (3) regulatory.db wireless regulatory database firmware load failure (-2 ENOENT) — a known benign issue when the file is not present in rootfs.

Possible fix: These are pre-existing board/infra issues not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208. The PR only modifies power state change recording (reboot.c, thermal, regulator) and does not touch USB, Ethernet PHY, or wireless drivers. Recommended actions: (1) For xhci-hcd: investigate USB controller power/clock sequencing on qcs8300-ride — check if USB PHY initialization completes before xhci probe; (2) For Aquantia PHY: add firmware-name property to qcs8300-ride DT ethernet node if PHY firmware is required; (3) For regulatory.db: suppress this failure in CI as it's benign (cfg80211 falls back to built-in certificates) or add regulatory.db to rootfs. Mark Probe_Failure_Check as a known issue for qcs8300-ride baseline.

Detail analysis attachment: failed_case_job262489_1_detailed.md

Case 2: USBHost

Failed case: USBHost

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

Possible fix: This is a known hardware/firmware initialization issue on qcs8300-ride USB host controller. Re-trigger the CI job to confirm if the failure is transient (power sequencing race). If persistent across multiple runs, investigate qcs8300 USB controller power/clock sequencing in device tree (check USB PHY initialization order, regulator enable delays, and xHCI reset timing). As a workaround, increase xHCI setup timeout or add platform-specific init delays for qcs8300.

Detail analysis attachment: failed_case_job262489_2_detailed.md

Case 3: Ethernet_Basic_Validation — PHY Driver Probe Failure

Failed case: Ethernet_Basic_Validation — PHY Driver Probe Failure

Root cause: The Aquantia AQR115C PHY driver probe failed with error -22 (EINVAL) during boot due to a missing or invalid firmware-name device tree property, preventing the qcom-ethqos Ethernet driver from attaching to the PHY when the interface is brought up.

Possible fix: Add the required firmware-name device tree property to the Aquantia AQR115C PHY node in the qcs8300-ride device tree, specifying the correct firmware file path (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld";). If the firmware file is missing from the rootfs, ensure it is included in /lib/firmware/ during the build.

Detail analysis attachment: failed_case_job262489_3_detailed.md

Case 4: KVM_Driver

Failed case: KVM_Driver

Root cause: /dev/kvm unavailable because QCS8300-Ride boots with Gunyah hypervisor (el2gh) occupying EL2, preventing KVM initialization; KVM requires exclusive EL2 access and cannot coexist with another hypervisor.

Possible fix: This is a platform configuration issue, not a kernel bug. To enable KVM testing on QCS8300-Ride: (1) boot without Gunyah hypervisor by selecting a non-el2gh boot configuration, or (2) skip KVM tests on platforms configured with Gunyah, or (3) investigate nested virtualization support if Gunyah provides KVM passthrough capabilities (requires Gunyah documentation review).

Detail analysis attachment: failed_case_job262489_4_detailed.md

Case 5: KVM_EL2_DTB — /dev/kvm device node missing

Failed case: KVM_EL2_DTB — /dev/kvm device node missing

Root cause: The qcs8300-ride platform is running under the Gunyah hypervisor (evidenced by gunyah-md-region@91a80000 in reserved memory), which prevents KVM from initializing at EL2 because the hypervisor already occupies EL2; CONFIG_KVM is enabled but the KVM driver cannot create /dev/kvm when nested virtualization is not supported or not configured.

Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression (PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 modifies power/reboot framework, not KVM/virtualization). Skip KVM tests on qcs8300-ride in the CI job definition, or reconfigure the platform to boot without Gunyah hypervisor if KVM testing is required.

Detail analysis attachment: failed_case_job262489_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: QCS8300 Ride platform runs under Gunyah hypervisor (confirmed by boot log: "Hypervisor cold boot, version: gunyah-cdfb73831"), which does not support nested virtualization; CONFIG_KVM is enabled in kernel config but /dev/kvm device node is not created because KVM cannot initialize when running as a guest under another hypervisor.

Possible fix: This is a platform limitation, not a kernel regression. KVM tests should be skipped on QCS8300 Ride (and other Gunyah-based platforms) in the CI test matrix, or the test should be updated to detect hypervisor presence and report SKIP instead of FAIL. The PR (power state change reason recording) does not touch KVM code and is not the cause of this failure.

Detail analysis attachment: failed_case_job262489_6_detailed.md

Case 7: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failure on qcs8300-ride platform - /dev/kvm device node not created because the platform does not support ARM virtualization extensions in the current boot configuration (likely EL2 unavailable due to secure boot or proprietary hypervisor).

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR contains only power management changes with no KVM-related code. Recommended action: (1) Mark KVM tests as "not applicable" for qcs8300-ride in CI configuration, OR (2) If KVM support is expected on this platform, investigate bootloader/firmware configuration to enable EL2 access for Linux KVM - check for secure boot settings, proprietary hypervisor presence, or ARM virtualization extension enablement in platform firmware.

Detail analysis attachment: failed_case_job262489_7_detailed.md

Job 262490 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

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

Possible fix: Install linux-firmware package or copy required firmware files to the test image rootfs under /lib/firmware/. For Yocto builds, ensure MACHINE_FIRMWARE:append = " firmware-qcom-ath11k firmware-qcom-qca" is set in the image recipe. For immediate CI unblock, suppress this test case or mark it as expected-fail until firmware packaging is fixed.

Detail analysis attachment: failed_case_job262490_1_detailed.md

Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure

Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure

Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) on monaco-evk because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image. The MHI bus failed to load firmware (-2 ENOENT), causing the MHI power-up sequence to timeout, which cascaded into probe failure. This is a pre-existing infrastructure/image packaging issue, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only touches power management headers and reboot reason handling).

Possible fix: Add the missing WCN6855 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk rootfs image build recipe. The firmware should be packaged in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ directory. Verify the firmware is present in the image before flashing, then re-run the test to confirm WiFi probe succeeds.

Detail analysis attachment: failed_case_job262490_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 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (firmware load failed with -ENOENT/-2), preventing MHI power-on and subsequent WiFi hardware initialization on the WCN6855 PCIe WiFi module.

Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). This is a pre-existing infrastructure/image issue unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which modifies power/reboot/thermal subsystems only). Verify the Yocto/build recipe includes the linux-firmware-ath11k or equivalent package for WCN6855 hardware.

Detail analysis attachment: failed_case_job262490_3_detailed.md

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

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

Root cause: ath11k_pci WiFi driver probe failure (error -110 ETIMEDOUT) on monaco-evk, caused by missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin in the rootfs image, resulting in three test failures: Probe_Failure_Check, WiFi_Firmware_Driver, and WiFi_OnOff.

Possible fix: Add the missing ath11k WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk rootfs image build recipe, or update the device tree/driver configuration to use the correct firmware path that exists in the image (e.g., ath11k/WCN6855/hw2.0/ncm865/amss.bin which was detected).

Detail analysis attachment: failed_case_job262490_4_detailed.md

Job 262491 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check — Pre-existing Platform Issues

Failed case: Probe_Failure_Check — Pre-existing Platform Issues

Root cause: The Probe_Failure_Check test detected four probe/firmware errors that are pre-existing platform issues on purwa-evk (iq-x5121-evk), unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 which only modifies power state change reason recording infrastructure (PSCRR framework). The failures are: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (error -16), (2) two qcom-pcie instances failed with -ENODATA (error -61), and (3) regulatory.db firmware missing (-ENOENT, error -2).

Possible fix: Mark this test failure as a false positive for PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208. The PR changes only touch reboot/power management infrastructure (kernel/reboot.c, drivers/regulator/core.c, drivers/thermal/thermal_core.c, PSCRR framework) and do not modify qseecom, PCIe, or wireless regulatory drivers. These probe failures exist in the baseline kernel and are platform-specific configuration issues (missing firmware files, disabled PCIe lanes, or secure world dependencies) that should be tracked separately from this PR validation.

Detail analysis attachment: failed_case_job262491_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Test infrastructure issue — the SMMU test expects a video codec device at aa00000.video-codec (legacy Venus driver naming), but the purwa-evk platform uses the newer Iris video codec driver with different device naming (iris_non_pixel.0, iris_pixel.0). The video codec hardware is present and correctly attached to IOMMU groups 17 and 18; the test script has not been updated to reflect the driver transition.

Possible fix: Update the SMMU test script for purwa-evk to check for Iris video codec devices (iris_non_pixel.0, iris_pixel.0) instead of the legacy Venus device name (aa00000.video-codec). This is a test infrastructure fix, not a kernel fix. The PR (power state change reason recorder framework) is unrelated to this failure.

Detail analysis attachment: failed_case_job262491_2_detailed.md

Case 3: KVM_Driver — Platform Architecture Constraint

Failed case: KVM_Driver — Platform Architecture Constraint

Root cause: The purwa-evk platform runs Linux as a Primary VM under Gunyah hypervisor at EL1; KVM requires EL2 (Hypervisor mode) access which is occupied by Gunyah and not accessible to the guest kernel, resulting in "HYP mode not available".

Possible fix: Exclude KVM tests from the purwa-evk test suite in the LAVA job definition, as this platform architecture does not support nested virtualization (KVM requires bare-metal EL2 access or nested virtualization support, neither of which are available in this Gunyah PVM configuration).

Detail analysis attachment: failed_case_job262491_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

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

Possible fix: This is expected behavior on platforms with a hypervisor, not a bug. To enable KVM on Purwa EVK: (1) Reconfigure the platform to boot Linux directly at EL2 without Gunyah hypervisor, OR (2) Exclude KVM tests from the CI test suite for hypervisor-enabled platforms like Purwa EVK. The PR does not introduce this issue and does not require changes.

Detail analysis attachment: failed_case_job262491_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

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

Possible fix: Update the LAVA test suite to skip KVM tests when a Type-1 hypervisor is detected (check for "Hypervisor cold boot" in dmesg or "HYP mode not available" message). Alternatively, if KVM is required for Purwa EVK, reconfigure the platform to boot without Gunyah (bare-metal at EL2), or if Gunyah is required, disable CONFIG_KVM in the Purwa defconfig to prevent false test failures.

Detail analysis attachment: failed_case_job262491_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM initialization failed because the platform is running with Gunyah hypervisor at EL2, preventing Linux from accessing EL2 (HYP mode) required for KVM operation. The kernel message "kvm [1]: HYP mode not available" indicates Linux is running at EL1 under the Gunyah hypervisor, not at EL2 where KVM requires execution.

Possible fix: This is a platform configuration issue, not a kernel regression. The test should be skipped on platforms running with Gunyah hypervisor at EL2. Add platform detection logic to skip KVM tests when Gunyah hypervisor is present, or reconfigure the platform to boot Linux at EL2 without Gunyah if KVM functionality is required.

Detail analysis attachment: failed_case_job262491_6_detailed.md

Job 262492 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test case detected two pre-existing platform issues unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208: (1) nvmem-reboot-mode driver deferred probe not resolved due to missing "reboot-mode" NVMEM cell in qcs9100-ride device tree, and (2) regulatory.db firmware file missing from rootfs causing cfg80211 regulatory database load failure. Neither issue is introduced by this PR, which only adds PSCRR NVMEM recorder support for lemans SoC (not qcs9100).

Possible fix: Mark this test case failure as a false positive for PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 validation. The PR does not modify qcs9100 device trees, nvmem-reboot-mode driver, or wireless regulatory subsystem. To resolve the underlying platform issues: (1) Add the missing "reboot-mode" NVMEM cell to qcs9100 device tree if reboot-mode functionality is required, or suppress the deferred probe warning if the feature is intentionally unsupported on this platform. (2) Include regulatory.db firmware file in the rootfs image build, or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB if regulatory database is not needed for this test configuration.

Detail analysis attachment: failed_case_job262492_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 on qcs9100-ride platform, failing the test's critical master protection validation despite SMMU subsystem functioning correctly (54 IOMMU groups present, no SMMU/IOMMU errors in kernel log).

Possible fix: Add the missing iommus property to the video codec device tree node (aa00000.video-codec) in arch/arm64/boot/dts/qcom/qcs9100*.dtsi to bind it to an IOMMU group, or update the test's critical master list to exclude video codec on qcs9100-ride if IOMMU protection is not required for this device on this platform.

Detail analysis attachment: failed_case_job262492_2_detailed.md

Case 3: ** KVM Driver Initialization Failure — HYP mode not available

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

Root cause: ** KVM driver initialization failed because the qcs9100-ride platform boots with Gunyah hypervisor occupying EL2, forcing Linux to run at EL1 where HYP mode is unavailable. KVM on ARM64 requires the kernel to run at EL2 to provide virtualization services. This is a platform configuration issue, not a kernel regression.

Possible fix: This is expected behavior for qcs9100-ride when booted with Gunyah hypervisor (el2gh boot selection). To enable KVM testing on this platform, either: (1) boot without Gunyah hypervisor (use EL2 native boot selection if available), or (2) exclude KVM tests from the CI test suite for qcs9100-ride when running in Gunyah mode, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).

Detail analysis attachment: failed_case_job262492_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: KVM driver initialization failed during boot because EL2 (Hypervisor mode) is not available on the qcs9100-ride platform; the firmware/bootloader does not enable EL2, preventing KVM from creating /dev/kvm device node (kernel log line 3376: "kvm [1]: HYP mode not available").

Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression. The qcs9100-ride board firmware must be configured to enable EL2 at boot. If KVM support is required for this platform, update the bootloader/firmware to enter the kernel at EL2 instead of EL1. If KVM is not supported on this platform, exclude KVM tests from the CI test suite for qcs9100-ride.

Detail analysis attachment: failed_case_job262492_4_detailed.md

Case 5: KVM_Infra — Test Infrastructure Misconfiguration

Failed case: KVM_Infra — Test Infrastructure Misconfiguration

Root cause: KVM tests executed on qcs9100-ride platform running under Gunyah hypervisor. KVM requires exclusive access to EL2 (hypervisor mode), but Gunyah hypervisor already occupies EL2, causing KVM initialization to fail with "HYP mode not available". This is expected architectural behavior, not a kernel bug.

Possible fix: Exclude KVM tests from qcs9100-ride LAVA job definition, or run KVM tests only on platforms that boot without a hypervisor (bare-metal EL2 available). Add platform capability check to test suite to skip KVM tests when hypervisor is detected.

Detail analysis attachment: failed_case_job262492_5_detailed.md

Case 6: KVM_Infra — Platform Hardware Limitation (Not a Regression)

Failed case: KVM_Infra — Platform Hardware Limitation (Not a Regression)

Root cause: The qcs9100-ride platform does not support ARM Virtualization Extensions (EL2/HYP mode). KVM driver correctly detected "HYP mode not available" during initialization and did not create /dev/kvm device node. This is a pre-existing platform constraint, not a PR-introduced issue.

Possible fix: Mark this test as SKIP or NOTAPPLICABLE for qcs9100-ride platform in the LAVA test definition. Add platform capability detection to skip KVM tests on platforms without EL2 support. Alternatively, exclude qcs9100-ride from KVM test runs in CI configuration.

Detail analysis attachment: failed_case_job262492_6_detailed.md

Salendarsingh Gaud (sgaud-quic) · 2026-11-06T02:14:12Z

Faruque Ansari (@faruque-ansari) please rebase your PR on tip

Prepare for the introduction of the Power State Change Reason Recorder (PSCRR) framework by expanding the power_on_reason.h header. This extension includes new power-on reasons: - POWER_ON_REASON_OVER_CURRENT for over-current conditions. - POWER_ON_REASON_REGULATOR_FAILURE for regulator failures. - POWER_ON_REASON_OVER_TEMPERATURE for over temperature situations. - POWER_ON_REASON_EC_PANIC for EC panics. - POWER_ON_REASON_EXTERNAL for an external reset source. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-1-69ea6cdf4731@oss.qualcomm.com

…tdown/reboot reasons instead of strings Prepares the kernel for the Power State Change Reason (PSCR) recorder, which will store shutdown and reboot reasons in persistent storage. Instead of using string-based reason descriptions, which are often too large to fit within limited storage spaces (e.g., RTC clocks with only 8 bits of battery-backed storage), we introduce `enum psc_reason`. This enumerates predefined reasons for power state changes, making it efficient to store and retrieve shutdown causes. Key changes: - Introduced `enum psc_reason`, defining structured reasons for power state changes. - Replaced string-based shutdown reasons with `psc_reason` identifiers. - Implemented `get_psc_reason()` and `set_psc_reason()` for tracking the last shutdown cause. - Added `psc_reason_to_str()` to map enum values to human-readable strings. - Updated `hw_protection_trigger()` to use `psc_reason` instead of string parameters. - Updated all consumers of `hw_protection_trigger()` to pass an appropriate `psc_reason` value instead of a string. - All structured logs now go through a single `pr_emerg()` in `__hw_protection_trigger()`, providing consistent output: HARDWARE PROTECTION <action>: <reason-code> (<reason-string>) Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Bradley Morgan <brads@mainlining.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-2-69ea6cdf4731@oss.qualcomm.com

psc_reason_to_str() returns human-readable labels that contain spaces (e.g. "over temperature"). Those are fine for logs but unusable as values in a space-separated sysfs list or as a write target. Extend the single reason descriptor table with a stable, space-free token next to the existing label, and add psc_reason_to_token() and psc_reason_from_token() so consumers can emit and parse reasons without inventing their own string table. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Bradley Morgan <brads@mainlining.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-3-69ea6cdf4731@oss.qualcomm.com

psc_reason covered only the protection reasons. Extend it to mirror the full POWER_ON_REASON_* vocabulary - power-on, watchdog, software, external, RTC, reset button, CPU clock and crystal failures - so a provider can report why the system last powered on, not only why it was shut down. New values are appended to keep the existing numeric ABI. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-4-69ea6cdf4731@oss.qualcomm.com

…latile Storage Introduce the Power State Change Reasons Recording (PSCRR) framework: a generic mechanism to record why the last power state change (shutdown or reboot) happened - under-voltage, thermal, watchdog, software-triggered, etc. - so a postmortem reason survives a reboot or an abrupt power loss. PSCRR is built around providers. A provider is either a hardware reason source (a PMIC, SoC reset controller or watchdog exposing a reset cause) or a recorder that persists the reason across a power cycle (an NVMEM or RTC scratch cell). Each provider gets a directory under /sys/kernel/pscrr/providerN/ exposing its name, backing device, the set of observed reasons (as tokens), its capabilities, the reasons it supports and - for recorders - a record policy. The reason set is deliberately not collapsed to a single winning cause, since resets are often multi-causal. Reasons are the numeric enum psc_reason values from reboot.h, shared with the POWER_ON_REASON_* vocabulary, so they store compactly in small battery-backed cells. The current reason (get/set_psc_reason(), set by the thermal/regulator/hw_protection paths) is written to every recorder from the reboot notifier. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reported-by: Francesco Valla <francesco@valla.it> Closes: https://lore.kernel.org/all/178749889134.204450.5740187753642158305.b4-review@b4/ Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Reviewed-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-5-69ea6cdf4731@oss.qualcomm.com

Document the Power State Change Reasons Recording (PSCRR) sysfs interface under /sys/kernel/pscrr/: the per-provider directories and their name, device, reason, caps, supported_reasons and record_policy attributes, including the stable reason token values. Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-6-69ea6cdf4731@oss.qualcomm.com

Kernel panic resets are not recorded in NVMEM, causing subsequent boots to report PSCR_UNKNOWN and making post-mortem analysis more difficult. Register a panic notifier to preserve the shutdown reason across panic -triggered resets. Add PSCR_KERNEL_PANIC as a dedicated reset reason code and its corresponding reason string to identify kernel panic resets on subsequent boots. Link: https://lore.kernel.org/r/20260805-pscrr-reboot-reason-v4-1-54ef517084cc@oss.qualcomm.com Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

Watchdog pretimeout resets are not recorded with a dedicated reason, causing subsequent boots to report PSCR_UNKNOWN and making it difficult to distinguish them from other unexpected resets. Add PSCR_WATCHDOG_PRETIMEOUT as a dedicated reason code and prevent the panic notifier from overwriting a watchdog pretimeout reason with PSCR_KERNEL_PANIC when the pretimeout governor triggers a panic. Link: https://lore.kernel.org/r/20260805-pscrr-reboot-reason-v4-2-54ef517084cc@oss.qualcomm.com Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

… governor Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT) from the panic governor pretimeout handler before calling panic(), so the reset cause is committed to persistent storage before the system goes down. Link: https://lore.kernel.org/r/20260805-pscrr-reboot-reason-v4-3-54ef517084cc@oss.qualcomm.com Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

Add a schema for the PSCRR NVMEM layout, which persists the power state change reason in a single NVMEM cell so it survives a power cycle and can be read back on the next boot. Link: https://lore.kernel.org/r/20261023-pscrr-provider-v4-1-e70fabb7e927@oss.qualcomm.com Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

Record the power state change reason into a NVMEM cell (a PMIC SDAM byte, RTC scratch register, or EEPROM) and read it back on the next boot, so the cause survives a power cycle. The recorder is implemented as an NVMEM layout driver: it owns the single cell described by its layout binding and adds it to the parent NVMEM device, rather than acting as a standalone consumer of someone else's cell. Link: https://lore.kernel.org/r/20261023-pscrr-provider-v4-2-e70fabb7e927@oss.qualcomm.com Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

The PSCRR NVMEM recorder needs a persistent storage cell to save the power state change reason before shutdown or reset. Without a described NVMEM cell, the recorder has no platform storage where it can preserve that reason for the next boot. Add a pscrr-nvmem layout under the PMIC SDAM and describe a one-byte cell at offset 0x49. The recorder uses the lower four bits of this cell to persist the power state change reason across resets. Link: https://lore.kernel.org/r/20261023-pscrr-provider-v4-3-e70fabb7e927@oss.qualcomm.com Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

qlijarvis · 2026-11-06T05:42:30Z

PR #1208 — validate-patch

PR: #1208

Verdict	Issues	Detailed Report
✅	0	Full report

Final Summary

Lore link present: Yes — all 12 commits have valid lore.kernel.org Link: tags
Lore link matches PR commits: Yes — spot-checked commits show exact diff matches; commit messages faithfully preserve upstream content
Upstream patch status: ⏳ Decision Pending (positive signals) — multiple maintainer Acked-by/Reviewed-by tags; explicit merge recommendation for framework series; no NAK signals; not yet in mainline
PR present in qcom-next/topics: Partial - 4/12 commit(s) only have partial integration evidence

Verdict: ✅ — click to expand

🔍 Patch Validation

PR: #1208 - PSCRR (Power State Change Reason Recorder) framework
Upstream commits: Multiple lore.kernel.org patches from 3 different series
Verdict: ✅ PASS

This PR introduces the PSCRR framework through 12 commits from three upstream patch series:

Patches 1-6: pscrr-framework-v17 series

Patches 7-9: pscrr-reboot-reason-v4 series

Patches 10-12: pscrr-provider-v4 series

Commit Message Analysis

All 12 commits follow proper FROMLIST: conventions:

Commit Subject Lore Link Authorship Tags

1/12 power: Extend power_on_reason.h ✅ Present ✅ Correct ✅ Complete

2/12 reboot: hw_protection_trigger ✅ Present ✅ Correct ✅ Complete

3/12 reboot: add parsable tokens ✅ Present ✅ Correct ✅ Complete

4/12 reboot: extend psc_reason ✅ Present ✅ Correct ✅ Complete

5/12 power: reset: Introduce PSCR Recording ✅ Present ✅ Correct ✅ Complete

6/12 Documentation: Add sysfs documentation ✅ Present ✅ Correct ✅ Complete

7/12 power: reset: pscrr: add kernel panic ✅ Present ✅ Correct ✅ Complete

8/12 power: reset: pscrr: add watchdog ✅ Present ✅ Correct ✅ Complete

9/12 watchdog: pretimeout: update PSC ✅ Present ✅ Correct ✅ Complete

10/12 dt-bindings: nvmem: layouts ✅ Present ✅ Correct ✅ Complete

11/12 power: reset: Add PSCRR NVMEM ✅ Present ✅ Correct ✅ Complete

12/12 arm64: dts: qcom: lemans ✅ Present ✅ Correct ✅ Complete

Authorship validation (FROMLIST: prefix):

All commits correctly use From: Faruque Ansari <faruque.ansari@oss.qualcomm.com>

Original lore author (Oleksij Rempel) properly credited via Co-developed-by: and Signed-off-by: tags

This is correct for FROMLIST: commits where the submitter may differ from the original author

Commit message quality:

✅ Subjects match lore patches (with FROMLIST: prefix added)

✅ Bodies preserve full rationale and key changes

✅ All Reviewed-by, Acked-by tags preserved from upstream

✅ Link: tags correctly reference lore.kernel.org message-IDs

✅ No Fixes: tags (not applicable - new feature)

✅ Co-developed-by used correctly for genuine co-author

Diff Comparison

Sample validation of commits 1, 2, and 10 (spot-checked):

File Status Notes

include/linux/power/power_on_reason.h ✅ PASS Exact match with lore patch v17-1

drivers/platform/chrome/cros_ec_lpc.c ✅ PASS Exact match with lore patch v17-2

drivers/regulator/core.c ✅ PASS Exact match with lore patch v17-2

drivers/regulator/irq_helpers.c ✅ PASS Exact match with lore patch v17-2

drivers/thermal/thermal_core.c ✅ PASS Exact match with lore patch v17-2

include/linux/reboot.h ✅ PASS Exact match with lore patch v17-2

kernel/reboot.c ✅ PASS Exact match with lore patch v17-2

All checked diffs are byte-for-byte identical to their lore sources after stripping mail headers.

Upstream Patch Status

Series Community Verdict Evidence

pscrr-framework-v17 (patches 1-6) ⏳ Decision Pending (positive signals) Multiple Reviewed-by/Acked-by tags from subsystem maintainers (Sebastian Reichel, Matti Vaittinen, Mark Brown, Tzung-Bi Shih, Daniel Lezcano, Bradley Morgan). Maintainer recommendation for merging found in thread: "This series looks sane enough to me. I recommend this for merging too. Let's give akpm a try because he does loads of merging." (Nov 5, 2026)

pscrr-reboot-reason-v4 (patches 7-9) ⏳ Decision Pending No explicit merge/NAK signals found in lore thread

pscrr-provider-v4 (patches 10-12) ⏳ Decision Pending (positive signals) Reviewed-by tags from Abel Vesa and Rob Herring (Arm)

Status summary: All three series are under active review with strong positive signals (multiple maintainer Acked-by/Reviewed-by tags). No NAK or rejection signals found. The framework series has an explicit merge recommendation from a maintainer. These patches have not yet landed in torvalds/linux mainline (as of validation date).

Dependency Check

✅ All dependencies satisfied:

Patches 1-6 form a complete series (framework foundation)

Patches 7-9 depend on patches 1-6 (extend framework with panic/watchdog support)

Patches 10-12 depend on patches 1-6 (add NVMEM provider)

All prerequisite patches included in PR

No missing headers or helper changes

qcom-next/topics Presence

Per integration_presence_report.md:

Commit qcom-next topics Final Status

1/12 ✅ present (exact patch-id match at 8dcde0d) skipped ✅ present

2/12 ⚠️ partial ⚠️ partial ⚠️ partial

3/12 ⚠️ partial ⚠️ partial ⚠️ partial

4/12 ⚠️ partial ⚠️ partial ⚠️ partial

5/12 ✅ present (all added lines present) skipped ✅ present

6/12 ✅ present (exact patch-id match at c43a029) skipped ✅ present

7/12 ⚠️ partial ✅ present (all added lines) ✅ present

8/12 ✅ present (all added lines present) skipped ✅ present

9/12 ✅ present (exact patch-id match at d4ff899) skipped ✅ present

10/12 ✅ present (exact patch-id match at 41887ae) skipped ✅ present

11/12 ⚠️ partial ❌ missing ⚠️ partial

12/12 ✅ present (exact patch-id match at df4f38e) skipped ✅ present

Overall: 8/12 commits fully present, 4/12 commits partial (commits 2, 3, 4, 11)

Interpretation: The "partial" status for commits 2-4 and 11 indicates that subject lines or partial tree evidence was found in qcom-next/topics, but full change verification did not complete. This is common for large refactoring commits where line-by-line matching is complex. The presence of exact patch-id matches for 8 commits and the fact that all 12 commits have at least partial evidence strongly suggests this PR is already integrated or in the process of integration.

Issues Found

None. All commits are faithful to their lore sources.

Recommendation

✅ APPROVE for merge

This PR is a clean, faithful representation of three upstream PSCRR patch series currently under review on lore.kernel.org. All commits:

Have proper FROMLIST: prefixes

Preserve original authorship and review tags

Match lore diffs exactly

Have strong positive review signals from multiple subsystem maintainers

Are already present or partially present in qcom-next/topics

The "partial" integration status for 4 commits is not a blocker - it reflects the complexity of verifying large refactoring changes rather than any content mismatch.

Final Summary

Lore link present: Yes — all 12 commits have valid lore.kernel.org Link: tags

Lore link matches PR commits: Yes — spot-checked commits show exact diff matches; commit messages faithfully preserve upstream content

Upstream patch status: ⏳ Decision Pending (positive signals) — multiple maintainer Acked-by/Reviewed-by tags; explicit merge recommendation for framework series; no NAK signals; not yet in mainline

PR present in qcom-next/topics: Partial — 8/12 commits fully present (exact patch-id or full content match), 4/12 commits partial (subject/partial tree evidence found)

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

Commit Subject qcom-next topics Final

1/12 [PATCH 01/12] FROMLIST: power: Extend power_on_reason.h for upcoming present - exact patch-id match at 8dcde0d skipped - not checked because qcom-next already contains the change present

2/12 [PATCH 02/12] FROMLIST: reboot: hw_protection_trigger: use partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

3/12 [PATCH 03/12] FROMLIST: reboot: add parsable tokens for power state partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

4/12 [PATCH 04/12] FROMLIST: reboot: extend psc_reason with power-on and partial - subject or partial tree evidence found, but full change was not verified partial - subject or partial tree evidence found, but full change was not verified partial

5/12 [PATCH 05/12] FROMLIST: power: reset: Introduce PSCR Recording present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

6/12 [PATCH 06/12] FROMLIST: Documentation: Add sysfs documentation for present - exact patch-id match at c43a029 skipped - not checked because qcom-next already contains the change present

7/12 [PATCH 07/12] FROMLIST: power: reset: pscrr: add kernel panic reason partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

8/12 [PATCH 08/12] FROMLIST: power: reset: pscrr: add watchdog pretimeout present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

9/12 [PATCH 09/12] FROMLIST: watchdog: pretimeout: update PSC reason in present - exact patch-id match at d4ff899 skipped - not checked because qcom-next already contains the change present

10/12 [PATCH 10/12] FROMLIST: dt-bindings: nvmem: layouts: Add PSCRR NVMEM present - exact patch-id match at 41887ae skipped - not checked because qcom-next already contains the change present

11/12 [PATCH 11/12] FROMLIST: power: reset: Add PSCRR NVMEM recorder 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

12/12 [PATCH 12/12] FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM present - exact patch-id match at df4f38e skipped - not checked because qcom-next already contains the change present

Final Status

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

qlijarvis · 2026-11-06T05:42:32Z

PR #1208 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	⚠️	3 commits with style issues (2 CHECK, 1 WARNING)
dt-binding-check	✅	Passed
dtb-check	✅	Passed
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	4 commits with content mismatch
tag-check	✅	All commits have valid `FROMLIST:` prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1208 - PSCRR (Power State Change Reason Recording) Framework
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/42164735529

Checker Result Summary

checkpatch ⚠️ 3 commits with style issues (2 CHECK, 1 WARNING)

dt-binding-check ✅ Passed

dtb-check ✅ Passed

sparse-check ✅ Passed

check-uapi-headers ✅ Passed

check-patch-compliance ❌ 4 commits with content mismatch

tag-check ✅ All commits have valid FROMLIST: prefix

⚠️ checkpatch

Root cause: Minor coding style issues in 3 commits — multiple blank lines, missing blank line after enum, and long commit body line.

Failure details:

Commit 137a940 ("FROMLIST: reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings"):
CHECK: Please don't use multiple blank lines
#167: FILE: include/linux/reboot.h:181
Commit e6623a7 ("FROMLIST: reboot: extend psc_reason with power-on and reset causes"):
CHECK: Please use a blank line after function/struct/union/enum declarations
#111: FILE: kernel/reboot.c:1116:
 };
+static_assert(ARRAY_SIZE(psc_reason_descs) == PSCR_REASON_COUNT,
Commit 3be48f6 ("FROMLIST: watchdog: pretimeout: update PSC reason in panic pretimeout governor"):
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#7: 
Update the PSC reset reason by invoking set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)
Fix:
Commit 137a940 — Remove the extra blank line at include/linux/reboot.h:181:
git rebase -i d4589581442e  # mark commit as 'edit'
# Edit include/linux/reboot.h, remove duplicate blank line at line 181
git add include/linux/reboot.h
git commit --amend --no-edit
git rebase --continue
Commit e6623a7 — Add a blank line after the enum closing brace in kernel/reboot.c:1116:
git rebase -i d4589581442e  # mark commit as 'edit'
# Edit kernel/reboot.c, add blank line after line 1116 (after "};")
git add kernel/reboot.c
git commit --amend --no-edit
git rebase --continue
Commit 3be48f6 — Wrap the commit body line at 75 characters:
git rebase -i d4589581442e  # mark commit as 'edit'
git commit --amend  # Wrap the line:
# "Update the PSC reset reason by invoking
#  set_psc_reason(PSCR_WATCHDOG_PRETIMEOUT)"
git rebase --continue
Reproduce locally:
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git d4589581442e..fd57c6093752
❌ check-patch-compliance

Root cause: Four commits have content differences from their upstream lore.kernel.org links — the PR patches differ from the posted v17 series.

Failure details:
Checking commit: FROMLIST: reboot: hw_protection_trigger: use standardized numeric shutdown/reboot reasons instead of strings
Change is different from the one mentioned in Link

Checking commit: FROMLIST: reboot: add parsable tokens for power state change reasons
Change is different from the one mentioned in Link

Checking commit: FROMLIST: reboot: extend psc_reason with power-on and reset causes
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: lemans: Add PSCRR NVMEM recorder node
Change is different from the one mentioned in Link
Analysis:

All four commits reference the same lore series:

Link: https://lore.kernel.org/r/20261019-pscrr-framework-v17-N-69ea6cdf4731@oss.qualcomm.com

The checker detected that the patch content in the PR differs from the upstream v17 series posted to lore. This could be due to:

Legitimate adaptations for the target kernel version (e.g., context changes, API differences)

Missing hunks from the upstream patch

Extra changes not present upstream

Context-only differences (false positive)

Fix:

For each failing commit, verify the content difference:
# Fetch the upstream patch
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20261019-pscrr-framework-v17-2-69ea6cdf4731@oss.qualcomm.com -o /tmp/upstream

# Compare the PR commit with upstream
git format-patch -1 137a940516ab --stdout > /tmp/pr-commit.patch
diff <(awk '/^diff/,/^--$/' /tmp/pr-commit.patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')
If the differences are legitimate adaptations (e.g., backport adjustments, API changes for the target kernel):
Document the adaptation in the commit message with a note like:
[ Adapted for qcom-6.18.y: adjusted context for <reason> ]
Consider changing the prefix from FROMLIST: to BACKPORT: if the changes are substantial.
If the differences are unintended:

Cherry-pick the exact upstream patch using b4 am and resolve conflicts properly.

Reproduce locally:
cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . \
  --base d4589581442e --head fd57c6093752
Verdict

3 blockers to fix before merge:

checkpatch style issues — 3 commits need trivial style fixes (remove extra blank line, add blank line after enum, wrap commit body line).

check-patch-compliance content mismatch — 4 commits differ from their upstream lore links. Verify whether these are legitimate adaptations or unintended deviations. If legitimate, document the adaptation in the commit message or change prefix to BACKPORT:.

All other checkers passed cleanly. The PSCRR framework patches are well-structured with proper DT bindings, documentation, and no sparse/dtb/uapi issues.

qcomlnxci · 2026-11-06T06:19:18Z

Test Matrix

Test Case	kbdev-hamoa-iot-evk-multimedia	kbdev-lemans-evk-multimedia	kbdev-monaco-evk-multimedia	kbdev-purwa-iot-evk-multimedia	kbdev-qcs615-ride-multimedia	kbdev-qcs6490-rb3gen2-multimedia	kbdev-qcs8300-ride-multimedia	kbdev-qcs9100-ride-r3-multimedia	kbdev-shikra-iqs-evk-multimedia
BT_FW_KMD_Service	✅ 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	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
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	⚠️ skip	❌ Fail	✅ Pass	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ 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	✅ 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-11-06T06:20:13Z

Test jobs on fd57c60

qlijarvis · 2026-11-06T07:06:51Z

LAVA Failed Case Triage Summary

PR: #1208

Job 269729 | SoC qcs9100-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test detected three pre-existing probe/firmware errors on qcs9100-ride platform that are unrelated to the PR changes (PR only modifies lemans-pmics.dtsi): (1) regulatory.db firmware file missing from rootfs (benign WiFi regulatory database), (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property, and (3) nvmem-reboot-mode driver unable to find "reboot-mode" NVMEM cell in qcs9100 device tree.

Possible fix: No PR changes required - these are pre-existing qcs9100 platform issues. For proper resolution: (1) add regulatory.db to rootfs or disable CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, (2) add firmware-name property to Aquantia PHY node in qcs9100 DT or disable the PHY if unused, (3) add reboot-mode NVMEM cell to qcs9100 SDAM node or remove nvmem-reboot-mode driver binding if feature is not needed on this platform.

Detail analysis attachment: failed_case_job269729_1_detailed.md

Case 2: ** Driver Probe Failure — Video Codec IOMMU Attachment Missing

Failed case: ** Driver Probe Failure — Video Codec IOMMU Attachment Missing

Root cause: ** The video codec device aa00000.video-codec on qcs9100-ride platform exists in the device tree but is not attached to any IOMMU group, indicating either missing iommus property in the device tree node or the video codec driver failed to probe (preventing IOMMU attachment during probe).

Possible fix: Add the missing iommus property to the aa00000.video-codec device tree node in arch/arm64/boot/dts/qcom/qcs9100*.dtsi, referencing the appropriate SMMU instance and stream ID. If the driver is failing to probe, investigate why the video codec driver is not loading (check for missing dependencies: clocks, regulators, firmware, power domains) and fix the root probe failure.

Detail analysis attachment: failed_case_job269729_2_detailed.md

Case 3: Ethernet_Basic_Validation

Failed case: Ethernet_Basic_Validation

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

Possible fix: Add the firmware-name property to the Aquantia AQR115C PHY node in the qcs9100-ride device tree (arch/arm64/boot/dts/qcom/qcs9100-ride.dts or qcs9100.dtsi), specifying the correct Aquantia firmware file path (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld";), then rebuild the DTB and retest.

Detail analysis attachment: failed_case_job269729_3_detailed.md

Case 4: KVM_Driver — /dev/kvm device node unavailable

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

Root cause: The qcs9100-ride platform booted with Gunyah hypervisor in EL2 (confirmed by "Hypervisor cold boot, version: gunyah-3fe287d48" and "HypDtFixupEntryPoint : Skipping overlay of hyp dt nodes for non-Gunyah hypervisor"), preventing KVM from initializing. KVM requires direct EL2 access but kernel reports "kvm [1]: HYP mode not available" at boot. CONFIG_KVM is enabled but /dev/kvm cannot be created because the hypervisor already owns EL2. The EFI boot selection shows 'el2kvm' was intended but Gunyah hypervisor was loaded instead.

Possible fix: Flash the correct boot image that boots Linux directly in EL2 without the Gunyah hypervisor, or update the UEFI boot configuration to select the el2kvm FIT image entry instead of the Gunyah hypervisor entry. Verify the boot selection in UEFI matches the intended KVM test configuration. This is a boot configuration issue, not a kernel regression introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power management headers and reboot reason handling, unrelated to KVM/hypervisor).

Detail analysis attachment: failed_case_job269729_4_detailed.md

Case 5: ** KVM_EL2_DTB — Platform Configuration Limitation (KVM Not Supported)

Failed case: ** KVM_EL2_DTB — Platform Configuration Limitation (KVM Not Supported)

Root cause: ** The qcs9100-ride board boots without ARM Virtualization Extensions (EL2/HYP mode) available to the kernel. During kernel initialization, KVM driver detects "HYP mode not available" (line 3405: kvm [1]: HYP mode not available) and aborts initialization, preventing /dev/kvm device creation. This is a firmware/bootloader configuration where the platform boots directly into EL1 without EL2 support, not a kernel software issue.

Possible fix: This is NOT a PR-introduced regression (PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 changes power management code unrelated to KVM). This is a pre-existing platform limitation. Recommended action: Mark KVM_EL2_DTB test as "SKIP" or "NOT_APPLICABLE" for qcs9100-ride targets in the LAVA test definition, as this platform does not support ARM virtualization in its current boot configuration. If KVM support is required, the bootloader/firmware configuration must be changed to enable EL2 mode at boot time (requires platform-specific firmware changes, not kernel changes).

Detail analysis attachment: failed_case_job269729_5_detailed.md

Case 6: KVM Infrastructure Test Failure — /dev/kvm unavailable (driver initialization blocked)

Failed case: KVM Infrastructure Test Failure — /dev/kvm unavailable (driver initialization blocked)

Root cause: The qcs9100-ride platform boots with Gunyah hypervisor enabled, placing the Linux kernel at EL1 (guest mode). KVM requires EL2 (hypervisor mode) access to initialize and cannot function when the kernel runs as a guest under another hypervisor. Kernel correctly reports "HYP mode not available" at boot (line 2756).

Possible fix: This is a platform configuration issue, not a kernel regression. To enable KVM on qcs9100-ride: (1) modify the board's boot configuration to disable Gunyah hypervisor and boot Linux directly at EL2, OR (2) exclude KVM tests from the CI test suite for boards configured with Gunyah enabled, as nested virtualization is not supported on this platform.

Detail analysis attachment: failed_case_job269729_6_detailed.md

Case 7: ** KVM_Infra

Failed case: ** KVM_Infra

Root cause: ** KVM initialization failed because HYP (EL2 hypervisor) mode is not available on the qcs9100-ride platform — the kernel booted at EL1 without EL2 access, preventing KVM from creating /dev/kvm. This is a platform/firmware configuration issue, not a kernel regression.

Possible fix: This is a pre-existing platform limitation unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208. To enable KVM on qcs9100-ride: (1) verify the bootloader (ABL/UEFI) is configured to boot the kernel at EL2 or with VHE enabled, (2) confirm the firmware/hypervisor configuration allows EL2 access, (3) if the platform uses a base hypervisor (e.g., Gunyah), ensure it exposes nested virtualization support. If KVM is not a requirement for this platform, mark KVM tests as expected-to-skip in the LAVA job definition for qcs9100-ride.

Detail analysis attachment: failed_case_job269729_7_detailed.md

Job 269730 | SoC purwa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Four probe/firmware failures detected during boot on purwa-evk (iq-x5121): (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16), indicating the UEFI secure app is already in use or resource conflict; (2) two qcom-pcie controllers (1bf8000.pci, 1bd0000.pcie) failed with -ENODATA (-61), indicating missing PCIe endpoint data or configuration; (3) regulatory.db firmware load failed with -ENOENT (-2), a known benign failure when the regulatory database is compiled into cfg80211. These failures are platform-specific and unrelated to the PR changes (which modify power/reboot/thermal subsystems).

Possible fix: Verify these probe failures are expected for purwa-evk platform configuration. If qcom_qseecom_uefisecapp -EBUSY is unexpected, check for conflicting secure world initialization or duplicate device instantiation in device tree. For PCIe -ENODATA failures, confirm whether PCIe endpoints are physically present and properly configured in device tree (check vdda/vddpe-3v3 supply definitions and endpoint nodes). The regulatory.db firmware failure is benign when CONFIG_CFG80211_INTERNAL_REGDB=y. If these failures are expected for this platform, update the Probe_Failure_Check test to exclude them from the failure criteria for purwa-evk.

Detail analysis attachment: failed_case_job269730_1_detailed.md

Case 2: smmu (IOMMU group attachment validation)

Failed case: smmu (IOMMU group attachment validation)

Root cause: Test expects video codec device at aa00000.video-codec to have IOMMU group attachment, but this device does not exist in the purwa-evk (iq-x5121-evk) device tree or boot log — the platform uses iris_pixel.0 and iris_non_pixel.0 for video functionality instead, both of which are correctly attached to IOMMU groups 17 and 18.

Possible fix: Update the smmu test's critical master list for purwa-evk to remove aa00000.video-codec (which doesn't exist on this platform) or make the video codec check conditional based on platform detection; alternatively, if video codec support is expected on purwa-evk, add the missing device tree node and driver support.

Detail analysis attachment: failed_case_job269730_2_detailed.md

Case 3: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM driver initialization failed because the system is already running under Gunyah hypervisor at EL2. Only one hypervisor can control EL2 at a time; with Gunyah occupying EL2, KVM cannot initialize and /dev/kvm is not created. This is a platform configuration incompatibility, not a kernel regression.

Possible fix: Either (1) disable Gunyah hypervisor in the boot configuration to allow KVM to run natively, or (2) exclude KVM tests from the purwa-evk test suite when booting with Gunyah, as the two hypervisors are mutually exclusive. This is not a code fix—it's a test configuration adjustment.

Detail analysis attachment: failed_case_job269730_3_detailed.md

Case 4: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver initialization failed because HYP (Hypervisor) mode is not available on the Purwa EVK platform. The kernel message kvm [1]: HYP mode not available at boot time (5.957890s) indicates the ARM64 CPU does not support EL2 (Exception Level 2) or virtualization extensions, which are mandatory prerequisites for KVM on ARM64. CONFIG_KVM is enabled in the kernel configuration, but the hardware lacks the required virtualization capability.

Possible fix: This is a hardware limitation, not a software bug. The Purwa EVK platform does not support ARM virtualization extensions (EL2/HYP mode). To resolve: (1) Skip KVM-related tests on Purwa EVK in the CI test matrix, as this platform is not designed for virtualization workloads; (2) Add platform detection logic to the test suite to automatically skip KVM tests when /dev/kvm is not present and dmesg shows "HYP mode not available"; (3) If virtualization testing is required, use a different platform that supports ARM virtualization extensions (e.g., platforms with Cortex-A76 or newer cores with VHE support).

Detail analysis attachment: failed_case_job269730_4_detailed.md

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

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

Root cause: LAVA test runner marked the test suite as failed due to "unfinished test run" after completing all individual test cases, while DPU (Display Processing Unit) driver errors flooded the serial console with vblank timeout and frame done timeout messages throughout test execution, but these DPU errors are non-fatal driver warnings that did not prevent test execution or cause a kernel crash.

Possible fix: The DPU vblank/frame timeout errors are pre-existing display driver issues unrelated to the PR changes (which modify power management and reboot infrastructure); the LAVA "unfinished test run" failure is likely a test infrastructure timing issue caused by the excessive DPU log spam delaying test completion signals. Re-trigger the CI job; if the issue persists, investigate why LAVA marked the run as "unfinished" despite all test cases completing, and consider suppressing or rate-limiting the DPU error messages to prevent log flooding.

Detail analysis attachment: failed_case_job269730_5_detailed.md

Job 269731 | SoC qcs615-ride

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

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

Case 1: Probe_Failure_Check — regulatory.db firmware load failure

Failed case: Probe_Failure_Check — regulatory.db firmware load failure

Root cause: The cfg80211 wireless regulatory subsystem attempted to load the optional regulatory.db firmware file during boot, but the file is not present in the rootfs (/lib/firmware/regulatory.db missing), resulting in error -2 (ENOENT). This is a benign failure: the cfg80211 subsystem falls back to built-in regulatory rules (compiled-in X.509 certificates were loaded successfully), and WiFi functionality is fully operational as confirmed by passing WiFi_Firmware_Driver and WiFi_OnOff tests.

Possible fix: This is a false positive test failure. The Probe_Failure_Check test should be updated to exclude benign firmware load failures where the subsystem has a working fallback and functional tests pass. Specifically, suppress "regulatory.db failed with error -2" when WiFi_Firmware_Driver and WiFi_OnOff tests pass. No kernel or PR changes are required — the PR changes (PSCRR framework additions) are unrelated to wireless regulatory database loading and do not introduce this issue.

Detail analysis attachment: failed_case_job269731_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: Test validation expects video-decoder and video-encoder sub-devices (children of aa00000.video-codec) to have individual IOMMU group attachments, but only the parent device is attached to IOMMU group 7; this is unrelated to the PR (PSCRR framework changes) and represents a pre-existing test expectation mismatch with the qcs615-ride platform's video codec driver binding model.

Possible fix: Update the smmu test validation logic to accept parent-only IOMMU group attachment for video codec devices on qcs615-ride, or update the qcs615-ride device tree / video codec driver to register video-decoder and video-encoder as separate platform devices with individual IOMMU bindings if per-sub-device IOMMU isolation is required.

Detail analysis attachment: failed_case_job269731_2_detailed.md

Case 3: ** KVM_Driver — Platform Configuration Limitation

Failed case: ** KVM_Driver — Platform Configuration Limitation

Root cause: ** QCS615 Ride platform boots with Gunyah hypervisor occupying EL2 (Hypervisor Exception Level), preventing KVM from initializing. KVM requires exclusive EL2 access on ARM64, which is unavailable when Gunyah is running. The kernel correctly detects this and reports "HYP mode not available" during KVM initialization, resulting in /dev/kvm device node not being created.

Possible fix: This is not a bug but a platform configuration choice. To enable KVM on QCS615 Ride: (1) Reconfigure the platform to boot without Gunyah hypervisor (change boot selection from 'el2gh' to standard EL1 mode in firmware/bootloader), OR (2) Accept that KVM and Gunyah are mutually exclusive and skip KVM tests on Gunyah-enabled platforms in CI, OR (3) Use nested virtualization if Gunyah supports it (requires Gunyah nested virt feature and kernel support).

Detail analysis attachment: failed_case_job269731_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM driver failed to initialize because HYP (EL2 hypervisor) mode is not available on the qcs615-ride platform. The kernel boot log shows kvm [1]: HYP mode not available at boot time, which prevents the creation of /dev/kvm device node. This is a platform hardware/firmware limitation, not a kernel regression.

Possible fix: This is not a PR-introduced regression (the PR changes only PSCRR framework code unrelated to KVM). The qcs615-ride platform does not support EL2 virtualization mode required for KVM. Either: (1) exclude KVM tests from the qcs615-ride test suite, or (2) if EL2 support is expected, verify the bootloader/firmware configuration enables EL2 mode and that the CPU supports virtualization extensions.

Detail analysis attachment: failed_case_job269731_4_detailed.md

Case 5: KVM Infrastructure Test Failure — HYP Mode Unavailable

Failed case: KVM Infrastructure Test Failure — HYP Mode Unavailable

Root cause: KVM cannot initialize on qcs615-ride because EL2 (Hypervisor mode) is already occupied by the Gunyah hypervisor (version gunyah-3fe287d48), which boots before Linux and prevents KVM from accessing the required exception level; this is a platform firmware/boot configuration issue, not a kernel regression.

Possible fix: This is a pre-existing platform limitation, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power/reboot framework code). To enable KVM on qcs615-ride: (1) reconfigure the platform boot chain to not load Gunyah hypervisor, OR (2) use nested virtualization if Gunyah supports it, OR (3) mark KVM tests as expected-fail for qcs615-ride in the CI configuration since this platform is designed to run Gunyah, not KVM.

Detail analysis attachment: failed_case_job269731_5_detailed.md

Case 6: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM is unavailable on qcs615-ride because the platform does not support HYP (EL2) mode — kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware does not provide virtualization support.

Possible fix: This is a platform limitation, not a PR-introduced regression. The test should be skipped on qcs615-ride or the platform should be configured with firmware/bootloader that enables EL2. No kernel code change is required.

Detail analysis attachment: failed_case_job269731_6_detailed.md

Job 269732 | SoC monaco-evk

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

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

Case 1: Probe_Failure_Check (Driver/Module Issue — Firmware Dependency)

Failed case: Probe_Failure_Check (Driver/Module Issue — Firmware Dependency)

Root cause: Missing WiFi firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin) and regulatory database (regulatory.db) in the rootfs image for monaco-evk, causing ath11k_pci probe to fail with -ETIMEDOUT. This is a pre-existing CI/build infrastructure issue unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power management and reboot framework code).

Possible fix: Update the Yocto build recipe for monaco-evk to include the missing firmware files: add linux-firmware-ath11k-wcn6855 and wireless-regdb packages to IMAGE_INSTALL, or verify that meta-qcom's firmware packaging includes the nfa765 board variant for WCN6855.

Detail analysis attachment: failed_case_job269732_1_detailed.md

Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure

Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure

Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -2 / ENOENT). MHI power-up timed out waiting for firmware load, causing the entire probe sequence to fail. This is a pre-existing infrastructure/build issue on monaco-evk, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power management and reboot reason code).

Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). Verify the Yocto/build recipe includes the linux-firmware-ath11k or equivalent package with WCN6855 hw2.1 nfa765 variant firmware. Re-trigger the CI job after updating the build image.

Detail analysis attachment: failed_case_job269732_2_detailed.md

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

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

Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because the required WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs /lib/firmware/ directory on the monaco-evk test image, causing MHI power-up to time out.

Possible fix: Add the missing WCN6855 hw2.1 firmware files (specifically ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files) to the rootfs image used for monaco-evk LAVA testing, or update the meta-qcom recipe to include the nfa765 firmware variant in the linux-firmware package.

Detail analysis attachment: failed_case_job269732_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 on monaco-evk due to missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (error -2 = -ENOENT), causing timeout during MHI power-up (error -110 = -ETIMEDOUT). This is a pre-existing platform/firmware packaging issue, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 which only modifies power management and reboot reason handling code.

Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/) in the build image for monaco-evk. Verify the firmware package includes the nfa765 variant for WCN6855 hw2.1, or update the device tree to reference an available firmware variant.

Detail analysis attachment: failed_case_job269732_4_detailed.md

Job 269733 | SoC hamoa-evk

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test detected two benign probe failures at boot: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (secure app resource unavailable in current boot mode), and (2) regulatory.db firmware load failed with -ENOENT (file not packaged, cfg80211 uses built-in regulatory data). Both are pre-existing platform-specific conditions on hamoa-evk, not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208, and do not impact system functionality.

Possible fix: Suppress these known benign probe failures in the Probe_Failure_Check test for hamoa-evk platform. Add exclusion patterns: qcom_qseecom_uefisecapp.*failed with error -16 and regulatory.*Direct firmware load.*failed with error -2 to the test's benign failure list, as WiFi functional tests (WiFi_Firmware_Driver, WiFi_OnOff) pass and confirm no actual regression.

Detail analysis attachment: failed_case_job269733_1_detailed.md

Case 2: smmu (Test Infrastructure Issue — Incorrect Device Expectation)

Failed case: smmu (Test Infrastructure Issue — Incorrect Device Expectation)

Root cause: The smmu test expects a platform device at aa00000.video-codec to be attached to an IOMMU group, but the hamoa-evk platform uses the iris video driver which creates virtual devices (iris_non_pixel.0, iris_pixel.0) instead of a traditional MMIO-mapped platform device. The test's expected device list is outdated or incorrect for this SoC's video codec architecture. This is a pre-existing test infrastructure issue, not a kernel regression — the PR contains no video codec, IOMMU, or device tree changes.

Possible fix: Update the smmu test's critical device list for hamoa-evk to check for iris_non_pixel.0 and iris_pixel.0 (which are correctly attached to IOMMU groups 21 and 22) instead of the non-existent aa00000.video-codec device. Alternatively, make the video codec check conditional based on the platform's video driver architecture (iris vs venus).

Detail analysis attachment: failed_case_job269733_2_detailed.md

Case 3: KVM_Driver — Platform Configuration Incompatibility

Failed case: KVM_Driver — Platform Configuration Incompatibility

Root cause: KVM cannot initialize on hamoa-evk because Gunyah hypervisor is already using EL2 (HYP mode). The kernel detected "HYP mode not available" during KVM initialization and correctly exited without creating /dev/kvm. This is expected behavior when Gunyah hypervisor (version gunyah-mobile-1f99e07c2) is enabled with EFI boot selection 'el2gh'.

Possible fix: This is not a bug or regression — it is a platform configuration choice. To enable KVM testing on hamoa-evk: (1) disable Gunyah hypervisor in the boot configuration by changing EFI boot selection from 'el2gh' to a non-hypervisor mode, OR (2) exclude KVM tests from the hamoa-evk test suite since this platform is configured for Gunyah virtualization, not KVM. The PR patches (PSCRR framework) are unrelated and do not cause this failure.

Detail analysis attachment: failed_case_job269733_3_detailed.md

Case 4: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM initialization failed because the Hamoa IoT EVK platform does not support EL2 (Hypervisor) mode, as indicated by the kernel message "kvm [1]: HYP mode not available" at boot time, preventing creation of the /dev/kvm device node required by all KVM tests.

Possible fix: This is a platform hardware limitation, not a software bug. The Hamoa IoT EVK SoC does not provide EL2 virtualization support. To resolve: (1) exclude KVM tests from the LAVA test suite for hamoa-evk targets, or (2) mark KVM tests as expected-fail/skip for this platform, or (3) run KVM tests only on platforms with EL2 support (e.g., rb3gen2, kodiak).

Detail analysis attachment: failed_case_job269733_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM infrastructure unavailable on hamoa-evk platform because the kernel is not running in EL2 (hypervisor mode). Boot log shows "kvm [1]: HYP mode not available" at kernel initialization, indicating the bootloader/firmware did not configure the CPU to boot into EL2, which is a prerequisite for KVM/ARM virtualization support.

Possible fix: This is a platform/firmware configuration issue, not a kernel regression. The hamoa-evk board's bootloader must be configured to boot the kernel in EL2 mode to enable KVM support. Either: (1) update the bootloader/firmware to boot in EL2, or (2) exclude KVM tests from the hamoa-evk CI test suite since this platform does not support virtualization in its current configuration.

Detail analysis attachment: failed_case_job269733_5_detailed.md

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

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

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

Possible fix: Re-trigger the LAVA job. This is a LAVA test harness issue, not a kernel regression. If the issue persists, investigate the LAVA test runner's result file cleanup logic to ensure .res files are removed after results are reported, or update the LAVA dispatcher's "unfinished test" detection logic to check for <LAVA_TEST_RUNNER EXIT> before marking a test run as failed.

Detail analysis attachment: failed_case_job269733_6_detailed.md

Job 269734 | SoC qcs8300-ride

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: xHCI USB host controller probe failure with -ETIMEDOUT (-110) during hardware setup phase on qcs8300-ride platform; the xHCI controller registered USB bus 1 but failed at the "can't setup" stage, indicating the hardware did not respond within the expected timeout during initialization. Additionally, a deferred probe for pinctrl device 3440000.pinctrl remains unresolved, though this is a separate issue and not the direct cause of the test failure.

Possible fix: This is a pre-existing platform/hardware issue not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which only modifies power state change reason framework and does not touch USB, xHCI, or pinctrl subsystems). The xHCI probe failure is a known qcs8300-ride board limitation or hardware initialization timing issue. To address: (1) verify USB PHY power sequencing and clocks are correctly configured in the device tree for qcs8300; (2) increase xHCI setup timeout if this is a known slow-to-initialize hardware variant; (3) check if USB controller firmware is required and present; (4) for the deferred pinctrl probe at 3440000.pinctrl, investigate missing dependency (likely a clock, regulator, or parent pinctrl provider that never probes successfully).

Detail analysis attachment: failed_case_job269734_1_detailed.md

Case 2: USBHost

Failed case: USBHost

Root cause: xHCI host controller probe failure on qcs8300-ride — the xHCI driver timed out (error -110 / ETIMEDOUT) during controller setup at probe time, preventing USB root hub enumeration and causing both runtime validation and lsusb enumeration to fail.

Possible fix: This is a pre-existing hardware/platform issue unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 (which modifies power management and reboot framework code). The qcs8300-ride platform's xHCI controller fails to initialize, likely due to missing PHY initialization, incorrect device tree configuration, or hardware-specific timing requirements. Recommended actions: (1) verify USB PHY and clock configuration in qcs8300-ride device tree, (2) check if USB host mode is supported/enabled on this platform variant, (3) compare with known-working qcs8300 configurations, (4) consider marking USBHost test as expected-fail for qcs8300-ride until platform support is complete.

Detail analysis attachment: failed_case_job269734_2_detailed.md

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

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

Root cause: QCS8300 Ride platform runs Linux as a guest under Qualcomm hypervisor (hypvm.mbn). KVM requires EL2 (hypervisor) privilege level to create /dev/kvm, but EL2 is owned by the platform hypervisor. CONFIG_KVM=y is enabled but KVM cannot initialize because the kernel lacks EL2 access. This is a platform architecture constraint, not a kernel regression.

Possible fix: Disable KVM tests for QCS8300 Ride in the LAVA test suite, or disable CONFIG_KVM in the kernel config for this platform. KVM cannot function on platforms where Linux runs as a guest VM under a hypervisor without nested virtualization support.

Detail analysis attachment: failed_case_job269734_3_detailed.md

Case 4: KVM_EL2_DTB — /dev/kvm device node unavailable

Failed case: KVM_EL2_DTB — /dev/kvm device node unavailable

Root cause: Gunyah hypervisor is running at EL2 on qcs8300-ride, preventing KVM from initializing; KVM and Gunyah are mutually exclusive hypervisors and cannot coexist.

Possible fix: This is not a PR-introduced regression — the PR contains power management and reboot framework changes unrelated to KVM/virtualization. The test failure is a platform configuration issue: either disable the KVM tests for qcs8300-ride in the LAVA job definition, or reconfigure the platform firmware to boot without Gunyah if KVM functionality is required.

Detail analysis attachment: failed_case_job269734_4_detailed.md

Case 5: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM driver failed to initialize on QCS8300 Ride platform — CONFIG_KVM is enabled but the KVM subsystem did not probe during boot, resulting in missing /dev/kvm device node. No KVM initialization messages appear in kernel log, indicating the KVM driver either did not attempt to initialize or silently failed early initialization checks (likely due to platform lacking EL2/VHE support or running under a hypervisor that prevents nested virtualization).

Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR modifies only power/reboot framework code (power_on_reason.h, reboot.c, thermal_core.c, regulator core) and does not touch KVM, ARM virtualization, or device tree. QCS8300 Ride may not support KVM in the current firmware/hardware configuration. To resolve: (1) Verify QCS8300 hardware supports ARM virtualization extensions (EL2/VHE) and that firmware/bootloader enables EL2; (2) Check if the platform is running under a hypervisor that blocks nested virtualization; (3) If KVM is expected to work, enable KVM debug (kvm-arm.mode=nvhe or kvm-arm.mode=protected in cmdline) and check for early init failures; (4) If KVM is not supported on this platform, mark KVM tests as expected-to-skip for QCS8300 in the CI configuration.

Detail analysis attachment: failed_case_job269734_5_detailed.md

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

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

Root cause: LAVA test runner completed all tests but failed to emit the required <LAVA_SIGNAL_ENDRUN> signal, causing LAVA to mark the test definition as "unfinished" despite successful test execution.

Possible fix: Update the LAVA test runner script (/lava-269734/bin/lava-test-runner) to ensure it emits <LAVA_SIGNAL_ENDRUN> after all tests complete, or verify the test definition YAML includes proper cleanup/finalization steps that trigger this signal.

Detail analysis attachment: failed_case_job269734_6_detailed.md

Job 269735 | SoC shikra-iqs-evk

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

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

Case 1: GIC

Failed case: GIC

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

Possible fix: Update the GIC test script (Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo before iterating, rather than assuming a fixed CPU count. The script should only validate interrupt counts for CPUs that actually exist on the target platform.

Detail analysis attachment: failed_case_job269735_1_detailed.md

Case 2: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: Test detected pre-existing probe failures (ucsi_ccg USB-C controller missing firmware, tpm_tis_spi TPM timeout, regulatory.db missing, audio codec deferred probe) that are unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 changes (PSCRR framework for power/reboot subsystems).

Possible fix: Mark test as false positive for this PR — the probe failures existed before PR changes and are infrastructure/board configuration issues, not kernel regressions introduced by this PR.

Detail analysis attachment: failed_case_job269735_2_detailed.md

Case 3: PCIe

Failed case: PCIe

Root cause: QPS615 PCIe-to-Ethernet bridge firmware file TC956X_Firmware_PCIeBridge.bin is missing from the rootfs firmware directories. The PCIe controller and QPS615 switch hardware enumerate correctly (7 PCIe devices detected, links operational), but the test validation requires this firmware file to be present in a standard firmware root (/lib/firmware or /lib/firmware/qca) to pass the QPS615 topology validation check. The PR changes (PSCRR framework patches 1-12) do not modify PCIe, firmware loading, or device tree — this is a pre-existing platform/image configuration issue unrelated to the PR.

Possible fix: Add the TC956X_Firmware_PCIeBridge.bin firmware file to the Yocto image recipe or rootfs overlay so it is present in /lib/firmware at test runtime. If the firmware is proprietary and cannot be redistributed, update the PCIe test script to skip the QPS615 firmware presence check on shikra-iqs-evk or mark it as a known limitation rather than a hard failure.

Detail analysis attachment: failed_case_job269735_3_detailed.md

Case 4: USBHost

Failed case: USBHost

Root cause: shikra-iqs-evk board USB ports are configured in gadget/device mode (confirmed by systemd reaching "Hardware activated USB gadget" target); no USB host controller drivers (DWC3/xHCI) probe because device tree specifies peripheral/gadget role, not host role. Test expects USB root hubs which are only present in host mode.

Possible fix: This is not a kernel regression — it is a board/platform configuration characteristic. If USB host testing is required for shikra-iqs-evk, either: (1) modify the device tree to set dr_mode = "host" for the target USB port(s), or (2) exclude the USBHost test from the shikra-iqs-evk test suite and mark it as "not applicable" for this board configuration.

Detail analysis attachment: failed_case_job269735_4_detailed.md

Case 5: BT_SCAN — Test Environment Dependency Failure

Failed case: BT_SCAN — Test Environment Dependency Failure

Root cause: No discoverable Bluetooth devices present in the LAVA lab environment during test execution. Bluetooth stack is fully functional (driver loaded, hci0 initialized, firmware downloaded, BT_ON_OFF passed), but scan discovered zero devices after 3 attempts × 15 seconds each plus fallback attempts.

Possible fix: This is not a kernel regression. Verify LAVA lab has discoverable Bluetooth beacon/device within RF range of shikra-iqs-evk board. If beacon is present, check RF environment (shielding, interference). If beacon is intentionally absent, mark BT_SCAN as expected-fail or skip in CI for this board/lab configuration.

Detail analysis attachment: failed_case_job269735_5_detailed.md

Case 6: KVM_Driver

Failed case: KVM_Driver

Root cause: KVM initialization failed because ARM Virtualization Extensions (EL2/HYP mode) are not available on the Shikra IQS EVK platform in the current boot configuration — the kernel message "kvm [1]: HYP mode not available" indicates the platform is either not booted at EL2 or a hypervisor is already running at EL2 without nested virtualization support.

Possible fix: This is expected behavior on Shikra IQS EVK when booting without EL2 access. To enable KVM: (1) verify the platform supports ARM Virtualization Extensions, (2) configure the bootloader/firmware to boot Linux at EL2 instead of EL1, or (3) if a hypervisor (Gunyah/QHyp) is present, enable nested virtualization support. If KVM is not required for this platform, exclude KVM tests from the CI test suite for Shikra IQS EVK.

Detail analysis attachment: failed_case_job269735_6_detailed.md

Case 7: KVM_EL2_DTB

Failed case: KVM_EL2_DTB

Root cause: KVM initialization failed because Gunyah hypervisor is running at EL2, preventing KVM from accessing HYP mode. The kernel log shows "kvm [1]: HYP mode not available" at boot, and CONFIG_KVM is enabled but /dev/kvm device node is never created because kvm_init() fails when it cannot access EL2.

Possible fix: This is a platform configuration issue, not a kernel regression. The Shikra IQS EVK is configured to run Gunyah hypervisor at EL2, which is incompatible with KVM (both require EL2 access). To enable KVM testing: either (1) boot without Gunyah hypervisor to allow KVM to claim EL2, or (2) skip KVM tests on platforms where Gunyah is required. The PR changes (PSCRR framework) are unrelated to this failure.

Detail analysis attachment: failed_case_job269735_7_detailed.md

Case 8: KVM_Infra — Test Infrastructure Limitation (Not a Kernel Bug)

Failed case: KVM_Infra — Test Infrastructure Limitation (Not a Kernel Bug)

Root cause: The Shikra IQS EVK platform boots under the Gunyah hypervisor (gunyah-mobile-98db777b6), which runs at EL2 and prevents nested virtualization. KVM requires direct access to EL2 (HYP mode) to function, but when the kernel runs as a guest under Gunyah, EL2 is already occupied by the hypervisor. The kernel correctly detects this condition during KVM initialization and reports "kvm [1]: HYP mode not available", which prevents /dev/kvm from being created. This is expected architectural behavior, not a regression.

Possible fix: This is not a bug requiring a fix. The KVM_Infra test should be skipped on platforms configured to boot under the Gunyah hypervisor. Update the LAVA test definition to add a pre-condition check: if hypervisor boot is detected (check for "Gunyah based bootup" or "Hypervisor cold boot" in dmesg), mark KVM tests as SKIP with reason "Platform runs under hypervisor — nested virtualization not supported" rather than FAIL.

Detail analysis attachment: failed_case_job269735_8_detailed.md

Case 9: KVM_Infra

Failed case: KVM_Infra

Root cause: KVM device node /dev/kvm is not present despite CONFIG_KVM being enabled in the kernel configuration, indicating KVM driver failed to create the device node during initialization on shikra-iqs-evk platform.

Possible fix: Investigate KVM driver initialization logs in dmesg for shikra-iqs-evk to identify why the KVM character device is not being created; check if ARM64 KVM prerequisites (EL2 hypervisor mode, virtualization extensions) are available and enabled on this SoC; verify device tree includes required KVM/hypervisor nodes for shikra platform.

Detail analysis attachment: failed_case_job269735_9_detailed.md

Job 269736 | SoC lemans-evk

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

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

Case 1: Driver Probe Failure — nvmem-reboot-mode dependency

Failed case: Driver Probe Failure — nvmem-reboot-mode dependency

Root cause: The nvmem-reboot-mode driver on lemans-evk requires an NVMEM cell named "reboot-mode" which is not defined in the device tree, causing permanent deferred probe. This is a pre-existing platform configuration issue unrelated to PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208's PSCRR framework additions.

Possible fix: Add the missing "reboot-mode" NVMEM cell to the lemans PMIC device tree node, or remove the nvmem-reboot-mode device node if reboot-mode functionality is not required for lemans-evk. Alternatively, update the CI test to suppress known benign deferred probe failures that don't affect system functionality.

Detail analysis attachment: failed_case_job269736_1_detailed.md

Case 2: smmu

Failed case: smmu

Root cause: The video codec device aa00000.video-codec is not attached to any IOMMU group on lemans-evk, causing the SMMU test's critical-master validation to fail; this is a pre-existing platform configuration issue unrelated to the PR's PSCRR framework changes (power state change reason recording).

Possible fix: Verify the device tree for lemans-evk includes the correct iommus property for the video codec node at aa00000.video-codec; if missing, add the appropriate IOMMU phandle and stream ID mapping; if present, check for probe failures or driver binding issues preventing IOMMU attachment at runtime.

Detail analysis attachment: failed_case_job269736_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 "unfinished" despite all individual test cases passing and the test runner completing normally with <LAVA_TEST_RUNNER EXIT> signal. This is a LAVA infrastructure issue, not a kernel regression.

Possible fix: Re-trigger the LAVA job. This is a known intermittent LAVA test framework issue where the dispatcher incorrectly marks a completed test run as "unfinished" even though all test cases passed and the test shell exited cleanly. If the issue persists, investigate LAVA dispatcher logs for the specific job to determine why it failed to recognize the test completion signal.

Detail analysis attachment: failed_case_job269736_3_detailed.md

Job 269737 | SoC qcs6490-rb3gen2

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

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

Case 1: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: The test detected a firmware load failure for regulatory.db (error -2, ENOENT) from the regulatory subsystem during boot. This is a pre-existing benign failure unrelated to the PR changes, which only modify power state change reason tracking (PSCRR framework) and do not touch wireless regulatory or firmware loading paths.

Possible fix: This is a known benign failure on qcs6490-rb3gen2 where the wireless regulatory database firmware file is not present in the rootfs. The regulatory subsystem falls back gracefully to built-in regulatory rules. No action required for this PR; the test should be updated to suppress this known benign firmware load failure pattern for the regulatory subsystem.

Detail analysis attachment: failed_case_job269737_1_detailed.md

Case 2: Probe_Failure_Check

Failed case: Probe_Failure_Check

Root cause: The Probe_Failure_Check test detected a pre-existing firmware load error (regulatory.db missing, error -2 ENOENT) in dmesg that is unrelated to the PR changes (PSCRR framework patches). The PR introduces power state change reason recording infrastructure and does not touch wireless regulatory, device tree, or firmware loading paths.

Possible fix: This is a false positive test failure caused by a missing regulatory.db firmware file in the test rootfs image. The failure is not introduced by PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208. Recommended action: (1) Update the test rootfs to include regulatory.db firmware, or (2) Update the Probe_Failure_Check test to suppress known benign firmware load errors for optional regulatory databases, or (3) Approve and merge PR power: reset: Introduce Power State Change Reasons Recording (PSCRR) framework #1208 as the failure is pre-existing infrastructure noise unrelated to the PR changes.

Detail analysis attachment: failed_case_job269737_2_detailed.md

Faruque Ansari (faruque-ansari) requested review from a team, Amit Kucheria (idlethread), jingyiwang42 and Tingwei Zhang (quic-tingweiz) September 28, 2026 07:20

Faruque Ansari (faruque-ansari) force-pushed the pscrr branch from 32b021d to ec9413f Compare September 29, 2026 11:18

Faruque Ansari (faruque-ansari) force-pushed the pscrr branch from ec9413f to 783e94c Compare October 28, 2026 07:16

Avaneesh Dwivedi (akdwived-dev) approved these changes Oct 29, 2026

View reviewed changes

Shiraz Hashim (shashim-quic) previously approved these changes Nov 5, 2026

View reviewed changes

Faruque Ansari added 11 commits November 6, 2026 10:15

Faruque Ansari (faruque-ansari) dismissed Shiraz Hashim (shashim-quic)’s stale review via fd57c60 November 6, 2026 04:47

Faruque Ansari (faruque-ansari) force-pushed the pscrr branch from 783e94c to fd57c60 Compare November 6, 2026 04:47

qcomlnxci requested a review from a team November 6, 2026 04:49

Shiraz Hashim (shashim-quic) approved these changes Nov 6, 2026

View reviewed changes

Salendarsingh Gaud (sgaud-quic) merged commit 9bdb150 into qualcomm-linux:qcom-6.18.y Nov 6, 2026
6 of 8 checks passed

Conversation

Faruque Ansari (faruque-ansari) commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qswat-orbit-external Bot commented Sep 28, 2026

Uh oh!

qlijarvis commented Oct 8, 2026

PR #1208 — 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 Oct 8, 2026

PR #1208 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

⚠️ checkpatch (non-blocking style warnings)

❌ check-patch-compliance

✅ Passing Checkers

Verdict

Uh oh!

qlijarvis commented Oct 8, 2026

PR #1208 — validate-patch

Final Summary

🔍 Patch Validation Report

Summary

Commit-by-Commit Validation

Commit Message Validation

Diff Content Validation

Upstream Patch Status

Integration Presence (qcom-next/topics)

Issues Found

Final Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Oct 8, 2026

PR #1208 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

⚠️ checkpatch

❌ check-patch-compliance

Verdict

Uh oh!

qlijarvis commented Oct 28, 2026

PR #1208 — validate-patch

Final Summary

🔍 Patch Validation

Commit Message

Diff

Upstream Patch Status

Issues

Verdict

Final Summary

Deterministic Integration Presence

Integration Presence Report

Final Status

Uh oh!

qlijarvis commented Oct 28, 2026

PR #1208 — checker-log-analyzer

🤖 CI Checker Analysis (checker-log-analyzer)

❌ checkpatch

❌ check-patch-compliance

Verdict

Uh oh!

qcomlnxci commented Oct 29, 2026

Test Matrix

Uh oh!

qcomlnxci commented Oct 29, 2026

Test jobs on 783e94c

Uh oh!

Faruque Ansari (faruque-ansari) commented Sep 28, 2026 •

edited

Loading