Merge tag 'v6.18.44' into qcom-6.18.y

[nsiddams (nsiddams)]

CR:4656222

[qcomlnxci]

Test jobs on f9d3c5d

• multimedia Job 212424 on hamoa-iot-evk
• multimedia Job 212431 on lemans-evk
• multimedia Job 212426 on monaco-evk
• multimedia Job 212427 on purwa-iot-evk
• multimedia Job 212425 on qcs615-ride
• multimedia Job 212430 on qcs6490-rb3gen2
• multimedia Job 212423 on qcs8300-ride
• multimedia Job 212428 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212429 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qswat-orbit-external]

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]

PR #970 — validate-patch

PR: #970

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: No — no lore.kernel.org Link tags found in pr.patch (per lore_evidence/README.md)

2. Lore link matches PR commits: N/A — no lore links to compare against; cannot validate diff faithfulness

3. Upstream patch status: N/A — no upstream attribution provided; cannot determine acceptance status

4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #970 (title unavailable - network restricted)
Upstream commit: N/A
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	❌	No commit subject found (empty string)
Body preserves rationale	❌	No commit message body available
Fixes tag present/correct	❌	No Fixes tag found
Authorship preserved	❌	No author information in raw diff format
Backport note (if applicable)	N/A	Not applicable - no upstream reference

Diff

File	Status	Notes
Makefile	❌	Version bump: SUBLEVEL 37→44 without commit context
Documentation/* (multiple)	❌	88,826 files changed without attribution
arch/* (multiple)	❌	Massive tree-wide changes without commit message
drivers/* (multiple)	❌	No lore links or commit prefixes to validate against

Issues

Critical Issues:

1. No commit message or subject — The PR contains a raw diff with no git commit metadata. Cannot validate commit message correctness, authorship, or trailers.

2. No lore.kernel.org links — Per lore_evidence/README.md: "no lore.kernel.org Link tags found in pr.patch". The validate-patch skill requires a lore link to perform validation. Without upstream attribution, this PR cannot be validated for:

   • Faithful representation of upstream patches
   • Correct authorship preservation
   • Proper commit message formatting
   • Upstream acceptance status

3. Missing commit prefix — No UPSTREAM:, FROMLIST:, BACKPORT:, QCLINUX:, or other standard prefix found. Cannot determine the intended upstream relationship.

4. Partial integration presence — Per integration_presence_report.md:

   • Status: PARTIAL
   • 1,118,271 lines checked, 42,372 lines missing from qcom-next
   • 42,537 lines missing from topics/baseline
   • Missing samples include: Makefile version bump (SUBLEVEL = 44), MAINTAINERS updates, sc7280.dtsi OPP entries, and others

5. Massive scope without structure — 4,992,702 lines in the diff, 88,826 files changed. This appears to be a merge or rebase commit that should be broken down into properly attributed individual commits with lore links.

Verdict

REJECT — This PR cannot be validated or merged in its current form.

Required corrections:

1. Split into atomic commits — Break this massive diff into individual, logically grouped commits, each with:

   • A descriptive subject line following kernel style
   • A commit body explaining the change rationale
   • Proper authorship (From: line)
   • Appropriate commit prefix (UPSTREAM:, FROMLIST:, BACKPORT:, etc.)
   • Link: tag pointing to lore.kernel.org for upstream patches

2. Add lore attribution — For each commit that originates from upstream:

   • Include Link: https://lore.kernel.org/r/<message-id> in the commit message
   • Preserve original authorship
   • Add Signed-off-by: trailers

3. Document vendor-only changes — For Qualcomm-specific changes with no upstream equivalent:

   • Use QCLINUX: prefix
   • Provide clear rationale in commit body
   • No lore link required

4. Resolve integration gaps — Investigate the 42k missing lines:

   • Determine if these are intentional differences
   • Document why they differ from qcom-next/topics
   • Ensure version bumps (Makefile SUBLEVEL) are appropriate

Final Summary

1. Lore link present: No — no lore.kernel.org Link tags found in pr.patch (per lore_evidence/README.md)

2. Lore link matches PR commits: N/A — no lore links to compare against; cannot validate diff faithfulness

3. Upstream patch status: N/A — no upstream attribution provided; cannot determine acceptance status

4. PR present in qcom-next/topics: Partial — 1/1 commit has partial integration evidence (1,118,271 lines present, 42,372-42,537 lines missing across qcom-next and topics/baseline). Missing samples include Makefile version bump, MAINTAINERS updates, and sc7280.dtsi OPP entries.

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

Commit	Subject	qcom-next	topics	Final
1/1	``	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

Final Status

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

[qlijarvis]

PR #970 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	Merge conflict during setup
dt-binding-check	❌	Merge conflict during setup
dtb-check	❌	Merge conflict during setup
sparse-check	❌	Merge conflict during setup
check-uapi-headers	❌	Merge conflict during setup
check-patch-compliance	❌	Merge conflict during setup
tag-check	⏭️	Cannot run - merge conflict blocks analysis

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #970 (title unknown - logs only)
Target branch: qcom-6.18.y
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32331976782

Checker	Result	Summary
checkpatch	❌	Merge conflict during setup
dt-binding-check	❌	Merge conflict during setup
dtb-check	❌	Merge conflict during setup
sparse-check	❌	Merge conflict during setup
check-uapi-headers	❌	Merge conflict during setup
check-patch-compliance	❌	Merge conflict during setup
tag-check	⏭️	Cannot run - merge conflict blocks analysis

---

❌ All Checkers — Merge Conflict During CI Setup

Root cause: The CI automerge process failed when attempting to merge PR #970 (targeting qcom-6.18.y) with the qcom-next baseline. A merge conflict occurred in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c, preventing all checker jobs from running.

Failure details:

2026-08-20T04:44:12.6674220Z CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
2026-08-20T04:44:12.7277884Z Automatic merge failed; fix conflicts and then commit the result.
2026-08-20T04:44:12.7417950Z Merge failed or conflicts detected. Aborting merge.
2026-08-20T04:44:14.4207612Z ##[error]Process completed with exit code 3.

This failure occurred during the CI setup phase before any actual checker validation could run. The CI workflow performs an automerge operation that:

1. Checks out qcom-next as the baseline
2. Runs automerge to integrate topic branches
3. Attempts to merge the PR branch on top

The merge conflict at step 3 blocked all subsequent checker execution.

Fix: Resolve the merge conflict in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

Option 1 — Rebase the PR locally:

# In your local kernel tree
git fetch origin qcom-next
git checkout pr-970-branch
git rebase origin/qcom-next

# Resolve conflicts in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
# Edit the file, remove conflict markers, stage the resolution
git add drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
git rebase --continue

# Force-push the rebased branch
git push --force-with-lease

Option 2 — Use the resolve-conflict skill (if available in your environment):

$resolve-conflict

Option 3 — Investigate the conflict manually:

# Reproduce the conflict locally
git fetch origin qcom-next pr-970-branch
git checkout qcom-next
git merge --no-commit pr-970-branch

# Examine the conflict
git diff drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

Why this happened:
The PR targets qcom-6.18.y, but the CI checker workflow uses qcom-next as the integration baseline for validation. Changes in amdgpu_dm.c between qcom-6.18.y and qcom-next are incompatible with the changes in this PR, causing a three-way merge conflict.

Note on tag-check:
Since the target branch is qcom-6.18.y (not qcom-next or qcom-next-staging), the subject-prefix check (tag-check) would normally be mandatory — every commit must start with FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND:. However, this check cannot be performed until the merge conflict is resolved and the checkers can run.

---

Verdict

Cannot merge — blocker must be fixed first.

The merge conflict in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c must be resolved before any checker validation can proceed. Once resolved:

1. Re-trigger the CI run
2. All checkers will execute
3. Additional issues (if any) will be reported in a subsequent run

Immediate action required: Rebase PR #970 onto qcom-next and resolve the conflict in amdgpu_dm.c.

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

[qcomlnxci]

Test jobs on 39249be

• multimedia Job 212440 on hamoa-iot-evk
• multimedia Job 212445 on lemans-evk
• multimedia Job 212437 on monaco-evk
• multimedia Job 212438 on purwa-iot-evk
• multimedia Job 212443 on qcs615-ride
• multimedia Job 212441 on qcs6490-rb3gen2
• multimedia Job 212439 on qcs8300-ride
• multimedia Job 212442 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 212444 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[nsiddams (nsiddams)]

dp_display.c

These macros were removed as part of https://lore.kernel.org/all/20250808-hpd-refactor-v2-8-7f4e1e741aa3@oss.qualcomm.com/

None of these changes are needed.

Updated the change

[riteshk-quic]

Approved for dp_display.c

[qcomlnxci]

Test jobs on 39249be

• multimedia Job 218018 on hamoa-iot-evk
• multimedia Job 218021 on lemans-evk
• multimedia Job 218017 on monaco-evk
• multimedia Job 218022 on purwa-iot-evk
• multimedia Job 218025 on qcs615-ride
• multimedia Job 218024 on qcs6490-rb3gen2
• multimedia Job 218023 on qcs8300-ride
• multimedia Job 218019 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 218020 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on 39249be

• multimedia Job 218062 on hamoa-iot-evk
• multimedia Job 218061 on lemans-evk
• multimedia Job 218060 on monaco-evk
• multimedia Job 218066 on purwa-iot-evk
• multimedia Job 218064 on qcs615-ride
• multimedia Job 218067 on qcs6490-rb3gen2
• multimedia Job 218059 on qcs8300-ride
• multimedia Job 218065 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 218063 on shikra-iqs-evk

[qcomlnxci]

Test Matrix

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

[qlijarvis]

PR #970 — validate-patch

PR: #970

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: No — no lore.kernel.org link found in pr.patch (per lore_evidence/README.md)
2. Lore link matches PR commits: N/A — no lore link to compare against; patch has no commit structure
3. Upstream patch status: N/A — cannot determine without lore link or commit metadata
4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #970 (title unknown - network restricted)
Upstream commit: N/A
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	❌	No commit message present in pr.patch
Body preserves rationale	❌	No commit message present in pr.patch
Fixes tag present/correct	❌	No commit message present in pr.patch
Authorship preserved	❌	No commit metadata (From/Author) present
Backport note (if applicable)	N/A	No commit message to evaluate

Diff

File	Status	Notes
94,677 files modified	❌	Massive unified diff with no commit structure
Makefile (appears 33 times)	❌	Duplicate/overlapping changes suggest malformed patch
SUBLEVEL 37→44	⚠️	Appears to be stable kernel version bump (v6.12.37 → v6.12.44)

Issues

Critical structural problems:

1. No commit metadata — pr.patch is a raw unified diff with no From:, Subject:, Date:, or commit message headers. This violates kernel patch submission standards.

2. No lore.kernel.org link — Per lore_evidence/README.md: "no lore.kernel.org Link tags found in pr.patch". The validate-patch skill requires a lore link to verify patch integrity. Without one, validation cannot proceed.

3. Malformed patch structure — The same file (e.g., Makefile) is modified 33 times within the same patch, suggesting either:

   • Multiple commits were concatenated without proper git format-patch boundaries
   • A merge conflict resolution was exported as a raw diff
   • The patch was generated incorrectly

4. Massive scope — 94,677 files changed across ~5M lines. This scale is consistent with a stable kernel merge (v6.12.37 → v6.12.44) but should be represented as a merge commit, not a unified diff.

5. Partial integration presence — Per integration_presence_report.md: "PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence". The report shows 1,118,832 added lines present but 41,712 lines missing from qcom-next, with missing samples in Documentation/, MAINTAINERS, Makefile, and arch/arm64/boot/dts/qcom/sc7280.dtsi.

Verdict

Do not merge. This PR cannot be validated because:

1. It lacks the required lore.kernel.org link (mandatory per validate-patch skill Step 1)
2. It has no commit message or metadata to review
3. The patch structure is malformed (duplicate file modifications)
4. It cannot be verified against upstream sources

If this is a stable kernel merge (v6.12.37 → v6.12.44):

• Use git merge to create a proper merge commit, not git diff
• The merge commit message should reference the stable release tag
• Individual stable commits should preserve their original authorship and commit messages
• No lore link is needed for a merge commit itself, but constituent commits should have proper attribution

If this is a backport series:

• Split into individual commits with proper git format-patch structure
• Each commit must have: From, Date, Subject, commit body, and Link: tag pointing to lore.kernel.org
• Use appropriate prefixes: UPSTREAM:, BACKPORT:, or FROMLIST:

Final Summary

1. Lore link present: No — no lore.kernel.org link found in pr.patch (per lore_evidence/README.md)
2. Lore link matches PR commits: N/A — no lore link to compare against; patch has no commit structure
3. Upstream patch status: N/A — cannot determine without lore link or commit metadata
4. PR present in qcom-next/topics: Partial — 1,118,832/1,160,544 added lines present (96.4%); 41,712 lines missing including changes to sc7280.dtsi, Makefile, MAINTAINERS, Documentation/ (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: 3c1e80ceb9fb6978aa94bc0624e7c0003f3b4f6e
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	``	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

Final Status

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

[qlijarvis]

PR #970 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	⚠️	Minor warnings (Reported-by/Closes, commit description style, email mismatches)
dt-binding-check	✅	All binding checks passed
dtb-check	❌	Pre-existing tree issues (Allwinner, MediaTek, Nvidia Tegra234)
sparse-check	✅	No sparse warnings
check-uapi-headers	❌	UAPI ABI breakage in btrfs headers
check-patch-compliance	❌	All 3297 commits missing required prefix (expected for stable merge)
tag-check	N/A	Not applicable for stable release merges

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #970 - Linux 6.18.44 stable release merge
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32747138731

Checker	Result	Summary
checkpatch	⚠️	Minor warnings (Reported-by/Closes, commit description style, email mismatches)
dt-binding-check	✅	All binding checks passed
dtb-check	❌	Pre-existing tree issues (Allwinner, MediaTek, Nvidia Tegra234)
sparse-check	✅	No sparse warnings
check-uapi-headers	❌	UAPI ABI breakage in btrfs headers
check-patch-compliance	❌	All 3297 commits missing required prefix (expected for stable merge)
tag-check	N/A	Not applicable for stable release merges

---

❌ check-uapi-headers

Root cause: UAPI ABI breakage detected in include/linux/btrfs.h — the buf[] array element type changed from __u64 to __u8 in struct btrfs_ioctl_search_args_v2.

Failure details:

==== ABI differences detected in include/linux/btrfs.h from dc0f4d4280a7 -> f9d3c5dfa71e ====
    [C] 'struct btrfs_ioctl_search_args_v2' changed:
      type size hasn't changed
      1 data member change:
        type of '__u64 buf[]' changed:
          array element type 'typedef __u64' changed:
            typedef name changed from __u64 to __u8 at int-ll64.h:21:1
            underlying type 'unsigned long long int' changed:
              type name changed from 'unsigned long long int' to 'unsigned char'
              type size changed from 64 to 8 (in bits)
          type name changed from '__u64[]' to '__u8[]'
          type size hasn't changed

Analysis: This is a genuine UAPI ABI breakage introduced by one of the 3297 commits in the Linux 6.18.44 stable release. The btrfs_ioctl_search_args_v2 structure's buf[] field changed its element type from __u64 (8 bytes) to __u8 (1 byte). While the total array size hasn't changed, this breaks binary compatibility for userspace programs that expect __u64 elements.

Fix: This requires investigation of which commit in the stable release introduced this change. The change may be intentional (a fix) or unintentional (a regression). Check the btrfs commits in the 6.18.44 release notes and verify if this is a known issue.

Reproduce locally:

./scripts/check-uapi.sh -b f9d3c5dfa71e2c90b7cc5e9c6769f1a3cafe51ce -p dc0f4d4280a7ecfcf8bc2d6bff1f42b1b8d33b08 -l uapi_errors.log

---

❌ dtb-check

Root cause: Pre-existing devicetree validation errors in Allwinner, MediaTek, and Nvidia Tegra234 platforms — these are not introduced by this PR.

Failure details:

# Allwinner sun55i pinctrl (4 DTBs affected):
pinctrl@2000000 (allwinner,sun55i-a523-pinctrl): interrupts: [[0, 67, 4], ...] is too long

# MediaTek mt8192 PCIe (2 DTBs affected):
pcie@11230000 (mediatek,mt8192-pcie): Unevaluated properties are not allowed ('memory-region' was unexpected)

# Nvidia Tegra234 MGBE ethernet (multiple DTBs affected):
ethernet@6800000 (nvidia,tegra234-mgbe): clock-names:3: 'ptp-ref' was expected

Analysis: These are recurring tree-wide issues documented in the skill's log-patterns reference (Section 8). They exist in the baseline tree and are exposed when new DTBs are built. The checker's baseline subtraction should have filtered these out, but they appear in the log, indicating either:

1. The base build was incomplete, or
2. These errors were introduced in a previous merge and are now being flagged

Fix: These are not blockers for this PR. They should be fixed in separate patches targeting the affected platform DTS/binding files:

• Allwinner: Update allwinner,sun55i-a523-pinctrl.yaml to allow more interrupt entries
• MediaTek: Add memory-region to mediatek-pcie-gen3.yaml properties
• Nvidia: Add ptp-ref clock to Tegra234 MGBE ethernet nodes

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb

---

❌ check-patch-compliance

Root cause: All 3297 commits in the Linux 6.18.44 stable release lack the required subject-line prefix (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, etc.).

Failure details:

Checking commit: KVM: x86: Fix shadow paging use-after-free due to unexpected role
Commit summary does not start with a required prefix

Checking commit: lsm: add backing_file LSM hooks
Commit summary does not start with a required prefix

... (3297 total failures)

Checking commit: Linux 6.18.44
Commit summary does not start with a required prefix

Analysis: This is expected behavior for a stable release merge. The check-patch-compliance checker enforces that every commit must start with a prefix like UPSTREAM:, FROMLIST:, etc. However, stable release commits from kernel.org are imported as-is without modification.

Fix: For a stable release merge, there are two options:

1. Accept as-is (recommended): Stable releases are authoritative upstream sources and don't require prefix modification. The checker limitation is known.
2. Rewrite all 3297 commits (not recommended): Prepend UPSTREAM: to every commit subject, but this breaks traceability to the original stable release and complicates future merges.

Note: The skill documentation (Section 2.6) explicitly states: "QCLINUX: and PENDING: prefixes always fail check-patch-compliance — this is a known checker limitation for vendor-only commits." The same limitation applies to unmodified stable release merges.

---

⚠️ checkpatch

Root cause: Minor style warnings in a small subset of commits (not blockers).

Failure details:

• Reported-by: should be immediately followed by Closes: — Several commits have Reported-by: without a Closes: link
• From:/Signed-off-by: email address mismatch — Author Wenjie Qi has different emails in From: vs Signed-off-by:
• Prefer a maximum 75 chars per line — A few commit messages have long lines
• ERROR: Please use git commit description style — One commit references another commit incorrectly

Analysis: These are minor style issues inherited from the upstream stable release. They do not affect functionality.

Fix: Not required for a stable release merge. These commits are imported from kernel.org and should not be modified.

---

Verdict

This is a Linux 6.18.44 stable release merge with 3297 commits.

Blockers:

1. check-uapi-headers UAPI ABI breakage — The btrfs_ioctl_search_args_v2 structure change is a genuine ABI break that must be investigated. Verify if this is intentional (a fix in the stable release) or a regression.

Non-blockers:

• check-patch-compliance — Expected failure for stable merges (all 3297 commits lack prefix)
• dtb-check — Pre-existing tree issues in Allwinner/MediaTek/Nvidia platforms (not introduced by this PR)
• checkpatch — Minor style warnings inherited from upstream (acceptable for stable merges)

Recommendation:
Investigate the btrfs UAPI change before merging. If the ABI break is intentional and documented in the 6.18.44 release notes, proceed with merge. Otherwise, consider excluding the problematic btrfs commit(s) or waiting for a fix in a subsequent stable release.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #970

Job 212437 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check (4 genuine failures; 2 suppressed as benign)

1. Failed case: Probe_Failure_Check (4 genuine failures; 2 suppressed as benign)
2. Root cause: ath11k_pci WiFi driver probe timeout (-110) after firmware load failure on monaco-evk (SM8275); PR970 modifies ath11k PCI driver code and likely introduced a regression in the probe/initialization path causing the WCN6855 WiFi module to fail enumeration.
3. Possible fix: Revert or debug the ath11k driver changes in PR970 (drivers/net/wireless/ath/ath11k/pci.c, ahb.c, dp.c, dp_rx.c); verify firmware path /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/amss.bin exists in rootfs; add regulatory.db to firmware package; cpufreq-dt -EEXIST and BT firmware errors are benign and require no action.
4. Detail analysis attachment: failed_case_job212437_1_detailed.md

  Case 2: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: ath11k_pci driver probe timeout (-110 ETIMEDOUT) on monaco-evk WCN6855 WiFi device after PR Merge tag 'v6.18.44' into qcom-6.18.y #970 modified ath11k_pci_soc_global_reset() to add PCI posted-write flush operations, which altered reset timing and caused MHI firmware load failure (amss.bin -2 ENOENT) followed by probe timeout.
3. Possible fix: Revert the ath11k/pci.c changes from PR Merge tag 'v6.18.44' into qcom-6.18.y #970 or adjust the reset delay timing in ath11k_pci_soc_global_reset() to account for the additional latency introduced by the read-back flush operations — increase the mdelay(delay) value from 10ms to 20-50ms after each flush to allow the WCN6855 device sufficient time to complete reset and respond to MHI firmware requests.
4. Detail analysis attachment: failed_case_job212437_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing WCN6855 nfa765 firmware binary (ath11k/WCN6855/hw2.1/nfa765/amss.bin) to the rootfs image build recipe for monaco-evk. Verify the firmware package (e.g., linux-firmware-ath11k or equivalent) includes the nfa765 variant and is installed in the Yocto/build configuration for this target.
4. Detail analysis attachment: failed_case_job212437_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test infrastructure marked the test definition as failed because WiFi test cases (WiFi_Firmware_Driver and WiFi_OnOff) failed due to ath11k_pci probe timeout (error -110) caused by missing firmware file (ath11k/WCN6855/hw2.1/nfa765/amss.bin) on monaco-evk platform.
3. Possible fix: This is a test infrastructure/firmware packaging issue, not a kernel regression. The PR changes to ath11k_pci.c (adding flush reads after global reset) may have exposed a pre-existing timing sensitivity in the monaco-evk WiFi hardware initialization. Verify firmware files are present in the test image rootfs at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/. If firmware is present, the PCI flush reads may need timing adjustment for this specific platform.
4. Detail analysis attachment: failed_case_job212437_4_detailed.md

Job 212438 | SoC purwa-evk

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

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

  Case 1: Build Load Failure — HTTP download timeout

1. Failed case: Build Load Failure — HTTP download timeout
2. Root cause: Result: Build Load Failure. The LAVA dispatcher's HTTP download action timed out after 2396 seconds (39m56s) while downloading a 1033 MB build artifact from AWS S3. The download reached only 35% (361 MB) before the configured timeout was exceeded. The exact error string is "http-download timed out after 2396 seconds".
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2396s (39m56s) to at least 7200s (2 hours) and the download-retry block timeout from 2396s to match in the LAVA job definition. Additionally, investigate network bandwidth between the LAVA worker and AWS S3 us-west-2 region, as the observed download rate (~9 MB/min) is abnormally slow for a 1 GB file transfer.
4. Detail analysis attachment: failed_case_job212438_1_detailed.md

  Case 2: Build Load Failure — HTTP download timeout

1. Failed case: Build Load Failure — HTTP download timeout
2. Root cause: Result: Build Load Failure. The LAVA dispatcher's http-download action timed out after 2396 seconds (39 minutes 56 seconds) while downloading a 1033 MB build artifact from AWS S3. The download reached only 35% (361 MB) before the timeout, indicating severely degraded network throughput (~150 KB/s average) between the LAVA worker and the S3 artifact server. The error type is "Infrastructure", confirming this is a LAVA lab infrastructure issue, not a kernel or PR-introduced problem.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download timeout from 2396s (~40min) to 7200s (2 hours) and the download-retry block timeout from 00:39:56 to 02:30:00 in the LAVA job definition to accommodate the 1 GB+ artifact size over slow network links. Additionally, investigate network path performance between the LAVA worker (board serial FTA9W2BQ, purwa-evk SoC) and qli-prd-kernel-gh-artifacts.s3.us-west-2.amazonaws.com to identify bottlenecks.
4. Detail analysis attachment: failed_case_job212438_2_detailed.md

  Case 3: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The LAVA dispatcher's HTTP download of the 1033 MB root filesystem image from S3 (qcom-multimedia-image-iq-x5121-evk.rootfs.qcomflash.tar.gz) timed out after 2396 seconds (39m56s) at 35% completion (361 MB transferred). Network transfer rate was extremely slow (averaging ~150 KB/s for the first 20%, then briefly accelerating before stalling completely at 35%). The error type Infrastructure indicates a LAVA lab-side issue, not a build artifact problem.
3. Possible fix: Re-trigger the CI job; if the timeout recurs, increase the http-download action timeout from 2396s (00:39:56) to at least 3600s (1 hour) and the parent download-retry block timeout from 2400s to 4000s in the LAVA job definition. Additionally, investigate S3 bucket throttling limits and LAVA worker network path to AWS us-west-2 region for the purwa-evk board (serial FTA9W2BQ, debugboard 'tac').
4. Detail analysis attachment: failed_case_job212438_3_detailed.md

  Case 4: ** Build Load Failure — HTTP download timeout

1. Failed case: ** Build Load Failure — HTTP download timeout
2. Root cause: ** Result: Build Load Failure. The LAVA dispatcher's HTTP download of the 1033 MB rootfs image (qcom-multimedia-image-iq-x5121-evk.rootfs.qcomflash.tar.gz) from the S3 artifact server timed out after 2396 seconds (39m56s) at 35% completion (361 MB downloaded). Network connectivity was intermittent: initially very slow (~5-7 MB/min for 0-20%), briefly fast (~2500 MB/min for 20-35%), then completely stalled for the final 3m44s until timeout. The kernel never booted.
3. Possible fix: Re-trigger the CI job to rule out transient network issues. If the failure recurs, increase the http-download action timeout from the current 2396s (~40min) to 3600s (60min) and increase the download-retry block timeout proportionally in the LAVA job definition to accommodate the large 1033 MB image size over potentially slow/unstable network paths. Additionally, investigate S3 bucket network path stability and consider enabling download resume/chunking if supported by the LAVA dispatcher.
4. Detail analysis attachment: failed_case_job212438_4_detailed.md

Job 212439 | SoC qcs8300-ride

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

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

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

1. Failed case: Probe_Failure_Check — Pre-existing Platform Issues (Not PR-Introduced)
2. Root cause: Two pre-existing platform-specific probe failures on qcs8300-ride: (1) regulatory.db firmware file missing from rootfs (benign — cfg80211 falls back to built-in certificates), and (2) Aquantia AQR115C Ethernet PHY probe failure due to missing firmware-name DT property (error -22 / -EINVAL), a known board-specific configuration issue unrelated to this PR's changes (documentation, cpufreq, crypto, DT bindings, and PHY driver fixes for Marvell/Realtek/SFP — no Aquantia driver modifications).
3. Possible fix: Mark this test failure as a false positive for PR validation purposes. The regulatory.db warning is cosmetic (WiFi/BT functional tests passed). The Aquantia PHY probe failure requires a separate board-level fix: add the missing firmware-name property to the qcs8300-ride DTS ethernet PHY node, or confirm the PHY firmware is not required for this board configuration and suppress the error in the driver.
4. Detail analysis attachment: failed_case_job212439_1_detailed.md

  Case 2: USBHost — Test Infrastructure Issue

1. Failed case: USBHost — Test Infrastructure Issue
2. Root cause: The USBHost test expects at least one functional USB device to be connected to the qcs8300-ride board's USB host port, but only the USB 2.0 root hub (Bus 001 Device 001: ID 1d6b:0002) is enumerated. The kernel USB host controller (xhci-hcd at 0x0a400000) initialized successfully and the USB stack is functional, but no external USB devices are physically connected to the test board.
3. Possible fix: This is a test infrastructure/lab setup issue, not a kernel regression. The PR contains no USB host driver changes for qcs8300 (USB changes in the patch are limited to ipq5424 device tree node address corrections). Re-run the test with a USB device (e.g., USB flash drive, keyboard, or mouse) physically connected to the board's USB host port, or mark this test as expected-fail for boards without permanently attached USB peripherals.
4. Detail analysis attachment: failed_case_job212439_2_detailed.md

  Case 3: Ethernet_Basic_Validation — Driver Probe Failure (PHY Attachment)

1. Failed case: Ethernet_Basic_Validation — Driver Probe Failure (PHY Attachment)
2. Root cause: The qcom-ethqos Ethernet driver (st_gmac) at 23040000.ethernet on qcs8300-ride fails to attach to the PHY during interface bring-up due to phylink validation failure of 2500base-x mode. The PHY advertises link modes (0x000062c0) that are incompatible with the MAC's supported capabilities (0x000062cc) for 2500base-x, resulting in -EINVAL from phylink_validate(). This is a platform-specific configuration mismatch between the PHY capabilities advertised in device tree and the MAC driver's supported link modes, not a regression introduced by PR Merge tag 'v6.18.44' into qcom-6.18.y #970.
3. Possible fix: This is a pre-existing platform configuration issue on qcs8300-ride, not introduced by PR Merge tag 'v6.18.44' into qcom-6.18.y #970 (which contains no qcom-ethqos, qcs8300, phylink validation, or 2500base-x capability changes). The PR can proceed to merge. To fix the underlying board issue: (1) verify the PHY device tree node's max-speed property and phy-mode are correctly set for the installed PHY hardware on qcs8300-ride; (2) check if the qcom-ethqos driver's mac_capabilities in drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c correctly declares 2500base-x support for this SoC variant; (3) if the PHY hardware does not support 2500base-x, update the device tree to use phy-mode = "rgmii" or sgmii and remove max-speed = <2500> if present.
4. Detail analysis attachment: failed_case_job212439_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: /dev/kvm device node is not created despite CONFIG_KVM being enabled in the kernel configuration. On qcs8300-ride (Monaco SoC), KVM requires hardware virtualization support (EL2/VHE) which may not be available or enabled in the firmware/bootloader configuration for this platform. The KVM ARM64 driver successfully compiles into the kernel but does not initialize at runtime because the platform does not meet the hardware prerequisites for KVM operation (CPU must support virtualization extensions and boot at EL2).
3. Possible fix: This is a platform limitation, not a kernel regression. The qcs8300-ride platform either lacks hardware virtualization support or the bootloader is not configured to enable EL2. To resolve: (1) verify the SoC supports ARM virtualization extensions (check CPU features for "VHE" or check if CPU boots to EL2); (2) if supported, ensure the bootloader (ABL/XBL) is configured to boot the kernel at EL2 instead of EL1; (3) if the platform fundamentally does not support virtualization, mark KVM tests as "not applicable" for qcs8300-ride in the CI test matrix rather than treating this as a failure.
4. Detail analysis attachment: failed_case_job212439_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)

1. Failed case: KVM_EL2_DTB — KVM device node unavailable (pre-existing platform limitation)
2. Root cause: /dev/kvm device node is not present on QCS8300 Ride (Monaco) platform because KVM/hypervisor support is not initialized at EL2 on this SoC. CONFIG_KVM is enabled in the kernel configuration, but the KVM driver did not create /dev/kvm, indicating that the platform either does not support virtualization extensions at the hardware/firmware level, or the hypervisor mode (EL2) is not accessible to the kernel on this board configuration.
3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR Merge tag 'v6.18.44' into qcom-6.18.y #970. The PR changes are related to KVM code (GICv3 LR count, nested virtualization, MTE capability checks, and address size fault codes) but do not affect KVM initialization or device node creation. No fix is required for the PR. If KVM support is required on QCS8300 Ride, verify: (1) the SoC/board supports ARM virtualization extensions (VHE/nVHE), (2) the bootloader/firmware boots the kernel at EL2 or allows EL2 access, (3) the device tree includes any required hypervisor/virtualization nodes, and (4) check for any KVM initialization error messages in the full dmesg log that may indicate why KVM did not probe successfully.
4. Detail analysis attachment: failed_case_job212439_5_detailed.md

  Case 6: KVM_Infra — Platform Configuration Limitation

1. Failed case: KVM_Infra — Platform Configuration Limitation
2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running under the Gunyah hypervisor, which occupies EL2 (hypervisor mode). KVM requires EL2 access to create /dev/kvm and enable virtualization, but EL2 is already owned by Gunyah. This is an expected architectural limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: Update the LAVA KVM test suite to detect hypervisor presence (check for "Hypervisor cold boot.*gunyah" in dmesg) and skip KVM tests with a SKIP result instead of FAIL when running under Gunyah. Add a test gate in Runner/suites/Virtualization/KVM/*/run.sh before checking for /dev/kvm.
4. Detail analysis attachment: failed_case_job212439_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failure on qcs8300-ride — CONFIG_KVM is enabled but /dev/kvm device node is not created; PR introduces changes to init_subsystems() that access hyp_gicv3_nr_lr symbol during VGIC initialization, likely causing silent initialization failure on this SoC where GICv3 configuration may differ from expected.
3. Possible fix: Verify that hyp_gicv3_nr_lr symbol is properly initialized before use in init_subsystems(); add error handling and logging around the new code at line 2327 in arch/arm64/kvm/arm.c that accesses kvm_nvhe_sym(hyp_gicv3_nr_lr); check if static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif) condition is correctly evaluating on qcs8300-ride; add defensive check to ensure kvm_vgic_global_state.nr_lr is valid before assignment.
4. Detail analysis attachment: failed_case_job212439_7_detailed.md

Job 212440 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check — Deferred probe loop and hard probe failures

1. Failed case: Probe_Failure_Check — Deferred probe loop and hard probe failures
2. Root cause: Pinctrl driver 6e80000.pinctrl is stuck in deferred probe state, causing cascading deferrals for all audio subsystem devices (soundwire controllers, codecs, sound card) that depend on its pinctrl states; additionally, three drivers have hard probe failures: qcom_qseecom_uefisecapp (-EBUSY), qcom-spmi-lpg (-EINVAL), and regulatory.db firmware load (-ENOENT).
3. Possible fix: Investigate why 6e80000.pinctrl (TLMM pinctrl) is deferring probe on hamoa-evk — check device tree for missing clock/regulator/power-domain dependencies or incorrect phandle references; for the hard failures, qseecom -EBUSY indicates TrustZone resource conflict (expected on some platforms), lpg -EINVAL suggests DT property mismatch, and regulatory.db -ENOENT is a known benign firmware warning that can be ignored.
4. Detail analysis attachment: failed_case_job212440_1_detailed.md

  Case 2: ** smmu (Test Expectation Mismatch — Not a Kernel Crash)

1. Failed case: ** smmu (Test Expectation Mismatch — Not a Kernel Crash)
2. Root cause: ** Test expects USB wrapper devices (a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb) and video codec device (aa00000.video-codec) to have IOMMU group attachments, but these devices either do not have drivers on hamoa-evk platform or are parent/wrapper nodes that do not perform DMA and do not require IOMMU protection. The actual USB controllers and all other critical masters are correctly protected by SMMU. No SMMU hardware faults or kernel errors present.
3. Possible fix: Update the smmu test's device list for hamoa-evk platform to exclude USB wrapper devices (addresses ending in f8800) and aa00000.video-codec, or mark them as optional. The test should only validate devices that actually probe and perform DMA operations.
4. Detail analysis attachment: failed_case_job212440_2_detailed.md

  Case 3: KVM_Driver — /dev/kvm not available (driver initialization failure)

1. Failed case: KVM_Driver — /dev/kvm not available (driver initialization failure)
2. Root cause: KVM driver initialization failed during kernel boot because ARM EL2 (Hypervisor mode) is not available on the Hamoa IoT EVK platform. The kernel message "kvm [1]: HYP mode not available" at boot time (6.373361s) indicates the CPU is not running in or does not support EL2, which is a prerequisite for KVM/ARM virtualization. This is a platform hardware/firmware limitation, not a kernel software issue.
3. Possible fix: This is not a PR-introduced regression. The Hamoa IoT EVK platform does not support ARM virtualization (EL2/HYP mode), either due to hardware limitations or firmware configuration that boots the kernel at EL1 without EL2 access. To enable KVM on this platform: (1) verify the SoC hardware supports virtualization extensions, (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 or with EL2 accessible, (3) check secure firmware (TZ) configuration to ensure EL2 is not disabled. If the hardware does not support EL2, KVM tests should be skipped for this platform in CI. Add platform-specific test skip logic for hamoa-evk in the LAVA test definition.
4. Detail analysis attachment: failed_case_job212440_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM initialization failure

1. Failed case: KVM_EL2_DTB — KVM initialization failure
2. Root cause: KVM cannot initialize because Gunyah hypervisor (gunyah-mobile-c487961e9) is already running at EL2 on hamoa-evk, preventing KVM from taking control of HYP mode; kernel log shows "kvm [1]: HYP mode not available" at boot.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The hamoa-evk board boots with Gunyah hypervisor by default, which occupies EL2 and prevents KVM from initializing. To enable KVM testing on this platform: (1) boot without Gunyah hypervisor (requires bootloader/firmware configuration change to disable Gunyah), OR (2) exclude KVM tests from the hamoa-evk test suite since this platform is configured for Gunyah virtualization, not KVM.
4. Detail analysis attachment: failed_case_job212440_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is expected behavior on hamoa-evk with Gunyah hypervisor; to enable KVM testing, either (1) use a different platform without Gunyah, (2) boot hamoa-evk without Gunyah hypervisor (requires firmware/bootloader configuration change), or (3) mark KVM tests as expected-to-skip on hamoa-evk in the CI test matrix.
4. Detail analysis attachment: failed_case_job212440_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because the hamoa-evk platform is running under Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-mobile-c487961e9"), which prevents KVM from initializing in nested virtualization mode, resulting in "kvm [1]: HYP mode not available" and no /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The hamoa-evk board runs Gunyah hypervisor by default, which occupies EL2 and prevents KVM (which also requires EL2) from running. To enable KVM testing on this platform: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, OR (2) exclude KVM tests from the hamoa-evk test suite, OR (3) use a different platform without a pre-existing hypervisor for KVM validation.
4. Detail analysis attachment: failed_case_job212440_6_detailed.md

Job 212441 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test false positive — reports deferred probe chains and missing optional firmware as failures on qcs6490-rb3gen2 where audio hardware is not configured in DT and regulatory.db/renesas USB firmware are not included in rootfs
3. Possible fix: Suppress known-benign probe failures in Probe_Failure_Check test: (1) deferred probe entries when no corresponding hard probe failure exists, (2) regulatory.db firmware load failure when WiFi functional tests pass, (3) xhci-pci-renesas probe failure on platforms without Renesas USB firmware
4. Detail analysis attachment: failed_case_job212441_1_detailed.md

  Case 2: USBHost — Driver Probe Failure (USB Host Controller)

1. Failed case: USBHost — Driver Probe Failure (USB Host Controller)
2. Root cause: On-SoC USB host controllers (8c00000.usb, a600000.usb) are present in device tree and registered with IOMMU but no USB host controller driver (dwc3-qcom/xhci-hcd) is probing them; the only USB controller probe attempt was for a PCIe-attached Renesas xHCI (0001:04:00.0) which failed due to missing firmware (renesas_usb_fw.mem, error -2/ENOENT); qcs6490-rb3gen2 requires dwc3-qcom driver to initialize on-SoC USB controllers for host mode functionality.
3. Possible fix: Enable CONFIG_USB_DWC3_QCOM=y (or =m and ensure module is loaded) in the kernel configuration to probe the on-SoC Qualcomm DWC3 USB controllers at 8c00000.usb and a600000.usb; verify the driver probes successfully and creates xhci-hcd host controller instances; optionally install renesas_usb_fw.mem firmware to /lib/firmware/ if the PCIe USB controller is intended to be used.
4. Detail analysis attachment: failed_case_job212441_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Suppress KVM tests for qcs6490-rb3gen2 in CI by adding it to the test exclusion list in the LAVA test definition. Long-term: work with Qualcomm firmware team to enable EL2 in the bootloader/TrustZone configuration. To verify after firmware update: check dmesg | grep kvm shows "Hyp mode initialized successfully" and confirm /dev/kvm exists.
4. Detail analysis attachment: failed_case_job212441_3_detailed.md

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

1. Failed case: KVM_EL2_DTB — /dev/kvm unavailable (HYP mode not available)
2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform boots without EL2/HYP mode available, causing KVM initialization to fail with "HYP mode not available" at boot time (line 2960), which prevents /dev/kvm device node creation and causes all KVM-dependent tests to fail.
3. Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression. To enable KVM on qcs6490-rb3gen2: (1) verify the bootloader (ABL/XBL) is configured to boot Linux at EL2 instead of EL1, (2) ensure the hypervisor firmware (hypvm.mbn) is present and correctly loaded, (3) check that the platform's TrustZone configuration allows EL2 execution, or (4) if the hardware does not support virtualization extensions, mark KVM tests as "not applicable" for this platform in the CI test matrix.
4. Detail analysis attachment: failed_case_job212441_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. To enable KVM on qcs6490-rb3gen2: (1) Update board firmware (ABL/UEFI) to boot Linux at EL2 instead of EL1, or (2) Exclude KVM tests from the CI test suite for this SoC, as it does not support virtualization in its current firmware configuration. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job212441_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform limitation — qcs6490-rb3gen2 (Kodiak) does not support ARM EL2 (Hypervisor mode), which is required for KVM functionality; kernel correctly detected and reported "HYP mode not available" at boot.
3. Possible fix: Mark KVM_Infra test as expected-fail or skip for qcs6490-rb3gen2 platform in the LAVA test definition; alternatively, exclude KVM tests from the test suite for platforms without EL2 support.
4. Detail analysis attachment: failed_case_job212441_6_detailed.md

Job 212442 | SoC qcs9100-ride

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

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

  Case 1: Kernel Crash — Synchronous External Abort (SMMU Hardware Access Fault)

1. Failed case: Kernel Crash — Synchronous External Abort (SMMU Hardware Access Fault)
2. Root cause: The qcs9100-ride platform experienced a synchronous external abort at PC qcom_smmu_write_s2cr+0x84/0x140 during SMMU (System MMU) device probe at boot. The fault occurred when the qcom-smmu driver attempted to write to the S2CR (Stream-to-Context Register) at address ffff800084000c28 (x19 register), indicating the SMMU hardware register block is either not powered, not clocked, or the memory-mapped region is inaccessible due to platform-specific power/clock/interconnect configuration issues on qcs9100-ride.
3. Possible fix: This is a pre-existing platform bring-up issue specific to qcs9100-ride, not introduced by PR Merge tag 'v6.18.44' into qcom-6.18.y #970 (which only modifies arm-smmu-v3 iommufd code and documentation, not qcom-smmu or qcs9100 device tree). Verify qcs9100-ride device tree SMMU node power-domain, clock, and interconnect properties; confirm SMMU power rails and clocks are enabled before driver probe; check if qcs9100-ride requires platform-specific SMMU initialization sequence or firmware dependencies not present in the test environment.
4. Detail analysis attachment: failed_case_job212442_1_detailed.md

  Case 2: ** Kernel Crash — Synchronous External Abort during SMMU Initialization

1. Failed case: ** Kernel Crash — Synchronous External Abort during SMMU Initialization
2. Root cause: ** The kernel crashes with a synchronous external abort (bus error) when the ARM SMMU driver attempts to write to the S2CR (Stream-to-Context Register) at offset 0xc28 during arm_smmu_device_probe. The SMMU hardware block on qcs9100-ride either: (1) is not powered/clocked correctly, (2) has incorrect register base address mapping in the device tree, (3) is held in reset, or (4) has secure firmware blocking non-secure S2CR writes. This is a pre-existing platform/board configuration issue, not a regression introduced by PR Merge tag 'v6.18.44' into qcom-6.18.y #970 (the PR does not modify ARM SMMU v1/v2 driver code).
3. Possible fix: Verify qcs9100-ride SMMU device tree configuration: (1) Confirm SMMU register base address and size in DT match hardware spec, (2) Verify SMMU power domain and clock bindings are correct and enabled before probe, (3) Check if secure firmware (TZ/XBL) has configured SMMU security policy to allow non-secure S2CR writes, (4) Compare with a known-good qcs9100 DTB to identify missing or incorrect properties. If this is a lab-specific board issue, re-trigger the CI job on a different qcs9100-ride board to confirm hardware health.
4. Detail analysis attachment: failed_case_job212442_2_detailed.md

  Case 3: Kernel Crash — Synchronous External Abort in SMMU Driver

1. Failed case: Kernel Crash — Synchronous External Abort in SMMU Driver
2. Root cause: Synchronous external abort (hardware fault) at qcom_smmu_write_s2cr+0x84/0x140 during ARM SMMU driver probe on qcs9100-ride; the SMMU driver attempted to write to S2CR registers but triggered a bus fault, indicating either unmapped/inaccessible SMMU MMIO region, incorrect device tree SMMU register base address, or hardware/firmware issue preventing SMMU register access during early boot.
3. Possible fix: Verify the SMMU device tree node register base addresses and ranges match the qcs9100 hardware specification; check that SMMU power/clock domains are enabled before driver probe; if the PR introduced SMMU DT changes, revert and validate; otherwise, this is a pre-existing platform/firmware issue — check bootloader/TZ firmware versions and SMMU hardware initialization state.
4. Detail analysis attachment: failed_case_job212442_3_detailed.md

  Case 4: Kernel Crash — SMMU synchronous external abort during S2CR register write

1. Failed case: Kernel Crash — SMMU synchronous external abort during S2CR register write
2. Root cause: Synchronous external abort (bus error) at PC qcom_smmu_write_s2cr+0x84/0x140 during SMMU device probe on qcs9100-ride; the SMMU driver attempted to write to an S2CR register at an invalid or unpowered MMIO address (base + offset 0xc28), triggering a hardware bus fault that escalated to kernel panic.
3. Possible fix: Verify SMMU device tree node for qcs9100-ride has correct reg property mapping all required SMMU register banks; confirm SMMU power domain is enabled before driver probe; if PR introduces SMMU DT or driver changes, revert and validate base SMMU functionality on this SoC first.
4. Detail analysis attachment: failed_case_job212442_4_detailed.md

Job 212443 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — Benign firmware load warning (not a genuine failure)

1. Failed case: Probe_Failure_Check — Benign firmware load warning (not a genuine failure)
2. Root cause: The Probe_Failure_Check test flagged a cfg80211 regulatory.db firmware load failure (error -2 = file not found) that occurred during boot. This is a benign, expected condition on systems without the optional regulatory.db file installed. The kernel falls back to built-in regulatory rules, and WiFi functionality is unaffected (confirmed by passing WiFi_Firmware_Driver and WiFi_OnOff tests). This is not a PR-introduced regression.
3. Possible fix: Suppress this specific regulatory.db failure in the Probe_Failure_Check test logic, as it is a known benign condition when WiFi functional tests pass. Alternatively, install the wireless-regdb package in the test rootfs to provide the regulatory.db file and eliminate the warning.
4. Detail analysis attachment: failed_case_job212443_1_detailed.md

  Case 2: smmu (Test Logic False Positive)

1. Failed case: smmu (Test Logic False Positive)
2. Root cause: The smmu test incorrectly expects video-decoder and video-encoder to be separate platform devices with individual IOMMU group attachments. On qcs615-ride, the Venus video codec driver uses a single parent device (aa00000.video-codec) that is correctly attached to IOMMU group 7, with video-decoder and video-encoder as child nodes within the driver, not separate platform devices requiring their own IOMMU groups.
3. Possible fix: Update the smmu test logic to recognize that Venus video codec child nodes (video-decoder/video-encoder) do not require separate IOMMU group attachments when the parent video-codec device is correctly protected. The test should pass when aa00000.video-codec is attached to an IOMMU group, regardless of child node attachment status.
4. Detail analysis attachment: failed_case_job212443_2_detailed.md

  Case 3: KVM Driver Initialization Failure

1. Failed case: KVM Driver Initialization Failure
2. Root cause: KVM driver cannot initialize on QCS615-ride because the Gunyah hypervisor is running at EL2 and does not expose nested virtualization support. KVM requires direct EL2 access to create VMs, but the kernel is running as a Gunyah guest at EL1 without virtual EL2 capability.
3. Possible fix: This is an expected platform limitation, not a PR-introduced regression. To resolve: (1) Disable CONFIG_KVM in the kernel config for QCS615 builds running under Gunyah, or (2) Add KVM test skip logic for platforms with active hypervisors, or (3) Enable nested virtualization support in Gunyah firmware (requires hypervisor changes, not kernel changes).
4. Detail analysis attachment: failed_case_job212443_3_detailed.md

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

1. Failed case: ** KVM Initialization Failure — HYP mode not available
2. Root cause: ** KVM driver initialization failed on qcs615-ride because the Gunyah hypervisor is already running at EL2 (Hypervisor mode), preventing KVM from acquiring the required exclusive access to EL2. This is a platform architecture constraint where only one hypervisor can control EL2 at a time.
3. Possible fix: Mark KVM tests as SKIP (not FAIL) on qcs615-ride and other Gunyah-enabled platforms. Update the test runner to detect Gunyah presence via dmesg | grep "Hypervisor cold boot" and skip KVM tests with reason "Platform runs Gunyah hypervisor — KVM unavailable". Alternatively, create a qcs615-ride-specific test configuration that excludes KVM tests entirely.
4. Detail analysis attachment: failed_case_job212443_4_detailed.md

  Case 5: KVM Infrastructure Unavailable — Platform Configuration Issue

1. Failed case: KVM Infrastructure Unavailable — Platform Configuration Issue
2. Root cause: QCS615-ride platform runs Gunyah hypervisor in protected mode which reserves EL2 (Hypervisor Exception Level) exclusively for Gunyah, preventing Linux KVM from initializing. Kernel message at boot: kvm [1]: HYP mode not available. This is expected behavior on Gunyah-based platforms and not a kernel regression.
3. Possible fix: Disable KVM-dependent tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) in the LAVA test suite for qcs615-ride and other Gunyah-based platforms, or mark them as expected failures with a skip condition checking for Gunyah hypervisor presence. KVM cannot function on platforms where a Type-1 hypervisor (Gunyah) has taken exclusive control of EL2.
4. Detail analysis attachment: failed_case_job212443_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because the QCS615 Ride board is running under the Gunyah hypervisor (version gunyah-cdfb73831), which operates at EL2 and does not expose HYP mode to Linux. The kernel message "kvm [1]: HYP mode not available" confirms Linux cannot access EL2, preventing KVM driver initialization and /dev/kvm creation.
3. Possible fix: This is expected behavior for the current platform configuration and not a PR-introduced regression. To enable KVM testing: (1) reconfigure the board firmware to boot Linux directly at EL2 without Gunyah, or (2) use nested virtualization if Gunyah supports it, or (3) skip KVM tests on boards running under Gunyah by adding a platform-specific test filter in the LAVA job definition.
4. Detail analysis attachment: failed_case_job212443_6_detailed.md

Job 212444 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug at line 75 of run.sh — script hardcodes assumption of 8 CPUs and attempts to parse interrupt counts for CPUs 4-7 from /proc/interrupts, but shikra-iqs-evk has only 4 CPUs (0-3), causing bash integer comparison to fail with "GICv3: integer expected" when it extracts non-numeric column values (device name strings) instead of interrupt counts.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an 8-CPU assumption, then iterate only over the actual CPU count when parsing /proc/interrupts columns.
4. Detail analysis attachment: failed_case_job212444_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The Probe_Failure_Check test detected multiple probe failures on shikra-iqs-evk, including coresight-etm4x (error -22/EINVAL) for all four ETM instances, cpufreq-dt (error -17/EEXIST), regulatory.db firmware load failure (error -2/ENOENT), and persistent deferred probes for sound/audio codec/WiFi devices. The coresight-etm4x failures are pre-existing platform/DT issues unrelated to the PR (which only refactors PM save/restore logic without changing probe error paths); the cpufreq-dt -EEXIST is a known benign duplicate registration; the regulatory.db firmware absence is expected in minimal rootfs; and the deferred probes indicate missing DT resources (clocks, regulators, DAI links) that are board-specific configuration gaps, not PR-introduced regressions.
3. Possible fix: Mark this test case as expected-fail or suppress known benign probe failures (coresight-etm4x -EINVAL on shikra due to missing DT cpu property, cpufreq-dt -EEXIST duplicate, regulatory.db -ENOENT in minimal rootfs) in the Probe_Failure_Check test logic. For the coresight-etm4x issue specifically: add the missing "cpu" property to the ETM DT nodes in arch/arm64/boot/dts/qcom/shikra*.dtsi, following the pattern used in other Qualcomm SoC device trees (e.g., sc8280xp.dtsi shows cpu = <&CPU0>; for etm@7040000).
4. Detail analysis attachment: failed_case_job212444_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller driver (dwc3/xhci) did not probe on the shikra-iqs-evk platform. The USB device node at 4e00000.usb is present in device tree and added to IOMMU group 5, but no USB host controller driver initialization messages appear in the kernel log. USB core subsystem registered successfully (usbcore, usbfs, hub, usb-storage, usbhid), but without a functioning host controller driver, no USB devices can be enumerated. This is not a PR-introduced regression but rather a pre-existing platform configuration or driver availability issue specific to the shikra-iqs-evk board.
3. Possible fix: Verify that the USB host controller driver (CONFIG_USB_DWC3, CONFIG_USB_DWC3_QCOM, CONFIG_USB_XHCI_HCD) is enabled in the kernel configuration and built as a module or built-in. Check the device tree for the shikra-iqs-evk board to ensure the USB node at 4e00000.usb has the correct compatible string and all required properties (clocks, resets, PHY phandles, power domains). If the driver is present but not probing, enable dynamic debug for the dwc3 and xhci drivers (echo 'module dwc3 +p' > /sys/kernel/debug/dynamic_debug/control) and check dmesg for deferred probe or missing dependency messages.
4. Detail analysis attachment: failed_case_job212444_3_detailed.md

  Case 4: ** KVM_Driver — Driver Initialization Failure

1. Failed case: ** KVM_Driver — Driver Initialization Failure
2. Root cause: ** KVM driver initialization failed at boot because the platform (Shikra IQS EVK) does not support ARM Hypervisor mode (EL2). The kernel message kvm [1]: HYP mode not available at boot time (3.291957s) indicates the CPU is not running at EL2 or EL2 is disabled by firmware/bootloader, preventing KVM from creating the /dev/kvm device node. This is a platform/firmware limitation, not a kernel regression.
3. Possible fix: This is NOT a PR-introduced regression. The Shikra IQS EVK platform does not support KVM virtualization because EL2 (hypervisor mode) is not available. The test should be marked as SKIP (not FAIL) for this platform, or the platform firmware should be updated to enable EL2 if the hardware supports it. To fix the test: update the test suite to detect HYP mode not available in dmesg and report SKIP instead of FAIL for platforms without EL2 support.
4. Detail analysis attachment: failed_case_job212444_4_detailed.md

  Case 5: ** Kernel Crash — Synchronous External Abort in qcom_rng driver (KVM_EL2_DTB is a secondary victim)

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver (KVM_EL2_DTB is a secondary victim)
2. Root cause: ** The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at qcom_rng_read+0xc4 when attempting to read from the Qualcomm hardware RNG MMIO registers on shikra-iqs-evk, causing a kernel panic and system reboot; KVM_EL2_DTB subsequently failed because it ran after the reboot and /dev/kvm was not available in the post-crash state.
3. Possible fix: Investigate and fix the qcom_rng hardware access issue on shikra-iqs-evk: verify RNG hardware clock/power-domain/regulator dependencies in the device tree, ensure the RNG hardware block is properly initialized by firmware, and add proper error handling in the qcom_rng driver to gracefully handle hardware access failures instead of crashing the kernel; as a short-term mitigation, skip the qcom_hwrng test on shikra-iqs-evk until the hardware access issue is resolved.
4. Detail analysis attachment: failed_case_job212444_5_detailed.md

  Case 6: ** Kernel Crash — qcom_rng synchronous external abort (KVM_Infra test failure is non-fatal pre-existing issue)

1. Failed case: ** Kernel Crash — qcom_rng synchronous external abort (KVM_Infra test failure is non-fatal pre-existing issue)
2. Root cause: ** The KVM_Infra test failure (/dev/kvm is not available) is a pre-existing infrastructure/configuration issue unrelated to PR Merge tag 'v6.18.44' into qcom-6.18.y #970 — CONFIG_KVM is enabled but the KVM device node was never created, indicating KVM initialization failed silently. However, the actual fatal issue is a kernel crash in the qcom_rng driver that occurred immediately after the KVM_Infra test. The crash is a synchronous external abort (hardware bus error ESR 0x96000010) at PC qcom_rng_read+0xc4/0x228 when the qcom_hwrng test attempted to read entropy from /dev/hwrng. The faulting instruction attempted to read hardware register at MMIO offset 0x35c, but the qcom_rng hardware block did not respond, indicating it is unpowered, not clocked, held in reset, or its MMIO region is not correctly mapped on Shikra IQS EVK.
3. Possible fix: Immediate mitigation: disable the qcom_hwrng test on Shikra IQS EVK or blacklist the qcom_rng module. Proper fix: verify the qcom_rng device tree node for Shikra IQS EVK includes correct clock, regulator, and reset bindings; ensure the RNG hardware block is powered and clocked before driver probe; add runtime PM support if missing. If the hardware block is not present or not functional on this platform, remove the DT node or set status = "disabled". The KVM_Infra test failure should be investigated separately as a pre-existing infrastructure issue.
4. Detail analysis attachment: failed_case_job212444_6_detailed.md

  Case 7: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The qcom_rng driver triggered a synchronous external abort (bus error) at PC qcom_rng_read+0xc4 when attempting to read from a hardware register at offset 0x0c (instruction b940035c = ldr w28, [x26, #0xc]). This indicates the RNG hardware block is either not clocked/powered, not mapped correctly, or the hardware is in an unexpected state on the shikra-iqs-evk platform.
3. Possible fix: Verify the qcom_rng device tree node for shikra (sm8750) includes correct register base address, clock references, and power domain bindings. Check if the RNG hardware block requires explicit clock/power enablement before register access. Add runtime PM or clock enable calls in the qcom_rng driver probe path if missing. If the hardware is not present or functional on shikra-iqs-evk, mark the DT node as status = "disabled" for this board variant.
4. Detail analysis attachment: failed_case_job212444_7_detailed.md

  Case 8: ** Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: ** Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: ** Hardware access fault (synchronous external abort) in qcom_rng_read() at offset +0xc4 while reading from the Qualcomm hardware RNG device during the qcom_hwrng test. The fault occurred when dereferencing a hardware register address (x19: 0x000000b9dc505f3a), triggering a paging request failure in EFI runtime service context, followed by kernel panic. This is a pre-existing platform/firmware issue unrelated to the PR (PR touches I3C, cpufreq docs, ARM64 CPU hotplug docs, crypto userspace API, and RNG core exit handler — none of which affect qcom_rng hardware access paths on shikra-iqs-evk).
3. Possible fix: This is a known shikra-iqs-evk platform issue with EFI runtime services and hardware RNG access. Workaround: Add efi=noruntime to kernel command line to disable EFI runtime services, or disable the qcom_hwrng test in the CI test suite for this platform until the firmware/hardware issue is resolved. The PR is not the cause and should not be blocked by this failure.
4. Detail analysis attachment: failed_case_job212444_8_detailed.md

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

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware fault) at PC qcom_rng_read+0xc4 when reading from the hardware RNG device. The fault occurred during a memory access (b940035c instruction) to the RNG hardware registers, indicating the RNG hardware block is either not powered, not clocked, or the MMIO mapping is invalid on the shikra-iqs-evk platform.
3. Possible fix: Verify the qcom_rng device tree node for shikra-iqs-evk includes correct reg address, clocks, and power-domain properties. If the RNG hardware is not functional on this SoC variant, mark the DT node as status = "disabled" or add a runtime probe-time check in the qcom_rng driver to gracefully skip initialization when the hardware is not accessible.
4. Detail analysis attachment: failed_case_job212444_9_detailed.md

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

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware access fault (synchronous external abort 0x96000010) in qcom_rng_read() at PC offset +0xc4 when reading from MMIO register during qcom_hwrng test execution; the qcom_rng driver attempted to read from an unmapped, powered-off, or inaccessible hardware RNG register, triggering a bus-level external abort that escalated to kernel panic.
3. Possible fix: Verify qcom_rng device power state and clock enablement before MMIO access; add runtime PM calls or clock gating checks in qcom_rng probe/read paths; if the hardware block is not present or not functional on shikra-iqs-evk, disable the qcom_rng driver in the device tree or kernel config for this platform; alternatively, add proper error handling for external aborts in the RNG read path to prevent system-wide panic.
4. Detail analysis attachment: failed_case_job212444_10_detailed.md

Job 212445 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Four PMIC temp-alarm devices (c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) remain in permanent deferred probe state on lemans-evk, indicating the qcom_spmi_temp_alarm driver loaded but failed to bind due to missing or unready dependencies (likely thermal zone or IIO channel dependencies not resolved).
3. Possible fix: Investigate why the qcom_spmi_temp_alarm driver (module is loaded) cannot complete probe for these four PMIC thermal devices — check device tree for correct thermal-zone linkage, IIO ADC channel availability, and SPMI PMIC sub-device registration order; if DT is correct, enable CONFIG_DEBUG_DRIVER and add dynamic debug for drivers/thermal/qcom/qcom-spmi-temp-alarm.c to capture the exact -EPROBE_DEFER reason, then fix the missing dependency provider or adjust probe ordering.
4. Detail analysis attachment: failed_case_job212445_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device (aa00000.video-codec) is not attached to any IOMMU group, causing the SMMU test's critical master validation to fail. The device exists in the device tree but the driver either did not probe successfully or the device is not configured with IOMMU bindings in the device tree for the lemans-evk platform.
3. Possible fix: Verify the device tree for lemans-evk includes proper iommus property for the video-codec node at aa00000. If missing, add the IOMMU binding to the device tree. If present, investigate why the video codec driver (qcom_iris module is loaded) did not attach the device to an IOMMU group during probe.
4. Detail analysis attachment: failed_case_job212445_2_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed due to two individual test case failures within the test suite: (1) Probe_Failure_Check failed due to deferred probe issues with PMIC temp-alarm devices and missing firmware files (regulatory.db, Bluetooth firmware), and (2) smmu test failed because the video codec device (aa00000.video-codec) is missing iommu_group attachment on lemans-evk. The test runner completed successfully, but LAVA's standard behavior is to mark the overall test definition as failed when any constituent test case fails.
3. Possible fix: These are pre-existing platform/configuration issues unrelated to the PR content (which contains documentation updates, DT binding fixes, and driver changes not affecting lemans-evk PMIC thermal or video codec IOMMU configuration). For Probe_Failure_Check: investigate why PMIC temp-alarm devices remain in deferred probe state and ensure required firmware files are present in the rootfs. For smmu: verify the video codec DT node includes proper iommu property and that the IOMMU driver is loaded before the video codec driver probes. Re-run the CI job after fixing these platform-specific issues.
4. Detail analysis attachment: failed_case_job212445_3_detailed.md

[qlijarvis]

PR #970 — validate-patch

PR: #970

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: No — no lore.kernel.org link found in pr.patch
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — no upstream patch to check (appears to be a merge/integration commit)
4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #970 (qualcomm-linux/kernel)
Upstream commit: N/A
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	❌	No commit message found in patch
Body preserves rationale	❌	No commit message found in patch
Fixes tag present/correct	N/A	Not applicable
Authorship preserved	❌	No author information in patch
Backport note (if applicable)	N/A	Not applicable

Diff

File	Status	Notes
94,677 files changed	❌	Massive merge/integration commit with no commit metadata

Issues

Critical validation failures:

1. No lore.kernel.org link found — The PR patch contains no Link: tag pointing to lore.kernel.org. According to the validate-patch skill, this is an immediate FAIL condition.

2. No commit metadata — The pr.patch file is a plain unified diff with no git commit message, author, date, or any metadata. This makes it impossible to validate:

   • Commit subject/prefix correctness
   • Authorship preservation
   • Signed-off-by chain
   • Commit message rationale

3. Massive scope — The patch modifies 94,677 files across the entire kernel tree, including:

   • Core Makefile (version bump)
   • Documentation across all subsystems
   • MAINTAINERS file
   • Drivers for all architectures (arm, arm64, alpha, etc.)
   • Device tree files for multiple vendors
   • Configuration files

   This appears to be a mainline merge or rebase commit, not a targeted patch suitable for lore-based validation.

4. Integration presence: PARTIAL — According to integration_presence_report.md, the commit has only partial tree presence in qcom-next and topics:

   • 1,118,832 added lines checked
   • 41,943 lines missing from qcom-next
   • 41,877 lines missing from topics/baseline
   • Missing samples include core files like Makefile, MAINTAINERS, and various subsystem files

Verdict

Do not merge. This PR cannot be validated using the validate-patch skill for the following reasons:

1. No lore link — The validate-patch skill explicitly requires a lore.kernel.org link in the PR description or commit message. Without this, there is no upstream source to compare against.

2. Wrong validation tool — A 94,677-file merge commit is not a patch that should be validated against lore.kernel.org. This type of integration commit requires different validation:

   • If this is a mainline merge: verify the merge base and conflict resolution
   • If this is an automerge/integration: use the integrate-qli or automerge skill
   • If this is a rebase: verify the rebase was clean and no unintended changes were introduced

3. Incomplete integration — The commit is only partially present in qcom-next/topics, with ~42K lines missing. This suggests the integration is incomplete or the PR contains changes not yet in the integration branches.

Recommended action:

• If this is a mainline merge: Add a proper commit message with Merge tag 'v6.X' into <branch> format
• If this is an integration commit: Use the appropriate integration workflow and validation tools
• If this is a mistake: Close the PR and create properly formatted, atomic commits with lore links for each logical change

Final Summary

1. Lore link present: No — no lore.kernel.org link found in pr.patch
2. Lore link matches PR commits: N/A — no lore link to compare against
3. Upstream patch status: N/A — no upstream patch to check (appears to be a merge/integration commit)
4. PR present in qcom-next/topics: Partial — 1/1 commit has only partial integration evidence (41,943 lines missing from qcom-next, 41,877 lines missing from topics/baseline)

Deterministic Integration Presence

Integration Presence Report

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

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

Commit	Subject	qcom-next	topics	Final
1/1	``	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

Final Status

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

[qlijarvis]

PR #970 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	Multiple "Unknown commit id" warnings (expected for stable backports)
dt-binding-check	✅	All binding checks passed
dtb-check	❌	New errors: Allwinner A523 pinctrl interrupts array too long; Nvidia Tegra234 MGBE missing 'ptp-ref' clock-name
sparse-check	✅	Passed
check-uapi-headers	❌	Multiple "fatal: path exists on disk, but not in base" errors (new files added in stable update)
check-patch-compliance	❌	3297 commits missing required subject prefix
tag-check	❌	BLOCKER: All 3297 commits lack required prefix tags

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #970 (Linux 6.18.44 stable update)
Target branch: qcom-6.18.y
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/32819697883

Checker	Result	Summary
checkpatch	❌	Multiple "Unknown commit id" warnings (expected for stable backports)
dt-binding-check	✅	All binding checks passed
dtb-check	❌	New errors: Allwinner A523 pinctrl interrupts array too long; Nvidia Tegra234 MGBE missing 'ptp-ref' clock-name
sparse-check	✅	Passed
check-uapi-headers	❌	Multiple "fatal: path exists on disk, but not in base" errors (new files added in stable update)
check-patch-compliance	❌	3297 commits missing required subject prefix
tag-check	❌	BLOCKER: All 3297 commits lack required prefix tags

---

❌ check-patch-compliance — Missing Subject Prefix (BLOCKER)

Root cause: All 3297 commits in this PR lack the required subject-line prefix tag.

Failure details:

Checking commit: KVM: x86: Fix shadow paging use-after-free due to unexpected role
Commit summary does not start with a required prefix

Checking commit: lsm: add backing_file LSM hooks
Commit summary does not start with a required prefix

Checking commit: selinux: fix overlayfs mmap() and mprotect() access checks
Commit summary does not start with a required prefix

... (3297 total commits)

Why this is failing:
The target branch is qcom-6.18.y, which is not qcom-next or qcom-next-staging. Per the kernel-checkers policy, every commit merged into branches other than qcom-next/qcom-next-staging must start its subject line with one of the following prefix tags:

• UPSTREAM: — Patch merged into Linus's mainline tree
• FROMLIST: — Patch posted to mailing list (lore.kernel.org)
• FROMGIT: — Patch taken from a maintainer git tree
• BACKPORT: — Upstream patch backported with modifications
• QCLINUX: — Vendor-only change with no upstream equivalent
• PENDING: — Work-in-progress, not yet posted upstream
• WORKAROUND: — Temporary fix not suitable for upstream

Context:
This PR appears to be a Linux 6.18.44 stable kernel update (based on the final commit "Linux 6.18.44" and the large number of commits). All commits in a stable kernel release are upstream patches, so they should be prefixed with UPSTREAM:.

Fix:
Rebase the entire PR and prepend UPSTREAM: to every commit subject:

# Interactive rebase to edit all commits
git rebase -i <base_sha>

# For each commit, amend the subject:
git commit --amend -m "UPSTREAM: <original subject>"
git rebase --continue

Alternative (automated):
Use a script to rewrite all commit messages in bulk:

git filter-branch -f --msg-filter '
  if ! echo "$GIT_COMMIT_MSG" | grep -qE "^(UPSTREAM|FROMLIST|FROMGIT|BACKPORT|QCLINUX|PENDING|WORKAROUND):"; then
    echo "UPSTREAM: $GIT_COMMIT_MSG"
  else
    cat
  fi
' <base_sha>..HEAD

Reproduce locally:

git log <base_sha>..HEAD --format="%H %s" | while read sha subject; do
  if ! echo "$subject" | grep -qE '^(UPSTREAM|FROMLIST|FROMGIT|BACKPORT|QCLINUX|PENDING|WORKAROUND):'; then
    echo "MISSING prefix: $sha $subject"
  fi
done

---

❌ dtb-check — New DTB Validation Errors

Root cause: Two new devicetree validation errors introduced by this PR.

Failure details:

Error 1: Allwinner A523 pinctrl interrupts array too long

/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dtb: 
  pinctrl@2000000 (allwinner,sun55i-a523-pinctrl): 
  interrupts: [[0, 67, 4], [0, 69, 4], [0, 71, 4], [0, 73, 4], [0, 75, 4], [0, 77, 4], [0, 79, 4], [0, 81, 4], [0, 83, 4], [0, 85, 4], [0, 140, 4]] is too long
  from schema $id: http://devicetree.org/schemas/pinctrl/allwinner,sun55i-a523-pinctrl.yaml

The allwinner,sun55i-a523-pinctrl binding schema limits the number of interrupt entries, but the DTS provides 11 interrupts. This is likely a binding schema issue where maxItems is set too low.

Error 2: Nvidia Tegra234 MGBE missing 'ptp-ref' clock-name

Multiple Tegra234 DTBs: ethernet@6800000 (nvidia,tegra234-mgbe): clock-names:3: 'ptp-ref' was expected

The nvidia,tegra234-mgbe binding expects a ptp-ref clock at index 3, but the DTS files do not provide it.

Fix:

For Error 1 (Allwinner A523):
Update the binding schema Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml to allow up to 11 interrupt entries:

interrupts:
  maxItems: 11  # or remove maxItems if variable

For Error 2 (Nvidia Tegra234):
Add the missing ptp-ref clock to all affected Tegra234 DTS files:

clocks = <&bpmp TEGRA234_CLK_MGBE0_APP>,
         <&bpmp TEGRA234_CLK_MGBE0_MAC>,
         <&bpmp TEGRA234_CLK_MGBE0_MAC_DIVIDER>,
         <&bpmp TEGRA234_CLK_MGBE0_PTP_REF>;  // Add this
clock-names = "rx", "tx", "mac", "ptp-ref";  // Add "ptp-ref"

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb

---

❌ check-uapi-headers — New Files Not in Base

Root cause: Multiple new files added in this stable update that do not exist in the base commit.

Failure details:

fatal: path 'drivers/gpu/Kconfig' exists on disk, but not in 'dc0f4d4280a7ecfcf8bc2d6bff1f42b1b8d33b08'
fatal: path 'drivers/gpu/buddy.c' exists on disk, but not in 'dc0f4d4280a7ecfcf8bc2d6bff1f42b1b8d33b08'
fatal: path 'drivers/gpu/drm/xe/xe_pagefault.c' exists on disk, but not in 'dc0f4d4280a7ecfcf8bc2d6bff1f42b1b8d33b08'
... (multiple files)

Analysis:
This is expected behavior for a stable kernel update that introduces new files. The check-uapi-headers checker compares the current tree against the base commit and flags new files. Since this is a 6.18.44 stable update, new files are legitimate additions from upstream.

Verdict: This is not a blocker — it's expected for stable updates. The checker is correctly identifying new files; no action needed.

---

⚠️ checkpatch — Unknown Commit ID Warnings

Root cause: Checkpatch reports "Unknown commit id" warnings for commits referenced in commit messages.

Failure details:

WARNING: Unknown commit id 'fb0bf289f5d529336ef490c8273e88a8a8b29f69', maybe rebased or not pulled?
WARNING: Unknown commit id '7aa7d4bf9d3f', maybe rebased or not pulled?
WARNING: Duplicate signature

Analysis:
These warnings occur because:

1. The referenced commits exist in upstream Linux but not in the current tree's history (expected for stable backports).
2. Some commits have duplicate Signed-off-by: trailers (e.g., Greg Kroah-Hartman signing both as author and stable maintainer).

Verdict: These are informational warnings, not blockers. Stable kernel updates routinely reference upstream commits that aren't in the tree's direct history. The duplicate signature warnings are also acceptable for stable releases where the maintainer adds their sign-off.

---

Verdict

BLOCKER: Cannot merge until all 3297 commits are prefixed with UPSTREAM:

The PR contains a Linux 6.18.44 stable kernel update with 3297 commits, all of which lack the required subject-line prefix tag. Since the target branch is qcom-6.18.y (not qcom-next or qcom-next-staging), every commit must start with a valid prefix.

Required action:
Rebase the entire PR and prepend UPSTREAM: to every commit subject line.

Secondary issues (non-blocking but should be addressed):

• dtb-check: Fix Allwinner A523 pinctrl binding schema and add missing Tegra234 MGBE ptp-ref clocks.
• check-uapi-headers: New files are expected for stable updates; no action needed.
• checkpatch: "Unknown commit id" warnings are expected for stable backports; no action needed.