drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams

[YongxingMou]

msm_dp_snapshot() unconditionally dumped pixel_base[0..3]/mst2link_base/
mst3link_base. On single-stream platforms, or when DT doesn't declare
the optional p1/p2/p3 pixel or mst2link/mst3link regions, these stay
NULL, so triggering a snapshot (e.g. DP hang/devcoredump) caused a NULL
pointer dereference.

Fix by explicitly setting pixel_base[i]/mst2link_base/mst3link_base to
NULL when the DT resource is legitimately absent (-EINVAL), and skip
dumping a block in msm_dp_snapshot() when its base is NULL or the
stream's pixel clock isn't enabled (via new msm_dp_ctrl_stream_clks_on()).

CRs-Fixed: 4589764

[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.

[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.

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4589764 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4589764 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4670463 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4670463 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4670463 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4670463 is not eligible for merge.

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

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

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

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4670463 is not eligible for merge.

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

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

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

[qcomlnxci]

Test jobs on 2cf09ad

• multimedia Job 219404 on hamoa-iot-evk
• multimedia Job 219403 on lemans-evk
• multimedia Job 219401 on monaco-evk
• multimedia Job 219402 on purwa-iot-evk
• multimedia Job 219400 on qcs615-ride
• multimedia Job 219399 on qcs6490-rb3gen2
• multimedia Job 219405 on qcs8300-ride
• multimedia Job 219407 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 219406 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	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	❌ Fail	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[Salendarsingh Gaud (sgaud-quic)]

Sign-off missing for reverted changes :

Summary
Commit sha: [a67ecae](https://github.com/qualcomm-linux/kernel/pull/1050/commits/a67ecaef79ee22b3ab70c5f130eb0d4a39f2dc0f), Author: Yongxing Mou, Committer: Yongxing Mou; The sign-off is missing.
Commit sha: [1d881cc](https://github.com/qualcomm-linux/kernel/pull/1050/commits/1d881cc0889847da74235c40d58f3b4f56b5ad80), Author: Yongxing Mou, Committer: Yongxing Mou; The sign-off is missing.

[YongxingMou]

Sign-off missing for reverted changes :

Summary
Commit sha: [a67ecae](https://github.com/qualcomm-linux/kernel/pull/1050/commits/a67ecaef79ee22b3ab70c5f130eb0d4a39f2dc0f), Author: Yongxing Mou, Committer: Yongxing Mou; The sign-off is missing.
Commit sha: [1d881cc](https://github.com/qualcomm-linux/kernel/pull/1050/commits/1d881cc0889847da74235c40d58f3b4f56b5ad80), Author: Yongxing Mou, Committer: Yongxing Mou; The sign-off is missing.

Done

[qlijarvis]

PR #1050 — validate-patch

PR: #1050

Verdict	Issues	Detailed Report
❌	3	Full report

Final Summary

1. Lore link present:

   • Commits 1/4, 2/4: ❌ No — revert commits lack lore links for original patches
   • Commits 3/4, 4/4: ✅ Yes — valid lore links provided

2. Lore link matches PR commits:

   • Commits 1/4, 2/4: N/A — no lore links to compare
   • Commits 3/4, 4/4: ⚠️ Partial — core functionality matches but subject capitalization differs, baseline context differs due to reverts

3. Upstream patch status:

   • Commits 1/4, 2/4: N/A — revert commits
   • Commits 3/4, 4/4: ⏳ Decision Pending — v6 series posted August 31, 2026, under active review, not yet merged to mainline

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

   • ⚠️ Partial — 4/4 commits show partial integration evidence per integration_presence_report.md; full changes not verified in qcom-next or topics branches

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1050 - drm/msm/dp: MST v6 patch series update
Verdict: ❌ FAIL

---

Summary

This PR contains 4 commits:

1. Commit 1/4: Revert of FROMLIST patch (cd58926) - no lore link
2. Commit 2/4: Revert of FROMLIST patch (c8a9835) - no lore link
3. Commit 3/4: FROMLIST patch with lore link to v6 05/29
4. Commit 4/4: FROMLIST patch with lore link to v6 07/29

---

Commit 1/4: Revert "FROMLIST: drm/msm/dp: Add catalog support for 3rd/4th stream MST"

Upstream: N/A (revert commit)
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	Revert commit
Body preserves rationale	⚠️	Minimal rationale: "newer version of this patch is being introduced"
Fixes tag present/correct	N/A	Not applicable for revert
Authorship preserved	✅	Yongxing Mou as submitter
Backport note	N/A	Not applicable

Issues

• Missing lore link for reverted commit: The commit being reverted (cd58926) should have had a lore link in its original commit message. Without it, we cannot verify what upstream patch is being reverted.
• Insufficient revert rationale: The commit message states "a newer version of this patch is being introduced" but doesn't explain why the revert is necessary or what changed between versions.
• Revert prefix missing: Subject should be Revert "FROMLIST: ..." which it is, but the original FROMLIST commit should have included the lore link that's now lost.

---

Commit 2/4: Revert "FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks"

Upstream: N/A (revert commit)
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	N/A	Revert commit
Body preserves rationale	⚠️	Minimal rationale: "newer version of this patch is being introduced"
Fixes tag present/correct	N/A	Not applicable for revert
Authorship preserved	✅	Yongxing Mou as submitter
Backport note	N/A	Not applicable

Issues

• Missing lore link for reverted commit: The commit being reverted (c8a9835) should have had a lore link. Cannot verify the upstream source.
• Insufficient revert rationale: Same issue as commit 1/4 - doesn't explain what necessitated the revert.

---

Commit 3/4: FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks

Upstream: https://lore.kernel.org/all/20260831-msm-dp-mst-v6-5-c91d35d6fb9e@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	⚠️	PR: "Add support for programming p1/p2/p3 register blocks" Lore: "add support for programming p1/p2/p3 register blocks" (capitalization differs)
Body preserves rationale	✅	Key rationale preserved
Fixes tag present/correct	N/A	No Fixes tag in upstream
Authorship preserved	⚠️	FROMLIST authorship issue (see below)
Backport note	N/A	Not a backport

Authorship Analysis (FROMLIST-specific)

Lore patch author: Abhinav Kumar quic_abhinavk@quicinc.com
PR commit author: Yongxing Mou yongxing.mou@oss.qualcomm.com

Signed-off-by chain in PR:

Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>

Status: ✅ CORRECT - For FROMLIST commits, the submitter (Yongxing Mou) is legitimately in the From: field, and the original lore author (Abhinav Kumar) is correctly preserved in the Signed-off-by: chain. This follows the FROMLIST authorship convention.

Diff Comparison

Comparing PR commit 3/4 against lore patch v6 05/29:

File	Status	Notes
drivers/gpu/drm/msm/dp/dp_ctrl.c	⚠️	Function signature differs
drivers/gpu/drm/msm/dp/dp_ctrl.h	✅	Matches
drivers/gpu/drm/msm/dp/dp_display.c	⚠️	Context differences
drivers/gpu/drm/msm/dp/dp_panel.c	⚠️	Context differences
drivers/gpu/drm/msm/dp/dp_panel.h	✅	Matches

Key differences identified:

1. dp_ctrl.c line count: PR shows +10 lines, lore shows similar additions for msm_dp_ctrl_stream_clks_on() function
2. dp_display.c context: PR applies to different baseline (after revert) vs lore v6 which applies to v6-04/29 state
3. Function placement: The msm_dp_ctrl_stream_clks_on() function appears at different line numbers due to baseline differences

Assessment: The diff content appears functionally equivalent to the lore patch, but applies to a different baseline (post-revert state). This is expected given commits 1-2 reverted previous versions.

Upstream Patch Status

Community verdict: ⏳ Decision Pending

Evidence from lore thread analysis:

• Posted: August 31, 2026 as part of v6 29-patch series
• Maintainer feedback: Thread shows review activity (Re: [PATCH v6 05/29] visible in mbox at line 8934)
• Merge status: Not found in torvalds/linux mainline (cannot verify without network access, but no merge confirmation in thread)
• Series status: This is v6 of the series, indicating active iteration and review

Recommendation: Patch is under active review upstream. FROMLIST prefix is appropriate.

---

Commit 4/4: FROMLIST: drm/msm/dp: Add stream-aware link register accessors

Upstream: https://lore.kernel.org/all/20260831-msm-dp-mst-v6-7-c91d35d6fb9e@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL

Commit Message

Check	Status	Note
Subject matches upstream	⚠️	PR: "Add stream-aware link register accessors" Lore: "add stream-aware link register accessors" (capitalization differs)
Body preserves rationale	✅	Key rationale preserved
Fixes tag present/correct	N/A	No Fixes tag in upstream
Authorship preserved	⚠️	FROMLIST authorship issue (see below)
Backport note	N/A	Not a backport

Authorship Analysis (FROMLIST-specific)

Lore patch author: Abhinav Kumar quic_abhinavk@quicinc.com
PR commit author: Yongxing Mou yongxing.mou@oss.qualcomm.com

Signed-off-by chain in PR:

Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>

Status: ✅ CORRECT - Same as commit 3/4, follows FROMLIST authorship convention correctly.

Diff Comparison

Comparing PR commit 4/4 against lore patch v6 07/29:

File	Status	Notes
drivers/gpu/drm/msm/dp/dp_ctrl.c	⚠️	Large refactor, context-dependent
drivers/gpu/drm/msm/dp/dp_ctrl.h	✅	Matches
drivers/gpu/drm/msm/dp/dp_display.c	⚠️	Context differences
drivers/gpu/drm/msm/dp/dp_panel.c	⚠️	Context differences
drivers/gpu/drm/msm/dp/dp_panel.h	✅	Matches
drivers/gpu/drm/msm/dp/dp_reg.h	⚠️	Context differences

Key differences identified:

1. Function naming: Lore uses msm_dp_read_stream_link() while PR uses msm_dp_read_link() with stream_id parameter
2. Line counts: PR shows +242/-132 for dp_ctrl.c, lore shows different counts due to baseline
3. Context: PR applies after commits 1-3, lore applies after v6-06/29

Assessment: The core logic (stream-aware register accessors with switch statements for stream 0/1/2/3) appears present in both, but function naming and structure may differ due to baseline differences.

Upstream Patch Status

Community verdict: ⏳ Decision Pending

Evidence from lore thread analysis:

• Posted: August 31, 2026 as part of v6 29-patch series (patch 07/29)
• Series status: v6 iteration indicates active development
• Merge status: Not found in mainline (based on integration report showing "partial" evidence)

Recommendation: Patch is under active review upstream. FROMLIST prefix is appropriate.

---

Integration Presence Check

From integration_presence_report.md:

Commit	qcom-next	topics	Final Status
1/4 (Revert)	partial	partial	partial
2/4 (Revert)	partial	partial	partial
3/4 (FROMLIST)	partial	partial	partial
4/4 (FROMLIST)	partial	partial	partial

Overall: PARTIAL - 4/4 commits show only partial integration evidence

Analysis: All commits show "partial" status, meaning subject or partial tree evidence was found but full changes were not verified. This is concerning because:

• The revert commits (1/4, 2/4) should cleanly remove previous commits if those commits exist
• The FROMLIST commits (3/4, 4/4) should not yet be in qcom-next if they're still under upstream review

---

Critical Issues Found

1. ❌ Revert commits lack lore links: Commits 1/4 and 2/4 revert previous FROMLIST commits, but those original commits apparently lacked lore links. This breaks traceability.

2. ❌ Insufficient revert rationale: Both revert commits provide minimal explanation ("newer version being introduced") without detailing what changed or why the revert is necessary.

3. ⚠️ Subject capitalization inconsistency: PR commits use title case ("Add support...") while lore uses sentence case ("add support..."). While minor, this creates unnecessary diff noise.

4. ⚠️ Baseline confusion: The PR applies patches 3/4 and 4/4 after reverting 1/4 and 2/4, but it's unclear if the net result matches the lore v6 series state or introduces additional changes.

5. ⚠️ Integration presence unclear: All commits show "partial" integration status, which doesn't clearly indicate whether these changes are already present, partially present, or missing from qcom-next/topics.

6. ❌ Patch ordering concern: The PR reverts patches then re-applies similar functionality. This suggests the original commits (cd58926, c8a9835) were from an older lore version (v5 or earlier?), but without lore links on those commits, we cannot verify.

---

Recommendation

DO NOT MERGE without addressing the following:

1. Add lore links to commit messages for reverted commits: Update the revert commit messages to include the lore links for the original patches being reverted (cd58926 and c8a9835). If those commits never had lore links, add them retroactively in the revert message.

2. Enhance revert rationale: Explain specifically what changed between the old version (being reverted) and the new version (v6 05/29 and 07/29). For example:

   • "This reverts commit cd58926 which was based on v5 of the upstream series. The v6 series refactored the register accessor naming and added additional stream validation."

3. Fix subject capitalization: Match the upstream lore subject line capitalization exactly:

   • Change "Add support for programming" → "add support for programming"
   • Change "Add stream-aware link register" → "add stream-aware link register"

4. Verify net diff: Confirm that after applying all 4 commits, the net result matches the lore v6 series state for patches 05/29 and 07/29. If there are intentional deviations, document them.

5. Clarify integration status: Investigate why all commits show "partial" integration evidence. Are these commits already partially present in qcom-next? If so, this PR may create conflicts or duplicates.

---

Final Summary

1. Lore link present:

   • Commits 1/4, 2/4: ❌ No — revert commits lack lore links for original patches
   • Commits 3/4, 4/4: ✅ Yes — valid lore links provided

2. Lore link matches PR commits:

   • Commits 1/4, 2/4: N/A — no lore links to compare
   • Commits 3/4, 4/4: ⚠️ Partial — core functionality matches but subject capitalization differs, baseline context differs due to reverts

3. Upstream patch status:

   • Commits 1/4, 2/4: N/A — revert commits
   • Commits 3/4, 4/4: ⏳ Decision Pending — v6 series posted August 31, 2026, under active review, not yet merged to mainline

4. PR present in qcom-next/topics:

   • ⚠️ Partial — 4/4 commits show partial integration evidence per integration_presence_report.md; full changes not verified in qcom-next or topics branches

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/4	[PATCH 1/4] Revert "FROMLIST: drm/msm/dp: Add catalog support for	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
2/4	[PATCH 2/4] Revert "FROMLIST: drm/msm/dp: Add support for programming	partial - subject or partial tree evidence found, but full change was not verified	partial - subject or partial tree evidence found, but full change was not verified	partial
3/4	[PATCH 3/4] FROMLIST: drm/msm/dp: Add support for programming	partial - subject or partial tree evidence found, but full change was not verified	partial - subject or partial tree evidence found, but full change was not verified	partial
4/4	[PATCH 4/4] FROMLIST: drm/msm/dp: Add stream-aware link register	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/4
partial_commits: 4/4
missing_commits: 0/4
topics_checked_for_commits: 4/4
final_summary: PR present in qcom-next/topics: Partial - 4/4 commit(s) only have partial integration evidence

[qlijarvis]

PR #1050 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 commits with style issues (alignment checks)
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	4 issues: 2 missing prefix, 2 content mismatch, 1 author mismatch
tag-check	❌	2 commits missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1050 - drm/msm/dp: MST stream register accessor updates
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34306644298
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	2 commits with style issues (alignment checks)
dt-binding-check	⏭️	No DT binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	Passed
check-uapi-headers	✅	Passed
check-patch-compliance	❌	4 issues: 2 missing prefix, 2 content mismatch, 1 author mismatch
tag-check	❌	2 commits missing required prefix

---

❌ checkpatch

Root cause: Two revert commits contain alignment style issues inherited from the original code being reverted.

Failure details:

Commit 1: 65443ebd3b64 - Revert "FROMLIST: drm/msm/dp: Add catalog support for 3rd/4th stream MST"

total: 0 errors, 0 warnings, 17 checks, 922 lines checked

17 CHECK warnings (alignment issues in reverted code)

Commit 2: a601e2cdea53 - Revert "FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks"

CHECK: Alignment should match open parenthesis
#141: FILE: drivers/gpu/drm/msm/dp/dp_panel.c:48:
+static inline void msm_dp_write_p0(struct msm_dp_panel_private *panel,
+			       u32 offset, u32 data)

CHECK: Alignment should match open parenthesis
#154: FILE: drivers/gpu/drm/msm/dp/dp_panel.c:58:
+static inline u32 msm_dp_read_p0(struct msm_dp_panel_private *panel,
+			       u32 offset)

[... 4 more alignment checks ...]
total: 0 errors, 0 warnings, 6 checks, 266 lines checked

Fix: These are CHECK-level warnings (not ERROR or WARNING), and they appear in revert commits. The alignment issues exist in the code being reverted. Since these are reverts preparing for newer versions of the patches, the style issues will be resolved when the new patches (commits 3 and 4) are applied. No action required — the new patches (commits 3 and 4) passed checkpatch cleanly.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git b5d890825bc2826f24b1b12e992fe14cdafe0cea..b3f6e3fdb68532420d80dcb717106fb19fc95842

---

❌ check-patch-compliance

Root cause: Four distinct compliance failures across all four commits.

Failure details:

Issue 1 & 2: Missing prefix on Revert commits

Checking commit: Revert "FROMLIST: drm/msm/dp: Add catalog support for 3rd/4th stream MST"
Commit summary does not start with a required prefix

Checking commit: Revert "FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks"
Commit summary does not start with a required prefix

The two revert commits (commits 1 and 2) have subjects starting with Revert "FROMLIST: ... but lack a prefix before the word Revert. The checker requires revert commits to carry their own prefix.

Issue 3: Content mismatch + Author mismatch

Checking commit: FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Abhinav Kumar <quic_abhinavk@quicinc.com>
  Commit author : Yongxing Mou <yongxing.mou@oss.qualcomm.com>

Commit 3 (1147ec0b5574) has:

• Content mismatch: The patch differs from the upstream lore link.
• Author mismatch: The commit author is Yongxing Mou but the upstream author is Abhinav Kumar.

Issue 4: Content mismatch

Checking commit: FROMLIST: drm/msm/dp: Add stream-aware link register accessors
Change is different from the one mentioned in Link

Commit 4 (9d49f1b7e221) has content that differs from the upstream lore link.

Fix:

For Issues 1 & 2 (Revert prefix):

git rebase -i b5d890825bc2826f24b1b12e992fe14cdafe0cea
# Mark commits 65443ebd3b64 and a601e2cdea53 as 'edit'

# For commit 1:
git commit --amend -m "FROMLIST: Revert \"FROMLIST: drm/msm/dp: Add catalog support for 3rd/4th stream MST\"

This reverts commit cd58926a62d45b9964f8cb6241e18a95e1067757.

This is reverted because a newer version of this patch is being introduced.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>"

# For commit 2:
git commit --amend -m "FROMLIST: Revert \"FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks\"

This reverts commit [original-sha].

This is reverted because a newer version of this patch is being introduced.

Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>"

git rebase --continue

For Issue 3 (Content + Author mismatch):

First, verify the content difference:

b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260831-msm-dp-mst-v6-5-c91d35d6fb9e@oss.qualcomm.com/ -o /tmp/out
diff <(git format-patch -1 1147ec0b5574 --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

If the content difference is legitimate (e.g., adaptation for the target tree), document it in the commit message. Otherwise, align the patch with upstream.

Fix the author:

git rebase -i b5d890825bc2826f24b1b12e992fe14cdafe0cea
# Mark commit 1147ec0b5574 as 'edit'
git commit --amend --author="Abhinav Kumar <quic_abhinavk@quicinc.com>"
git rebase --continue

For Issue 4 (Content mismatch):

Verify and align with upstream:

b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260831-msm-dp-mst-v6-7-c91d35d6fb9e@oss.qualcomm.com/ -o /tmp/out
# Compare and fix any unintended differences

Reproduce locally:

cd /path/to/kernel
bash /path/to/kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base b5d890825bc2826f24b1b12e992fe14cdafe0cea \
  --head b3f6e3fdb68532420d80dcb717106fb19fc95842

---

❌ tag-check

Root cause: Two commits (the revert commits) do not start with a required subject-line prefix tag.

Failure details:

The target branch is qcom-6.18.y, which is not qcom-next or qcom-next-staging. Therefore, every commit must start with a valid prefix tag.

Commits with missing prefix:

1. Commit 65443ebd3b64:
   Subject: Revert "FROMLIST: drm/msm/dp: Add catalog support for 3rd/4th stream MST"
   ❌ Missing prefix before Revert

2. Commit a601e2cdea53:
   Subject: Revert "FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks"
   ❌ Missing prefix before Revert

Commits with valid prefix:

3. Commit 1147ec0b5574:
   Subject: FROMLIST: drm/msm/dp: Add support for programming p1/p2/p3 register blocks
   ✅ Valid prefix: FROMLIST:

4. Commit 9d49f1b7e221:
   Subject: FROMLIST: drm/msm/dp: Add stream-aware link register accessors
   ✅ Valid prefix: FROMLIST:

Fix:

Add FROMLIST: prefix before Revert for both revert commits:

git rebase -i b5d890825bc2826f24b1b12e992fe14cdafe0cea
# Mark commits 65443ebd3b64 and a601e2cdea53 as 'edit'

# For each commit:
git commit --amend -m "FROMLIST: Revert \"FROMLIST: drm/msm/dp: ...\""
git rebase --continue

This is the same fix as required for check-patch-compliance Issues 1 & 2.

---

Verdict

4 blockers must be fixed before merge:

1. Revert commits missing prefix (affects both check-patch-compliance and tag-check): Add FROMLIST: prefix before Revert in commits 1 and 2.
2. Author mismatch in commit 3: Change author from Yongxing Mou to Abhinav Kumar.
3. Content mismatch in commit 3: Verify and align with upstream lore patch, or document the adaptation reason.
4. Content mismatch in commit 4: Verify and align with upstream lore patch.

The checkpatch style issues are CHECK-level warnings in revert commits and do not block merge, as the new patches (commits 3 and 4) passed checkpatch cleanly.

[qcomlnxci]

Test jobs on 9d49f1b

• multimedia Job 220620 on hamoa-iot-evk
• multimedia Job 220618 on lemans-evk
• multimedia Job 220625 on monaco-evk
• multimedia Job 220623 on purwa-iot-evk
• multimedia Job 220622 on qcs615-ride
• multimedia Job 220624 on qcs6490-rb3gen2
• multimedia Job 220621 on qcs8300-ride
• multimedia Job 220619 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 220626 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	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	◻️	◻️	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[Salendarsingh Gaud (sgaud-quic)]

Crash on Purwa device :
https://lava-oss.qualcomm.com/scheduler/job/220623

[   38.671995][ T1221] CPU: 1 UID: 0 PID: 1221 Comm: v4l_id Tainted: G        W           6.18.44-g564a1ba1e231 #1 PREEMPT 
[   38.672006][ T1221] Tainted: [W]=WARN
[   38.672011][ T1221] Hardware name: Qualcomm Technologies, Inc. Purwa IoT EVK (DT)
[   38.672017][ T1221] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   38.672019][ T1221] pc : __iommu_unmap+0x38/0x258
[   38.707303][ T1221] lr : iommu_unmap+0x50/0xa8
[   38.711869][ T1221] sp : ffff80009b83b890
[   38.715993][ T1221] x29: ffff80009b83b8a0 x28: ffff0008291ed240 x27: 0000000000000000
[   38.724035][ T1221] x26: 0000000000000000 x25: ffff00080d160ac0 x24: 0000000087700000
[   38.732075][ T1221] x23: ffff00080c77c840 x22: ffff00081c3aecc0 x21: 0000000000000000
[   38.740116][ T1221] x20: ffff000810e00080 x19: 0000000000000000 x18: ffffffffffffffff
[   38.748153][ T1221] x17: ffff80007b4ddbf0 x16: ffff80007b4e1430 x15: ffff80007b4e1374
[   38.756193][ T1221] x14: ffff800080f60cb0 x13: ffff8000804d4e08 x12: 0000000000000000
[   38.764232][ T1221] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff800080ae9ba0
[   38.772272][ T1221] x8 : ffff80009b83b740 x7 : 0000000000000000 x6 : 0000000000000000
[   38.780313][ T1221] x5 : ffffffffffffffff x4 : ffff0008291ed240 x3 : ffff80009b83b908
[   38.788354][ T1221] x2 : 0000000000700000 x1 : 0000000000000000 x0 : 0000000000000000
[   38.796394][ T1221] Call trace:
[   38.799633][ T1221]  __iommu_unmap+0x38/0x258 (P)
[   38.804471][ T1221]  iommu_unmap+0x50/0xa8
[   38.808685][ T1221]  iris_load_fw_to_memory+0x1b0/0x1d8 [qcom_iris]
[   38.815135][ T1221]  iris_fw_load+0x20/0x118 [qcom_iris]
[   38.820601][ T1221]  iris_core_init+0xc8/0x190 [qcom_iris]
[   38.826241][ T1221]  iris_open+0x88/0x460 [qcom_iris]
[   38.831441][ T1221]  v4l2_open+0x80/0x1b8 [videodev]
[   38.836551][ T1221]  chrdev_open+0xb8/0x240
[   38.840856][ T1221]  do_dentry_open+0x23c/0x4d0
[   38.845519][ T1221]  vfs_open+0x34/0xf8
[   38.849461][ T1221]  do_open+0x288/0x350
[   38.853498][ T1221]  path_openat+0x110/0x260
[   38.857886][ T1221]  do_filp_open+0xb0/0x178
[   38.862272][ T1221]  do_sys_openat2+0x94/0x108
[   38.866839][ T1221]  __arm64_sys_openat+0x6c/0xc0
[   38.871670][ T1221]  invoke_syscall+0x4c/0xf8
[   38.876146][ T1221]  el0_svc_common.constprop.0+0xc8/0xf0
[   38.881695][ T1221]  do_el0_svc+0x24/0x38
[   38.885821][ T1221]  el0_svc+0x3c/0x110
[   38.889774][ T1221]  el0t_64_sync_handler+0xa0/0xe8
[   38.894785][ T1221]  el0t_64_sync+0x19c/0x1a0
[   38.899268][ T1221] Code: a90673fb f9432c80 f90007e0 d2800000 (b94002a0) 
[   38.906245][ T1221] ---[ end trace 0000000000000000 ]---
[   38.946005][ T1221] Kernel panic - not syncing: Oops: Fatal exception

[YongxingMou]

Crash on Purwa device : https://lava-oss.qualcomm.com/scheduler/job/220623

[   38.671995][ T1221] CPU: 1 UID: 0 PID: 1221 Comm: v4l_id Tainted: G        W           6.18.44-g564a1ba1e231 #1 PREEMPT 
[   38.672006][ T1221] Tainted: [W]=WARN
[   38.672011][ T1221] Hardware name: Qualcomm Technologies, Inc. Purwa IoT EVK (DT)
[   38.672017][ T1221] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   38.672019][ T1221] pc : __iommu_unmap+0x38/0x258
[   38.707303][ T1221] lr : iommu_unmap+0x50/0xa8
[   38.711869][ T1221] sp : ffff80009b83b890
[   38.715993][ T1221] x29: ffff80009b83b8a0 x28: ffff0008291ed240 x27: 0000000000000000
[   38.724035][ T1221] x26: 0000000000000000 x25: ffff00080d160ac0 x24: 0000000087700000
[   38.732075][ T1221] x23: ffff00080c77c840 x22: ffff00081c3aecc0 x21: 0000000000000000
[   38.740116][ T1221] x20: ffff000810e00080 x19: 0000000000000000 x18: ffffffffffffffff
[   38.748153][ T1221] x17: ffff80007b4ddbf0 x16: ffff80007b4e1430 x15: ffff80007b4e1374
[   38.756193][ T1221] x14: ffff800080f60cb0 x13: ffff8000804d4e08 x12: 0000000000000000
[   38.764232][ T1221] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff800080ae9ba0
[   38.772272][ T1221] x8 : ffff80009b83b740 x7 : 0000000000000000 x6 : 0000000000000000
[   38.780313][ T1221] x5 : ffffffffffffffff x4 : ffff0008291ed240 x3 : ffff80009b83b908
[   38.788354][ T1221] x2 : 0000000000700000 x1 : 0000000000000000 x0 : 0000000000000000
[   38.796394][ T1221] Call trace:
[   38.799633][ T1221]  __iommu_unmap+0x38/0x258 (P)
[   38.804471][ T1221]  iommu_unmap+0x50/0xa8
[   38.808685][ T1221]  iris_load_fw_to_memory+0x1b0/0x1d8 [qcom_iris]
[   38.815135][ T1221]  iris_fw_load+0x20/0x118 [qcom_iris]
[   38.820601][ T1221]  iris_core_init+0xc8/0x190 [qcom_iris]
[   38.826241][ T1221]  iris_open+0x88/0x460 [qcom_iris]
[   38.831441][ T1221]  v4l2_open+0x80/0x1b8 [videodev]
[   38.836551][ T1221]  chrdev_open+0xb8/0x240
[   38.840856][ T1221]  do_dentry_open+0x23c/0x4d0
[   38.845519][ T1221]  vfs_open+0x34/0xf8
[   38.849461][ T1221]  do_open+0x288/0x350
[   38.853498][ T1221]  path_openat+0x110/0x260
[   38.857886][ T1221]  do_filp_open+0xb0/0x178
[   38.862272][ T1221]  do_sys_openat2+0x94/0x108
[   38.866839][ T1221]  __arm64_sys_openat+0x6c/0xc0
[   38.871670][ T1221]  invoke_syscall+0x4c/0xf8
[   38.876146][ T1221]  el0_svc_common.constprop.0+0xc8/0xf0
[   38.881695][ T1221]  do_el0_svc+0x24/0x38
[   38.885821][ T1221]  el0_svc+0x3c/0x110
[   38.889774][ T1221]  el0t_64_sync_handler+0xa0/0xe8
[   38.894785][ T1221]  el0t_64_sync+0x19c/0x1a0
[   38.899268][ T1221] Code: a90673fb f9432c80 f90007e0 d2800000 (b94002a0) 
[   38.906245][ T1221] ---[ end trace 0000000000000000 ]---
[   38.946005][ T1221] Kernel panic - not syncing: Oops: Fatal exception

This error is not coming from the display subsystem and is unrelated to my changes. Was this error already present before this change was merged?

[YongxingMou]

hi Salendarsingh Gaud (@sgaud-quic) I added the patch and built Purwa locally, and I couldn't reproduce this issue. Could you please merge this PR?

[qcomlnxci]

Test jobs on 9d49f1b

• multimedia Job 220620 on hamoa-iot-evk
• multimedia Job 220618 on lemans-evk
• multimedia Job 220625 on monaco-evk
• multimedia Job on purwa-iot-evk
• multimedia Job 220622 on qcs615-ride
• multimedia Job 220624 on qcs6490-rb3gen2
• multimedia Job 220621 on qcs8300-ride
• multimedia Job 220619 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 220626 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	⚠️ skip
BT_FW_KMD_Service	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_ON_OFF	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
BT_SCAN	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	◻️	◻️	⚠️ skip	⚠️ skip	❌ Fail	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	✅ Pass
GIC	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	✅ Pass	✅ Pass	❌ Fail
IPA	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Interrupts	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
KVM_Driver	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_EL2_DTB	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
KVM_Infra	❌ Fail	✅ Pass	✅ Pass	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
OpenCV	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
PCIe	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
Probe_Failure_Check	❌ Fail	❌ Fail	❌ Fail	◻️	❌ Fail	❌ Fail	❌ Fail	❌ Fail	❌ Fail
RMNET	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
UFS_Validation	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
USBHost	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	❌ Fail	❌ Fail	❌ Fail	❌ Fail
WiFi_Firmware_Driver	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
WiFi_OnOff	✅ Pass	✅ Pass	❌ Fail	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
adsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
cdsp_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
gpdsp_remoteproc	⚠️ skip	✅ Pass	✅ Pass	◻️	⚠️ skip	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip
hotplug	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
irq	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
kaslr	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
pinctrl	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
qcom_hwrng	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	◻️
rngtest	✅ Pass	✅ Pass	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	✅ Pass	✅ Pass
shmbridge	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
smmu	❌ Fail	❌ Fail	✅ Pass	◻️	❌ Fail	✅ Pass	✅ Pass	❌ Fail	✅ Pass
watchdog	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
wpss_remoteproc	✅ Pass	✅ Pass	✅ Pass	◻️	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass

[qcomlnxci]

Test jobs on 9d49f1b

• multimedia Job 222696 on hamoa-iot-evk
• multimedia Job 222691 on lemans-evk
• multimedia Job 222697 on monaco-evk
• multimedia Job 222694 on purwa-iot-evk
• multimedia Job 222693 on qcs615-ride
• multimedia Job 222695 on qcs6490-rb3gen2
• multimedia Job 222699 on qcs8300-ride
• multimedia Job 222698 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 222692 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	✅ 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	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	◻️	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	❌ 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

[Salendarsingh Gaud (sgaud-quic)]

YongxingMou commits in mainline PR seems different from these.

[YongxingMou]

YongxingMou commits in mainline PR seems different from these.
In mainline, this was merged as a workaround in v7.2 and has already been approved by PDM. In v7.3, it has been aligned with the upstream implementation and has also been merged into latest topic branch. Therefore, this should not be an issue.

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1050

Job 222691 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test infrastructure false positive — the Probe_Failure_Check test flags deferred probe devices (SPMI PMIC temp-alarm sensors) and benign firmware load failures (Bluetooth firmware that successfully loads later, as proven by BT_ON_OFF passing) as hard failures, even though these conditions do not indicate actual kernel regressions. The PR modifies only DisplayPort MST driver code and does not touch any of the flagged subsystems.
3. Possible fix: Update the Probe_Failure_Check test to suppress Bluetooth firmware load failures when BT_ON_OFF passes (per Rule 3 in lava-known-benign-failures.md), and add a suppression rule for SPMI PMIC temp-alarm deferred probes on lemans-evk, which are known to remain deferred due to missing thermal zone dependencies but do not impact system functionality.
4. Detail analysis attachment: failed_case_job222691_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group on lemans-evk platform; the SMMU test expects all critical DMA masters (UFS, USB, GPU, Display, Video) to be IOMMU-protected, but the video codec device tree node lacks the required iommus property or the driver failed to attach to an IOMMU domain during probe.
3. Possible fix: Add the missing iommus property to the aa00000.video-codec device tree node in arch/arm64/boot/dts/qcom/sa8775p.dtsi (or the lemans-evk overlay), referencing the appropriate SMMU instance and stream ID; alternatively, if the video codec driver is not probing correctly, investigate why iommu_group sysfs link is missing and ensure the driver calls iommu_get_domain_for_dev() or the IOMMU core auto-attaches the device during probe.
4. Detail analysis attachment: failed_case_job222691_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 suite completed all individual tests but was marked as failed by LAVA infrastructure due to "Marking unfinished test run as failed" error. Two genuine test failures were detected: (1) smmu test failed because Video codec device (aa00000.video-codec) is missing IOMMU group attachment on lemans-evk, indicating the video codec driver is not properly configured for SMMU protection; (2) Probe_Failure_Check test failed but produced an empty probe_failures.log, suggesting a test script issue rather than actual probe failures.
3. Possible fix: For the smmu failure: verify that the video codec device tree node at aa00000.video-codec includes proper iommu property bindings for lemans-evk platform. For the Probe_Failure_Check failure: this appears to be a test infrastructure issue (empty log file) rather than a genuine kernel issue — re-run the test to confirm; if it persists, investigate the test script logic in Runner/suites/Kernel/Baseport/Probe_Failure_Check/run.sh.
4. Detail analysis attachment: failed_case_job222691_3_detailed.md

Job 222692 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test script incorrectly parses /proc/interrupts and attempts to validate timer interrupts for non-existent CPUs 4-7 on the shikra-iqs-evk platform (which has only 4 CPUs: 0-3). The script treats interrupt descriptor fields ("GICv3", "Level", "arch_timer") as CPU numbers, causing bash integer comparison errors and false failures.
3. Possible fix: Update the GIC test script (Runner/suites/Kernel/Baseport/GIC/run.sh) to correctly detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo before attempting to validate timer interrupts, and parse /proc/interrupts correctly by counting only the numeric interrupt count fields (not the trailing descriptor fields).
4. Detail analysis attachment: failed_case_job222692_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Multiple driver probe failures detected on shikra-iqs-evk: coresight-etm4x (etm0-3) failing with -EINVAL, lt9611c display bridge failing with -EIO, and audio codec/sound card deferred probe not resolving due to missing clock/DAI dependencies.
3. Possible fix: The probe failures are pre-existing platform/DT issues unrelated to the PR's DRM/MSM DisplayPort changes. coresight-etm4x failures are known on this platform (missing ETM configuration in DT); lt9611c failure indicates display bridge power/I2C issues; audio codec deferral is a known audio subsystem integration gap. These are not regressions introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050. To suppress this test failure, either fix the underlying DT/driver issues for shikra-iqs-evk or update the Probe_Failure_Check test to exclude known-benign probe failures for this platform.
4. Detail analysis attachment: failed_case_job222692_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Lab infrastructure issue — no USB device physically connected to the shikra-iqs-evk board's USB host port during test execution. USB core subsystem initialized successfully (usbcore, usbfs, hub, usb-storage, usbhid all registered), but lsusb/device enumeration found zero devices because no physical USB device was attached to the board's USB host connector in the LAVA lab setup.
3. Possible fix: This is not a kernel regression. The PR contains only DisplayPort MST driver changes (drm/msm/dp) with zero USB-related modifications. Recommended action: verify LAVA lab setup for shikra-iqs-evk includes a USB device (e.g., USB flash drive, USB hub) connected to the USB host port; if the test is optional for boards without USB host peripherals in the lab, mark USBHost as SKIP for shikra-iqs-evk or add a pre-condition check to the test script.
4. Detail analysis attachment: failed_case_job222692_3_detailed.md

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

1. Failed case: ** BT_SCAN (Test Environment Issue — No Discoverable Devices)
2. Root cause: ** Bluetooth scan completed successfully at the kernel/driver level (hci0 powered on, discovery started/stopped correctly, bluetoothctl functional), but no external Bluetooth devices were in range or advertising during the 3 scan attempts (3 × 15s windows). This is a test infrastructure/lab environment issue, not a kernel regression.
3. Possible fix: Ensure a known Bluetooth device (phone, speaker, beacon) is powered on, in pairing/discoverable mode, and within RF range (~10m) of the shikra-iqs-evk board during BT_SCAN test execution. Alternatively, configure the test to accept zero discovered devices as a SKIP rather than FAIL when no target MAC is specified, or provide a target MAC via BT_TARGET_MAC environment variable for deterministic validation.
4. Detail analysis attachment: failed_case_job222692_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a bug requiring a fix. The KVM_Driver test should be skipped or marked as expected-fail for platforms without ARM VE/EL2 support. To enable KVM on this platform, the bootloader/firmware must be configured to boot the kernel at EL2 (hypervisor exception level) instead of EL1, and the SoC must support ARM Virtualization Extensions. Alternatively, exclude KVM tests from the CI test suite for boards known to lack hypervisor support.
4. Detail analysis attachment: failed_case_job222692_5_detailed.md

  Case 6: ** KVM_EL2_DTB — KVM Host Initialization Failure (HYP mode not available)

1. Failed case: ** KVM_EL2_DTB — KVM Host Initialization Failure (HYP mode not available)
2. Root cause: ** KVM initialization failed at boot because ARM64 EL2 (Hypervisor) mode is not available on the Shikra IQS EVK platform. The bootloader/firmware boots the kernel at EL1 without granting EL2 access, or secure firmware has locked down EL2. This is a platform/firmware limitation, not a kernel issue.
3. Possible fix: This is a pre-existing platform limitation unrelated to PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DisplayPort drivers). To enable KVM on Shikra IQS EVK: (1) Update the bootloader/UEFI firmware to boot the kernel at EL2 or grant EL2 access via HVC calls, OR (2) Modify the secure firmware (TrustZone/ATF) configuration to allow kernel access to EL2. If KVM support is not a requirement for this platform, mark KVM tests as "not applicable" for Shikra IQS EVK in the LAVA test suite.
4. Detail analysis attachment: failed_case_job222692_6_detailed.md

  Case 7: Kernel Crash — Hardware RNG synchronous external abort (not KVM_Infra)

1. Failed case: Kernel Crash — Hardware RNG synchronous external abort (not KVM_Infra)
2. Root cause: The KVM_Infra test reported failure because /dev/kvm is not available on Shikra IQS EVK (expected — KVM/virtualization not supported on this platform). However, the actual kernel crash occurred in the subsequent qcom_hwrng test when the qcom_rng driver attempted to read from hardware RNG registers at offset +0xc4 in qcom_rng_read(), triggering a synchronous external abort (0x96000010). This indicates the RNG hardware block is either not powered, not clocked, or the MMIO region is not accessible on this SoC variant.
3. Possible fix: The qcom_hwrng test failure is a genuine hardware access bug unrelated to the PR (PR only touches DRM/MSM display code). To fix: (1) verify the RNG hardware block exists and is enabled in the Shikra device tree; (2) confirm clock/power dependencies for the RNG block are met before driver probe; (3) add runtime PM or clock gating checks in qcom_rng driver to prevent access when hardware is not ready; (4) if RNG is not present on Shikra, disable CONFIG_HW_RANDOM_QCOM or mark the device as disabled in DT. The KVM_Infra failure is expected and should be suppressed for non-KVM platforms.
4. Detail analysis attachment: failed_case_job222692_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: ** The qcom_rng driver triggered a synchronous external abort (bus error) at offset +0xc4 in qcom_rng_read() while attempting to read hardware PRNG registers during the qcom_hwrng test. This indicates the PRNG hardware block was either not powered/clocked, not properly initialized by firmware, or the register mapping is incorrect for the shikra-iqs-evk platform. The crash is NOT introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DisplayPort MST driver code).
3. Possible fix: This is a pre-existing platform/firmware issue, not a PR regression. Recommended actions: (1) Verify PRNG hardware power/clock configuration in device tree for shikra-iqs-evk; (2) Check if qcom_rng driver probe succeeded and hardware was properly initialized before the test ran; (3) Confirm firmware version supports PRNG on this platform; (4) Consider skipping the qcom_hwrng test on shikra-iqs-evk until the platform support is fixed, or add a runtime hardware availability check in the test. The PR can proceed to merge as it does not cause this failure.
4. Detail analysis attachment: failed_case_job222692_8_detailed.md

  Case 9: lava-test-shell

1. Failed case: lava-test-shell
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a hardware/firmware/platform integration issue, not a kernel software bug introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DRM/MSM DisplayPort code). Recommended actions: (1) Verify RNG hardware block power/clock configuration in device tree and firmware for shikra-iqs-evk; (2) Check if RNG hardware is properly initialized by bootloader/TZ; (3) Add error handling in qcom_rng driver to gracefully handle MMIO timeouts instead of allowing synchronous external aborts to panic the system; (4) Re-run the test on a known-good shikra-iqs-evk board to rule out hardware failure; (5) If reproducible, disable qcom_hwrng test for shikra-iqs-evk in CI until platform issue is resolved.
4. Detail analysis attachment: failed_case_job222692_9_detailed.md

  Case 10: lava-test-retry

1. Failed case: lava-test-retry
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Investigate and fix the qcom_rng device tree configuration for shikra-iqs-evk: (1) Verify the reg property points to the correct RNG hardware base address for SM8450, (2) Add missing clocks property referencing gcc_prng_ahb_clk, (3) Add interconnects property if required for bus access, (4) Check if runtime PM is properly implemented in the driver to prevent access to suspended hardware, (5) Verify TrustZone firmware allows non-secure access to RNG registers. As an immediate workaround, disable or skip the qcom_hwrng test on shikra-iqs-evk until the platform configuration is fixed.
4. Detail analysis attachment: failed_case_job222692_10_detailed.md

  Case 11: 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 offset +0xc4 when the qcom_hwrng test attempted to read entropy from /dev/hwrng; the driver accessed an unmapped or inaccessible MMIO register, triggering a bus-level abort on shikra-iqs-evk.
3. Possible fix: Verify the qcom_rng DT node in arch/arm64/boot/dts/qcom/qcs8300-*.dts* has correct reg property mapping for the RNG hardware block; cross-check against the SoC memory map and ensure the RNG clock/power domain is enabled before driver probe; if the hardware block is not present or not functional on shikra-iqs-evk, mark the qcom_rng DT node as status = "disabled" for this board variant.
4. Detail analysis attachment: failed_case_job222692_11_detailed.md

Job 222693 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the Probe_Failure_Check test script to suppress known-benign firmware load failures where functional tests pass. Specifically, exclude regulatory.db failures when WiFi_OnOff and BT_ON_OFF tests pass, similar to the suppression rules in lava-known-benign-failures.md. Alternatively, add regulatory.db to the rootfs firmware directory to silence the warning, though this is unnecessary for functionality.
4. Detail analysis attachment: failed_case_job222693_1_detailed.md

  Case 2: ** smmu (test validation failure — not a kernel crash)

1. Failed case: ** smmu (test validation failure — not a kernel crash)
2. Root cause: ** The smmu test script expects V4L2 video device child nodes (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be independently attached to IOMMU groups. However, these are V4L2 video device nodes created by the Venus driver, not separate platform devices. They inherit IOMMU protection through their parent platform device aa00000.video-codec, which is correctly attached to IOMMU group 7. The test expectation is incorrect for the qcs615-ride platform's Venus driver architecture.
3. Possible fix: Update the smmu test script to recognize that V4L2 video device nodes (video-decoder, video-encoder) do not require separate IOMMU group attachments when their parent platform device is already protected. The test should verify only that the parent aa00000.video-codec device is attached to an IOMMU group, which it is (group 7).
4. Detail analysis attachment: failed_case_job222693_2_detailed.md

  Case 3: ** KVM_Driver (driver initialization failure - HYP mode unavailable)

1. Failed case: ** KVM_Driver (driver initialization failure - HYP mode unavailable)
2. Root cause: ** KVM driver initialization failed because the QCS615 Ride platform firmware (ABL/XBL bootloader and/or TrustZone secure firmware) does not boot the kernel at EL2 (Hypervisor exception level) or has disabled EL2 access for the non-secure world. The kernel detected this condition during KVM initialization and aborted with "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: This is a platform firmware limitation, not a kernel bug or PR-introduced regression. To enable KVM on QCS615 Ride: (1) Update ABL/XBL bootloader to boot kernel at EL2 instead of EL1, and (2) ensure TrustZone secure firmware policy allows non-secure EL2 access. If virtualization is not required for this platform, suppress KVM tests in the LAVA job definition for QCS615 targets.
4. Detail analysis attachment: failed_case_job222693_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver initialization failed because the QCS615 platform does not support ARM virtualization extensions (EL2/HYP mode) — kernel message "kvm [1]: HYP mode not available" indicates the CPU is not running at EL2 or the bootloader did not preserve EL2 for the kernel.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The QCS615 SoC either lacks ARM virtualization extensions or the bootloader/firmware does not enable EL2 for Linux. Mark KVM tests as "skip" for qcs615-ride in the LAVA test suite configuration, or verify with Qualcomm whether QCS615 supports KVM and if bootloader changes are needed to enable EL2.
4. Detail analysis attachment: failed_case_job222693_4_detailed.md

  Case 5: ** KVM Infrastructure Failure — HYP mode not available

1. Failed case: ** KVM Infrastructure Failure — HYP mode not available
2. Root cause: ** KVM driver initialization failed because EL2 (hypervisor mode) is not accessible to the Linux kernel on the QCS615 Ride platform. The firmware/bootloader configuration boots the kernel at EL1 without preserving EL2 access, preventing KVM from enabling ARM virtualization support. This is a platform-specific limitation, not a kernel regression.
3. Possible fix: This is a pre-existing platform configuration issue unrelated to PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DRM DisplayPort drivers). To enable KVM on QCS615: (1) Update the bootloader/ABL firmware to boot the kernel at EL2 or enable VHE (Virtualization Host Extensions), OR (2) Configure the platform's secure firmware to allow EL2 access to the non-secure kernel, OR (3) If the platform uses a proprietary hypervisor, enable nested virtualization support. If KVM support is not required for this platform, mark these tests as expected failures in the CI configuration for QCS615.
4. Detail analysis attachment: failed_case_job222693_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: QCS615 platform does not support ARM virtualization extensions (EL2/HYP mode). KVM driver initialization fails with "HYP mode not available" because the hardware does not provide the required hypervisor support. CONFIG_KVM is enabled in kernel config but the driver cannot create /dev/kvm at runtime due to missing platform capability.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR modifies DRM DisplayPort code unrelated to KVM. To resolve: (1) Mark KVM tests as expected-fail or skip for qcs615-ride platform in LAVA job definition, OR (2) Disable CONFIG_KVM in the kernel config for platforms without EL2 support (qcs615, and similar IoT/edge SoCs), OR (3) Update test suite to detect platform capability and skip gracefully when HYP mode is unavailable.
4. Detail analysis attachment: failed_case_job222693_6_detailed.md

Job 222694 | SoC purwa-evk

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

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

  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: ** The Probe_Failure_Check test detected five pre-existing driver probe failures on the purwa-evk (iq-x5121-evk) platform: qcom_qseecom_uefisecapp (-EBUSY), two qcom-pcie instances (-ENODATA), qcom-spmi-lpg (-EINVAL), and regulatory.db firmware (-ENOENT). These failures are platform-specific hardware/firmware/DT configuration issues unrelated to the PR, which only modifies the DRM/MSM DisplayPort driver.
3. Possible fix: Suppress these known platform-specific probe failures in the Probe_Failure_Check test for purwa-evk, or address them separately: (1) qseecom: verify TrustZone firmware compatibility; (2) PCIe: expected on EVK without PCIe cards—suppress or mark as info-only; (3) lpg: audit device tree PWM configuration for this board revision; (4) regulatory.db: install firmware-regulatory package or suppress (WiFi functional via fallback). These issues should NOT block PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050, which is unrelated.
4. Detail analysis attachment: failed_case_job222694_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure — the SMMU test detected that 6 critical master devices (5 USB PHY controllers at addresses a0f8800, a2f8800, a4f8800, a6f8800, a8f8800 and 1 video codec at aa00000) are missing IOMMU group attachments on the purwa-evk platform, indicating incomplete device tree IOMMU bindings for these devices.
3. Possible fix: Add missing iommus properties to the device tree nodes for USB PHY controllers (dwc3_*_hs_phy) and video codec (venus/iris) in the purwa-evk device tree; verify the SMMU stream IDs are correctly assigned in the device tree and that the devices probe successfully with IOMMU group attachments after the fix.
4. Detail analysis attachment: failed_case_job222694_2_detailed.md

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

1. Failed case: KVM Driver Initialization Failure — HYP mode not available
2. Root cause: The Purwa IoT EVK platform boots with a hypervisor (hypvm.mbn) running at EL2, which prevents the Linux KVM driver from accessing HYP mode. The kernel message kvm [1]: HYP mode not available indicates KVM cannot initialize because EL2 is already occupied by the platform hypervisor, not available to Linux.
3. Possible fix: This is not a kernel bug or PR regression — it is the expected behavior for this platform configuration. The KVM_Driver test should be marked as SKIP (not FAIL) for platforms that boot under a hypervisor. Update the test suite to detect when Linux is running as a guest (check /sys/hypervisor/type or parse dmesg for hypervisor detection) and skip KVM tests on such platforms, or exclude purwa-evk from the KVM test matrix.
4. Detail analysis attachment: failed_case_job222694_3_detailed.md

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

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** KVM initialization fails because the Gunyah hypervisor is already running at EL2 on purwa-evk; Linux is running as a guest VM under Gunyah, not in bare-metal mode with VHE, preventing KVM from accessing EL2 and creating /dev/kvm.
3. Possible fix: This is not a kernel bug or PR regression. To enable KVM on purwa-evk, reconfigure the platform firmware/bootloader to boot Linux in bare-metal mode without Gunyah hypervisor, or use a different test platform that boots Linux with VHE at EL2. Alternatively, suppress KVM tests on Gunyah-enabled platforms in the CI job definition.
4. Detail analysis attachment: failed_case_job222694_4_detailed.md

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

1. Failed case: KVM_Infra — Platform Configuration Issue (Gunyah Hypervisor Conflict)
2. Root cause: KVM cannot initialize on purwa-evk because the Gunyah hypervisor is already running at EL2 (HYP mode). ARM architecture permits only one hypervisor to occupy EL2 at a time. Kernel message: "kvm [1]: HYP mode not available" (line 5.776616). Gunyah hypervisor boot confirmed: "Hypervisor cold boot, version: gunyah-mobile-c487961e9 perf" (line 3.156490).
3. Possible fix: This is not a bug — it is expected behavior on Gunyah-enabled platforms. To enable KVM testing on purwa-evk: (1) disable Gunyah hypervisor in the bootloader/firmware configuration, or (2) exclude KVM tests from the purwa-evk LAVA test suite, or (3) run KVM tests only on platforms without Gunyah (e.g., standard QEMU or non-virtualized ARM boards). The PR patch is unrelated to this failure and does not need modification.
4. Detail analysis attachment: failed_case_job222694_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP (EL2 hypervisor) mode is not available on the Purwa IoT EVK platform; kernel message "kvm [1]: HYP mode not available" at boot indicates the hardware/firmware does not support virtualization extensions or EL2 is disabled.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression (confirmed across jobs 222691, 222692, 222693, 222694). The PR contains only DisplayPort MST driver changes unrelated to KVM. No kernel fix is required; either: (1) skip KVM tests on purwa-evk in CI configuration, or (2) enable EL2/HYP mode in the platform firmware/bootloader if the hardware supports it.
4. Detail analysis attachment: failed_case_job222694_6_detailed.md

Job 222695 | SoC qcs6490-rb3gen2

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

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

  Case 1: GIC Test Script Bug — False Failure Due to Offline CPUs

1. Failed case: GIC Test Script Bug — False Failure Due to Offline CPUs
2. Root cause: The GIC test script assumes all CPUs in the possible mask (0-7) are online and attempts to parse interrupt counts for CPUs 6-7, which failed to boot during kernel initialization (PSCI error -EINVAL). The script encounters a non-integer string ("GICv3") when parsing the interrupt controller name column, causing a bash integer comparison error at line 75. This is a test infrastructure bug, not a kernel issue.
3. Possible fix: Update the GIC test script to iterate only over online CPUs (/sys/devices/system/cpu/online) instead of the possible CPU mask. The script should skip offline CPUs or handle missing interrupt count columns gracefully. This is a test harness fix, not a kernel fix. The PR is not related to this failure and should not be blocked by it.
4. Detail analysis attachment: failed_case_job222695_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing firmware load failures unrelated to PR changes: (1) regulatory.db firmware missing from rootfs (cfg80211 wireless regulatory database), and (2) renesas_usb_fw.mem firmware missing for Renesas USB 3.0 host controller. The PR modifies only DRM MSM DisplayPort driver code (dp_ctrl.c, dp_panel.c, dp_reg.h) and does not touch firmware loading, wireless regulatory, or USB/PCIe subsystems. These probe failures existed before the PR and are infrastructure/rootfs configuration issues, not kernel regressions introduced by this PR.
3. Possible fix: Update the rootfs image to include the missing firmware files: (1) add linux-firmware package or manually copy regulatory.db to /lib/firmware/, and (2) add renesas_usb_fw.mem to /lib/firmware/. These are rootfs packaging issues, not kernel code defects. The PR should not be blocked by these pre-existing infrastructure gaps.
4. Detail analysis attachment: failed_case_job222695_2_detailed.md

  Case 3: ** Freq_Scaling

1. Failed case: ** Freq_Scaling
2. Root cause: ** The Freq_Scaling test script is hardcoded to expect 8 CPUs (cpu0-cpu7) but qcs6490-rb3gen2 has only 6 CPUs (cpu0-cpu5). The test incorrectly fails when it cannot find /sys/devices/system/cpu/cpu7/cpufreq/ because cpu7 does not exist on this SoC. Evidence: CPU affinity mask 0x3f (binary 0011 1111) confirms only 6 CPUs present; test showed 7 consecutive PASS results for cpu0-cpu6 then immediately failed with "CPUFreq interface not found."
3. Possible fix: Update the Freq_Scaling test script in the LAVA test suite to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /sys/devices/system/cpu/present instead of using a hardcoded loop expecting 8 CPUs. Replace for cpu in 0 1 2 3 4 5 6 7 with dynamic iteration over actually-present CPUs using for cpu in /sys/devices/system/cpu/cpu[0-9]* or similar.
4. Detail analysis attachment: failed_case_job222695_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: No USB host controller available on qcs6490-rb3gen2 board — on-SoC USB controllers (8c00000.usb, a600000.usb) are configured in peripheral/gadget mode, and the PCIe-based Renesas xHCI host controller (0001:04:00.0) failed to probe due to missing firmware file renesas_usb_fw.mem (error -2 / -ENOENT).
3. Possible fix: Install the Renesas USB firmware package (linux-firmware or renesas-usb-fw) in the rootfs, or reconfigure one of the on-SoC USB controllers (8c00000.usb or a600000.usb) to host mode via device tree dr_mode = "host" property if the board hardware supports it.
4. Detail analysis attachment: failed_case_job222695_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test environment configuration issue, not a PR-introduced regression. To enable KVM: (1) disable Gunyah in the device tree by removing or disabling the gunyah node and hyp reserved-memory region, (2) ensure the bootloader does not load Gunyah firmware (hypvm.mbn), and (3) rebuild the boot image. Alternatively, exclude KVM tests from the CI suite for Gunyah-enabled builds, as KVM and Gunyah are mutually exclusive.
4. Detail analysis attachment: failed_case_job222695_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the system is running at EL1 under the Gunyah hypervisor instead of at EL2; the kernel message "HYP mode not available" indicates KVM detected it lacks EL2 access, which is required for ARM64 KVM host functionality.
3. Possible fix: This is a platform/firmware configuration issue, not a kernel regression introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DRM/MSM display driver code). The qcs6490-rb3gen2 board is configured to boot with Gunyah hypervisor enabled, which prevents KVM from functioning. To enable KVM testing on this platform: (1) disable Gunyah hypervisor in the firmware/bootloader configuration to allow Linux to boot at EL2, OR (2) exclude KVM tests from the CI test suite for boards running with Gunyah enabled, as nested virtualization (KVM inside Gunyah) is not supported in this configuration.
4. Detail analysis attachment: failed_case_job222695_6_detailed.md

  Case 7: ** KVM_Infra (Platform Limitation — HYP Mode Not Available)

1. Failed case: ** KVM_Infra (Platform Limitation — HYP Mode Not Available)
2. Root cause: ** The qcs6490-rb3gen2 (Kodiak) platform does not support or have HYP (EL2/hypervisor) mode enabled. At kernel boot (line 2963), KVM initialization reports kvm [1]: HYP mode not available, which prevents /dev/kvm device node creation. CONFIG_KVM is enabled in the kernel, but the hardware/firmware does not provide EL2 virtualization support required for KVM operation.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM_Infra, KVM_Driver, and KVM_EL2_DTB test cases should be marked as SKIP or NOT_APPLICABLE for the qcs6490-rb3gen2 platform in the LAVA test suite configuration, as this SoC does not support virtualization. If KVM support is required, use a platform with EL2/hypervisor mode enabled (e.g., platforms with Gunyah hypervisor or native KVM support).
4. Detail analysis attachment: failed_case_job222695_7_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression. The PR only modifies DisplayPort MST driver code and has zero impact on KVM. To enable KVM on this platform: (1) verify bootloader/firmware provides EL2 access to Linux (check HCR_EL2 configuration), (2) ensure device tree does not disable hypervisor mode, (3) if the platform does not support EL2 in non-secure world, mark KVM tests as "not applicable" for qcs6490-rb3gen2 in the CI test matrix.
4. Detail analysis attachment: failed_case_job222695_8_detailed.md

Job 222696 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three pre-existing platform driver probe failures unrelated to PR changes: (1) qcom_qseecom_uefisecapp failed with -EBUSY (secure execution environment resource conflict), (2) qcom-spmi-lpg failed with -EINVAL (PMIC PWM configuration issue), (3) regulatory.db firmware missing (-ENOENT). Multiple audio/soundwire devices remain in deferred probe state waiting for pinctrl supplier. PR only modifies DisplayPort driver code (drivers/gpu/drm/msm/dp/*) and does not touch any of the failing subsystems.
3. Possible fix: These are known platform bring-up issues on hamoa-evk unrelated to this PR. The Probe_Failure_Check test should be updated to exclude these known failures for hamoa-evk, or the underlying platform issues should be fixed separately: (1) investigate qseecom resource allocation conflict, (2) verify PMIC PWM DT configuration for spmi-lpg, (3) add regulatory.db to firmware package, (4) verify pinctrl DT nodes for audio subsystem. This PR should not be blocked by these pre-existing issues.
4. Detail analysis attachment: failed_case_job222696_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test validation failure - six devices (five USB PHY controllers: a0f8800.usb, a2f8800.usb, a4f8800.usb, a6f8800.usb, a8f8800.usb, and one video codec: aa00000.video-codec) are missing IOMMU group attachments on hamoa-evk, but the SMMU subsystem itself is functioning correctly with no faults or errors.
3. Possible fix: This is not a PR-introduced regression (PR only modifies DisplayPort MST code). Either: (1) update the test to exclude USB PHY devices and video codec from the "critical master" check if they are not expected to use IOMMU on this platform, or (2) add iommus properties to these devices in the hamoa-evk device tree if IOMMU protection is required.
4. Detail analysis attachment: failed_case_job222696_2_detailed.md

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

1. Failed case: KVM_Driver — /dev/kvm device node not created
2. Root cause: KVM initialization failed with "HYP mode not available" because the Gunyah hypervisor (gunyah-mobile-c487961e9) is already running at EL2 on hamoa-evk, preventing KVM from taking control of the hypervisor privilege level.
3. Possible fix: This is expected behavior on Qualcomm platforms with Gunyah hypervisor enabled. The test expectation is incorrect for this platform configuration. Either: (1) disable the KVM_Driver test for hamoa-evk in the LAVA test suite, or (2) boot without Gunyah hypervisor if KVM functionality is required (requires bootloader/firmware configuration change to not load Gunyah).
4. Detail analysis attachment: failed_case_job222696_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM driver initialization failure

1. Failed case: KVM_EL2_DTB — KVM driver initialization failure
2. Root cause: Kernel booted at EL1 instead of EL2; KVM requires EL2 (hypervisor mode) to initialize, resulting in "HYP mode not available" and missing /dev/kvm device node
3. Possible fix: Configure the bootloader/firmware on hamoa-evk to boot the kernel at EL2 instead of EL1; verify UEFI/ABL boot configuration enables HYP mode for Linux; this is a platform/firmware configuration issue, not a kernel or PR-introduced regression
4. Detail analysis attachment: failed_case_job222696_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available on the hamoa-evk platform — kernel message at boot: "kvm [1]: HYP mode not available" indicates the CPU is not running in EL2 or EL2 is disabled by firmware/bootloader.
3. Possible fix: Configure the bootloader/firmware to boot the kernel at EL2 (Hypervisor exception level) instead of EL1; verify that the platform's TrustZone/secure firmware allows EL2 access and that no hypervisor is already running that would prevent KVM from initializing.
4. Detail analysis attachment: failed_case_job222696_5_detailed.md

  Case 6: ** KVM_Infra

1. Failed case: ** KVM_Infra
2. Root cause: ** KVM driver initialization failed with "HYP mode not available" because the Hamoa IoT EVK platform does not provide EL2 (hypervisor mode) access to the kernel, preventing /dev/kvm device node creation. This is a platform hardware/firmware limitation, not a kernel software issue.
3. Possible fix: This is not a kernel bug. The KVM_Infra test should be excluded from the Hamoa EVK test suite, as this platform does not support KVM/virtualization. If KVM support is required, verify with the platform team whether EL2 can be enabled in the bootloader/firmware configuration, or use a different platform that supports virtualization (e.g., platforms with Gunyah hypervisor or native EL2 support).
4. Detail analysis attachment: failed_case_job222696_6_detailed.md

Job 222697 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: ath11k WiFi driver probe timeout (error -110) on monaco-evk due to missing firmware files (ath11k/WCN6855/hw2.1/nfa765/amss.bin) and/or MHI power-on failure during PCIe enumeration; this is a pre-existing platform firmware/configuration issue unrelated to the DisplayPort MST driver changes in PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050.
3. Possible fix: Add missing ath11k firmware files to the monaco-evk rootfs image (linux-firmware package or board-specific firmware partition); verify PCIe link training and MHI subsystem initialization for WCN6855 on monaco-evk; this is a board bring-up/CI infrastructure fix, not a kernel code fix required for this PR.
4. Detail analysis attachment: failed_case_job222697_1_detailed.md

  Case 2: ** WiFi Driver Probe Failure — ath11k_pci firmware missing

1. Failed case: ** WiFi Driver Probe Failure — ath11k_pci firmware missing
2. Root cause: ** The ath11k_pci WiFi driver probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up to timeout during driver initialization on the monaco-evk platform.
3. Possible fix: Add the missing WCN6855 WiFi firmware files to the rootfs image build. Specifically, ensure linux-firmware-ath11k package (or equivalent firmware blob for WCN6855 hw2.1 nfa765 variant) is included in the Yocto/build recipe for monaco-evk, or manually copy the firmware files to /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ in the rootfs before flashing.
4. Detail analysis attachment: failed_case_job222697_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 firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (and associated board files) to the Monaco EVK rootfs image under /lib/firmware/. Source the firmware from linux-firmware upstream or Qualcomm's firmware repository for WCN6855 hw2.1 nfa765 variant. Rebuild the rootfs and re-flash the board.
4. Detail analysis attachment: failed_case_job222697_3_detailed.md

  Case 4: Driver Probe Failure — ath11k WiFi driver

1. Failed case: Driver Probe Failure — ath11k WiFi driver
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) because the required MHI firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -2 / ENOENT). This is a pre-existing firmware packaging issue on monaco-evk, not introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DRM/MSM DisplayPort code).
3. Possible fix: Add the missing ath11k firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory. This is a build/packaging issue — the firmware must be included in the Yocto image recipe or manually installed. The PR changes are unrelated and should not be blocked by this pre-existing infrastructure issue.
4. Detail analysis attachment: failed_case_job222697_4_detailed.md

Job 222698 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform configuration issues on qcs9100-ride: (1) Aquantia AQR115C Ethernet PHY driver fails probe with -EINVAL due to missing or invalid firmware-name DT property; (2) cfg80211 regulatory database firmware file missing from rootfs (benign - common in test environments); (3) four PMIC temp-alarm devices stuck in deferred probe, likely awaiting thermal zone dependencies that never resolve.
3. Possible fix: These are pre-existing board/configuration issues unrelated to the PR (which only modifies DisplayPort MST drivers). For the Aquantia PHY: add the required firmware-name property to the Ethernet PHY DT node in arch/arm64/boot/dts/qcom/qcs9100-ride.dts or verify the PHY can operate without firmware. For regulatory.db: install the wireless-regdb package in the rootfs or disable the test's firmware check. For temp-alarm deferred probes: verify thermal zone DT bindings are complete for all four PMICs or suppress these devices from the probe failure check if they are non-critical.
4. Detail analysis attachment: failed_case_job222698_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The qcs9100-ride platform's video codec device (aa00000.video-codec) is missing IOMMU group attachment in the device tree or driver probe sequence, causing the SMMU validation test to fail when checking that all critical masters are protected by IOMMU groups.
3. Possible fix: Add the missing iommus property to the aa00000.video-codec device tree node in arch/arm64/boot/dts/qcom/qcs9100.dtsi to bind the video codec to an IOMMU group, following the pattern used by other critical masters (GPU, Display, USB) that successfully attach to IOMMU groups on this platform.
4. Detail analysis attachment: failed_case_job222698_2_detailed.md

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

1. Failed case: ** USBHost (Test Infrastructure Issue — No USB Devices Connected)
2. Root cause: ** The USBHost test failed because no physical USB devices are connected to the qcs9100-ride board's USB ports in the LAVA lab environment. The USB host controllers are functioning correctly (all three root hubs detected and operational), but the test validation logic requires at least one functional USB device (beyond root hubs) to be present. This is a test infrastructure configuration issue, not a kernel defect. The PR modifies only DisplayPort MST code and does not affect USB functionality.
3. Possible fix: Connect at least one functional USB device (USB flash drive, keyboard, or mouse) to one of the qcs9100-ride board's USB ports in the LAVA lab before running the test suite. Alternatively, if USB device connectivity is not guaranteed in the lab environment, update the USBHost test to report SKIP instead of FAIL when only root hubs are detected, or document this as a known lab limitation for this board.
4. Detail analysis attachment: failed_case_job222698_3_detailed.md

  Case 4: Ethernet_Basic_Validation — PHY Attachment Failure

1. Failed case: Ethernet_Basic_Validation — PHY Attachment Failure
2. Root cause: The qcom-ethqos driver at 23040000.ethernet fails to attach to its PHY with -EINVAL during interface bring-up. The driver probed successfully at boot, but no MDIO bus or PHY device probe messages appear in the boot log, indicating the device tree is missing the PHY node definition, has an incorrect phy-handle reference, or specifies a PHY driver that is not available in the kernel. This is a pre-existing platform configuration issue for qcs9100-ride, not introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies drm/msm/dp DisplayPort code).
3. Possible fix: Verify the device tree for 23040000.ethernet includes a valid MDIO bus child node with a PHY subnode at the correct address, ensure the phy-handle property points to this PHY node, confirm the phy-mode is correct (e.g., rgmii-id), and verify the required PHY driver (e.g., CONFIG_REALTEK_PHY, CONFIG_MOTORCOMM_PHY, or CONFIG_AQUANTIA_PHY depending on the hardware) is enabled in the kernel config. If the PHY hardware is not populated on this board variant, the device tree should mark the ethernet node as status = "disabled" to prevent the test from attempting to use it.
4. Detail analysis attachment: failed_case_job222698_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM is not available on qcs9100-ride (LeMans) platform because HYP mode (EL2 hypervisor mode) is not available on this SoC/board configuration. The kernel message kvm [1]: HYP mode not available indicates the ARM CPU is not running with virtualization extensions enabled or the firmware/bootloader did not configure EL2 mode.
3. Possible fix: This is a pre-existing platform limitation, not a regression introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DisplayPort drivers). To enable KVM on this platform: (1) verify the SoC supports ARM virtualization extensions, (2) ensure the bootloader/firmware enables EL2 mode and does not drop to EL1 before kernel entry, (3) confirm CONFIG_KVM is built as a module or built-in and the kvm.ko module loads successfully. If the platform fundamentally does not support virtualization, mark KVM tests as "not applicable" for qcs9100-ride in the CI test matrix.
4. Detail analysis attachment: failed_case_job222698_5_detailed.md

  Case 6: KVM Driver Initialization Failure — /dev/kvm not available (EL2/HYP mode unavailable)

1. Failed case: KVM Driver Initialization Failure — /dev/kvm not available (EL2/HYP mode unavailable)
2. Root cause: The qcs9100-ride platform firmware/bootloader does not enable EL2 (Hypervisor Exception Level) for Linux. The KVM driver detects "HYP mode not available" during initialization (dmesg line 3126: kvm [1]: HYP mode not available), preventing creation of /dev/kvm. The bootloader explicitly skips hypervisor DT overlay (line 2424: "Skipping overlay of hyp dt nodes for non-Gunyah hypervisor"), confirming EL2 is not configured for this platform.
3. Possible fix: Skip KVM tests on qcs9100-ride platform by adding a platform-specific test exclusion rule in the LAVA test definition, or modify the test script to detect and skip when dmesg | grep -q "HYP mode not available". Long-term: either disable CONFIG_KVM in qcs9100 defconfig (if EL2 will never be supported), or work with firmware team to enable EL2 in the bootloader/ABL for this platform.
4. Detail analysis attachment: failed_case_job222698_6_detailed.md

  Case 7: KVM Infrastructure Test Failure — Platform Does Not Support KVM

1. Failed case: KVM Infrastructure Test Failure — Platform Does Not Support KVM
2. Root cause: The qcs9100-ride platform boots with Gunyah hypervisor at EL2, which prevents KVM from initializing. KVM requires EL2 to be available for the Linux kernel, but on this platform EL2 is occupied by the Gunyah hypervisor. The kernel correctly detects this condition and reports "kvm [1]: HYP mode not available" at boot time (line 3126), causing /dev/kvm to never be created.
3. Possible fix: This is not a kernel regression introduced by PR drm/msm/dp: fix NULL pointer deref in msm_dp_snapshot() for unmapped MST streams #1050 (which only modifies DRM/MSM display driver code). The KVM_Infra test failure is a platform configuration issue, not a code defect. The test should be excluded from the qcs9100-ride test suite, or the platform firmware should be reconfigured to boot without Gunyah if KVM functionality is required. No kernel code fix is needed.
4. Detail analysis attachment: failed_case_job222698_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure unavailable on qcs9100-ride platform — kernel reports "HYP mode not available" during boot, preventing /dev/kvm device creation; CONFIG_KVM is enabled but EL2 (hypervisor mode) is not accessible on this SoC/board configuration.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR modifies only DisplayPort MST driver code (drm/msm/dp) and has no impact on KVM/virtualization subsystems. Recommended action: suppress KVM_Infra test on qcs9100-ride in CI configuration, or enable EL2 support in the platform firmware/bootloader if KVM testing is required on this board.
4. Detail analysis attachment: failed_case_job222698_8_detailed.md

Job 222699 | SoC qcs8300-ride

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

No failed cases detected from the LAVA results section.