Skip to content

monaco-evk: Enable PCIe M.2 Key E connector - #893

Open
weiden (WeiDeng-weiden) wants to merge 5 commits into
qualcomm-linux:qcom-6.18.yfrom
WeiDeng-weiden:qcom-6.18y-monaco-m2
Open

monaco-evk: Enable PCIe M.2 Key E connector#893
weiden (WeiDeng-weiden) wants to merge 5 commits into
qualcomm-linux:qcom-6.18.yfrom
WeiDeng-weiden:qcom-6.18y-monaco-m2

Conversation

@WeiDeng-weiden

@WeiDeng-weiden weiden (WeiDeng-weiden) commented Aug 3, 2026

Copy link
Copy Markdown

Enabling the PCIe M.2 Key E connector on Monaco EVK
and reverting the temporary Bluetooth workaround.

Revert BT workaround:

  • Revert the WORKAROUND commit that modelled BT power supplies as fixed
    regulators to work around the missing M.2 binding. Now superseded by
    the proper M.2 solution.

monaco.dtsi:

  • Add compatible = "pciclass,0604" to the PCIe Root Port node, required
    for pci_pwrctrl to associate the DT node with the PCI-to-PCI bridge
  • Add graph port/endpoint anchors (pcieport0_ep, uart2_ep) so board
    files can reference them via remote-endpoint

monaco-evk.dts:

  • Describe the PCIe M.2 Key E connector: connector node, PCIe and UART
    graph endpoints, regulator properties (vreg_wcn_3p3, vreg_dcin_12v)
  • Add serial1 = &uart2 alias required for Bluetooth serdev enumeration
  • Enable UART2

Upstream: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-0-0548e1dab760@oss.qualcomm.com/

CRs-Fixed: 4610036

@qlijarvis

qlijarvis commented Aug 3, 2026

Copy link
Copy Markdown

PR #893 — validate-patch

PR: #893

Verdict Issues Detailed Report
⚠️ 4 Full report

Final Summary

  1. Lore link present: Yes for commits 2/4, 3/4, 4/4 (FROMLIST); No for commit 1/4 (QCLINUX - vendor-only, no lore link expected or required)

  2. Lore link matches PR commits: Yes for commits 2/4 and 3/4 (byte-for-byte identical); Partial for commit 4/4 (semantically identical, context differs due to tree state); N/A for commit 1/4

  3. Upstream patch status: ⏳ Decision Pending for all three FROMLIST commits - Posted July 29, 2026 as v2 series; commits 1/3 and 2/3 have Reviewed-by from Konrad Dybcio (Qualcomm DT maintainer); commit 3/3 awaiting review; no merge/applied/queued signal found in lore threads yet

  4. PR present in qcom-next/topics: Yes - all 4 commit(s) are present in qcom-next or topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #893 - arm64: dts: qcom: Describe the PCIe M.2 Key E connector for Monaco EVK (4 commits)
Upstream commits: 3 FROMLIST patches from lore.kernel.org v2 series + 1 QCLINUX revert
Verdict: ⚠️ PARTIAL

Commit 1/4: QCLINUX Revert

Subject: QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: monaco-evk: Enable Bluetooth support"
Upstream: N/A (vendor-only)
Verdict: ✅ PASS (validation not applicable)

Check Status Note
Lore link required N/A QCLINUX prefix - vendor-only commit
Subject format ✅ Correct revert format with QCLINUX prefix
Authorship ✅ Wei Deng wei.deng@oss.qualcomm.com
Signed-off-by ✅ Present

Diff: Reverts Bluetooth support from monaco-evk-common.dtsi (removes uart2, regulators, bluetooth node)

Commit 2/4: FROMLIST - PCIe Root Port compatible

Subject: FROMLIST: arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port
Upstream: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-1-0548e1dab760@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check Status Note
Subject matches upstream ✅ Identical (FROMLIST prefix added correctly)
Body preserves rationale ✅ Identical - describes pciclass,0604 requirement
Fixes tag present/correct N/A Not a fix
Authorship preserved ✅ Wei Deng matches lore From:
Lore author in Signed-off-by ✅ Wei Deng present
Reviewed-by preserved ✅ Konrad Dybcio tag present
Link tag present ✅ Correct lore URL

Diff

File Status Notes
arch/arm64/boot/dts/qcom/monaco.dtsi ✅ Adds compatible = "pciclass,0604"; to pcieport0 - IDENTICAL to lore

Upstream Status: ⏳ Decision Pending - Posted July 29, 2026 (v2); has Reviewed-by from Konrad Dybcio (Qualcomm DT maintainer); no merge/applied signal yet

Commit 3/4: FROMLIST - Graph port/endpoint anchors

Subject: FROMLIST: arm64: dts: qcom: monaco: Add graph port/endpoint anchors to pcieport0 and uart2
Upstream: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-2-0548e1dab760@oss.qualcomm.com/
Verdict: ✅ PASS

Commit Message

Check Status Note
Subject matches upstream ✅ Identical (FROMLIST prefix added correctly)
Body preserves rationale ✅ Identical - describes graph anchor pattern
Fixes tag present/correct N/A Not a fix
Authorship preserved ✅ Wei Deng matches lore From:
Lore author in Signed-off-by ✅ Wei Deng present
Suggested-by preserved ✅ Konrad Dybcio tag present
Link tag present ✅ Correct lore URL

Diff

File Status Notes
arch/arm64/boot/dts/qcom/monaco.dtsi ✅ Adds port/endpoint nodes to uart2 and pcieport0 - IDENTICAL to lore

Upstream Status: ⏳ Decision Pending - Posted July 29, 2026 (v2); Reviewed-by from Konrad Dybcio added in thread reply; no merge/applied signal yet

Commit 4/4: FROMLIST - Monaco EVK M.2 connector

Subject: FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
Upstream: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/
Verdict: ⚠️ PARTIAL - context mismatch

Commit Message

Check Status Note
Subject matches upstream ✅ Identical (FROMLIST prefix added correctly)
Body preserves rationale ✅ Identical - describes M.2 connector, regulators, serial1 alias
Fixes tag present/correct N/A Not a fix
Authorship preserved ✅ Wei Deng matches lore From:
Lore author in Signed-off-by ✅ Wei Deng present
Link tag present ✅ Correct lore URL

Diff

File Status Notes
arch/arm64/boot/dts/qcom/monaco-evk.dts ⚠️ Context mismatch - PR applies changes to different file structure than lore

Issue: The PR patch modifies monaco-evk.dts while the lore patch modifies monaco-evk.dts at different line numbers and contexts:

  • Lore patch context: Adds serial1 = &uart2; to existing aliases block at line 21-24; adds connector-3 after usb2_con_hs_ep at line 47-80
  • PR patch context: Adds aliases block with serial1 = &uart2; at line 14-16 (new block); adds connector-3 at line 18-54 (different location)

Root cause: The PR is based on a tree state where commit 1/4 (the QCLINUX revert) has already removed the Bluetooth changes from monaco-evk-common.dtsi. The lore patch was posted against upstream which still has those changes in a different file. The semantic content is functionally equivalent but the file structure differs.

Assessment: This is a legitimate adaptation for the vendor tree structure. The changes are semantically identical:

  • Same connector-3 node content
  • Same regulator definitions (vreg_dcin_12v, vreg_wcn_3p3)
  • Same serial1 alias
  • Same endpoint overrides (&pcieport0_ep, &uart2_ep, &uart2)

Upstream Status: ⏳ Decision Pending - Posted July 29, 2026 (v2); no Reviewed-by tag yet; no merge/applied signal

Issues

Commit 4/4 context adaptation:

  • The PR applies the M.2 connector patch to monaco-evk.dts with different line number context than the lore patch
  • This is because commit 1/4 reverted Bluetooth support, changing the file structure
  • The semantic content is identical - all DT nodes, properties, and references match
  • This is a valid tree-specific adaptation and does not constitute a content divergence

Verdict

Merge with awareness of context adaptation in commit 4/4. The PR faithfully represents the upstream lore patches with one legitimate tree-specific adaptation:

  1. Commits 2/4 and 3/4 are byte-for-byte identical to their lore counterparts
  2. Commit 4/4 contains the same semantic changes as lore but applied to a different file context due to the preceding QCLINUX revert
  3. All commit messages preserve authorship, tags, and rationale correctly
  4. All three FROMLIST commits have proper Link: tags to lore

Recommendation: The context mismatch in commit 4/4 should be documented in the PR description to explain why the patch context differs from upstream. Consider adding a note like:

Note: Commit 4/4 applies to a different file context than the upstream lore patch
because commit 1/4 reverted the Bluetooth workaround from monaco-evk-common.dtsi.
The semantic content is identical to the lore patch.

Final Summary

  1. Lore link present: Yes for commits 2/4, 3/4, 4/4 (FROMLIST); No for commit 1/4 (QCLINUX - vendor-only, no lore link expected or required)

  2. Lore link matches PR commits: Yes for commits 2/4 and 3/4 (byte-for-byte identical); Partial for commit 4/4 (semantically identical, context differs due to tree state); N/A for commit 1/4

  3. Upstream patch status: ⏳ Decision Pending for all three FROMLIST commits - Posted July 29, 2026 as v2 series; commits 1/3 and 2/3 have Reviewed-by from Konrad Dybcio (Qualcomm DT maintainer); commit 3/3 awaiting review; no merge/applied/queued signal found in lore threads yet

  4. PR present in qcom-next/topics: Yes - all 4 commits present in topics branch per integration_presence_report.md (commits 1/4, 2/4, 3/4, 4/4 all show "present" status with exact patch-id matches in topics)

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

Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 4e84721 present
2/4 [PATCH 2/4] FROMLIST: arm64: dts: qcom: monaco: Add compatible to the missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at a6bd4e2 present
3/4 [PATCH 3/4] FROMLIST: arm64: dts: qcom: monaco: Add graph partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 2479c6b present
4/4 [PATCH 4/4] FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

Final Status

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

@qlijarvis

qlijarvis commented Aug 3, 2026

Copy link
Copy Markdown

PR #893 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ⚠️ 1 warning: undocumented vendor prefix pciclass
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ✅ Passed
sparse-check ⏭️ Skipped (no C/H changes)
check-uapi-headers ⏭️ Skipped (no C/H changes)
check-patch-compliance ❌ 2 failures: QCLINUX prefix + content mismatch
tag-check ✅ All commits have valid prefixes

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #893 - arm64: dts: qcom: monaco-evk: PCIe M.2 Key E connector support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/30809872896

Checker Result Summary
checkpatch ⚠️ 1 warning: undocumented vendor prefix pciclass
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ✅ Passed
sparse-check ⏭️ Skipped (no C/H changes)
check-uapi-headers ⏭️ Skipped (no C/H changes)
check-patch-compliance ❌ 2 failures: QCLINUX prefix + content mismatch
tag-check ✅ All commits have valid prefixes

⚠️ checkpatch

Root cause: Commit 2 uses vendor prefix pciclass which is not documented in vendor-prefixes.yaml.

Failure details:

Commit 4d3d7e33c9c3 ("FROMLIST: arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port")
WARNING: DT compatible string vendor "pciclass" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml
#28: FILE: arch/arm64/boot/dts/qcom/monaco.dtsi:2449:
+				compatible = "pciclass,0604";

Fix: The pciclass vendor prefix is a special PCI class code identifier used by the PCI subsystem. This is a false positive — pciclass,0604 is a standard PCI-to-PCI bridge class code and does not require a vendor-prefixes.yaml entry. The warning can be safely ignored.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1bc9614caed6..afed08d409a2

❌ check-patch-compliance

Root cause: Two distinct failures across two commits.

Failure 1: Commit 1 — Invalid prefix QCLINUX:

Failure details:

Checking commit: QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: monaco-evk: Enable Bluetooth support"
Commit summary does not start with a required prefix

Analysis: The check-patch-compliance checker only accepts FROMLIST:, FROMGIT:, UPSTREAM:, and BACKPORT: prefixes. The QCLINUX: prefix is a vendor-internal tag that is not recognized by this checker. This is a known limitation of the checker — vendor-only commits with QCLINUX: will always fail this check.

Fix: This is a vendor-only revert commit with no upstream equivalent. The checker limitation cannot be resolved without changing the commit prefix to one of the accepted values, which would be semantically incorrect. No action required — this is an expected failure for vendor-only commits.

Failure 2: Commit 4 — Content mismatch with Link

Failure details:

Checking commit: FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
Change is different from the one mentioned in Link

Analysis: The patch content in the PR differs from the upstream patch at the provided lore.kernel.org link.

Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/

Root cause investigation needed:

  1. Fetch the upstream patch:

    b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/ -o /tmp/upstream

  2. Compare the diff content:

    # Extract +/- lines from PR commit
git format-patch -1 afed08d409a2 --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]' > /tmp/pr.diff

# Extract +/- lines from upstream patch
awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]' > /tmp/upstream.diff

# Compare
diff /tmp/pr.diff /tmp/upstream.diff

  3. Classify the difference:

    • Context-only shift (line numbers changed but content identical) → Not a real issue
    • Legitimate adaptation (e.g., dependency on prior commit in the series) → Document in commit message
    • Missing hunk → Add the missing change
    • Extra hunk → Remove or attribute separately

Fix: Without access to the upstream patch content, I cannot determine the exact nature of the mismatch. The author should:

  1. Verify the patch content matches the upstream version
  2. If there are intentional changes (e.g., due to backport context), document them in the commit message with a note like: 
    [ Adapted for qcom tree: <explanation of changes> ]
  3. If the changes are unintentional, rebase and apply the exact upstream patch

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . --base 1bc9614caed6 --head afed08d409a2

Verdict

2 blockers to fix before merge:

  1. check-patch-compliance commit 1 (QCLINUX prefix) — This is a known checker limitation for vendor-only commits. The commit is semantically correct. This failure can be accepted as-is if the maintainer approves vendor-only commits in this branch.

  2. check-patch-compliance commit 4 (content mismatch) — This is a genuine blocker. The patch content must match the upstream lore link, or any intentional deviations must be documented in the commit message. Action required: Investigate and fix the content mismatch.

Non-blocking issues:

  • checkpatch warning on pciclass vendor prefix is a false positive and can be ignored.

@WeiDeng-weiden

weiden (WeiDeng-weiden) commented Aug 4, 2026

Copy link
Copy Markdown
Author

PR #893 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ⚠️ 1 warning: undocumented vendor prefix pciclass
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ✅ Passed
sparse-check ⏭️ Skipped (no C/H changes)
check-uapi-headers ⏭️ Skipped (no C/H changes)
check-patch-compliance ❌ 2 failures: QCLINUX prefix + content mismatch
tag-check ✅ All commits have valid prefixes
Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #893 - arm64: dts: qcom: monaco-evk: PCIe M.2 Key E connector support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/30809872896

Checker
Result
Summary

checkpatch
⚠️
1 warning: undocumented vendor prefix pciclass

dt-binding-check
⏭️
Skipped (no binding changes)

dtb-check
✅
Passed

sparse-check
⏭️
Skipped (no C/H changes)

check-uapi-headers
⏭️
Skipped (no C/H changes)

check-patch-compliance
❌
2 failures: QCLINUX prefix + content mismatch

tag-check
✅
All commits have valid prefixes

⚠️ checkpatch

Root cause: Commit 2 uses vendor prefix pciclass which is not documented in vendor-prefixes.yaml.
Failure details:

Commit 4d3d7e33c9c3 ("FROMLIST: arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port")
WARNING: DT compatible string vendor "pciclass" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml
#28: FILE: arch/arm64/boot/dts/qcom/monaco.dtsi:2449:
+				compatible = "pciclass,0604";

Fix: The pciclass vendor prefix is a special PCI class code identifier used by the PCI subsystem. This is a false positive — pciclass,0604 is a standard PCI-to-PCI bridge class code and does not require a vendor-prefixes.yaml entry. The warning can be safely ignored.
Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 1bc9614caed6..afed08d409a2

❌ check-patch-compliance

Root cause: Two distinct failures across two commits.

Failure 1: Commit 1 — Invalid prefix QCLINUX:

Failure details:

Checking commit: QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: monaco-evk: Enable Bluetooth support"
Commit summary does not start with a required prefix

Analysis: The check-patch-compliance checker only accepts FROMLIST:, FROMGIT:, UPSTREAM:, and BACKPORT: prefixes. The QCLINUX: prefix is a vendor-internal tag that is not recognized by this checker. This is a known limitation of the checker — vendor-only commits with QCLINUX: will always fail this check.
Fix: This is a vendor-only revert commit with no upstream equivalent. The checker limitation cannot be resolved without changing the commit prefix to one of the accepted values, which would be semantically incorrect. No action required — this is an expected failure for vendor-only commits.

Failure 2: Commit 4 — Content mismatch with Link

Failure details:

Checking commit: FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
Change is different from the one mentioned in Link

Analysis: The patch content in the PR differs from the upstream patch at the provided lore.kernel.org link.
Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/
Root cause investigation needed:

  1. Fetch the upstream patch:

    b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/ -o /tmp/upstream

  2. Compare the diff content:

    # Extract +/- lines from PR commit
git format-patch -1 afed08d409a2 --stdout | awk '/^diff/,/^--$/' | grep -E '^[+-][^+-]' > /tmp/pr.diff

# Extract +/- lines from upstream patch
awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]' > /tmp/upstream.diff

# Compare
diff /tmp/pr.diff /tmp/upstream.diff

  3. Classify the difference:

    • Context-only shift (line numbers changed but content identical) → Not a real issue
    • Legitimate adaptation (e.g., dependency on prior commit in the series) → Document in commit message
    • Missing hunk → Add the missing change
    • Extra hunk → Remove or attribute separately

Fix: Without access to the upstream patch content, I cannot determine the exact nature of the mismatch. The author should:

  1. Verify the patch content matches the upstream version
  2. If there are intentional changes (e.g., due to backport context), document them in the commit message with a note like: 
    [ Adapted for qcom tree: <explanation of changes> ]
  3. If the changes are unintentional, rebase and apply the exact upstream patch

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh --kernel-src . --base 1bc9614caed6 --head afed08d409a2

Verdict

2 blockers to fix before merge:

  1. check-patch-compliance commit 1 (QCLINUX prefix) — This is a known checker limitation for vendor-only commits. The commit is semantically correct. This failure can be accepted as-is if the maintainer approves vendor-only commits in this branch.
  2. check-patch-compliance commit 4 (content mismatch) — This is a genuine blocker. The patch content must match the upstream lore link, or any intentional deviations must be documented in the commit message. Action required: Investigate and fix the content mismatch.

Non-blocking issues:

  • checkpatch warning on pciclass vendor prefix is a false positive and can be ignored.

Adapted for vendor tree: applied to monaco-evk.dts after reverting the Bluetooth workaround from monaco-evk-common.dtsi.
Please review

@WeiDeng-weiden

weiden (WeiDeng-weiden) commented Aug 7, 2026

Copy link
Copy Markdown
Author

The check-patch-compliance failure on commit 4/4 is due to a vendor tree
adaptation: the upstream patch modifies monaco-evk.dts directly, but in
qcom-6.18.y the file arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
exists (introduced by other teams, not by this PR), which changes the file
structure. Some adjustments were needed to apply the patch correctly in this
context. Once monaco-evk-common.dtsi is removed in the future, this PR
will be fully aligned with upstream.

The QCLINUX: prefix failure on commit 1/4 is a known checker limitation
for vendor-only revert commits — no action needed.

shashim-quic
Shiraz Hashim (shashim-quic) requested changes Aug 7, 2026
View reviewed changes

@shashim-quic Shiraz Hashim (shashim-quic) left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reverts commit ba34902.

Add a reason as well, why.

@WeiDeng-weiden

weiden (WeiDeng-weiden) commented Aug 10, 2026

Copy link
Copy Markdown
Author

This reverts commit ba34902.

Add a reason as well, why.

Added in the commit message.
The WORKAROUND commit modelled BT power supplies as fixed regulators to
work around the missing M.2 Key E connector binding. Now that the proper
M.2 solution is described in the subsequent commits, this workaround is
no longer needed.

@qcomlnxci
qcomlnxci requested a review from a team August 10, 2026 02:41
@qlijarvis

qlijarvis commented Aug 10, 2026

Copy link
Copy Markdown

PR #893 — validate-patch

PR: #893

Verdict Issues Detailed Report
❌ 0 Full report

Final Summary

  1. Lore link present: Yes — all 3 FROMLIST commits have correct lore.kernel.org links; commit 1/4 is QCLINUX (no lore link expected)
  2. Lore link matches PR commits: No — commit 4/4 is missing regulator-always-on; property in vreg_wcn_3p3 regulator (semantic change from upstream)
  3. Upstream patch status: ⏳ Decision Pending — all 3 patches have Reviewed-by: Konrad Dybcio, but no "applied"/"queued" signal found; posted July 29, 2026 (12 days ago)
  4. PR present in qcom-next/topics: Yes - all 4 commit(s) are present in qcom-next or topics
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: [#893] arm64: dts: qcom: Describe the PCIe M.2 Key E connector for Monaco EVK
Upstream commits: 3 FROMLIST patches from lore.kernel.org
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream ✅ All FROMLIST commits match lore subjects
Body preserves rationale ✅ Key rationale preserved in all commits
Fixes tag present/correct N/A No Fixes tags required
Authorship preserved ✅ Wei Deng authorship correct for all FROMLIST commits
Backport note (if applicable) N/A FROMLIST commits, not backports

Diff

File Status Notes
monaco-evk-common.dtsi (commit 1/4) N/A QCLINUX revert — no lore link expected
monaco.dtsi (commit 2/4) ✅ Diff matches lore patch v2 1/3 exactly
monaco.dtsi (commit 3/4) ✅ Diff matches lore patch v2 2/3 exactly
monaco-evk.dts (commit 4/4) ❌ Missing regulator-always-on; property in vreg_wcn_3p3 regulator

Issues

Commit 4/4 diff mismatch:
The PR patch for monaco-evk.dts is missing the regulator-always-on; property in the vreg_wcn_3p3 regulator node. The lore patch v2 3/3 includes both regulator-always-on; and regulator-boot-on;, but the PR only has regulator-boot-on;.

Lore patch (correct):

+	vreg_wcn_3p3: regulator-wcn-3p3 {
+		...
+		regulator-always-on;
+		regulator-boot-on;
+	};

PR patch (incorrect):

+	vreg_wcn_3p3: regulator-wcn-3p3 {
+		...
+		regulator-boot-on;
+	};

This is a semantic change that alters the regulator behavior — the regulator will not be kept always-on as intended by the upstream patch.

Verdict

Do not merge. Commit 4/4 must be amended to add the missing regulator-always-on; property to the vreg_wcn_3p3 regulator node to match the lore patch exactly.

Final Summary

  1. Lore link present: Yes — all 3 FROMLIST commits have correct lore.kernel.org links; commit 1/4 is QCLINUX (no lore link expected)
  2. Lore link matches PR commits: No — commit 4/4 is missing regulator-always-on; property in vreg_wcn_3p3 regulator (semantic change from upstream)
  3. Upstream patch status: ⏳ Decision Pending — all 3 patches have Reviewed-by: Konrad Dybcio, but no "applied"/"queued" signal found; posted July 29, 2026 (12 days ago)
  4. PR present in qcom-next/topics: Yes — all 4 commits present in qcom-next or topics per integration_presence_report.md

Deterministic Integration Presence

Integration Presence Report

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

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

Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 4e84721 present
2/4 [PATCH 2/4] FROMLIST: arm64: dts: qcom: monaco: Add compatible to the missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at a6bd4e2 present
3/4 [PATCH 3/4] FROMLIST: arm64: dts: qcom: monaco: Add graph partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 2479c6b present
4/4 [PATCH 4/4] FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present

Final Status

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

@qlijarvis

qlijarvis commented Aug 10, 2026

Copy link
Copy Markdown

PR #893 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch ❌ 1 warning: undocumented DT vendor "pciclass"
dt-binding-check ⏭️ No binding changes
dtb-check ✅ All DTB validation passed
sparse-check ⏭️ No C/H file changes
check-uapi-headers ⏭️ No UAPI changes
check-patch-compliance ❌ 2 issues: QCLINUX prefix not allowed, content mismatch
tag-check ✅ All commits have valid prefixes

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #893 - arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/31350478243
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ❌ 1 warning: undocumented DT vendor "pciclass"
dt-binding-check ⏭️ No binding changes
dtb-check ✅ All DTB validation passed
sparse-check ⏭️ No C/H file changes
check-uapi-headers ⏭️ No UAPI changes
check-patch-compliance ❌ 2 issues: QCLINUX prefix not allowed, content mismatch
tag-check ✅ All commits have valid prefixes

❌ checkpatch

Root cause: Commit 2 uses the vendor prefix pciclass which is not documented in vendor-prefixes.yaml.

Failure details:

Commit 1dc64714b8bb ("FROMLIST: arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port")
WARNING: DT compatible string vendor "pciclass" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml
#28: FILE: arch/arm64/boot/dts/qcom/monaco.dtsi:2449:
+				compatible = "pciclass,0604";

Fix: This is a false positive. The pciclass prefix is a special PCI-defined compatible string format used for PCI class codes, not a vendor prefix. It's part of the PCI DT binding specification and does not need to be added to vendor-prefixes.yaml. This warning can be safely ignored.

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 8635749eab9a..e339bd52b8a2

❌ check-patch-compliance

Root cause: Two issues detected:

  1. Commit 1 uses QCLINUX: prefix which is not in the checker's allowed list
  2. Commit 4 has content differences from the upstream lore patch

Failure details:

Checking commit: QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: monaco-evk: Enable Bluetooth support"
Commit summary does not start with a required prefix

Checking commit: FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
Change is different from the one mentioned in Link

Analysis:

Issue 1 - QCLINUX prefix:
The QCLINUX: prefix is a vendor-internal tag used in the Qualcomm Linux tree but is not accepted by check-patch-compliance. The checker only accepts: FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:.

This is a known limitation of the checker. The commit is a revert of a vendor-specific workaround, so QCLINUX: is the appropriate prefix. However, the checker will always fail for vendor-only commits with this prefix.

Issue 2 - Content mismatch:
Commit 4 (f667cee3dd3b) differs from the upstream lore patch at:
https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/

This requires investigation to determine if the differences are:

  • Context-only shifts (acceptable)
  • Legitimate adaptations for the vendor tree (should be documented)
  • Missing or extra hunks (needs correction)

Fix:

For Issue 1: No fix possible within the checker framework. The QCLINUX: prefix is correct for vendor-only changes. This is an expected checker limitation.

For Issue 2: Fetch the upstream patch and compare:

b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/ -o /tmp/out
git format-patch -1 f667cee3dd3b --stdout > /tmp/pr-commit.patch
# Compare the diff sections
diff <(awk '/^diff/,/^--$/' /tmp/pr-commit.patch | grep -E '^[+-][^+-]') \
     <(awk '/^diff/,/^--$/' /tmp/out/*.mbx | grep -E '^[+-][^+-]')

If differences are legitimate adaptations (e.g., additional context needed for the vendor tree), document them in the commit message. If there are missing hunks, add them. If there are extra hunks unrelated to the upstream patch, consider splitting them into a separate commit.

Reproduce locally:

# For the QCLINUX prefix issue - this will always fail in the checker
# For the content mismatch:
b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/

Verdict

2 blockers require attention before merge:

  1. checkpatch warning (non-blocking): The pciclass vendor warning is a false positive and can be ignored. The pciclass,0604 compatible string is a standard PCI class code format.

  2. check-patch-compliance Issue 1 (known limitation): The QCLINUX: prefix failure is expected for vendor-only commits. This is a checker limitation, not a patch defect. The prefix is correct.

  3. check-patch-compliance Issue 2 (requires investigation): The content mismatch on commit 4 needs investigation. Verify whether the differences from upstream are intentional adaptations or unintended deviations. If intentional, document them in the commit message.

Recommendation: Investigate and resolve the content mismatch in commit 4. The other two issues are either false positives or known checker limitations and do not block merge.

@qcomlnxci

qcomlnxci commented Aug 11, 2026

Copy link
Copy Markdown

Test jobs on f667cee

@qcomlnxci

qcomlnxci commented Aug 11, 2026

Copy link
Copy Markdown

Test Matrix

Test Case *

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ BUILD SUCCEEDED

The kernel build completed successfully with no compilation errors. The workflow failure occurred during the test submission phase, not during compilation.

Phase Status Details
Kernel Build ✅ Pass Build completed successfully at 2026-08-11T10:58:10Z
DTC (Device Tree) ✅ Pass All device tree files compiled without errors
Test Submission ❌ Fail LAVA job submission timeout (network connectivity issue)

Failure Root Cause

The PR did NOT introduce any build errors. The workflow failure was caused by:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): 
Read timed out. (read timeout=20.0)

This is an infrastructure/network issue with the LAVA test submission service, not a code problem.

Verdict

0 of 0 errors are introduced by this PR. The build succeeded completely. The workflow failure is due to external infrastructure (LAVA server connectivity timeout) and is unrelated to the PR changes.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ SUCCESSFUL

Both kernel builds (standard and RT) completed successfully with no compilation errors.

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test server connectivity issues, not build failures.

Test Target Error Type Root Cause
All 10 test targets LAVA submission timeout/gateway errors LAVA server (lava-oss.qualcomm.com) was unreachable during test submission

Error patterns observed:

  • HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
  • 504 Server Error: Gateway Time-out
  • 502 Server Error: Bad Gateway

Verdict

0 compilation errors. The PR introduces no build failures. The workflow failure is due to infrastructure issues (LAVA server unavailability) unrelated to the code changes in this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ SUCCESS

Both the regular kernel build and RT kernel build completed successfully with no compilation errors.

Test Submission Status: ❌ FAILED

All LAVA test job submissions failed due to LAVA server connectivity issues (not PR-related):

Target Error Type Root Cause
hamoa-iot-evk Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
monaco-evk Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
qcs615-ride Gateway timeout 504 Server Error: Gateway Time-out for url: lava-oss.qualcomm.com/RPC2
qcs6490-rb3gen2 Gateway timeout 504 Server Error: Gateway Time-out for url: lava-oss.qualcomm.com/RPC2
qcs8300-ride Bad gateway 502 Server Error: Bad Gateway for url: lava-oss.qualcomm.com/RPC2
qcs9100-ride-r3 Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
qrb2210-rb1 Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
shikra-iqs-evk Bad gateway 502 Server Error: Bad Gateway for url: lava-oss.qualcomm.com/RPC2
lemans-evk Submission error ERROR: LAVA submission did not return a numeric job ID
purwa-iot-evk (Similar LAVA issue) LAVA server connectivity problem

Verdict

0 compilation errors found. The PR introduces only device tree changes (.dtsi and .dts files) which compiled successfully. The workflow failure is entirely due to infrastructure issues with the LAVA test server (lava-oss.qualcomm.com), not code problems introduced by this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ BUILD SUCCEEDED

The kernel build completed successfully for both standard and RT configurations. The workflow failure was caused by LAVA test job submission failures, not compilation errors.

Component Status Notes
Kernel Build (standard) ✅ Pass No compilation errors
Kernel Build (RT) ✅ Pass No compilation errors
DT Compilation ✅ Pass Pre-existing warnings only
LAVA Test Submission ❌ Fail Infrastructure issue

Verdict

No compilation errors were introduced by this PR. The workflow failure is due to test infrastructure issues (LAVA job submission), not code problems. All DT warnings observed are pre-existing and unrelated to the files modified in this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded; workflow failed due to LAVA test submission infrastructure errors

Verdict

No compilation errors found. The kernel build completed successfully for both default and RT variants. The workflow failure was caused by LAVA test infrastructure issues (502 Bad Gateway, 504 Gateway Timeout errors) when attempting to submit test jobs, not by any code introduced in this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ SUCCESSFUL

Both kernel builds (standard and RT) completed successfully with no compilation errors.

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test job submission failures, not build failures. All 10 test jobs failed to submit with the error:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): 
Read timed out. (read timeout=20.0)
# Error Type Component PR-introduced? Root Cause
1 Network Timeout LAVA Submission No Infrastructure issue - LAVA server unreachable during test submission phase

Verdict

Zero compilation errors. The workflow failure is due to infrastructure (LAVA connectivity), not code issues introduced by this PR.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Verdict

No compilation errors found. The kernel build completed successfully. The workflow failure was caused by a LAVA test infrastructure connection timeout during test job submission, not by any code issues in the PR.

Build Status: ✅ SUCCESS
Test Submission Status: ❌ FAILED (Infrastructure issue - LAVA connection timeout)

Root Cause

The workflow was marked as failed because the LAVA job submission step timed out when attempting to connect to lava-oss.qualcomm.com:443. This is an infrastructure/network issue, not a code quality issue.

Error from test logs:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)

PR Changes Summary

This PR makes the following changes to device tree files:

  1. Patch 1/4: Reverts a workaround for Monaco EVK Bluetooth support (removes fixed regulators)
  2. Patch 2/4: Adds compatible = "pciclass,0604" to PCIe Root Port in monaco.dtsi
  3. Patch 3/4: Adds graph port/endpoint anchors to pcieport0 and uart2 in monaco.dtsi
  4. Patch 4/4: Describes the PCIe M.2 Key E connector in monaco-evk.dts with proper power supply and graph connections

All changes are device tree modifications only—no C code changes that could introduce compilation errors.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ SUCCESS

Both kernel builds (standard and RT) completed successfully with no compilation errors.

Test Status: ❌ FAILED (Infrastructure Issue)

All test jobs failed due to LAVA server connectivity issues, not due to code problems.

Test Target Error Type Root Cause
monaco-evk Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
hamoa-iot-evk Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
lemans-evk Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
qcs615-ride Gateway timeout 504 Server Error: Gateway Time-out
qcs6490-rb3gen2 Gateway timeout 504 Server Error: Gateway Time-out
qcs8300-ride Bad gateway 502 Server Error: Bad Gateway
qcs9100-ride-r3 Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
qrb2210-rb1 Connection timeout HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out
shikra-iqs-evk Bad gateway 502 Server Error: Bad Gateway

Verdict

No compilation errors were introduced by this PR. The workflow failure is entirely due to LAVA infrastructure connectivity issues at the time of the test run. The PR changes are safe to merge from a build perspective.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Build Status: ✅ SUCCESS

Both kernel builds (standard and RT) completed successfully with zero compilation errors.

Build Type Status Duration
Standard Build ✅ Pass ~68 minutes
RT Build ✅ Pass ~14 minutes

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test job submission timeouts, NOT due to compilation errors.

Error: Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)

All 10 test jobs (hamoa-iot-evk, lemans-evk, monaco-evk, purwa-iot-evk, qcs615-ride, qcs6490-rb3gen2, qcs8300-ride, qcs9100-ride-r3, qrb2210-rb1, shikra-iqs-evk) failed to submit to the LAVA server due to network connectivity issues.

Verdict

0 compilation errors found. The PR changes compile cleanly. The workflow failure is an infrastructure issue (LAVA server connectivity timeout), not a code quality issue.

📎 Detailed analysis: Full report

@qlijarvis

qlijarvis commented Aug 11, 2026

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #893

PR: #893
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded

Verdict

✅ Build succeeded. Both standard and RT kernel builds completed successfully. The workflow failure was caused by LAVA test infrastructure issues (502 Bad Gateway errors when submitting test jobs), not by compilation problems. The PR changes compile cleanly.

📎 Detailed analysis: Full report

@WeiDeng-weiden

weiden (WeiDeng-weiden) commented Aug 12, 2026

Copy link
Copy Markdown
Author

🔨 Build Failure Analysis — PR #893

PR: #893 Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31479517929

Error File:Line PR-introduced? Root Cause

N/A No compilation errors N/A N/A Build succeeded

Verdict

✅ Build succeeded. Both standard and RT kernel builds completed successfully. The workflow failure was caused by LAVA test infrastructure issues (502 Bad Gateway errors when submitting test jobs), not by compilation problems. The PR changes compile cleanly.

📎 Detailed analysis: Full report

Hi Salendarsingh Gaud (@sgaud-quic), could you please take a look at this LAVA infra issue?

@qcomlnxci

qcomlnxci commented Aug 18, 2026

Copy link
Copy Markdown

Test jobs on f667cee

@qcomlnxci

qcomlnxci commented Aug 18, 2026

Copy link
Copy Markdown

Test Matrix

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

Wei Deng added 5 commits August 20, 2026 08:14
Wei Deng
QCLINUX: Revert "WORKAROUND: arm64: dts: qcom: monaco-evk: Enable Blu…
1f00097 
…etooth support"

This reverts commit ba34902.

The WORKAROUND commit modelled BT power supplies as fixed regulators to
work around the missing M.2 Key E connector binding. Now that the proper
M.2 solution is described in the subsequent commits, this workaround is
no longer needed.

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Wei Deng
FROMLIST: arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port
08ab806 
Add 'compatible = "pciclass,0604"' to the pcieport0 node in monaco.dtsi
to allow the PCI subsystem to associate the DT node with the PCI-to-PCI
bridge device. This is required for downstream DT nodes (such as M.2
connectors described as graph endpoints of the Root Port) to be matched
to PCI devices.

Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-1-0548e1dab760@oss.qualcomm.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Wei Deng
FROMLIST: arm64: dts: qcom: monaco: Add graph port/endpoint anchors t…
bb49875 
…o pcieport0 and uart2

Add empty graph port/endpoint nodes to pcieport0 and uart2 in monaco.dtsi
so that board files can reference the endpoint labels (pcieport0_ep,
uart2_ep) to describe connections to M.2 Key E connectors via
remote-endpoint overrides.

Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-2-0548e1dab760@oss.qualcomm.com/
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Wei Deng
FROMLIST: arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E c…
699b8d9 
…onnector

The monaco EVK has a PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe 0 Root Port and
UART2 nodes through graph port/endpoint.

The M.2 Key E connector is powered by a 3.3V fixed regulator
(vreg_wcn_3p3) which is sourced from the board's 12V DC input rail
(vreg_dcin_12v). Both regulators are always-on and are required by the
pcie-m2-e-connector binding.

Also add the serial1 = &uart2 alias, which is required for the
Bluetooth serdev device to be enumerated on the UART2 interface.

The graph endpoint anchors (pcieport0_ep, uart2_ep) referenced here are
defined in monaco.dtsi (see "arm64: dts: qcom: monaco: Add graph
port/endpoint anchors to pcieport0 and uart2").

Link: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-3-0548e1dab760@oss.qualcomm.com/
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Wei Deng
arm64: dts: qcom: monaco{,-evk}: Move graph port/endpoint anchors to …
e2347b9 
…board file

of_graph_is_present() only checks for the presence of a 'port' child
node, not whether remote-endpoint is actually connected. Adding empty
port anchor nodes to monaco.dtsi caused hci_qca to enter the M.2
pwrseq probe path on all monaco-based boards, including qcs8300-ride
which has a soldered WCN6855 and no M.2 Key E connector. This broke
BT initialization on qcs8300-ride.

Fix this by moving the port/endpoint nodes from monaco.dtsi into the
monaco-evk.dts board file where the M.2 connector is actually present,
so that of_graph_is_present() only returns true for boards that have
an M.2 Key E connector described.

Fixes: 9a18d35 ("FROMLIST: arm64: dts: qcom: monaco: Add graph port/endpoint anchors to pcieport0 and uart2")

Link: https://lore.kernel.org/all/20260819-b4-monaco-evk-m2-v1-v3-4-988145ef65cd@oss.qualcomm.com/
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
@qcomlnxci
qcomlnxci requested a review from a team August 20, 2026 02:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@shashim-quic Shiraz Hashim (shashim-quic) shashim-quic left review comments
@rrnayak Rajendra (rrnayak) Awaiting requested review from rrnayak rrnayak was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@quic-tingweiz Tingwei Zhang (quic-tingweiz) Awaiting requested review from quic-tingweiz quic-tingweiz was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@jingyiwang42 jingyiwang42 Awaiting requested review from jingyiwang42 jingyiwang42 was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@WeiDeng-weiden @qlijarvis @qcomlnxci @shashim-quic