Add DT support for the PCIe M.2 Mechanical Key E connector on the
Monaco EVK, following the same pattern as the lemans-evk series
(already in linux-next, commits 67f06acf/a6d4bb0a).

Patch 1/4 adds 'compatible = "pciclass,0604"' to the pcieport0 node in
monaco.dtsi, required for downstream DT nodes to be matched to PCI
devices.

Patch 2/4 adds empty labeled endpoints (pcieport0_ep, uart2_ep) to
pcieport0 and uart2 in monaco.dtsi as graph anchors.

Patch 3/4 describes the connector-3 node in monaco-evk.dts, wires the
endpoints via remote-endpoint overrides, adds the vreg_wcn_3p3
regulator, and adds the serial1 = &uart2 alias for BT serdev
enumeration.

Patch 4/4 moves the graph port/endpoint anchors from monaco.dtsi to
monaco-evk.dts. This ensures of_graph_is_present() only returns true
for boards that have an M.2 Key E connector present, preventing
unintended pwrseq probe on boards with soldered wireless chips
(e.g. qcs8300-ride).

This series is based on next-20260726.

Changes in v3:
- Drop vreg_dcin_12v from connector node; the 12V DC input is not
  software-controllable (Konrad)
- Add patch 4/4: move graph port/endpoint anchors from monaco.dtsi to
  monaco-evk.dts, so of_graph_is_present() only returns true on boards
  with an M.2 Key E connector; note that patch 2/4 (the anchor additions
  in monaco.dtsi) is based on a pending upstream series not yet merged:
  https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
- Link to v2: https://lore.kernel.org/r/20260729-b4-monaco-evk-m2-v1-v2-0-0548e1dab760@oss.qualcomm.com

Changes in v2:
- Move PCIe Root Port and UART2 graph port/endpoint declarations from
  monaco-evk.dts into monaco.dtsi, per Konrad's suggestion. The SoC
  DTSI now defines empty labeled endpoints (pcieport0_ep, uart2_ep) as
  graph anchors, and monaco-evk.dts wires them via remote-endpoint
  overrides. Splits the old patch 2/2 into two patches (new patch 2/3
  for the anchors, patch 3/3 for the EVK board wiring).
- Patch 1/3 unchanged, carries Konrad's Reviewed-by from v1.
- Dropped Dmitry's Reviewed-by on the EVK patch since the port/endpoint
  structure changed; open to re-review.
- Link to v1: https://lore.kernel.org/all/20260727-b4-monaco-evk-m2-v1-v1-0-5429cce68599@oss.qualcomm.com/

---
Wei Deng (4):
      arm64: dts: qcom: monaco: Add compatible to the PCIe Root Port
      arm64: dts: qcom: monaco: Add graph port/endpoint anchors to pcieport0 and uart2
      arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector
      arm64: dts: qcom: monaco{,-evk}: Move graph port/endpoint anchors to board file

 arch/arm64/boot/dts/qcom/monaco-evk.dts | 60 +++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco.dtsi    |  1 +
 2 files changed, 61 insertions(+)
---
base-commit: 80489b8b7c62068b5223af10ead175367dcd127d
change-id: 20260727-b4-monaco-evk-m2-v1-dd56eb997378

Best regards,
-- 
Wei Deng <wei.deng@oss.qualcomm.com>

Hi Konrad,

On Wed, 19 Aug 2026 19:27:31 +0530, Wei Deng wrote:
> Patch 4/4 moves the graph port/endpoint anchors from monaco.dtsi to
> monaco-evk.dts. This ensures of_graph_is_present() only returns true
> for boards that have an M.2 Key E connector present, preventing
> unintended pwrseq probe on boards with soldered wireless chips
> (e.g. qcs8300-ride).

I reached out to Manivannan to ask whether it would be acceptable to
change the M.2 detection in hci_qca.c from of_graph_is_present() to
of_graph_get_remote_endpoint(). His reply [1]:

> This means, the dummy port/endpoint node will always be present even
> when the M.2 connector is not used. I don't see a compelling reason
> to do so.
>
> - Mani

Given that feedback, the DTSI anchor approach (which you originally
suggested and reviewed) cannot proceed without the hci_qca.c detection
change, and that change is not something Mani finds compelling.

I'm therefore planning to drop the DTSI anchor patch in v4 and go with
board-file-only port/endpoint nodes. The series would shrink to 3 patches
and no DTSI anchors would be added.

Could you confirm whether this approach is acceptable before I send v4?

[1] https://lore.kernel.org/all/isbrpaztfrgwfcleujrn4w26cshbi2mgn57tbh5bubvsegn6lc@jh3ab6htvd24/

--
Best Regards,
Wei Deng