Skip to content

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

Open
weiden (WeiDeng-weiden) wants to merge 4 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 4 commits into
qualcomm-linux:qcom-6.18.yfrom
WeiDeng-weiden:qcom-6.18y-monaco-m2

Conversation

@WeiDeng-weiden

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

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 4e8472150209d26c3f2e7f2fb97d250ee241203b 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 a6bd4e2efa9374d233bcf02f52f49c1c24cafe2a 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 2479c6b2096e7fd3acb6715c48258dfedb4eff11 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

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 positivepciclass,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

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 positivepciclass,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

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.

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.

Wei Deng added 4 commits August 10, 2026 08:09
…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>
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>
…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>
…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>
@WeiDeng-weiden

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.

@qlijarvis

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 4e8472150209d26c3f2e7f2fb97d250ee241203b 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 a6bd4e2efa9374d233bcf02f52f49c1c24cafe2a 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 2479c6b2096e7fd3acb6715c48258dfedb4eff11 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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants