[weiden (WeiDeng-weiden)]

Summary

Describe the Monaco AC EVK PCIe M.2 Key E connector, its PCIe0 and UART2 graph connections, and its 3.3 V supply. Add the serial1 alias required to enumerate the Bluetooth serdev device on UART2.

Dependency

Depends on #1132. Please merge #1132 before this PR.

This branch currently includes the three prerequisite commits from #1132 rebased onto qcom-6.18.y, followed by the M.2 change. The current PR comparison therefore includes those prerequisites. After #1132 merges, this branch needs to be rebased onto its actual merge result so the comparison contains only the M.2 change.

The first prerequisite required resolving a conflict with newer Monaco EVK suspend support; both system_suspend and its system_pd reference were preserved and checked in the compiled DTB.

CRs-fixed: 4709469

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4709469 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4709469

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4709469 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4709469

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[qlijarvis]

PR #1400 — validate-patch

PR: #1400

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

1. Lore link present: Yes — all 4 commits link to lore (commit 1/4 links to v5 cover letter; commits 2-4 link to individual patches)
2. Lore link matches PR commits: Yes — diff content faithful to lore for commits 2-4; commit 1/4 is a local revert (not an upstream patch)
3. Upstream patch status:
   • Commits 2/4 and 3/4: ✅ ACKed — merged into mainline by Bjorn Andersson on 2026-09-03
   • Commit 4/4: ⏳ Decision Pending — Reviewed-by from Konrad Dybcio; awaiting merge decision
   • Commit 1/4: N/A — local revert, not an upstream patch
4. PR present in qcom-next/topics: Partial - 1/4 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1400 - Monaco AC EVK v5 series + M.2 Key E connector
Verdict: ⚠️ PARTIAL

---

Summary by Commit

Commit 1/4: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"

Check	Status	Note
Lore link present	✅	Links to v5 cover letter
Subject matches upstream	⚠️	This is a local revert, not an upstream patch
Body preserves rationale	✅	Explains v5 dropped shared dtsi
Authorship	⚠️	Faruque Ansari authored the revert; lore series by Umang Chheda
Upstream status	N/A	Revert is local tree management, not upstream

Analysis: This commit reverts a previous commit (8fad712) that introduced monaco-evk-common.dtsi. The lore v5 series dropped the shared dtsi approach per maintainer feedback (Dmitry). The revert is correctly explained and links to the v5 cover letter. However, this is a local tree management commit, not an upstream patch itself.

---

Commit 2/4: UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK board

Check	Status	Note
Lore link present	✅	20260626111301.3479559-3
Subject matches upstream	✅	Identical
Body preserves rationale	✅	Full description preserved
Authorship preserved	✅	Umang Chheda (matches lore)
Co-developed-by usage	✅	Faruque Ansari with matching Signed-off-by
Reviewed-by tags	✅	Konrad Dybcio + Avaneesh Dwivedi present
Upstream status	✅ ACKed	Applied by Bjorn Andersson on 2026-09-03

Diff comparison: Content matches lore patch v5 2/3. Trailer order differs slightly (PR has Umang's Signed-off-by before Faruque's; lore has Faruque's first), but both are valid.

---

Commit 3/4: UPSTREAM: arm64: dts: qcom: monaco-ac-evk: Add IFP mezzanine

Check	Status	Note
Lore link present	✅	20260626111301.3479559-4
Subject matches upstream	✅	Identical
Body preserves rationale	✅	Describes combined DTB
Authorship preserved	✅	Umang Chheda (matches lore)
Extra Signed-off-by	⚠️	PR adds Faruque Ansari Signed-off-by not in lore
Reviewed-by tags	✅	Konrad Dybcio present
Upstream status	✅ ACKed	Applied by Bjorn Andersson as 0fb8fb4

Issue: Lore patch has only Signed-off-by: Umang Chheda. PR adds Signed-off-by: Faruque Ansari without corresponding Co-developed-by: tag. This suggests Faruque may have cherry-picked/applied the patch locally, which is acceptable, but the extra Signed-off-by should ideally be documented in the commit message or removed if not a co-author.

---

Commit 4/4: FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector

Check	Status	Note
Lore link present	✅	20261021104709.1428234-1
Subject matches upstream	✅	Identical
Body preserves rationale	✅	Full description preserved
Authorship preserved	✅	Wei Deng (matches lore)
Upstream-Status tag	✅	Upstream-Status: Submitted present
Reviewed-by tags	⚠️	Konrad Dybcio reviewed on lore but tag missing in PR
Upstream status	⏳ Decision Pending	Reviewed-by from Konrad; no merge signal yet

Issue: Lore thread shows Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> but this tag is missing from the PR commit. Should be added.

---

Diff Comparison

Commit	File	Status	Notes
1/4	Makefile, monaco-ac-evk.dts, monaco-evk-common.dtsi, monaco-evk.dts	✅	Revert diff is local tree management
2/4	Makefile, monaco-ac-evk.dts	✅	Content matches lore v5 2/3
3/4	Makefile	✅	Content matches lore v5 3/3
4/4	monaco-ac-evk.dts	✅	Content matches lore patch

---

Upstream Patch Status

Commit	Community Verdict
1/4 (Revert)	N/A — local tree management, not an upstream patch
2/4	✅ ACKed — Applied by Bjorn Andersson on 2026-09-03 (commit 0fb8fb4 in mainline)
3/4	✅ ACKed — Applied by Bjorn Andersson on 2026-09-03 (commit 0fb8fb4 in mainline)
4/4	⏳ Decision Pending — Reviewed-by from Konrad Dybcio; no merge/NAK signal yet

---

Integration Presence (qcom-next/topics)

Per integration_presence_report.md:

Commit	qcom-next	topics	Final
1/4 (Revert)	partial	partial	partial
2/4	present	skipped	present
3/4	present	skipped	present
4/4	partial	present (9cd4e72)	present

Overall: 3/4 commits fully present; 1/4 (Revert) has partial evidence.

---

Issues Found

1. Commit 1/4 (Revert): Authorship mismatch — Faruque Ansari authored the revert, but the lore series is by Umang Chheda. This is acceptable for local tree management (reverting a previous commit to align with upstream v5), but the revert commit itself is not an upstream patch.

2. Commit 3/4: Extra Signed-off-by: Faruque Ansari not present in lore. If Faruque co-developed this patch, a Co-developed-by: tag should precede the Signed-off-by. If Faruque only applied/cherry-picked the patch, the extra Signed-off-by is acceptable but should be noted.

3. Commit 4/4: Missing Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> tag present in lore thread. Should be added to the PR commit.

---

Recommendation

Merge with minor corrections:

• Commit 1/4: Accept as-is. This is local tree management to align with upstream v5 series.
• Commit 2/4: Accept as-is. Trailer order differs slightly from lore but is valid.
• Commit 3/4: Accept as-is, but note the extra Signed-off-by from Faruque. If Faruque co-developed, add Co-developed-by: tag. Otherwise, document that Faruque applied the patch.
• Commit 4/4: Add missing Reviewed-by: Konrad Dybcio tag before merging.

---

Final Summary

1. Lore link present: Yes — all 4 commits link to lore (commit 1/4 links to v5 cover letter; commits 2-4 link to individual patches)
2. Lore link matches PR commits: Yes — diff content faithful to lore for commits 2-4; commit 1/4 is a local revert (not an upstream patch)
3. Upstream patch status:
   • Commits 2/4 and 3/4: ✅ ACKed — merged into mainline by Bjorn Andersson on 2026-09-03
   • Commit 4/4: ⏳ Decision Pending — Reviewed-by from Konrad Dybcio; awaiting merge decision
   • Commit 1/4: N/A — local revert, not an upstream patch
4. PR present in qcom-next/topics: Partial — 3/4 commits fully present; 1/4 (Revert) has partial evidence

Deterministic Integration Presence

Integration Presence Report

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

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 17bbb4b37bbc4fc5827b4667445a0c43967c0f48
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: arm64: dts: qcom: monaco-evk: Extract	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] UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present
3/4	[PATCH 3/4] UPSTREAM: arm64: dts: qcom: monaco-ac-evk: Add IFP	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present
4/4	[PATCH 4/4] FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the	partial - subject or partial tree evidence found, but full change was not verified	present - exact patch-id match at 9cd4e72	present

Final Status

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

[qlijarvis]

PR #1400 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	2 commits with warnings (undocumented vendor, Co-developed-by mismatch)
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Missing required property: vdda-refgen-supply
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	Revert commit missing prefix
tag-check	❌	Revert commit missing required prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1400 - Monaco AC EVK board support and PCIe M.2 Key E connector
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/41797981091

Checker	Result	Summary
checkpatch	❌	2 commits with warnings (undocumented vendor, Co-developed-by mismatch)
dt-binding-check	⏭️	No binding changes
dtb-check	❌	Missing required property: vdda-refgen-supply
sparse-check	⏭️	No C/H file changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	Revert commit missing prefix
tag-check	❌	Revert commit missing required prefix

---

❌ checkpatch

Root cause: Two commits have checkpatch warnings that need attention.

Failure details:

Commit 1: a2aa543 - Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"

WARNING: DT compatible string vendor "usb5e3" appears un-documented
#2180: FILE: arch/arm64/boot/dts/qcom/monaco-evk.dts:1096:
+		compatible = "usb5e3,610";

WARNING: DT compatible string vendor "usb5e3" appears un-documented
#2210: FILE: arch/arm64/boot/dts/qcom/monaco-evk.dts:1126:
+		compatible = "usb5e3,625";

Commit 2: f76d560 - UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK board

WARNING: Co-developed-by and Signed-off-by: name/email do not match
#57: 
Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>

Fix:

For Commit 1 (usb5e3 vendor):
This is a revert commit that restores code containing usb5e3 compatible strings. The vendor prefix usb5e3 needs to be documented:

# Add to Documentation/devicetree/bindings/vendor-prefixes.yaml:
"^usb5e3,.*":
  description: Genesys Logic, Inc.

Alternatively, if this is a pre-existing issue from the original code being reverted, document this in the commit message as a known limitation.

For Commit 2 (Co-developed-by mismatch):
The Co-developed-by: trailer should only be used for genuine co-authors who contributed substantially to the patch. If Faruque Ansari is the primary author (as indicated by the From: line), remove the Co-developed-by: line:

git rebase -i <base_sha>   # mark commit f76d560d1419 as 'edit'
# Edit commit message to remove the Co-developed-by line
git commit --amend
git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..8de7b7286e98

---

❌ dtb-check

Root cause: PCIe PHY nodes are missing the required vdda-refgen-supply property per the binding schema.

Failure details:

monaco-ac-evk.dtb: phy@1c04000 (qcom,qcs8300-qmp-gen4x2-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

monaco-ac-evk-ifp-mezzanine.dtb: phy@1c04000 (qcom,qcs8300-qmp-gen4x2-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

monaco-ac-evk-ifp-mezzanine.dtb: phy@1c14000 (qcom,sa8775p-qmp-gen4x4-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

Fix:

Add the missing vdda-refgen-supply property to the PCIe PHY nodes in the monaco-ac-evk DTS files. The property should reference the appropriate voltage regulator:

&pcie0_phy {
	vdda-refgen-supply = <&vreg_l3a>;  /* or appropriate regulator */
};

&pcie1_phy {
	vdda-refgen-supply = <&vreg_l3a>;  /* or appropriate regulator */
};

You'll need to identify the correct regulator from the board schematic or reference design. This is typically a 0.9V or 1.2V supply for PCIe PHY reference generation.

Reproduce locally:

make -j$(nproc) O=out defconfig
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/monaco-ac-evk.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/monaco-ac-evk-ifp-mezzanine.dtb

---

❌ check-patch-compliance

Root cause: The revert commit subject does not start with a required prefix.

Failure details:

Checking commit: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
Commit summary does not start with a required prefix

Fix:

The check-patch-compliance checker requires all commits to start with one of: FROMLIST:, FROMGIT:, UPSTREAM:, or BACKPORT:. Revert commits must also carry a prefix before the word Revert.

Update the commit subject:

git rebase -i <base_sha>   # mark commit a2aa543f0fcd as 'reword'
# Change subject from:
#   Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
# To:
#   UPSTREAM: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
# or
#   FROMLIST: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
git rebase --continue

Choose UPSTREAM: if the revert itself has been merged upstream, or FROMLIST: if it's posted but not yet merged.

---

❌ tag-check

Root cause: Same as check-patch-compliance - the revert commit is missing a required subject prefix.

Note: The tag-check applies to all branches except qcom-next and qcom-next-staging. Based on the integration presence report showing checks against qcom-next, if this PR targets qcom-next or qcom-next-staging directly, this check would not apply. However, if targeting any other branch (e.g., a feature branch), the prefix is mandatory.

Failure details:

Commit a2aa543f0fcd ("Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi""): 
subject line does not start with a required prefix.

Fix:

Same fix as check-patch-compliance above - add a prefix (UPSTREAM:, FROMLIST:, FROMGIT:, or BACKPORT:) before Revert.

---

Verdict

3 blockers must be fixed before merge:

1. dtb-check (CRITICAL): Add missing vdda-refgen-supply properties to PCIe PHY nodes - this is a schema validation failure that indicates incomplete hardware description.

2. check-patch-compliance / tag-check: Add required prefix to the revert commit subject line.

3. checkpatch (MEDIUM):

   • Document the usb5e3 vendor prefix in vendor-prefixes.yaml, or note in commit message that this is pre-existing from reverted code.
   • Fix the Co-developed-by trailer mismatch in commit 2.

Priority: Fix dtb-check first (missing required property), then the prefix issue (affects 2 checkers), then checkpatch warnings.

[Shiraz Hashim (shashim-quic)]

Upstream-Status: Submitted
Link: https://lore.kernel.org/all/20261021104709.1428234-1-wei.deng@oss.qualcomm.com/
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com

Remove Upstream-Status: from commit log, Link: tag is sufficient.

[qlijarvis]

PR #1400 — validate-patch

PR: #1400

Verdict	Issues	Detailed Report
⚠️	0	Full report

Final Summary

1. Lore link present: Yes — all 4 commits have lore links
2. Lore link matches PR commits: Yes — commits 2/4, 3/4, and 4/4 faithfully represent their lore sources; commit 1/4 is a revert with contextual link
3. Upstream patch status:
   • Commit 1/4: N/A (revert)
   • Commits 2/4, 3/4: ✅ Accepted and merged upstream
   • Commit 4/4: ⏳ Under review (Reviewed-by present, awaiting final merge confirmation)
4. PR present in qcom-next/topics: Partial - 1/4 commit(s) only have partial integration evidence

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: [#1400] arm64: dts: qcom: monaco-ac-evk: Add support and revert previous common dtsi approach
Verdict: ⚠️ PARTIAL

---

Commit 1/4: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"

Upstream commit: N/A (revert of internal commit 8fad712)
Lore link: https://lore.kernel.org/all/20260626111301.3479559-1-umang.chheda@oss.qualcomm.com/ (cover letter)

Commit Message

Check	Status	Note
Subject describes revert	✅	Clear revert statement
Body explains rationale	✅	Explains v5 series drops shared dtsi approach
Link present	⚠️	Links to cover letter (0/2), not a specific patch - acceptable for revert providing context
Authorship	✅	Faruque Ansari - appropriate for revert author

Diff

File	Status	Notes
Makefile	✅	Removes monaco-ac-evk.dtb and overlay references
monaco-ac-evk.dts	✅	Deletes old file (31 lines)
monaco-evk-common.dtsi	✅	Deletes shared dtsi (1068 lines)
monaco-evk.dts	✅	Restores inline content

Upstream Patch Status

Verdict: N/A — This is a revert of an internal commit to align with upstream v5 series design decision

Integration Presence

Status: ⚠️ Partial — integration_presence_report.md shows "partial - subject or partial tree evidence found, but full change was not verified"

---

Commit 2/4: UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK board

Upstream commit: https://lore.kernel.org/all/20260626111301.3479559-3-umang.chheda@oss.qualcomm.com/
Lore patch: [PATCH v5 2/3]

Commit Message

Check	Status	Note
Subject matches upstream	✅	Identical (with UPSTREAM: prefix added)
Body preserves rationale	✅	Full commit message preserved
Authorship preserved	✅	From: Umang Chheda matches lore
Co-developed-by present	✅	Faruque Ansari - matches lore patch
Link tag correct	✅	Points to correct lore message-ID

Diff

File	Status	Notes
Makefile	✅	Adds monaco-ac-evk.dtb
monaco-ac-evk.dts	✅	New file with 938 lines - matches lore patch structure

Upstream Patch Status

Verdict: ✅ ACKed — "Applied, thanks!" from maintainer; Reviewed-by: Konrad Dybcio, Acked-by: Krzysztof Kozlowski

Integration Presence

Status: ✅ Present — integration_presence_report.md shows "present - all checked added lines are present" in qcom-next

---

Commit 3/4: UPSTREAM: arm64: dts: qcom: monaco-ac-evk: Add IFP mezzanine

Upstream commit: https://lore.kernel.org/all/20260626111301.3479559-4-umang.chheda@oss.qualcomm.com/
Lore patch: [PATCH v5 3/3]

Commit Message

Check	Status	Note
Subject matches upstream	✅	Identical (with UPSTREAM: prefix added)
Body preserves rationale	✅	Full commit message preserved
Authorship preserved	✅	From: Umang Chheda matches lore
Link tag correct	✅	Points to correct lore message-ID
Additional Signed-off-by	✅	Faruque Ansari added as committer - appropriate

Diff

File	Status	Notes
Makefile	✅	Adds monaco-ac-evk-ifp-mezzanine combined DTB

Upstream Patch Status

Verdict: ✅ ACKed — "Applied, thanks!" from maintainer; Reviewed-by: Konrad Dybcio, Acked-by: Krzysztof Kozlowski

Integration Presence

Status: ✅ Present — integration_presence_report.md shows "present - all checked added lines are present" in qcom-next

---

Commit 4/4: FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector

Upstream commit: https://lore.kernel.org/all/20261021104709.1428234-1-wei.deng@oss.qualcomm.com/
Lore patch: [PATCH]

Commit Message

Check	Status	Note
Subject matches upstream	✅	Identical (with FROMLIST: prefix added)
Body preserves rationale	✅	Full commit message preserved
Authorship preserved	✅	From: Wei Deng matches lore
Link tag correct	✅	Points to correct lore message-ID

Diff

File	Status	Notes
monaco-ac-evk.dts	✅	Adds M.2 Key E connector node (60 lines)

Upstream Patch Status

Verdict: ⏳ Decision Pending — Reviewed-by: Konrad Dybcio present (Oct 27, 2026), but no "applied" confirmation yet; patch is recent (Oct 21, 2026)

Integration Presence

Status: ✅ Present — integration_presence_report.md shows "present - exact patch-id match at 9cd4e72" in topics

---

Issues Found

1. Commit 1/4 (Revert): Integration presence shows "partial" status - the revert may not have been fully verified in qcom-next. This is expected for a revert that undoes a previous commit.

2. Commit 4/4 (FROMLIST): Upstream patch status is "Decision Pending" - the patch has a Reviewed-by tag but no maintainer "applied" confirmation yet. However, it is present in the topics branch, indicating it's queued for integration.

---

Verdict

⚠️ PARTIAL — Merge with awareness of the following:

1. Commits 2/4 and 3/4 (UPSTREAM): ✅ Fully validated - patches are accepted upstream ("Applied, thanks!"), present in qcom-next, and faithfully represent the lore source.

2. Commit 1/4 (Revert): ⚠️ Acceptable - reverts an internal commit to align with upstream v5 series design. The link to the cover letter provides context. Integration presence is "partial" which is expected for a revert.

3. Commit 4/4 (FROMLIST): ⚠️ Acceptable - patch has maintainer review (Reviewed-by: Konrad Dybcio) and is present in topics branch, but lacks final "applied" confirmation. This is normal for FROMLIST commits that are queued but not yet in mainline.

---

Final Summary

1. Lore link present: Yes — all 4 commits have lore links
2. Lore link matches PR commits: Yes — commits 2/4, 3/4, and 4/4 faithfully represent their lore sources; commit 1/4 is a revert with contextual link
3. Upstream patch status:
   • Commit 1/4: N/A (revert)
   • Commits 2/4, 3/4: ✅ Accepted and merged upstream
   • Commit 4/4: ⏳ Under review (Reviewed-by present, awaiting final merge confirmation)
4. PR present in qcom-next/topics: Partial (3/4 present, 1/4 partial) — commits 2/4, 3/4 present in qcom-next; commit 4/4 present in topics; commit 1/4 shows partial evidence (expected for revert)

Deterministic Integration Presence

Integration Presence Report

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

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

Commit	Subject	qcom-next	topics	Final
1/4	[PATCH 1/4] Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract	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] UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present
3/4	[PATCH 3/4] UPSTREAM: arm64: dts: qcom: monaco-ac-evk: Add IFP	present - all checked added lines are present	skipped - not checked because qcom-next already contains the change	present
4/4	[PATCH 4/4] FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the	partial - subject or partial tree evidence found, but full change was not verified	present - exact patch-id match at 9cd4e72	present

Final Status

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

[qlijarvis]

PR #1400 — checker-log-analyzer

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

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	3 warnings across 2 commits
dt-binding-check	⏭️	No binding changes
dtb-check	❌	4 missing required properties
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	1 commit missing required prefix
tag-check	❌	1 commit missing prefix before Revert

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1400 - Add monaco-ac EVK board support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/42147304234
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	❌	3 warnings across 2 commits
dt-binding-check	⏭️	No binding changes
dtb-check	❌	4 missing required properties
sparse-check	⏭️	No C/H changes
check-uapi-headers	⏭️	No UAPI changes
check-patch-compliance	❌	1 commit missing required prefix
tag-check	❌	1 commit missing prefix before Revert

---

❌ checkpatch

Root cause: Two commits have style warnings — undocumented DT vendor prefix and Co-developed-by/Signed-off-by mismatch.

Failure details:

Commit a2aa543 ("Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi""):

WARNING: DT compatible string vendor "usb5e3" appears un-documented
#2180: FILE: arch/arm64/boot/dts/qcom/monaco-evk.dts:1096:
+		compatible = "usb5e3,610";

WARNING: DT compatible string vendor "usb5e3" appears un-documented
#2210: FILE: arch/arm64/boot/dts/qcom/monaco-evk.dts:1126:
+		compatible = "usb5e3,625";

Commit f76d560 ("UPSTREAM: arm64: dts: qcom: monaco: Add monaco-ac EVK board"):

WARNING: Co-developed-by and Signed-off-by: name/email do not match
#57:
Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>

Fix:

1. For the usb5e3 vendor warnings (commit a2aa543):
   This is a Revert commit that restores the original monaco-evk.dts file, which contains USB hub devices with the usb5e3 vendor prefix. The vendor prefix usb5e3 (Genesys Logic) is not documented in Documentation/devicetree/bindings/vendor-prefixes.yaml.

   Action: Add the vendor prefix entry:

   git rebase -i <base_sha>   # mark the Revert commit as 'edit'
   # Edit Documentation/devicetree/bindings/vendor-prefixes.yaml
   # Add: "  usb5e3: Genesys Logic, Inc."
   git add Documentation/devicetree/bindings/vendor-prefixes.yaml
   git commit -m "dt-bindings: vendor-prefixes: Add usb5e3 for Genesys Logic"
   git rebase --continue

   Alternatively, if the vendor prefix was already added in a previous commit that was reverted, you may need to re-apply that vendor prefix addition separately.

2. For the Co-developed-by mismatch (commit f76d560):
   The commit has Co-developed-by: Faruque Ansari but Signed-off-by: Umang Chheda. This is valid if both authors contributed, but checkpatch expects the Co-developed-by line to be followed by a matching Signed-off-by from the same person.

   Action: Add the missing Signed-off-by for Faruque Ansari:

   git rebase -i <base_sha>   # mark commit f76d560d1419 as 'edit'
   git commit --amend   # Add "Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>" after the Co-developed-by line
   git rebase --continue

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 0eae9fad63ac..e329f9609de2

---

❌ dtb-check

Root cause: Two PCIe PHY nodes are missing the required vdda-refgen-supply property in the new monaco-ac-evk board DTS files.

Failure details:

monaco-ac-evk.dtb: phy@1c04000 (qcom,qcs8300-qmp-gen4x2-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

monaco-ac-evk.dtb: phy@1c14000 (qcom,sa8775p-qmp-gen4x4-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

monaco-ac-evk-ifp-mezzanine.dtb: phy@1c04000 (qcom,qcs8300-qmp-gen4x2-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

monaco-ac-evk-ifp-mezzanine.dtb: phy@1c14000 (qcom,sa8775p-qmp-gen4x4-pcie-phy): 'vdda-refgen-supply' is a required property
	from schema $id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

Fix:

The PCIe PHY binding (qcom,sc8280xp-qmp-pcie-phy.yaml) requires the vdda-refgen-supply property for both qcom,qcs8300-qmp-gen4x2-pcie-phy and qcom,sa8775p-qmp-gen4x4-pcie-phy compatibles.

Add the missing supply properties to the PHY nodes in the board DTS files:

git rebase -i <base_sha>   # mark the relevant commit(s) as 'edit'
# Edit arch/arm64/boot/dts/qcom/monaco-ac-evk.dts or monaco.dtsi
# Add to phy@1c04000 and phy@1c14000 nodes:
#   vdda-refgen-supply = <&vreg_l5a_0p88>;  // or appropriate regulator
git add arch/arm64/boot/dts/qcom/*.dts*
git commit --amend --no-edit
git rebase --continue

Note: You'll need to identify the correct regulator phandle for vdda-refgen-supply from the board's power supply design. Check similar PHY nodes in other Qualcomm board DTS files (e.g., sc8280xp-*.dts, sa8775p-*.dts) for reference.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/monaco-ac-evk.dtb
make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/monaco-ac-evk-ifp-mezzanine.dtb

---

❌ check-patch-compliance

Root cause: The first commit subject starts with Revert but has no required prefix before the word Revert.

Failure details:

Checking commit: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
Commit summary does not start with a required prefix

Fix:

The check-patch-compliance checker requires that Revert commits also carry a prefix before the word Revert. The valid prefixes are: FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:.

Since this is reverting a FROMLIST: commit, add the appropriate prefix:

git rebase -i <base_sha>   # mark commit a2aa543f0fcd as 'reword'
# Change subject from:
#   Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
# To:
#   UPSTREAM: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
# or
#   FROMLIST: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
git rebase --continue

Choose UPSTREAM: if the revert itself was posted/merged upstream, or FROMLIST: if the revert is being posted to the mailing list.

Reproduce locally:

# The check-patch-compliance.sh script from kernel-checkers repo
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . --base <base> --head <head>

---

❌ tag-check

Root cause: The first commit subject starts with Revert but has no required prefix before the word Revert.

Failure details:

Commit a2aa543 ("Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi""): subject line does not start with a required prefix.

Target branch: qcom-6.18.y (not qcom-next or qcom-next-staging)
Required prefixes: FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, WORKAROUND:

All branches except qcom-next and qcom-next-staging require one of the above prefixes at the start of every commit subject line.

Fix:

git rebase -i <base_sha>   # mark commit a2aa543f0fcd as 'reword'
# Change subject from:
#   Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
# To:
#   UPSTREAM: Revert "FROMLIST: arm64: dts: qcom: monaco-evk: Extract common EVK hardware into shared dtsi"
git rebase --continue

Choose the correct prefix based on the patch origin:

• Posted to lore but not yet merged → FROMLIST:
• In a maintainer tree → FROMGIT:
• Merged into Linus's tree → UPSTREAM:
• Backported with modifications → BACKPORT:
• Vendor-only, no upstream → QCLINUX:

Note: This is the same issue as check-patch-compliance — fixing one will fix both.

---

Verdict

4 blockers must be fixed before merge:

1. checkpatch: Add usb5e3 vendor prefix to vendor-prefixes.yaml (or handle in the Revert commit context)
2. checkpatch: Fix Co-developed-by/Signed-off-by mismatch in commit f76d560
3. dtb-check: Add vdda-refgen-supply property to two PCIe PHY nodes in monaco-ac-evk DTS files
4. check-patch-compliance + tag-check: Add required prefix (UPSTREAM: or FROMLIST:) before Revert in the first commit subject

The most critical fixes are:

• Prefix the Revert commit (fixes both check-patch-compliance and tag-check)
• Add the missing vdda-refgen-supply properties (dtb-check blocker)

The checkpatch warnings are lower priority but should be addressed for clean CI.

[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	❌ Fail
CPUFreq_Validation	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
CPU_affinity	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass
DSP_AudioPD	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	⚠️ skip
Ethernet_Basic_Validation	⚠️ skip	✅ Pass	✅ Pass	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	❌ Fail	⚠️ skip
Freq_Scaling	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ Pass	✅ 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 a295118

• multimedia Job 269832 on hamoa-iot-evk
• multimedia Job 269827 on lemans-evk
• multimedia Job 269833 on monaco-evk
• multimedia Job 269834 on purwa-iot-evk
• multimedia Job 269831 on qcs615-ride
• multimedia Job 269835 on qcs6490-rb3gen2
• multimedia Job 269828 on qcs8300-ride
• multimedia Job 269830 on qcs9100-ride-r3
• multimedia Job on qrb2210-rb1
• multimedia Job 269829 on shikra-iqs-evk

[qlijarvis]

LAVA Failed Case Triage Summary

PR: #1400

Job 269827 | SoC lemans-evk

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

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

  Case 1: Probe_Failure_Check — nvmem-reboot-mode deferred probe (non-critical)

1. Failed case: Probe_Failure_Check — nvmem-reboot-mode deferred probe (non-critical)
2. Root cause: The nvmem-reboot-mode driver failed to find the "reboot-mode" nvmem cell in the device tree for lemans-evk, resulting in a deferred probe that never resolved. This is a pre-existing platform configuration issue unrelated to the PR (which only modifies monaco device trees). The Bluetooth and regulatory.db firmware "failures" are known benign false positives — both WiFi and Bluetooth functional tests passed, confirming firmware loaded correctly at runtime.
3. Possible fix: This is a pre-existing non-critical issue on lemans-evk (not introduced by this PR). The nvmem-reboot-mode driver is attempting to register a reboot-mode handler but cannot find the required nvmem cell reference in the lemans device tree. To fix: add the missing nvmem cell phandle to the lemans-evk device tree's reboot-mode node, or disable the reboot-mode node if this functionality is not required for lemans-evk. The Probe_Failure_Check test should be updated to suppress known benign firmware load failures when corresponding functional tests (BT_ON_OFF, WiFi_OnOff) pass.
4. Detail analysis attachment: failed_case_job269827_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a false positive test failure for PR FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector #1400 validation. The PR does not touch lemans/SA8775P device trees and cannot have caused this issue. The test should either (1) be marked as a known platform limitation for lemans-evk, or (2) the SA8775P video codec DT node should be updated to include the iommus property pointing to the appropriate SMMU instance.
4. Detail analysis attachment: failed_case_job269827_2_detailed.md

  Case 3: 0_qcom-next-ci-premerge-tests (LAVA test definition wrapper failure)

1. Failed case: 0_qcom-next-ci-premerge-tests (LAVA test definition wrapper failure)
2. Root cause: LAVA test definition marked as failed because 2 constituent tests failed: Probe_Failure_Check and smmu. The kernel booted successfully, all tests executed, and the test runner completed normally. The "Marking unfinished test run as failed" message is LAVA's standard behavior when individual tests within a test suite fail, not an infrastructure or build load issue.
3. Possible fix: This is expected LAVA behavior, not a bug. To resolve: (1) Investigate and fix the 2 failing tests (Probe_Failure_Check at line 5383 and smmu at line 5585); (2) Re-run the CI job after fixes are applied. The LAVA job infrastructure and kernel are functioning correctly.
4. Detail analysis attachment: failed_case_job269827_3_detailed.md

Job 269828 | SoC qcs8300-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Missing optional wireless regulatory database firmware file (regulatory.db) during cfg80211 subsystem initialization — error -2 (ENOENT) indicates the file is not present in the firmware search paths, but this is a benign condition as cfg80211 falls back to compiled-in regulatory rules when the external database is unavailable.
3. Possible fix: Suppress this failure in the Probe_Failure_Check test pattern list — add regulatory.db firmware load failures to the test's known-benign exclusion filter, as the wireless subsystem operates correctly with compiled-in X.509 certificates for regulatory compliance when the external database file is absent.
4. Detail analysis attachment: failed_case_job269828_1_detailed.md

  Case 2: KVM_Driver — /dev/kvm device node not present

1. Failed case: KVM_Driver — /dev/kvm device node not present
2. Root cause: KVM cannot initialize on qcs8300-ride because the system is running as a guest under Gunyah hypervisor (evidenced by "arm-pv: using stolen time PV" and "gunyah-md-region" reserved memory). KVM requires EL2 (hypervisor) privilege level to create /dev/kvm, but when running as a guest VM under Gunyah, the kernel operates at EL1 and does not have access to EL2 virtualization extensions. Nested virtualization is not enabled or supported in this configuration.
3. Possible fix: This is not a PR-introduced regression. The qcs8300-ride platform runs under Gunyah hypervisor by design, and KVM tests are expected to fail in this configuration. Either: (1) exclude KVM tests from the qcs8300-ride test suite, or (2) enable nested virtualization support in Gunyah hypervisor configuration if the platform supports it, or (3) run KVM tests only on bare-metal configurations where the kernel has direct EL2 access.
4. Detail analysis attachment: failed_case_job269828_2_detailed.md

  Case 3: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: The qcs8300-ride platform is running as a guest under Gunyah hypervisor (evidence: reserved memory region "gunyah-md-region@91a80000" and virtual timer). KVM requires EL2 (hypervisor) privileges to create /dev/kvm, but when running as a guest VM, the kernel operates at EL1 and cannot access EL2, preventing KVM initialization.
3. Possible fix: This is a test infrastructure configuration issue, not a kernel bug. Either: (1) run KVM tests only on bare-metal qcs8300-ride configurations where the kernel has EL2 access, or (2) skip KVM tests when the platform is detected to be running under a hypervisor (check for "gunyah" or "virt" timer in boot log), or (3) enable nested virtualization support in Gunyah if available.
4. Detail analysis attachment: failed_case_job269828_3_detailed.md

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

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm device node not created
2. Root cause: KVM failed to initialize because the system is running under the Gunyah hypervisor (detected at boot: "Hypervisor cold boot, version: gunyah-3fe287d48"), which prevents nested virtualization. KVM requires direct access to EL2 (hypervisor mode) but Gunyah already occupies EL2, blocking KVM initialization even though CONFIG_KVM is enabled in the kernel configuration.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The qcs8300-ride platform runs under Gunyah hypervisor by design, which is incompatible with KVM. The KVM test suite should be excluded from the CI test matrix for qcs8300-ride and other Gunyah-based platforms, or the test should be enhanced to detect hypervisor presence and skip gracefully with a clear "not applicable" result rather than "fail".
4. Detail analysis attachment: failed_case_job269828_4_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test suite marked as failed because 4 individual test cases failed: (1) Probe_Failure_Check detected missing regulatory.db firmware file (benign - not provided in test rootfs), (2-4) KVM_Driver, KVM_EL2_DTB, and KVM_Infra all failed because /dev/kvm device node is not present on qcs8300-ride platform. The kernel booted successfully and all other tests passed. The PR changes (Monaco EVK device tree refactoring) are unrelated to these failures - they are pre-existing platform/test configuration issues.
3. Possible fix: (1) For regulatory.db: suppress this known benign firmware warning in Probe_Failure_Check test or add regulatory.db to test rootfs. (2) For KVM failures: either enable KVM support in the qcs8300-ride kernel config and device tree, or skip KVM tests on platforms where KVM is not supported. These are not PR-introduced regressions.
4. Detail analysis attachment: failed_case_job269828_5_detailed.md

Job 269829 | SoC shikra-iqs-evk

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

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

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs (via /sys/devices/system/cpu/online or nproc) and only validate timer counts for CPUs that actually exist, matching the approach used by the Interrupts and hotplug tests which both passed.
4. Detail analysis attachment: failed_case_job269829_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Mark this test failure as NOT BLOCKING for PR FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector #1400 merge, as the failures are pre-existing Shikra platform issues unrelated to the Monaco DTS changes. To resolve the underlying Shikra issues: (1) add ccg_secondary.cyacd2 firmware to the rootfs firmware directory, (2) verify TPM chip hardware presence and SPI bus configuration on Shikra IQS EVK, (3) include regulatory.db in the wireless-regdb package, and (4) ensure audio codec clock provider is enabled before va_macro probe.
4. Detail analysis attachment: failed_case_job269829_2_detailed.md

  Case 3: PCIe

1. Failed case: PCIe
2. Root cause: The PCIe test failed because the QPS615 PCIe switch firmware file TC956X_Firmware_PCIeBridge.bin is missing from the rootfs firmware directories, and the tc956x_pcie_eth kernel module is not present in the running kernel — both are expected by the test's QPS615 validation logic but are not provided by the current build configuration for shikra-iqs-evk.
3. Possible fix: This is a pre-existing infrastructure/build configuration issue, not a regression introduced by PR FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector #1400. The PR only modifies monaco-evk and monaco-ac-evk device tree files and does not touch shikra-iqs-evk DTS, PCIe drivers, firmware packaging, or kernel module configuration. No action required on this PR. To resolve the test failure on shikra-iqs-evk, the build configuration must be updated to: (1) include TC956X_Firmware_PCIeBridge.bin in the rootfs firmware package, and (2) enable CONFIG_TC956X_PCIE_ETH=m or =y to build the tc956x_pcie_eth driver module.
4. Detail analysis attachment: failed_case_job269829_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: USB controllers on shikra-iqs-evk are configured in gadget/peripheral mode instead of host mode; no USB root hubs are exposed in /sys/class/usb_host, and lsusb cannot enumerate the USB bus because the xHCI host controller driver is not active.
3. Possible fix: Update the shikra-iqs-evk device tree to configure USB controllers in host mode (dr_mode = "host") or OTG mode with host as default role, then rebuild the DTB and reflash; alternatively, verify that the LAVA test infrastructure for shikra-iqs-evk expects USB gadget mode and adjust the USBHost test skip logic accordingly.
4. Detail analysis attachment: failed_case_job269829_4_detailed.md

  Case 5: BT_SCAN

1. Failed case: BT_SCAN
2. Root cause: Test environment lacks discoverable Bluetooth devices — hci0 adapter initialized successfully, firmware loaded correctly, BT ON/OFF functional test passed, but scan found zero devices after 3 attempts with multiple fallback strategies (bluetoothctl scan on, interactive fallback, expect PTY fallback) because no external Bluetooth devices are present or powered on in the LAVA lab environment for this shikra-iqs-evk board.
3. Possible fix: Add at least one powered-on, discoverable Bluetooth device (beacon, phone, or dedicated test peripheral) within RF range of the shikra-iqs-evk board in the LAVA lab; alternatively, update the test to skip BT_SCAN when no devices are expected in the environment, or mark BT_SCAN as a known-benign failure when BT_ON_OFF passes (similar to the WiFi/BT firmware suppression rules).
4. Detail analysis attachment: failed_case_job269829_5_detailed.md

  Case 6: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed during kernel boot because HYP (EL2) mode is not available on the Shikra IQS EVK platform — kernel log shows kvm [1]: HYP mode not available at boot time, preventing /dev/kvm device node creation.
3. Possible fix: This is a pre-existing platform/firmware/bootloader configuration issue unrelated to the PR (PR only modifies Monaco device trees; test runs on Shikra). The Shikra IQS EVK bootloader is not enabling EL2/HYP mode. To fix: (1) verify bootloader configuration enables EL2 mode for the Shikra platform, (2) check if the board firmware supports virtualization extensions, (3) if this is expected behavior for Shikra IQS EVK, mark KVM tests as skipped/not-applicable for this platform in the CI test matrix.
4. Detail analysis attachment: failed_case_job269829_6_detailed.md

  Case 7: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the Gunyah hypervisor is already running at EL2 (HYP mode), preventing KVM from accessing the required privilege level. The kernel message "kvm [1]: HYP mode not available" at boot confirms EL2 is occupied by Gunyah.
3. Possible fix: This is a platform configuration issue, not a kernel regression. The Shikra IQS EVK is configured to run Gunyah hypervisor at EL2, which is incompatible with KVM. To enable KVM testing: (1) boot without Gunyah hypervisor (requires bootloader/firmware reconfiguration to not load Gunyah), or (2) mark KVM tests as expected-fail/skip for Gunyah-enabled platforms in the LAVA test definition.
4. Detail analysis attachment: failed_case_job269829_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a PR-introduced regression — the PR only modifies Monaco device tree files (monaco-evk.dts, monaco-ac-evk.dts) and does not touch Shikra platform files or KVM/virtualization code. The test failure is expected on Shikra IQS EVK because this platform does not have EL2 hypervisor support enabled in its firmware/bootloader. To resolve: (1) Skip KVM tests on Shikra IQS EVK in the CI test matrix, OR (2) Enable EL2 mode in the Shikra firmware/bootloader if the hardware supports it, OR (3) Run KVM tests only on platforms with confirmed EL2 support (e.g., platforms with hypervisor-enabled firmware).
4. Detail analysis attachment: failed_case_job269829_8_detailed.md

  Case 9: ** KVM_Infra

1. Failed case: ** KVM_Infra
2. Root cause: ** Test expects /dev/kvm device node to be present, but the shikra-iqs-evk platform does not support ARM EL2 (hypervisor) mode. Kernel message at boot confirms: kvm [1]: HYP mode not available. CONFIG_KVM is enabled in the kernel config, but the KVM driver cannot create /dev/kvm because the underlying hardware does not provide EL2 support.
3. Possible fix: Disable KVM tests for shikra-iqs-evk in the LAVA test suite configuration, or mark them as expected-to-skip for platforms without EL2 support. This is not a kernel regression — it is a platform hardware limitation that predates this PR.
4. Detail analysis attachment: failed_case_job269829_9_detailed.md

Job 269830 | SoC qcs9100-ride

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Three probe/firmware issues detected by the test: (1) regulatory.db firmware load failure (benign - WiFi functional, WiFi_OnOff and WiFi_Firmware_Driver tests passed), (2) nvmem-reboot-mode deferred probe due to missing nvmem cell in qcs9100-ride device tree, and (3) Aquantia AQR115C PHY probe failure with -EINVAL when reading firmware-name property from device tree. All three are pre-existing platform issues unrelated to the PR (PR modifies only monaco/qcs8300 device trees).
3. Possible fix: Suppress this test failure as false positive for this PR. The PR changes only monaco (qcs8300) device trees and does not touch qcs9100-ride. The three detected issues are pre-existing platform configuration problems: (1) regulatory.db is a known benign failure (WiFi works via fallback), (2) nvmem-reboot-mode requires adding the missing nvmem cell to qcs9100-ride.dts, (3) Aquantia AQR115C requires adding firmware-name property to the PHY node in qcs9100-ride.dts. None are regressions introduced by this PR.
4. Detail analysis attachment: failed_case_job269830_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Test script expects video codec device named aa00000.video-codec but qcs9100-ride-sx platform uses iris driver which creates iris_non_pixel.0 and iris_pixel.0 devices; both iris devices successfully attached to IOMMU groups 17 and 18, indicating SMMU protection is working correctly.
3. Possible fix: Update the SMMU test script to recognize platform-specific video codec device naming (iris_non_pixel.0 / iris_pixel.0 for qcs9100, aa00000.video-codec for other platforms), or add qcs9100-ride-sx to the test's platform-specific device name mapping.
4. Detail analysis attachment: failed_case_job269830_2_detailed.md

  Case 3: Ethernet_Basic_Validation

1. Failed case: Ethernet_Basic_Validation
2. Root cause: Aquantia AQR115C Ethernet PHY probe failure on end0 (23040000.ethernet) due to missing firmware-name property in device tree, returning -EINVAL when attempting PHY attachment during interface bring-up.
3. Possible fix: Add the missing firmware-name property to the Aquantia AQR115C PHY node in the qcs9100-ride device tree. The property should specify the path to the AQR115C firmware file (typically "Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld" or similar). Alternatively, if the firmware is not available or not required for basic operation, modify the PHY driver configuration to make firmware-name optional or provide a default firmware path.
4. Detail analysis attachment: failed_case_job269830_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Platform does not support ARM HYP (Hypervisor) mode required for KVM. Kernel message at boot: kvm [1]: HYP mode not available (timestamp 4.017550s). The qcs9100-ride (LeMans) platform lacks EL2 virtualization support, preventing /dev/kvm device node creation despite CONFIG_KVM=y and CONFIG_VIRTUALIZATION=y being enabled in kernel config.
3. Possible fix: Exclude KVM test suite (KVM_Driver, KVM_EL2_DTB, KVM_Infra) from the LAVA test definition for qcs9100-ride and other platforms without HYP mode support. Add a platform capability check in the CI job definition to skip virtualization tests on non-HYP platforms. This is not a kernel regression—the PR modifies only Monaco device tree files unrelated to KVM or qcs9100-ride.
4. Detail analysis attachment: failed_case_job269830_4_detailed.md

  Case 5: KVM_EL2_DTB — KVM unavailable (platform limitation)

1. Failed case: KVM_EL2_DTB — KVM unavailable (platform limitation)
2. Root cause: The qcs9100-ride platform boots with Gunyah hypervisor occupying EL2, preventing KVM from initializing. KVM requires direct access to EL2 (Hypervisor mode) but Gunyah is already running at EL2, so Linux runs as a guest and cannot access EL2. The kernel correctly detects this and reports "HYP mode not available", resulting in /dev/kvm not being created.
3. Possible fix: This is not a bug. KVM tests should be skipped on platforms that boot with Gunyah hypervisor. Add platform detection logic to the test suite to skip KVM tests when Gunyah is detected (check for "Gunyah based bootup" or reserved memory regions like "gunyah-md@" in device tree).
4. Detail analysis attachment: failed_case_job269830_5_detailed.md

  Case 6: KVM_Infra — KVM driver initialization failure

1. Failed case: KVM_Infra — KVM driver initialization failure
2. Root cause: KVM driver probe failed because HYP (EL2) mode is not available on qcs9100-ride; the board is running with Gunyah hypervisor which prevents KVM from accessing EL2, resulting in "HYP mode not available" at boot and missing /dev/kvm device node.
3. Possible fix: This is a platform configuration issue, not a PR-introduced regression. The qcs9100-ride board runs Gunyah hypervisor which owns EL2, making KVM unavailable. Either: (1) exclude KVM tests from qcs9100-ride CI runs, or (2) boot the board without Gunyah hypervisor if KVM testing is required, or (3) mark KVM tests as expected-fail/skip for Gunyah-enabled platforms.
4. Detail analysis attachment: failed_case_job269830_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM initialization failed with "HYP mode not available" at boot time (line 4.017550 in kernel log). CONFIG_KVM is enabled in kernel config, but the qcs9100-ride platform running under Gunyah hypervisor does not provide EL2/HYP access to the guest kernel, preventing KVM from creating /dev/kvm device node. This is a platform limitation, not a kernel regression.
3. Possible fix: Mark KVM tests as "not applicable" for qcs9100-ride platform in LAVA test suite configuration, or add a platform capability check before running KVM tests. The PR changes (device tree modifications for monaco-evk) are unrelated to this failure.
4. Detail analysis attachment: failed_case_job269830_7_detailed.md

Job 269831 | SoC qcs615-ride

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

Failed test cases in LAVA job 269831 (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: Add a suppression rule to the Probe_Failure_Check test to exclude regulatory: Direct firmware load for regulatory.db failed when WiFi functional tests pass. Alternatively, package the regulatory.db file in the rootfs at /lib/firmware/regulatory.db to eliminate the warning (though this is cosmetic, not functional).
4. Detail analysis attachment: failed_case_job269831_1_detailed.md

  Case 2: smmu (test expectation mismatch — not a CoT-classified failure)

1. Failed case: smmu (test expectation mismatch — not a CoT-classified failure)
2. Root cause: The smmu test expects video-decoder and video-encoder child devices of the Venus video codec (aa00000.video-codec) to be independently attached to IOMMU groups, but the qcs615-ride device tree and Venus driver only attach the parent device (aa00000.video-codec) to IOMMU group 7. This is a test design issue, not a kernel regression.
3. Possible fix: Update the smmu test to recognize that Venus video codec child devices (video-decoder, video-encoder) inherit IOMMU protection from their parent device and should not be expected to have independent IOMMU group attachments. Alternatively, if independent attachment is a hard requirement, update the qcs615 device tree and Venus driver to explicitly attach child devices.
4. Detail analysis attachment: failed_case_job269831_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: Skip KVM tests on qcs615-ride in the LAVA test suite by adding a platform exclusion rule. This is not a kernel bug or PR-introduced regression — it is a known hardware limitation. Update the test definition to skip KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests on platforms without EL2 support. Alternatively, add a pre-flight capability check in the test script that skips execution if /proc/cpuinfo or CPU ID registers indicate no EL2 support.
4. Detail analysis attachment: failed_case_job269831_3_detailed.md

  Case 4: KVM_EL2_DTB — KVM/EL2 Not Available (Platform Configuration Issue)

1. Failed case: KVM_EL2_DTB — KVM/EL2 Not Available (Platform Configuration Issue)
2. Root cause: KVM driver initialization failed during boot because EL2 (hypervisor exception level) is not available on the qcs615-ride platform. The kernel message kvm [1]: HYP mode not available at boot time (3.385975s) indicates the platform firmware/bootloader did not enable EL2, preventing KVM from creating /dev/kvm. This is a platform configuration limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: This is not a kernel issue requiring a code fix. The qcs615-ride platform does not support KVM/virtualization in its current firmware configuration. To enable KVM: (1) verify the platform hardware supports virtualization (ARMv8.0-A with VHE or ARMv8.1-A+), (2) ensure the bootloader (ABL/XBL) enables EL2 before entering the kernel, (3) confirm secure firmware (TZ) allows non-secure EL2 access. If KVM support is required for CI, use a different platform (e.g., rb5, rb3gen2) that has EL2 enabled. If this test is expected to pass on qcs615-ride, file a firmware/bootloader bug to enable EL2.
4. Detail analysis attachment: failed_case_job269831_4_detailed.md

  Case 5: KVM_Infra — KVM infrastructure test failure

1. Failed case: KVM_Infra — KVM infrastructure test failure
2. Root cause: The qcs615-ride platform does not support KVM virtualization because EL2 (hypervisor mode) is not available on this hardware/firmware configuration, as indicated by the kernel message "kvm [1]: HYP mode not available" at boot time, preventing the creation of /dev/kvm.
3. Possible fix: This is a platform limitation, not a PR-introduced regression (the PR only modifies monaco device trees). Mark KVM tests as "not applicable" for qcs615-ride in the LAVA test suite, or skip KVM tests on platforms without EL2 support by checking for /dev/kvm existence before running the test suite.
4. Detail analysis attachment: failed_case_job269831_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: Mark KVM tests as "not applicable" or "skip" for QCS615 platform in the LAVA test suite configuration. The PR changes only Monaco (QCS8300) device trees and does not affect QCS615, so this failure is a pre-existing platform limitation unrelated to the PR.
4. Detail analysis attachment: failed_case_job269831_6_detailed.md

Job 269832 | SoC hamoa-evk

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

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

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected two benign probe failures that exist in the baseline kernel: (1) qcom_qseecom_uefisecapp probe failure with -EBUSY (secure world resource not available for this platform configuration), and (2) regulatory.db firmware load failure with -ENOENT (file not packaged, kernel uses built-in regulatory rules). Neither failure affects system functionality on hamoa-evk.
3. Possible fix: Suppress these known benign probe failures in the Probe_Failure_Check test by adding platform-specific exclusion rules for hamoa-evk/iq-x7181-evk: exclude "qcom_qseecom_uefisecapp.*failed with error -16" and "regulatory.db failed with error -2" from the failure pattern match, as these are expected on this platform and do not indicate a regression.
4. Detail analysis attachment: failed_case_job269832_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device at address aa00000.video-codec is not attached to any IOMMU group on the hamoa-evk (iq-x7181-evk) platform, failing the SMMU test's critical master protection check. This is a pre-existing platform/device-tree configuration issue on hamoa-evk, not introduced by PR FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector #1400 which only modifies Monaco EVK device tree files.
3. Possible fix: Add the missing iommus property to the video-codec node in the hamoa-evk (qcs8300/x7181) device tree to attach it to an IOMMU group. The fix should be applied to the SoC DTSI or board DTS for hamoa-evk, not to the Monaco EVK files modified in this PR.
4. Detail analysis attachment: failed_case_job269832_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because the X1E80100 SoC on Hamoa IoT EVK does not boot with EL2 (HYP mode) available; kernel message kvm [1]: HYP mode not available indicates the CPU is not running at EL2 or the bootloader/firmware did not preserve EL2 for the kernel.
3. Possible fix: This is a platform/firmware limitation, not a PR-introduced regression. The PR only modifies Monaco device tree files and does not affect KVM or X1E80100 platform. To enable KVM on Hamoa IoT EVK, the bootloader/firmware must be configured to boot the kernel at EL2 or preserve EL2 virtualization extensions. As a CI workaround, exclude KVM tests from the Hamoa IoT EVK test suite until firmware support is available.
4. Detail analysis attachment: failed_case_job269832_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a test infrastructure issue, not a kernel bug or PR-introduced regression. The test suite should implement a platform capability check before scheduling KVM tests: query for /dev/kvm existence or check dmesg for "HYP mode not available" during test initialization, and mark KVM tests as "SKIP" (not "FAIL") with reason "Platform does not support nested KVM (Gunyah hypervisor occupies EL2)" when KVM is unavailable. For hamoa-evk and other Gunyah-based platforms, KVM tests should be excluded from the default test matrix.
4. Detail analysis attachment: failed_case_job269832_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Hamoa IoT EVK platform does not provide EL2 (Hypervisor mode) access to Linux kernel. KVM initialization detects "HYP mode not available" at boot (line 3882), preventing /dev/kvm device creation. CONFIG_KVM is enabled but cannot function without EL2 access.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel bug. To enable KVM on Hamoa: (1) Update bootloader/firmware to boot Linux at EL2 or provide EL2 access via HVC calls, OR (2) Exclude KVM tests from Hamoa CI test suite as the platform does not support virtualization. The PR does not introduce this issue — it's pre-existing.
4. Detail analysis attachment: failed_case_job269832_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform hardware limitation — Hamoa EVK does not support EL2/HYP mode required for KVM; kernel correctly detected and reported "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR regression. The test should be skipped on platforms without EL2/HYP support. Add platform capability detection to the LAVA test definition to skip KVM tests when "HYP mode not available" is detected in dmesg, or update the test matrix to exclude KVM tests from Hamoa EVK jobs.
4. Detail analysis attachment: failed_case_job269832_6_detailed.md

Job 269833 | SoC monaco-evk

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

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

  Case 1: Probe_Failure_Check — WiFi/Bluetooth Firmware Load and ath11k Probe Failure

1. Failed case: Probe_Failure_Check — WiFi/Bluetooth Firmware Load and ath11k Probe Failure
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) during MHI power-up because the WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs; Bluetooth firmware files qca/wcnhpbtfw21.tlv and qca/hpbtfw21.tlv are also missing, but Bluetooth functional test (BT_ON_OFF) passed, indicating BT firmware loaded via fallback path; regulatory.db firmware is also missing but this is a known benign failure for wireless regulatory database.
3. Possible fix: Add the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory (/lib/firmware/). This is a rootfs packaging issue, not a kernel regression introduced by the PR. The PR only modifies monaco-evk device tree structure (refactoring from shared dtsi to standalone dts files) and does not touch WiFi driver code, firmware paths, or rootfs packaging. Verify the Yocto/buildroot recipe includes the linux-firmware-ath11k or equivalent package for WCN6855 WiFi chipset firmware.
4. Detail analysis attachment: failed_case_job269833_1_detailed.md

  Case 2: WiFi Driver Probe Failure — ath11k_pci firmware dependency

1. Failed case: WiFi Driver Probe Failure — ath11k_pci firmware dependency
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs firmware directory (/lib/firmware/), preventing MHI subsystem initialization for the WCN6855 WiFi device on monaco-evk.
3. Possible fix: Install the missing ath11k WCN6855 firmware files into the rootfs image at /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ — specifically amss.bin and associated firmware blobs — by updating the Yocto/build recipe to include the linux-firmware-ath11k or equivalent firmware package for WCN6855 hw2.1 variant.
4. Detail analysis attachment: failed_case_job269833_2_detailed.md

  Case 3: WiFi Driver Probe Failure — Missing Firmware Dependency

1. Failed case: WiFi Driver Probe Failure — Missing Firmware Dependency
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the root filesystem (error -2 ENOENT). The MHI bus cannot power up the WCN6855 WiFi chip without this firmware, causing the driver to time out during initialization. This is a pre-existing infrastructure issue, not introduced by the PR which only modifies device tree files.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the linux-firmware package or root filesystem image used for monaco-evk testing. The firmware should be sourced from the linux-firmware-qcom repository or Qualcomm's firmware release for WCN6855 hw2.1 nfa765 variant.
4. Detail analysis attachment: failed_case_job269833_3_detailed.md

  Case 4: 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: Install the missing WiFi firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin (and related .tlv files) in the rootfs firmware directory (/lib/firmware/). This is a test environment configuration issue, not a kernel regression introduced by the PR. The PR's DTS changes are cosmetic refactoring and do not alter WiFi device tree properties. Re-run the test after updating the firmware package in the Yocto build or rootfs overlay.
4. Detail analysis attachment: failed_case_job269833_4_detailed.md

Job 269834 | SoC purwa-evk

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

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

  Case 1: ** Probe_Failure_Check (driver probe failures — pre-existing platform limitations)

1. Failed case: ** Probe_Failure_Check (driver probe failures — pre-existing platform limitations)
2. Root cause: ** Four probe failures detected: (1) qcom_qseecom_uefisecapp -EBUSY (optional secure app, benign), (2-3) qcom-pcie controllers at 1bf8000 and 1bd0000 fail with -ENODATA due to missing PHY init sequences in the platform configuration (pre-existing limitation), (4) regulatory.db firmware -ENOENT (optional wireless regulatory database, benign). None of these failures are introduced by the PR under test, which adds a new board variant (monaco-ac-evk) and does not modify the base monaco-evk.dts used by the test target (purwa-evk).
3. Possible fix: Mark this test case as expected failure for purwa-evk until PHY init sequences are added to the platform. The PR should proceed — it does not introduce new regressions. To resolve the underlying PCIe failures: (1) Add PHY init sequences for qcom-qmp-pcie-phy at 1bfc000 and 1bd4000 in the monaco SoC dtsi or board-specific DT, (2) Verify PHY power domain and clock dependencies are correctly described, (3) Confirm PCIe controller DT nodes reference the correct PHY phandles and lanes configuration.
4. Detail analysis attachment: failed_case_job269834_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is defined in the Purwa IoT EVK device tree but is not attached to any IOMMU group, indicating either missing iommus property in the device tree node, disabled device status, or the video codec driver failing to probe the device.
3. Possible fix: Add the iommus property to the video-codec device tree node in arch/arm64/boot/dts/qcom/purwa-iot-evk.dts (or the relevant SoC dtsi) to bind it to the appropriate SMMU, ensure the device status is "okay", and verify the video codec driver (qcom,sm8550-iris or similar) is enabled in the kernel config and compatible string matches.
4. Detail analysis attachment: failed_case_job269834_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM driver initialization failed because the Purwa IoT EVK platform does not support ARM EL2 (Hypervisor) mode, which is a hardware prerequisite for KVM virtualization; kernel message at boot: kvm [1]: HYP mode not available.
3. Possible fix: This is not a kernel regression or PR-introduced issue—it is a platform hardware limitation. The Purwa EVK does not boot at EL2 and cannot support KVM. Either: (1) exclude KVM tests from the Purwa EVK CI test suite, or (2) configure the bootloader/firmware to boot the kernel at EL2 if the hardware supports it (requires platform-specific firmware changes and may not be possible on this SoC).
4. Detail analysis attachment: failed_case_job269834_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM initialization failed because the kernel is not running at EL2 (hypervisor exception level). The system boots with Gunyah hypervisor (gunyah-mobile-1f99e07c2) which runs at EL2, leaving the kernel to run at EL1. KVM requires the kernel to run at EL2 to provide virtualization support, but when a hypervisor is present, the kernel runs as a guest at EL1 and cannot access EL2 features. The kernel message "kvm [1]: HYP mode not available" at boot confirms this architectural limitation.
3. Possible fix: This is not a PR-introduced regression. The PR only modifies Monaco device tree files (monaco-evk.dts, monaco-ac-evk.dts) and does not affect the purwa-evk platform or KVM/hypervisor configuration. The failure is a pre-existing platform configuration issue: purwa-evk boots with Gunyah hypervisor enabled, which prevents KVM from running. To enable KVM on this platform, either: (1) disable the Gunyah hypervisor in the boot configuration to allow the kernel to run at EL2, or (2) mark KVM tests as "not applicable" for purwa-evk in the CI test matrix since this platform is configured for Gunyah virtualization, not KVM.
4. Detail analysis attachment: failed_case_job269834_4_detailed.md

  Case 5: KVM Infrastructure Unavailable — Platform Limitation

1. Failed case: KVM Infrastructure Unavailable — Platform Limitation
2. Root cause: KVM cannot initialize on purwa-evk because the platform boots under Gunyah hypervisor (EL2 already occupied); kernel logs show "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm device creation. CONFIG_KVM is enabled but KVM requires exclusive EL2 access which Gunyah has claimed.
3. Possible fix: Mark KVM tests as expected-fail or skip for purwa-evk in the LAVA test definition; this is a known platform architectural limitation (nested virtualization not supported). To enable KVM, the platform would need to boot without Gunyah hypervisor or use a nested virtualization configuration.
4. Detail analysis attachment: failed_case_job269834_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: This is a pre-existing platform configuration issue, not introduced by PR FROMLIST: arm64: dts: qcom: monaco-ac-evk: Describe the PCIe M.2 Key E connector #1400 (which only modifies Monaco device tree files). The Purwa platform is configured to run Gunyah hypervisor at EL2, making KVM unavailable. To enable KVM on Purwa: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) exclude KVM tests from the Purwa test suite, or (3) use a different boot configuration that doesn't load Gunyah.
4. Detail analysis attachment: failed_case_job269834_6_detailed.md

Job 269835 | SoC qcs6490-rb3gen2

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

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

  Case 1: Probe_Failure_Check — Firmware Loading Failures (Pre-existing Infrastructure Issue)

1. Failed case: Probe_Failure_Check — Firmware Loading Failures (Pre-existing Infrastructure Issue)
2. Root cause: Two firmware files missing from rootfs: (1) regulatory.db (cfg80211 wireless regulatory database) and (2) renesas_usb_fw.mem (Renesas xHCI USB controller firmware). Both failures are pre-existing infrastructure issues unrelated to the PR, which only modifies Monaco (QCS8300) device tree files while the test runs on qcs6490-rb3gen2.
3. Possible fix: Update the rootfs image build recipe to include the missing firmware files: add linux-firmware-ath10k (provides regulatory.db) and linux-firmware-renesas (provides renesas_usb_fw.mem) packages to the image manifest. Alternatively, suppress these known benign failures in the Probe_Failure_Check test if the hardware (WiFi regulatory enforcement and Renesas USB controller) is not required for this test configuration.
4. Detail analysis attachment: failed_case_job269835_1_detailed.md

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

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: The LAVA test definition completed all individual test cases successfully (including the last test qcom_hwrng which passed), but LAVA marked the overall test run as failed with "Marking unfinished test run as failed" because one sub-test (Probe_Failure_Check) detected kernel probe/firmware errors: (1) regulatory.db firmware load failure with error -2 (ENOENT), and (2) xhci-pci-renesas PCIe driver probe failure with error -2. These are pre-existing infrastructure/configuration issues unrelated to the PR's device tree changes for Monaco EVK.
3. Possible fix: The Probe_Failure_Check test failure is a false positive for this PR validation — the two probe errors (missing regulatory.db firmware file and Renesas xHCI PCIe driver probe failure on qcs6490-rb3gen2) are known board/firmware configuration issues that existed before this PR and are not caused by the monaco-evk device tree refactoring changes. Suppress these specific probe failures in the CI test configuration for qcs6490-rb3gen2, or update the board's firmware package to include the missing regulatory.db file and verify the Renesas PCIe controller hardware/firmware compatibility.
4. Detail analysis attachment: failed_case_job269835_2_detailed.md