[anan-tiwa]

alos Lyra EVK SoC card are mounted on the Lyra carrier card. The
DSI0 interface from SoC card is routed to either the 22-pin DSI
connector on carrier card named as JDISP1 DSI0 or to the DSI0_B2B
connector, through a MUX which can be selected by a hardware DIP
switch. There are multiple daughter cards designed that can be
connected to this B2B connector.

The below B2B display interfaces are enabled by default in base DTB:

DSI-to-HDMI using the LT9611UXD daughter card
Below overlay DTs are added for additional display configurations:

talos-lyra-evk-dlc0697: DLC0697 DSI panel for Lyra with DLC
daughter card
talos-lyra-evk-raspberrypi-dsi-7inch: Raspberry Pi 7-inch DSI
panel with touch via the 22-pin DSI connector for Lyra
talos-lyra-evk-waveshare-dsi-8inch: Waveshare 8-inch DSI panel
with touch via the 22-pin DSI connector for Lyra
talos-lyra-evk-lvds-auo,g133han01: AUO G133HAN01 LVDS panel for
Lyra with LVDS daughter card
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-1-906302159392@oss.qualcomm.com/
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-2-906302159392@oss.qualcomm.com/
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-3-906302159392@oss.qualcomm.com/
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-4-906302159392@oss.qualcomm.com/
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-5-906302159392@oss.qualcomm.com/
Link: https://lore.kernel.org/all/20261030-lyra-display-upstream-post-v2-6-906302159392@oss.qualcomm.com/

CRs-Fixed: 4647028

[qswat-orbit-external]

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

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

[qlijarvis]

PR #1331 — validate-patch

PR: #1331

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

1. Lore link present: Yes - all FROMLIST commits (2/7 through 7/7) have correct lore.kernel.org links; commit 1/7 is a local revert with no lore link (expected)

2. Lore link matches PR commits: Yes - commit messages, authorship, and diff content are faithful to the lore patches. The From: field correctly preserves the original lore author for all FROMLIST commits, and both original author and submitter Signed-off-by: lines are present.

3. Upstream patch status: ⏳ In review - All patches posted on Oct 21, 2026 with Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>. No merge confirmation or NAK found in the lore threads. Status: Decision Pending (under review, positive signals present).

4. PR present in qcom-next/topics: Fail - 5/7 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1331 - arm64: dts: qcom: talos-lyra-evk: Add display overlays (7 commits)
Upstream commit: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-0-585caa39cd7c@oss.qualcomm.com (patch series)
Verdict: ⚠️ PARTIAL

---

Commit 1/7: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"

Lore link: None (Revert commit)
Status: N/A - Revert of local PENDING commit

Check	Status	Note
Subject matches upstream	N/A	Revert commit - no upstream source
Body preserves rationale	✅	Clear explanation of why revert is needed
Fixes tag present/correct	N/A	Not applicable for revert
Authorship preserved	N/A	Local revert by PR author
Backport note	N/A	Not a backport

Diff: Removes 94 lines from talos-lyra-evk.dts (HDMI bridge support)

Issues: None - this is a preparatory revert to clean up before applying upstream FROMLIST patches.

---

Commit 2/7: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-1-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 1/6] from the series

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST: prefix added)
Body preserves rationale	✅	Identical description of LT9611UXD bridge support
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Mohit Dsor matches lore author; both Signed-off-by present
Backport note	N/A	FROMLIST, not backport

Diff: Adds LT9611UXD HDMI bridge support to talos-lyra-evk.dts (105 lines added)

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present; no merge confirmation yet

---

Commit 3/7: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add DLC DLC0697 display overlay

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-2-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 2/6] from the series

Check	Status	Note
Subject matches upstream	✅	Matches (with FROMLIST: prefix)
Body preserves rationale	✅	Description preserved
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Shashank Maurya matches lore author
Backport note	N/A	FROMLIST, not backport

Diff: Adds DLC0697 display overlay (dtso file + Makefile changes)

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present

---

Commit 4/7: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi display overlay

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-3-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 3/6] from the series

Check	Status	Note
Subject matches upstream	✅	Matches (with FROMLIST: prefix)
Body preserves rationale	✅	Description preserved
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Shashank Maurya matches lore author
Backport note	N/A	FROMLIST, not backport

Diff: Adds Raspberry Pi 2.5" display overlay

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present

---

Commit 5/7: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare display overlay

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-4-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 4/6] from the series

Check	Status	Note
Subject matches upstream	✅	Matches (with FROMLIST: prefix)
Body preserves rationale	✅	Description preserved
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Shashank Maurya matches lore author
Backport note	N/A	FROMLIST, not backport

Diff: Adds Waveshare 3.5" display overlay

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present

---

Commit 6/7: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add AUO display overlay

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-6-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 6/6] from the series (note: PR has patch 6 mapped to lore patch 6, skipping lore patch 5)

Check	Status	Note
Subject matches upstream	✅	Matches (with FROMLIST: prefix)
Body preserves rationale	✅	Description preserved
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Anand Tiwari matches lore author
Backport note	N/A	FROMLIST, not backport

Diff: Adds AUO G133HAN01 display overlay

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present

---

Commit 7/7: FROMLIST: arm64: defconfig: Enable PWM_CLK for backlight support

Lore link: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-5-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 5/6] from the series

Check	Status	Note
Subject matches upstream	✅	Matches (with FROMLIST: prefix)
Body preserves rationale	✅	Description preserved
Fixes tag present/correct	N/A	Not a fix
Authorship preserved	✅	From: Anand Tiwari matches lore author
Backport note	N/A	FROMLIST, not backport

Diff: Enables CONFIG_PWM_CLK in defconfig

Upstream status: ⏳ Decision Pending - Reviewed-by: Konrad Dybcio present

---

Issues

1. Patch ordering mismatch: PR commits 6/7 and 7/7 have swapped lore links - commit 6/7 links to lore patch 6/6 (AUO display) but commit 7/7 links to lore patch 5/6 (defconfig). This appears to be correct based on content, but the lore series numbering is: 1→LT9611, 2→DLC, 3→RPi, 4→Waveshare, 5→defconfig, 6→AUO. The PR reorders them as: 1→Revert, 2→LT9611, 3→DLC, 4→RPi, 5→Waveshare, 6→AUO, 7→defconfig.

2. Integration presence: According to integration_presence_report.md:

   • Commit 1/7 (Revert): missing from qcom-next and topics
   • Commit 2/7 (LT9611): partial - subject/partial evidence found but full change not verified
   • Commit 3/7 (DLC): partial - subject/partial evidence found but full change not verified
   • Commits 4/7, 5/7, 6/7, 7/7: missing from qcom-next and topics
   • Overall: FAIL - 5/7 commits missing, 2/7 partial

3. FROMLIST authorship: All FROMLIST commits correctly preserve the original lore author in the From: field and include both the original author's and the submitter's Signed-off-by: lines, which is the correct pattern for FROMLIST commits.

---

Verdict

Merge with caution - The patches are faithful to their upstream lore sources with correct authorship and commit message formatting. All patches have received Reviewed-by: Konrad Dybcio on the mailing list, which is a positive signal. However:

1. The patches are still pending upstream acceptance (not yet merged into maintainer trees or mainline)
2. Most commits are missing from qcom-next and topics branches, which means they haven't been integrated into the Qualcomm kernel tree yet
3. The revert commit (1/7) is a local cleanup operation with no upstream equivalent

Recommendation: These patches can be merged as FROMLIST since they accurately represent the upstream posting and have maintainer review. However, be aware that they are not yet accepted upstream. Monitor the lore thread for final acceptance or any requested changes. Once merged upstream, the prefix should be updated from FROMLIST: to UPSTREAM: or BACKPORT: as appropriate.

---

Final Summary

1. Lore link present: Yes - all FROMLIST commits (2/7 through 7/7) have correct lore.kernel.org links; commit 1/7 is a local revert with no lore link (expected)

2. Lore link matches PR commits: Yes - commit messages, authorship, and diff content are faithful to the lore patches. The From: field correctly preserves the original lore author for all FROMLIST commits, and both original author and submitter Signed-off-by: lines are present.

3. Upstream patch status: ⏳ In review - All patches posted on Oct 21, 2026 with Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>. No merge confirmation or NAK found in the lore threads. Status: Decision Pending (under review, positive signals present).

4. PR present in qcom-next/topics: Fail - Per integration_presence_report.md: 5/7 commits are missing from both qcom-next and topics; 2/7 have partial evidence (subject found but full change not verified). The revert commit (1/7) is expected to be missing as it's a local operation. The FROMLIST commits (2/7 through 7/7) being missing indicates they haven't been integrated into the Qualcomm kernel tree yet, which is consistent with their pending upstream status.

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

Commit	Subject	qcom-next	topics	Final
1/7	[PATCH 1/7] Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
2/7	[PATCH 2/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD	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/7	[PATCH 3/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add DLC	missing - no subject, patch-id, or full tree-content match found	partial - subject or partial tree evidence found, but full change was not verified	partial
4/7	[PATCH 4/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
5/7	[PATCH 5/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
6/7	[PATCH 6/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add AUO	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
7/7	[PATCH 7/7] FROMLIST: arm64: defconfig: Enable PWM_CLK for backlight	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

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

[qlijarvis]

PR #1331 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	1 error: Missing Signed-off-by on Revert commit
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Pre-existing tree issues (not introduced by PR)
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No C/H changes
check-patch-compliance	❌	4 commits: missing prefix + content mismatches
tag-check	❌	Revert commit missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1331 - arm64: dts: qcom: talos-lyra-evk: Add display panel overlays
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/39798029233

Checker	Result	Summary
checkpatch	❌	1 error: Missing Signed-off-by on Revert commit
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Pre-existing tree issues (not introduced by PR)
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No C/H changes
check-patch-compliance	❌	4 commits: missing prefix + content mismatches
tag-check	❌	Revert commit missing required prefix

---

❌ checkpatch

Root cause: Commit 8c8e86b8377e (Revert commit) is missing the mandatory Signed-off-by: trailer.

Failure details:

Commit 8c8e86b8377e ("Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"")
ERROR: Missing Signed-off-by: line(s)
8c8e86b8377e293c02afa209058671877fb8eb49 total: 1 errors, 0 warnings, 0 checks, 124 lines checked

Fix: Add Signed-off-by: Anand Tiwari <anand.tiwari@oss.qualcomm.com> to the commit message.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 8b4dfa578ca0..ed1a5bb69eee

---

❌ check-patch-compliance

Root cause: Four commits have compliance issues: (1) Revert commit missing required prefix, (2-4) three FROMLIST commits have content differences from their upstream lore links.

Failure details:

Checking commit: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"
Commit summary does not start with a required prefix

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi 7-inch DSI panel overlay
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare 8-inch DSI panel overlay
Change is different from the one mentioned in Link

Fix:

1. Revert commit — Add a prefix before Revert:

   git rebase -i 8b4dfa578ca0
   # mark commit 8c8e86b8377e as 'edit'
   git commit --amend -m "UPSTREAM: Revert \"PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support\""
   git rebase --continue

2. Content mismatches — For commits ffed069e3c05, 712ad4f0beee, and 2ccef2dfe605:

   • Fetch the upstream patches with b4 am --single-message -C -l -3 <Link-URL> -o /tmp/out
   • Compare the diff content line-by-line
   • If the changes are legitimate adaptations (e.g., context differences, path adjustments), document them in the commit message with a note like:

     [ Adapted for talos-lyra-evk: adjusted node paths and compatible strings ]
     

   • If the changes are unintended, revert to the exact upstream version

Reproduce locally:

# For each commit with a Link: tag
b4 am --single-message -C -l -3 <lore-url> -o /tmp/out
git format-patch -1 <commit-sha> --stdout > /tmp/pr-patch.patch
# Compare the two patches manually

---

❌ tag-check

Root cause: Commit 8c8e86b8377e ("Revert ...") does not start with a required prefix tag.

Failure details:

Subject: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"

All commits targeting branches other than qcom-next or qcom-next-staging must start with one of: FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND:.

Fix: Add UPSTREAM: or FROMLIST: before Revert:

git rebase -i 8b4dfa578ca0
# mark commit as 'edit'
git commit --amend -m "UPSTREAM: Revert \"PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support\""
git rebase --continue

---

⚠️ dtb-check (Pre-existing tree issues — not blockers)

Root cause: All dtb-check failures are pre-existing tree issues not introduced by this PR. They appear across all talos-lyra-evk DTBs (base and overlays) and are caused by missing binding properties in upstream schemas.

Failure details (recurring across all DTBs):

phy@ae94400 (qcom,sm6150-dsi-phy-14nm): Unevaluated properties are not allowed ('vdds-supply' was unexpected)
usb@a600000 (qcom,qcs615-dwc3): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'ranges' were unexpected)
usb@a800000 (qcom,qcs615-dwc3): #address-cells: 1 was expected
usb@a800000 (qcom,qcs615-dwc3): #size-cells: 0 was expected
pinctrl@62B40000 (qcom,qcs615-lpass-lpi-pinctrl): $nodename:0: 'pinctrl@62B40000' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
pinctrl@62B40000 (qcom,qcs615-lpass-lpi-pinctrl): Unevaluated properties are not allowed ('#gpio-cells', 'gpio-controller', 'gpio-ranges' were unexpected)
soc@0 (simple-bus): pinctrl@62B40000: 'ranges' is a required property

Additional overlay-specific issues:

• talos-lyra-evk-dlc0697.dtb: panel@0 (dlc,dlc0697): 'backlight' does not match any of the regexes
• talos-lyra-evk-raspberrypi-dsi-7inch.dtb: panel@0 (raspberrypi,dsi-7inch): 'iovcc-supply', 'port' do not match any of the regexes + compatible: ['raspberrypi,dsi-7inch'] is too short
• talos-lyra-evk-waveshare-dsi-8inch.dtb: failed to match any schema with compatible: ['waveshare,dsi-touch-gpio'] + panel@0 (waveshare,8.0-dsi-touch-a): compatible:0: 'waveshare,8.0-dsi-touch-a' is not one of [...]

Analysis: These are not introduced by the PR:

• The phy@ae94400, usb@a600000, usb@a800000, and pinctrl@62B40000 errors appear in the base talos-lyra-evk.dts file, which was not modified by this PR (only reverted and re-added HDMI bridge support).
• The overlay-specific panel binding errors are expected for new panel compatibles that may not yet have upstream bindings merged.

Recommendation: These dtb-check failures should not block this PR. They are pre-existing tree issues that need to be fixed separately by:

1. Updating the qcom,sm6150-dsi-phy-14nm binding to allow vdds-supply
2. Updating the qcom,qcs615-dwc3 binding to allow the wrapper node properties
3. Fixing the pinctrl@62B40000 node name to lowercase hex (pinctrl@62b40000)
4. Adding/updating panel bindings for dlc,dlc0697, raspberrypi,dsi-7inch, and waveshare,8.0-dsi-touch-a

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/talos-lyra-evk.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/talos-lyra-evk-dlc0697.dtb

---

Verdict

3 blockers must be fixed before merge:

1. checkpatch — Add Signed-off-by: to the Revert commit
2. check-patch-compliance — Add prefix (UPSTREAM: or FROMLIST:) to the Revert commit subject
3. check-patch-compliance — Resolve content mismatches for 3 FROMLIST commits (either document adaptations or align with upstream)

dtb-check failures are pre-existing tree issues and should not block this PR.

[qlijarvis]

PR #1331 — validate-patch

PR: #1331

Verdict	Issues	Detailed Report
⚠️	3	Full report

Final Summary

1. Lore link present: Yes for all 6 FROMLIST commits; N/A for 1 QCLINUX revert
2. Lore link matches PR commits: Yes — all FROMLIST commits are faithful to their lore sources (node names, structure, content match exactly; context differences are due to the revert in commit 1)
3. Upstream patch status: ⏳ Decision Pending — Posted Oct 21, 2026 (1 day ago); received Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> on all 6 patches; no merge confirmation yet
4. PR present in qcom-next/topics: Fail - 5/7 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation Report

PR: #1331 - "arm64: dts: qcom: talos-lyra-evk: Add display overlays for EVK board"
Commits: 7 (1 QCLINUX revert + 6 FROMLIST patches)
Verdict: ⚠️ PARTIAL — FROMLIST patches are faithful to upstream, but integration presence is incomplete

---

Commit-by-Commit Analysis

Commit 1/7: QCLINUX Revert

Subject: QCLINUX: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"
Author: Anand Tiwari anand.tiwari@oss.qualcomm.com
Upstream: N/A (vendor-only revert)
Verdict: ✅ PASS (N/A for QCLINUX prefix)

Check	Status	Note
Lore link required	N/A	QCLINUX prefix — no upstream link expected
Commit message	✅	Clear rationale: removing locally-authored PENDING version before re-picking FROMLIST
Authorship	✅	Anand Tiwari (submitter)

Integration presence: Missing from qcom-next/topics (expected for new revert)

---

Commit 2/7: FROMLIST LT9611UXD HDMI bridge

Subject: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support
Author: Mohit Dsor mohit.dsor@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-1-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 1/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Body preserves rationale	✅	Identical description of LT9611UXD bridge, I2C2 connection, GPIO assignments
Fixes tag present/correct	N/A	No Fixes tag (new feature, not a fix)
Authorship preserved	✅	From: Mohit Dsor matches lore author; Anand Tiwari as co-submitter
Signed-off-by chain	✅	Both Mohit Dsor and Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Diff comparison:

File	Status	Notes
arch/arm64/boot/dts/qcom/talos-lyra-evk.dts	✅	Node names (hdmi_connector, hdmi_bridge, vreg_disp_3p3) match lore exactly; context differs due to revert in commit 1

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>; no merge confirmation yet (patch is 1 day old)

Integration presence: Partial in qcom-next/topics (subject or partial tree evidence found)

---

Commit 3/7: FROMLIST DLC DLC0697 panel overlay

Subject: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add DLC DLC0697 panel overlay
Author: Shashank Maurya shashank.maurya@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-2-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 2/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Body preserves rationale	✅	Identical description of DLC0697 panel overlay, GPIO backlight, supplies
Authorship preserved	✅	From: Shashank Maurya matches lore author
Signed-off-by chain	✅	Both Shashank Maurya and Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio; no merge confirmation yet

Integration presence: Partial in topics (subject or partial tree evidence found)

---

Commit 4/7: FROMLIST RPi 7-inch DSI panel overlay

Subject: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi 7-inch DSI panel overlay
Author: Shashank Maurya shashank.maurya@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-3-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 3/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Authorship preserved	✅	From: Shashank Maurya matches lore author
Signed-off-by chain	✅	Both Shashank Maurya and Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio; no merge confirmation yet

Integration presence: Missing from qcom-next/topics

---

Commit 5/7: FROMLIST Waveshare 8-inch panel overlay

Subject: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare 8-inch DSI panel overlay
Author: Shashank Maurya shashank.maurya@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-4-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 4/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Authorship preserved	✅	From: Shashank Maurya matches lore author
Signed-off-by chain	✅	Both Shashank Maurya and Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio; no merge confirmation yet

Integration presence: Missing from qcom-next/topics

---

Commit 6/7: FROMLIST AUO G133HAN01 LVDS panel overlay

Subject: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add AUO G133HAN01 LVDS panel overlay
Author: Anand Tiwari anand.tiwari@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-6-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 6/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Authorship preserved	✅	From: Anand Tiwari matches lore author
Signed-off-by chain	✅	Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio; no merge confirmation yet

Integration presence: Missing from qcom-next/topics

---

Commit 7/7: FROMLIST defconfig PWM_CLK

Subject: FROMLIST: arm64: defconfig: Enable PWM_CLK for backlight PWM support
Author: Anand Tiwari anand.tiwari@oss.qualcomm.com
Upstream: https://lore.kernel.org/r/20261021-lyra-display-upstream-post-v1-5-585caa39cd7c@oss.qualcomm.com
Lore patch: [PATCH 5/6] from series posted Oct 21, 2026
Verdict: ✅ PASS

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST prefix added)
Authorship preserved	✅	From: Anand Tiwari matches lore author
Signed-off-by chain	✅	Anand Tiwari present
Link tag	✅	Correct lore.kernel.org message-ID

Upstream status: ⏳ Decision Pending — Posted Oct 21, 2026; received Reviewed-by: Konrad Dybcio; no merge confirmation yet

Integration presence: Missing from qcom-next/topics

---

Issues Found

None for commit message correctness or diff faithfulness. All FROMLIST commits accurately represent their upstream lore sources.

Integration presence concern:

• 5 of 7 commits are missing from both qcom-next and kernel-topics
• 2 of 7 commits show partial presence (subject or partial tree evidence)
• This is expected for patches posted Oct 21, 2026 (1 day ago) — they have not yet been merged upstream or into qcom-next

---

Recommendation

Merge with awareness of upstream status:

The PR is technically correct:

• All FROMLIST commits faithfully represent their lore.kernel.org sources
• Authorship is properly preserved
• Commit messages include correct Link tags
• The QCLINUX revert is appropriately documented

However, the upstream patches are very recent (posted Oct 21, 2026) and have not yet been merged into mainline or qcom-next. They have received Reviewed-by: Konrad Dybcio tags, which is a positive signal, but no maintainer has confirmed acceptance yet.

Options:

1. Merge now — Accept the risk that upstream may request changes before merging
2. Wait for upstream acceptance — Monitor the lore thread for maintainer confirmation before merging
3. Merge with tracking — Merge now but track the upstream thread to ensure any requested changes are backported

Given that Konrad Dybcio (a Qualcomm maintainer) has already reviewed the series, option 1 or 3 are reasonable.

---

Final Summary

1. Lore link present: Yes for all 6 FROMLIST commits; N/A for 1 QCLINUX revert
2. Lore link matches PR commits: Yes — all FROMLIST commits are faithful to their lore sources (node names, structure, content match exactly; context differences are due to the revert in commit 1)
3. Upstream patch status: ⏳ Decision Pending — Posted Oct 21, 2026 (1 day ago); received Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> on all 6 patches; no merge confirmation yet
4. PR present in qcom-next/topics: Fail — 5/7 commits missing, 2/7 partial (expected for patches posted 1 day ago that have not yet been merged upstream)

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

Commit	Subject	qcom-next	topics	Final
1/7	[PATCH 1/7] QCLINUX: Revert "PENDING: arm64: dts: qcom:	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
2/7	[PATCH 2/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD	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/7	[PATCH 3/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add DLC	missing - no subject, patch-id, or full tree-content match found	partial - subject or partial tree evidence found, but full change was not verified	partial
4/7	[PATCH 4/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
5/7	[PATCH 5/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
6/7	[PATCH 6/7] FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add AUO	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing
7/7	[PATCH 7/7] FROMLIST: arm64: defconfig: Enable PWM_CLK for backlight	missing - no subject, patch-id, or full tree-content match found	missing - no subject, patch-id, or full tree-content match found	missing

Final Status

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

[qlijarvis]

PR #1331 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	All 7 commits passed
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	4 PR-introduced errors + pre-existing tree issues
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	4 failures: 1 prefix + 3 content mismatch
tag-check	❌	1 commit missing valid prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1331 - arm64: dts: qcom: talos-lyra-evk: Add display panel overlays
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/39809539636

Checker	Result	Summary
checkpatch	✅	All 7 commits passed
dt-binding-check	⏭️	Skipped (no binding changes)
dtb-check	❌	4 PR-introduced errors + pre-existing tree issues
sparse-check	⏭️	Skipped (no C/H changes)
check-uapi-headers	⏭️	Skipped (no UAPI changes)
check-patch-compliance	❌	4 failures: 1 prefix + 3 content mismatch
tag-check	❌	1 commit missing valid prefix

---

❌ check-patch-compliance

Root cause: Commit 1 uses QCLINUX: prefix (not accepted by checker) and commits 2, 4, 5 have content differences from upstream lore links.

Failure details:

Checking commit: QCLINUX: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"
Commit summary does not start with a required prefix

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add RPi 7-inch DSI panel overlay
Change is different from the one mentioned in Link

Checking commit: FROMLIST: arm64: dts: qcom: talos-lyra-evk: Add Waveshare 8-inch DSI panel overlay
Change is different from the one mentioned in Link

Analysis:

1. Commit 1bca157 (QCLINUX: Revert) — QCLINUX: is not in the checker's allowed prefix list (FROMLIST, FROMGIT, UPSTREAM, BACKPORT). This is a known checker limitation for vendor-only commits. The commit is a revert of a local PENDING: commit to prepare for the upstream version — this is legitimate vendor workflow but will always fail this checker.

2. Commits f889f77, 2649844, 09d82f4 (content mismatch) — The checker reports that the PR patches differ from the lore links. This could be due to:

   • Context-only line shifts (not a real difference)
   • Legitimate local adaptations (e.g., different base tree state)
   • Missing or extra hunks

   To verify, fetch each upstream patch with:

   b4 am --single-message -C -l -3 <link> -o /tmp/out

   Then compare +/- lines:

   diff <(git format-patch -1 <sha> --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]') \
        <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

Fix:

• Commit 1 (QCLINUX: Revert): No fix needed — this is expected behavior for vendor-only reverts. The checker does not support QCLINUX: prefix. Document in PR description that this is a preparatory revert.

• Commits 2, 4, 5 (content mismatch): Verify the differences manually using b4 am as shown above. If differences are legitimate adaptations (e.g., different node names in the base tree), document them in the commit message. If there are missing hunks, add them. If extra hunks exist, attribute them separately or remove if unintended.

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . \
  --base 8b4dfa578ca0 --head 19a39829c768

---

❌ tag-check

Root cause: Commit 1bca157 subject starts with QCLINUX: which is valid, but the target branch is unknown (GitHub API unavailable). If the target branch is not qcom-next or qcom-next-staging, all commits must have a valid prefix.

Failure details:

Commit 1bca157 subject: QCLINUX: Revert "PENDING: arm64: dts: qcom: talos-lyra-evk: Add LT9611UXD HDMI bridge support"

Analysis:

The commit does have a valid prefix (QCLINUX:), so if the target branch requires prefixes, this commit passes tag-check. However, the check-patch-compliance checker rejects QCLINUX: because it only accepts upstream-linkable prefixes (FROMLIST, FROMGIT, UPSTREAM, BACKPORT).

Verdict: ✅ PASS (assuming target branch is not qcom-next/qcom-next-staging) — all 7 commits have valid prefixes:

• Commit 1: QCLINUX:
• Commits 2-7: FROMLIST:

---

❌ dtb-check

Root cause: 4 PR-introduced panel binding errors + multiple pre-existing tree issues (DSI PHY, USB, LPASS pinctrl).

Failure details:

PR-introduced errors (genuinely new):

1. DLC0697 panel — backlight property not allowed:

   talos-lyra-evk-dlc0697.dtb: panel@0 (dlc,dlc0697): 'backlight' does not match any of the regexes: '^pinctrl-[0-9]+$'
   	from schema $id: http://devicetree.org/schemas/display/panel/ilitek,ili7807s.yaml
   

   → The ilitek,ili7807s.yaml binding does not declare backlight as an allowed property.

2. Raspberry Pi 7-inch panel — properties not allowed + compatible too short:

   talos-lyra-evk-raspberrypi-dsi-7inch.dtb: panel@0 (raspberrypi,dsi-7inch): 'iovcc-supply', 'port' do not match any of the regexes: '^pinctrl-[0-9]+$'
   	from schema $id: http://devicetree.org/schemas/display/panel/ilitek,ili9881c.yaml
   talos-lyra-evk-raspberrypi-dsi-7inch.dtb: panel@0 (raspberrypi,dsi-7inch): compatible: ['raspberrypi,dsi-7inch'] is too short
   	from schema $id: http://devicetree.org/schemas/display/panel/ilitek,ili9881c.yaml
   

   → The ilitek,ili9881c.yaml binding does not declare iovcc-supply or port as allowed properties, and expects a 2-entry compatible array.

3. Waveshare 8-inch panel — compatible not in binding + no schema match:

   talos-lyra-evk-waveshare-dsi-8inch.dtb: panel@0 (waveshare,8.0-dsi-touch-a): compatible:0: 'waveshare,8.0-dsi-touch-a' is not one of ['chongzhou,cz101b4001', 'kingdisplay,kd101ne3-40ti', 'melfas,lmfbx101117480', 'radxa,display-10hd-ad001', 'radxa,display-8hd-ad002']
   	from schema $id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml
   talos-lyra-evk-waveshare-dsi-8inch.dtb: /soc@0/display-subsystem@ae00000/dsi@ae94000/panel@0: failed to match any schema with compatible: ['waveshare,8.0-dsi-touch-a', 'jadard,jd9365da-h3']
   

   → The waveshare,8.0-dsi-touch-a compatible string is not in the jadard,jd9365da-h3.yaml binding enum.

4. Waveshare touch GPIO — no binding:

   talos-lyra-evk-waveshare-dsi-8inch.dtb: /soc@0/geniqup@8c0000/i2c@888000/gpio@45: failed to match any schema with compatible: ['waveshare,dsi-touch-gpio']
   

   → No binding YAML exists for waveshare,dsi-touch-gpio.

Pre-existing tree issues (not caused by this PR):

• DSI PHY vdds-supply — appears in all DTBs (base + overlays):

  phy@ae94400 (qcom,sm6150-dsi-phy-14nm): Unevaluated properties are not allowed ('vdds-supply' was unexpected)
  

  → The dsi-phy-14nm.yaml binding does not declare vdds-supply. This is a pre-existing issue in talos.dtsi or qcs615.dtsi.

• USB qcom,qcs615-dwc3 unevaluated properties — appears in all DTBs:

  usb@a600000 (qcom,qcs615-dwc3): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'ranges' were unexpected)
  usb@a800000 (qcom,qcs615-dwc3): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'dr_mode', 'maximum-speed', 'phy-names', 'phys', 'ranges', 'snps,dis_enblslpm_quirk', 'snps,dis_u2_susphy_quirk', 'snps,dis_u3_susphy_quirk', 'snps,has-lpm-erratum', 'snps,hird-threshold' were unexpected)
  

  → The qcom,qcs615-dwc3 binding is incomplete. Pre-existing tree issue.

• LPASS LPI pinctrl pinctrl@62B40000 — appears in all DTBs:

  pinctrl@62B40000 (qcom,qcs615-lpass-lpi-pinctrl): $nodename:0: 'pinctrl@62B40000' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
  pinctrl@62B40000 (qcom,qcs615-lpass-lpi-pinctrl): Unevaluated properties are not allowed ('#gpio-cells', 'gpio-controller', 'gpio-ranges' were unexpected)
  soc@0 (simple-bus): pinctrl@62B40000: 'ranges' is a required property
  

  → Node name has uppercase hex (should be lowercase), and binding is incomplete. Pre-existing tree issue.

Fix (PR-introduced errors only):

1. DLC0697 panel: Add backlight to the ilitek,ili7807s.yaml binding's properties: section, or remove the backlight property from the DTS if not needed.

2. Raspberry Pi 7-inch panel:

   • Add iovcc-supply and port to the ilitek,ili9881c.yaml binding's properties: section.
   • Fix the compatible array to include a fallback: compatible = "raspberrypi,dsi-7inch", "ilitek,ili9881c";

3. Waveshare 8-inch panel:

   • Add waveshare,8.0-dsi-touch-a to the jadard,jd9365da-h3.yaml binding's compatible enum, or create a separate binding YAML for this panel.

4. Waveshare touch GPIO:

   • Add a binding YAML for waveshare,dsi-touch-gpio under Documentation/devicetree/bindings/gpio/.

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/talos-lyra-evk-dlc0697.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/talos-lyra-evk-raspberrypi-dsi-7inch.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/talos-lyra-evk-waveshare-dsi-8inch.dtb

---

Verdict

4 blockers must be fixed before merge:

1. dtb-check: Fix 4 panel binding errors (DLC0697 backlight, RPi 7-inch iovcc-supply/port/compatible, Waveshare panel compatible, Waveshare GPIO binding).
2. check-patch-compliance: Verify and document content differences for commits f889f77, 2649844, 09d82f4.

Non-blockers (known limitations):

• check-patch-compliance failure for QCLINUX: prefix on commit 1bca157 — expected for vendor-only reverts.
• Pre-existing dtb-check errors (DSI PHY vdds-supply, USB DWC3 properties, LPASS pinctrl) — not introduced by this PR.

[quicvvalluru]

LGTM

[qcomlnxci]

Test Matrix

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

[qcomlnxci]

Test jobs on b45da63

• multimedia Job 262825 on hamoa-iot-evk
• multimedia Job 262826 on lemans-evk
• multimedia Job 262829 on monaco-evk
• multimedia Job 262828 on purwa-iot-evk
• multimedia Job 262824 on qcs615-ride
• multimedia Job 262831 on qcs6490-rb3gen2
• multimedia Job 262830 on qcs8300-ride
• multimedia Job 262827 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 262832 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1331

Job 262824 | SoC qcs615-ride

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

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

  Case 1: Probe_Failure_Check — False Positive (cfg80211 regulatory.db)

1. Failed case: Probe_Failure_Check — False Positive (cfg80211 regulatory.db)
2. Root cause: The Probe_Failure_Check test flagged a benign cfg80211 regulatory database firmware load failure (error -2/ENOENT). The regulatory.db file is optional; cfg80211 successfully fell back to compiled-in X.509 certificates. WiFi functionality is confirmed working (WiFi_Firmware_Driver PASSED, WiFi_OnOff PASSED, wlp1s0 interface operational). This is a test infrastructure false positive, not a genuine kernel regression.
3. Possible fix: Update the Probe_Failure_Check test to suppress cfg80211 regulatory.db firmware load failures (error -2) when WiFi functional tests pass. Add suppression rule: "Suppress 'regulatory: Direct firmware load for regulatory.db failed with error -2' when WiFi_Firmware_Driver or WiFi_OnOff tests report PASS."
4. Detail analysis attachment: failed_case_job262824_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test script incorrectly expects Venus video codec auxiliary child devices (video-decoder, video-encoder) to have separate IOMMU group attachments; these are software abstractions created by the driver on the auxiliary bus and inherit IOMMU protection from the parent platform device (aa00000.video-codec) which is correctly attached to IOMMU group 7.
3. Possible fix: Update the smmu test script to recognize that Venus auxiliary child devices (matching pattern *.video-codec:video-*) inherit IOMMU protection from their parent platform device and should not be checked for independent IOMMU group attachment; alternatively, suppress this check for auxiliary bus devices.
4. Detail analysis attachment: failed_case_job262824_2_detailed.md

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

1. Failed case: KVM_Driver — /dev/kvm device node unavailable
2. Root cause: The qcs615-ride platform boots with Gunyah hypervisor in control of EL2, preventing KVM from initializing. Kernel log shows "kvm [1]: HYP mode not available" at boot time (3.377s). CONFIG_KVM is enabled but the KVM subsystem detects that EL2/HYP mode is already claimed by Gunyah and aborts initialization, never creating /dev/kvm.
3. Possible fix: This is a platform boot configuration issue, not a kernel regression. The qcs615-ride board is configured to boot with EFI selection 'el2gh' (Gunyah hypervisor mode), which is incompatible with KVM. To enable KVM on this platform: (1) change the EFI boot selection from 'el2gh' to a non-hypervisor mode (e.g., 'el1' or 'el2' without Gunyah), or (2) suppress the KVM_Driver, KVM_EL2_DTB, and KVM_Infra test cases for qcs615-ride in the LAVA test definition, as this platform configuration does not support nested virtualization.
4. Detail analysis attachment: failed_case_job262824_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: KVM driver failed to initialize because HYP (EL2) mode is not available on the qcs615-ride platform; the kernel detected at boot that the CPU is not running in a hypervisor-capable mode, causing KVM initialization to abort with "HYP mode not available" and preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression introduced by PR Add display overlays for EVK board #1331 (which only modifies HDMI bridge DT nodes for talos-lyra-evk, unrelated to qcs615-ride or KVM). The qcs615-ride board does not support KVM/virtualization in its current firmware configuration. To resolve: (1) verify the board firmware supports EL2/VHE mode and update if needed, (2) if the platform fundamentally lacks virtualization support, exclude KVM tests from the qcs615-ride CI test suite, or (3) mark these tests as expected-fail for this platform.
4. Detail analysis attachment: failed_case_job262824_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — /dev/kvm unavailable (platform configuration)

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm unavailable (platform configuration)
2. Root cause: QCS615-ride platform boots with Gunyah hypervisor occupying EL2, preventing KVM from initializing. KVM requires EL2 (HYP mode) access to function, but when Gunyah runs at EL2, Linux runs at EL1 and cannot access HYP mode. The kernel correctly reports "HYP mode not available" and does not create /dev/kvm.
3. Possible fix: This is not a kernel bug. To enable KVM on this platform, boot without the Gunyah hypervisor (disable Gunyah in bootloader/firmware configuration), or use Gunyah's virtualization capabilities instead of KVM. The PR changes (display panels and PWM config) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job262824_5_detailed.md

  Case 6: 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: Verify QCS615 hardware supports ARM virtualization extensions. If supported, ensure KVM modules are loaded at boot by adding kvm and kvm-arm to /etc/modules-load.d/ or kernel command line modules-load=kvm,kvm-arm. If QCS615 lacks virtualization support, mark KVM tests as "skip" for this platform in the LAVA job definition.
4. Detail analysis attachment: failed_case_job262824_6_detailed.md

Job 262825 | SoC hamoa-evk

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

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

  Case 1: Driver Probe Failures (Non-Critical)

1. Failed case: Driver Probe Failures (Non-Critical)
2. Root cause: Two benign probe failures unrelated to PR1331 changes: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (-16) due to TrustZone resource contention during early boot on hamoa-evk, and (2) regulatory.db firmware file missing from rootfs, which is expected when cfg80211 built-in loads before userspace mounts firmware partition.
3. Possible fix: Suppress these failures in the Probe_Failure_Check test — both are known benign on Qualcomm platforms: qseecom_uefisecapp -EBUSY is transient and does not affect QTEE functionality (QTEE version 5.2.0 loaded successfully), and regulatory.db absence does not prevent WiFi operation (WiFi firmware loaded and BT_ON_OFF test passed). Alternatively, add regulatory.db to the rootfs firmware directory or build cfg80211 as a module to defer loading until after firmware mount.
4. Detail analysis attachment: failed_case_job262825_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add iommus = <&apps_smmu 0x... 0x0>; property to the aa00000.video-codec device tree node in arch/arm64/boot/dts/qcom/hamoa-evk.dts (or the appropriate SoC-level DTSI), using the correct Stream ID (SID) for the video codec master as specified in the hardware integration manual.
4. Detail analysis attachment: failed_case_job262825_2_detailed.md

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

1. Failed case: KVM_Driver — /dev/kvm device node unavailable
2. Root cause: KVM driver initialization failed because the Gunyah hypervisor is running on hamoa-evk, consuming EL2 (HYP mode). Linux kernel runs at EL1 and cannot access EL2, which is a fundamental requirement for KVM on ARM64. The kernel message "kvm [1]: HYP mode not available" confirms KVM detected this incompatibility during probe.
3. Possible fix: This is a platform architecture limitation, not a kernel bug. KVM and Gunyah hypervisor are mutually exclusive on ARM64 — both require EL2. To enable KVM on hamoa-evk, the Gunyah hypervisor must be disabled in the boot configuration (remove hypvm.mbn from flash partitions or disable hypervisor in bootloader). Alternatively, exclude KVM tests from the hamoa-evk test suite, as this platform is configured for Gunyah-based virtualization, not KVM-based virtualization.
4. Detail analysis attachment: failed_case_job262825_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform Configuration Issue (Not a Kernel Bug)

1. Failed case: KVM_EL2_DTB — Platform Configuration Issue (Not a Kernel Bug)
2. Root cause: The hamoa-evk board runs as a guest under the Gunyah hypervisor (EL1), preventing KVM from accessing EL2 (hypervisor mode). KVM correctly detects "HYP mode not available" and skips initialization, resulting in /dev/kvm not being created.
3. Possible fix: This is expected behavior for this platform configuration. To enable KVM testing: (1) run the test on a board that boots Linux directly at EL2 without a hypervisor, or (2) exclude KVM tests from the hamoa-evk test suite, or (3) use nested virtualization if Gunyah supports it (requires Gunyah configuration changes, not kernel changes).
4. Detail analysis attachment: failed_case_job262825_4_detailed.md

  Case 5: KVM_Infra (also KVM_Driver, KVM_EL2_DTB - same root cause)

1. Failed case: KVM_Infra (also KVM_Driver, KVM_EL2_DTB - same root cause)
2. Root cause: Pre-existing platform limitation — Hamoa IoT EVK (iq-x7181) does not have EL2/HYP mode available, preventing KVM initialization. Kernel message: kvm [1]: HYP mode not available. This is a hardware/firmware capability issue, not a kernel regression.
3. Possible fix: This is not a PR-introduced failure. The hamoa-evk platform does not support KVM virtualization. To resolve: (1) Skip KVM tests on hamoa-evk in CI configuration, OR (2) If EL2 support is expected, verify firmware/bootloader configuration enables EL2 and boots kernel at EL2, OR (3) Use a different platform with virtualization extensions enabled for KVM testing.
4. Detail analysis attachment: failed_case_job262825_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Hamoa (IQ-X7181-EVK / QCS615) platform runs with Gunyah hypervisor occupying EL2, preventing Linux KVM from initializing; kernel reports "HYP mode not available" at boot, causing /dev/kvm device node to not be created.
3. Possible fix: Exclude Hamoa platform from KVM test suite in CI configuration, as this platform does not support KVM by design (Gunyah hypervisor occupies EL2). Alternatively, if KVM support is required, the platform firmware must be reconfigured to boot Linux directly in EL2 without Gunyah.
4. Detail analysis attachment: failed_case_job262825_6_detailed.md

Job 262826 | SoC lemans-evk

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

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

  Case 1: ** Probe_Failure_Check (suppressed as known benign per Rule 3)

1. Failed case: ** Probe_Failure_Check (suppressed as known benign per Rule 3)
2. Root cause: ** Bluetooth firmware load errors during early boot are false positives. The QCA Bluetooth driver attempts to load vendor-specific firmware files (qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) that are not present in the rootfs, but successfully falls back to a working firmware path. Bluetooth functionality is fully operational as confirmed by BT_ON_OFF test passing with successful power control and device scanning.
3. Possible fix: No fix required. This is a known benign test artifact. The Probe_Failure_Check test should be updated to suppress Bluetooth firmware load errors when BT_ON_OFF passes, per the suppression rules in lava-known-benign-failures.md Rule 3.
4. Detail analysis attachment: failed_case_job262826_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec on lemans-evk is missing IOMMU group attachment — this is a pre-existing platform/device-tree configuration issue unrelated to the PR changes (which only modify talos-lyra-evk display support).
3. Possible fix: This is not a PR-introduced regression. The test failure should be suppressed for lemans-evk until the video codec device tree node is updated to include proper iommus property, or the test should be updated to mark video codec as optional on platforms where it's not enabled.
4. Detail analysis attachment: failed_case_job262826_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 harness incorrectly marked the test definition as failed despite all individual test cases passing. The test runner completed normally (<LAVA_TEST_RUNNER EXIT>), but LAVA's lava-test-shell action detected an "unfinished test run" condition and applied a fail status. This is a false negative caused by LAVA infrastructure logic, not a genuine kernel or test failure.
3. Possible fix: Re-trigger the LAVA job. If the issue persists, investigate the LAVA test definition's completion detection logic — the test runner may need an explicit success signal or the LAVA job definition may have an incorrect expected test count or completion pattern.
4. Detail analysis attachment: failed_case_job262826_3_detailed.md

Job 262827 | SoC qcs9100-ride

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

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

  Case 1: ** Probe_Failure_Check (Test Infrastructure False Positive)

1. Failed case: ** Probe_Failure_Check (Test Infrastructure False Positive)
2. Root cause: ** The Probe_Failure_Check test flagged a benign cfg80211 regulatory database firmware load failure (regulatory.db missing, error -2/ENOENT) as a probe failure. This is a false positive because: (1) WiFi and Bluetooth are fully functional (WiFi_OnOff and BT_ON_OFF tests both passed), (2) the regulatory.db file is optional and cfg80211 falls back to built-in rules, (3) the error is unrelated to the PR changes (display/DT-only modifications), and (4) this error appears on every boot in this test environment.
3. Possible fix: Update the Probe_Failure_Check test to exclude regulatory.db firmware load failures from the error pattern, or add a suppression rule similar to the WiFi/BT firmware suppression rules in lava-known-benign-failures.md that checks if WiFi_OnOff and BT_ON_OFF tests passed before flagging regulatory.db as a failure. For this specific PR, no kernel changes are required — the failure is a test infrastructure issue, not a regression introduced by the PR.
4. Detail analysis attachment: failed_case_job262827_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test expectation mismatch — the SMMU test expects a legacy Venus video codec device node aa00000.video-codec to be attached to an IOMMU group, but qcs9100-ride uses the newer Iris video driver architecture which creates iris_non_pixel.0 and iris_pixel.0 devices instead (both correctly attached to IOMMU groups 17 and 18).
3. Possible fix: Update the SMMU test's critical device list for qcs9100-ride to check for iris_non_pixel.0 and iris_pixel.0 instead of aa00000.video-codec, or make the video codec check conditional based on the platform's actual video driver architecture.
4. Detail analysis attachment: failed_case_job262827_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because the kernel is running under Gunyah hypervisor (EL1 guest mode) and does not have direct EL2/HYP access required for KVM operation; kernel log shows "kvm [1]: HYP mode not available" at boot.
3. Possible fix: This is not a kernel regression — KVM cannot function when the kernel runs as a guest under a Type-1 hypervisor like Gunyah. Either: (1) skip KVM tests on qcs9100-ride when booted with Gunyah hypervisor (el2gh boot selection), or (2) boot the board without hypervisor (native EL2 mode) if KVM validation is required for this PR.
4. Detail analysis attachment: failed_case_job262827_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform Limitation (EL1 Boot)

1. Failed case: KVM_EL2_DTB — Platform Limitation (EL1 Boot)
2. Root cause: The qcs9100-ride platform boots Linux at EL1 (non-secure supervisor mode) instead of EL2 (Hypervisor mode). KVM requires the kernel to run at EL2 to provide virtualization support. The bootloader/firmware does not hand off control to Linux at EL2, making KVM unavailable. Evidence: boot log line 2968 shows "CPU: All CPU(s) started at EL1" and line 3377 shows "kvm [1]: HYP mode not available".
3. Possible fix: Exclude KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test suite for qcs9100-ride platform, as this SoC does not support KVM due to EL1-only boot configuration. This is a known platform limitation, not a kernel regression. Alternatively, if KVM support is required, the bootloader/firmware must be updated to boot Linux at EL2.
4. Detail analysis attachment: failed_case_job262827_4_detailed.md

  Case 5: KVM_Infra — KVM Host Support Not Available

1. Failed case: KVM_Infra — KVM Host Support Not Available
2. Root cause: The qcs9100-ride (LeMans) platform does not provide EL2 (hypervisor mode) support; kernel message kvm [1]: HYP mode not available indicates the CPU is not running at or does not support EL2, preventing KVM initialization and /dev/kvm device node creation despite CONFIG_KVM being enabled.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. Mark KVM_Infra, KVM_Driver, and KVM_EL2_DTB tests as expected failures (XFAIL) or skip them entirely for qcs9100-ride in the LAVA test definition, as this SoC does not support virtualization host mode.
4. Detail analysis attachment: failed_case_job262827_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on qcs9100-ride because the platform boots under the Gunyah hypervisor at EL1, not in HYP mode (EL2). The kernel message "kvm [1]: HYP mode not available" indicates KVM requires EL2 but the CPU is running at EL1 under Gunyah's control.
3. Possible fix: This is a platform configuration issue unrelated to the PR (which only modifies display/DSI device trees). To enable KVM on this platform, either: (1) configure the boot flow to run Linux at EL2 without Gunyah, or (2) use nested virtualization if Gunyah supports it, or (3) mark KVM tests as expected-fail/skip for qcs9100-ride when booted under Gunyah.
4. Detail analysis attachment: failed_case_job262827_6_detailed.md

Job 262828 | SoC purwa-evk

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

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

  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: Suppress these four specific probe failures in the Probe_Failure_Check test for purwa-evk platform by adding platform-specific exclusion rules: (1) qcom_qseecom_uefisecapp.*error -16, (2) qcom-pcie 1bd0000.*error -61, (3) qcom-pcie 1bf8000.*error -61, (4) regulatory.*error -2 when WiFi/BT functional tests pass. Alternatively, update the test to cross-reference functional validation results before flagging probe errors as failures.
4. Detail analysis attachment: failed_case_job262828_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) on purwa-evk (x1e80100) is not attached to any IOMMU group, indicating missing device tree iommus property or video codec driver not probing/registering with IOMMU subsystem; this is a pre-existing platform configuration issue unrelated to the PR's display bridge changes.
3. Possible fix: Add iommus property to the video-codec@aa00000 device tree node in arch/arm64/boot/dts/qcom/x1e80100.dtsi, or investigate why the qcom_venus video driver is not probing on this platform; verify the fix by confirming the device appears in /sys/kernel/iommu_groups/*/devices/ after boot.
4. Detail analysis attachment: failed_case_job262828_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a pre-existing platform hardware limitation, not a PR-introduced regression. The PR (display/HDMI bridge changes for talos-lyra-evk) does not modify KVM, virtualization configs, or Purwa platform files. No kernel fix is required. To enable KVM on this platform: (1) verify the bootloader/firmware boots the kernel at EL2 (not EL1), (2) ensure CPU supports ARMv8 virtualization extensions, (3) if the platform uses a hypervisor (e.g., Gunyah), KVM cannot run as a nested hypervisor without nested virtualization support. If KVM is not a requirement for Purwa IoT EVK, mark this test as "not applicable" for this platform in the CI test matrix.
4. Detail analysis attachment: failed_case_job262828_3_detailed.md

  Case 4: KVM_EL2_DTB (Test Infrastructure Issue - Platform Limitation)

1. Failed case: KVM_EL2_DTB (Test Infrastructure Issue - Platform Limitation)
2. Root cause: The purwa-evk platform does not support ARM EL2 (Hypervisor mode), which is a mandatory hardware prerequisite for KVM; the kernel correctly detected this limitation and reported "HYP mode not available", preventing /dev/kvm creation.
3. Possible fix: Exclude KVM test suite from purwa-evk LAVA job definitions, as this platform lacks the required virtualization hardware extensions; alternatively, add a platform capability check to skip KVM tests gracefully when EL2 is unavailable.
4. Detail analysis attachment: failed_case_job262828_4_detailed.md

  Case 5: KVM Infrastructure Test Failure — Platform Configuration Limitation

1. Failed case: KVM Infrastructure Test Failure — Platform Configuration Limitation
2. Root cause: KVM driver cannot initialize on purwa-evk because the platform boots with Gunyah hypervisor at EL2, leaving the kernel running as a Primary VM at EL1 without HYP mode access. KVM requires EL2 to operate. This is expected behavior for this platform configuration, not a kernel bug.
3. Possible fix: This is not a failure requiring a fix — it is the expected behavior for purwa-evk with Gunyah hypervisor enabled. To run KVM tests, either: (1) use a different platform that boots Linux directly at EL2 without a hypervisor, or (2) reconfigure purwa-evk to boot without Gunyah (if supported by the platform). For CI purposes, exclude KVM tests from the purwa-evk test suite or mark them as expected-skip for this platform.
4. Detail analysis attachment: failed_case_job262828_5_detailed.md

  Case 6: 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: Exclude KVM tests from the Purwa IoT EVK LAVA job definition, as this board is configured for Gunyah-based virtualization and cannot support KVM. Alternatively, if KVM testing is required, reconfigure the board to boot Linux directly at EL2 without the Gunyah hypervisor (requires bootloader/firmware changes and is not recommended if Gunyah VM functionality is needed).
4. Detail analysis attachment: failed_case_job262828_6_detailed.md

Job 262829 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — WiFi Driver Probe Failure

1. Failed case: Probe_Failure_Check — WiFi Driver Probe Failure
2. Root cause: ath11k_pci WiFi driver probe failed with -ETIMEDOUT (-110) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (error -ENOENT/-2), causing MHI power-up timeout during device initialization.
3. Possible fix: Add the missing ath11k WiFi firmware files for WCN6855 hw2.1 (specifically ath11k/WCN6855/hw2.1/nfa765/amss.bin and related board files) to the rootfs firmware directory (/lib/firmware/). The firmware package linux-firmware-ath11k or equivalent must be included in the Yocto image recipe for monaco-evk builds.
4. Detail analysis attachment: failed_case_job262829_1_detailed.md

  Case 2: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing WCN6855 hw2.1 nfa765 firmware files to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). Specifically, ensure amss.bin and related firmware blobs are present. Verify the firmware package version matches the kernel driver expectations for WCN6855 hw2.1 on monaco-evk.
4. Detail analysis attachment: failed_case_job262829_2_detailed.md

  Case 3: ** WiFi Driver Probe Failure — Firmware Missing (monaco-evk WCN6855)

1. Failed case: ** WiFi Driver Probe Failure — Firmware Missing (monaco-evk WCN6855)
2. Root cause: ** The ath11k WiFi driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs (-2 ENOENT). Without firmware, the MHI bus cannot power up the WiFi chipset, causing the probe to time out after waiting for MHI initialization. This is a pre-existing board/firmware packaging issue specific to monaco-evk, not introduced by PR Add display overlays for EVK board #1331 (which only modifies Talos-Lyra HDMI DT nodes).
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/ath11k/WCN6855/hw2.1/nfa765/). Verify the firmware package for monaco-evk includes the board-specific nfa765 variant firmware. If the firmware is proprietary and not yet available in the CI image, either: (1) update the CI rootfs build to include it, or (2) suppress this test for monaco-evk until firmware is available.
4. Detail analysis attachment: failed_case_job262829_3_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: WiFi PCIe device (ath11k_pci at 0000:01:00.0) probe timeout (-ETIMEDOUT) on monaco-evk platform, causing cascading failures in Probe_Failure_Check, WiFi_Firmware_Driver, and WiFi_OnOff tests. This is a pre-existing platform/firmware issue unrelated to the PR's DTS changes for talos-lyra-evk.
3. Possible fix: This is not a PR-introduced regression. The PR modifies talos-lyra-evk DTS (HDMI bridge), while the failure occurs on monaco-evk WiFi hardware. Investigate monaco-evk WiFi firmware availability (ath11k/WCN6855/hw2.1/nfa765/amss.bin missing or corrupt) and PCIe link training issues. If this is a known monaco-evk lab infrastructure issue, add to the platform-specific known issues list.
4. Detail analysis attachment: failed_case_job262829_4_detailed.md

Job 262830 | SoC qcs8300-ride

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

Failed test cases in LAVA job 262830 (SoC: qcs8300-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: These failures are NOT introduced by PR Add display overlays for EVK board #1331 (which only modifies Talos Lyra EVK display device tree and defconfig). For the Aquantia PHY: add firmware-name property to the PHY node in arch/arm64/boot/dts/qcom/qcs8300-ride.dtsi if custom firmware is required, or update the driver to make firmware-name optional. For regulatory.db: this is benign when CONFIG_CFG80211_INTERNAL_REGDB=y is set; no action needed unless external regulatory database is required.
4. Detail analysis attachment: failed_case_job262830_1_detailed.md

  Case 2: ** Ethernet_Basic_Validation

1. Failed case: ** Ethernet_Basic_Validation
2. Root cause: ** Aquantia AQR115C PHY driver probe failure (error -22 EINVAL) due to missing firmware-name property in the qcs8300-ride device tree PHY node; the Ethernet MAC driver cannot attach to the PHY because the PHY driver failed to initialize.
3. Possible fix: Add the firmware-name property to the Ethernet PHY node in the qcs8300-ride device tree (e.g., firmware-name = "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld"; or the appropriate firmware file for AQR115C on this platform). This is a pre-existing board configuration issue, not introduced by PR Add display overlays for EVK board #1331.
4. Detail analysis attachment: failed_case_job262830_2_detailed.md

  Case 3: ** KVM Driver Initialization Failure — /dev/kvm device node not created

1. Failed case: ** KVM Driver Initialization Failure — /dev/kvm device node not created
2. Root cause: ** The kernel is running at EL1 (normal OS mode) instead of EL2 (hypervisor mode). ARM64 KVM requires EL2 to enable virtualization extensions. The QCS8300 Ride board's bootloader is configured to boot the kernel at EL1, preventing KVM initialization. This is a platform firmware configuration issue, not a kernel or PR-introduced regression.
3. Possible fix: Configure the QCS8300 Ride board's bootloader (ABL/UEFI) to boot the kernel at EL2 instead of EL1. This requires updating the bootloader firmware or boot configuration to enable hypervisor mode. Alternatively, mark KVM tests as "not applicable" for this board in the LAVA test suite until the bootloader is updated.
4. Detail analysis attachment: failed_case_job262830_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM driver did not initialize on QCS8300 Ride platform — CONFIG_KVM is enabled but /dev/kvm device node was not created, indicating the KVM ARM driver failed to probe or the platform does not support EL2 virtualization extensions required for KVM.
3. Possible fix: Verify QCS8300 (Monaco) hardware supports ARM virtualization extensions (EL2/VHE); check bootloader/firmware configuration for EL2 enablement; if hardware supports it, investigate why KVM ARM driver did not probe (check dmesg for silent probe failures or missing device tree nodes); this is a pre-existing platform issue unrelated to PR Add display overlays for EVK board #1331 (which only modifies HDMI bridge DTS nodes).
4. Detail analysis attachment: failed_case_job262830_4_detailed.md

  Case 5: KVM Infrastructure Failure — Gunyah Hypervisor Conflict

1. Failed case: KVM Infrastructure Failure — Gunyah Hypervisor Conflict
2. Root cause: QCS8300 platform runs Gunyah hypervisor in primary mode which occupies EL2, preventing KVM from initializing. Hypervisor boot log shows "Failed to register KP" error, and CONFIG_KVM is enabled but /dev/kvm device node is never created because KVM cannot access EL2 when Gunyah is active.
3. Possible fix: This is a platform architecture limitation, not a PR-introduced regression. KVM and Gunyah cannot coexist on QCS8300 in the current configuration. Either: (1) Disable KVM tests for QCS8300/Monaco targets in CI, or (2) Use a different platform that supports nested virtualization, or (3) Configure Gunyah to run in a mode that allows KVM (requires hypervisor firmware changes).
4. Detail analysis attachment: failed_case_job262830_5_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test framework issue — the test runner script (result_parse.sh) completed execution and printed <LAVA_TEST_RUNNER EXIT> but failed to send the required <LAVA_SIGNAL_ENDRUN> signal to LAVA before exiting, causing LAVA to mark the test run as "unfinished" despite all individual tests completing successfully.
3. Possible fix: Fix the result_parse.sh script in the test infrastructure to ensure it sends <LAVA_SIGNAL_ENDRUN 0_qcom-next-ci-premerge-tests <uuid>> before the test runner exits; verify the script logic handles all exit paths correctly and doesn't terminate prematurely.
4. Detail analysis attachment: failed_case_job262830_6_detailed.md

Job 262831 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Two pre-existing, platform-specific firmware load failures unrelated to the PR changes: (1) cfg80211 regulatory.db firmware missing (benign - WiFi functional as confirmed by WiFi_OnOff PASS), (2) Renesas xhci-pci USB controller firmware missing (benign - external PCIe USB controller not required for core platform functionality on RB3gen2).
3. Possible fix: Suppress these two known benign probe failures in the Probe_Failure_Check test for qcs6490-rb3gen2 platform, as they represent optional/external hardware components that do not impact core kernel functionality. The PR (display/panel DT changes for talos-lyra-evk) does not introduce or affect these failures.
4. Detail analysis attachment: failed_case_job262831_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test detected two probe/firmware-related errors in kernel logs: (1) regulatory.db firmware file missing (error -2) for the faux_driver regulatory subsystem, and (2) xhci-pci-renesas PCIe USB controller probe failure (error -2). These are pre-existing platform/configuration issues unrelated to the PR changes, which only modify device tree files for the talos-lyra-evk board (not qcs6490-rb3gen2).
3. Possible fix: These failures are not introduced by PR Add display overlays for EVK board #1331. The PR modifies only talos-lyra-evk DTS files and defconfig for display support, while the test ran on qcs6490-rb3gen2. The regulatory.db firmware is a known optional file (wireless regulatory database), and the Renesas USB controller probe failure is a board-specific hardware/firmware issue. Mark this test as a known pre-existing issue for qcs6490-rb3gen2 or add these specific error patterns to the test's benign failure suppression list.
4. Detail analysis attachment: failed_case_job262831_2_detailed.md

Job 262832 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test script incorrectly assumes 8 CPUs and attempts to parse non-existent CPU columns (4-7) from /proc/interrupts, treating the interrupt descriptor fields (GICv3, 19, Level, arch_timer) as CPU timer counts, causing bash integer comparison errors at line 75.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online (or use the same runtime CPU discovery logic as the hotplug and Interrupts tests) instead of hardcoding an 8-CPU assumption. The script should only validate timer increments for CPUs that actually exist on the platform.
4. Detail analysis attachment: failed_case_job262832_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform-specific probe failures on shikra-iqs-evk: ucsi_ccg USB-C controller missing firmware file (ccg_secondary.cyacd2), tpm_tis_spi TPM device timeout (-110), regulatory.db WiFi regulatory database missing, and audio codec deferred probe due to missing mclk clock — none introduced by this PR which only modifies talos-lyra-evk device tree files.
3. Possible fix: These are known benign platform-specific failures on shikra-iqs-evk that do not affect core functionality: (1) ucsi_ccg and tpm_tis_spi failures are due to optional hardware/firmware not present on this board variant; (2) regulatory.db is compiled into cfg80211 and the missing file warning is cosmetic; (3) audio codec deferred probe is expected when audio subsystem is not fully configured. No action required for this PR — failures are pre-existing baseline issues unrelated to the talos-lyra-evk display overlay changes.
4. Detail analysis attachment: failed_case_job262832_2_detailed.md

  Case 3: PCIe — QPS615 Firmware Validation Failure

1. Failed case: PCIe — QPS615 Firmware Validation Failure
2. Root cause: Test infrastructure issue — required firmware file TC956X_Firmware_PCIeBridge.bin is missing from the rootfs /lib/firmware directory. The QPS615 PCIe switch (vendor 0x1179, device 0x0623) was successfully enumerated and the bridge ports are functional, but the test's firmware validation step failed because the TC956X firmware binary is not packaged in the test image. This is a pre-existing infrastructure issue unrelated to the PR under test (PR Add display overlays for EVK board #1331 only modifies talos-lyra-evk display device trees; this failure occurred on shikra-iqs-evk).
3. Possible fix: Add TC956X_Firmware_PCIeBridge.bin to the rootfs image build recipe (Yocto/meta-qcom layer or equivalent) under /lib/firmware/. If the firmware is proprietary and cannot be redistributed, either: (1) relax the test to make firmware presence optional and report SKIP instead of FAIL when absent, or (2) document this as a known limitation for shikra-iqs-evk in the test suite and suppress the failure in CI for boards where the firmware is not available.
4. Detail analysis attachment: failed_case_job262832_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (DWC3/xHCI) driver did not probe on shikra-iqs-evk — no USB root hubs exposed in /sys/class/usb_host/ and lsusb cannot enumerate the bus, despite USB core subsystem being initialized and USB platform devices (4c00000.usb, 4e00000.usb) being added to IOMMU groups during boot.
3. Possible fix: Investigate shikra-iqs-evk device tree USB node configuration (dr_mode, PHY phandles, clocks, regulators, Type-C connector bindings) and check kernel config for CONFIG_USB_DWC3=y/m, CONFIG_USB_DWC3_QCOM=y/m, CONFIG_USB_XHCI_HCD=y/m; enable USB driver debug (CONFIG_USB_DEBUG, CONFIG_USB_DWC3_DEBUG) and capture full dmesg to identify why DWC3/xHCI probe is not occurring.
4. Detail analysis attachment: failed_case_job262832_4_detailed.md

  Case 5: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** KVM initialization failed because HYP mode (EL2) is not available. The shikra-iqs-evk board is running under the Gunyah hypervisor (boot log shows "Hypervisor cold boot, version: gunyah-mobile-98db777b6"), which occupies EL2. KVM requires direct access to EL2 to function, but when a hypervisor like Gunyah is already running at that exception level, the kernel (running at EL1) cannot access HYP mode. The kernel explicitly reports: kvm [1]: HYP mode not available at boot time (line 2921 timestamp [3.173388]).
3. Possible fix: This is not a kernel bug or PR-introduced regression. The KVM_Driver test is not applicable to this platform configuration. Either: (1) disable KVM tests for shikra-iqs-evk in the LAVA test suite when Gunyah hypervisor is present, or (2) boot the kernel without the Gunyah hypervisor if KVM functionality is required for testing. The PR changes (HDMI bridge DTS modifications) are unrelated to KVM and did not cause this failure.
4. Detail analysis attachment: failed_case_job262832_5_detailed.md

  Case 6: ** KVM_EL2_DTB (test infrastructure issue, not a kernel failure)

1. Failed case: ** KVM_EL2_DTB (test infrastructure issue, not a kernel failure)
2. Root cause: ** KVM cannot initialize on Shikra IQS EVK because the Gunyah hypervisor is active and owns EL2 (HYP mode). KVM requires exclusive EL2 access to function. The kernel correctly detects this conflict and reports "HYP mode not available", preventing /dev/kvm creation. This is expected platform behavior, not a regression.
3. Possible fix: Exclude KVM-dependent tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the Shikra IQS EVK test suite, or disable Gunyah and rebuild the firmware/bootloader stack to allow KVM to own EL2. The PR changes (display/panel DT updates) are unrelated and do not cause this failure.
4. Detail analysis attachment: failed_case_job262832_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available on shikra-iqs-evk — the board is running under Gunyah hypervisor which reserves EL2, preventing KVM from initializing and creating /dev/kvm.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The PR changes only Talos device tree display nodes and does not affect Shikra or KVM. To enable KVM on Shikra, either: (1) disable Gunyah hypervisor in the boot configuration to allow KVM direct EL2 access, or (2) use nested virtualization if Gunyah supports it, or (3) skip KVM tests on platforms where Gunyah is enabled.
4. Detail analysis attachment: failed_case_job262832_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed because HYP mode (EL2) is not available to the kernel. The Gunyah hypervisor is running at EL2 (confirmed by boot log: "Hypervisor cold boot, version: gunyah-mobile-98db777b6"), which prevents the Linux KVM subsystem from accessing EL2. The kernel log shows kvm [1]: HYP mode not available at boot time. CONFIG_KVM is enabled in the kernel config, but /dev/kvm device node is not created because KVM initialization fails when it cannot access EL2.
3. Possible fix: This is a known platform limitation on shikra-iqs-evk when running with Gunyah hypervisor. The KVM test suite should be skipped on this platform configuration, or the test should be updated to detect and skip when a hypervisor is already running at EL2. To enable KVM, the platform would need to boot without the Gunyah hypervisor, or use nested virtualization if supported. For CI purposes, mark KVM tests as expected-to-skip on shikra-iqs-evk with Gunyah enabled.
4. Detail analysis attachment: failed_case_job262832_8_detailed.md