Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

Hi Konrad,

On Mon, 27 Jul 2026 16:43:50 +0200, Konrad Dybcio wrote:
> On 7/27/26 4:16 PM, Wei Deng wrote:
> > @@ -644,6 +701,12 @@ &pcie1_phy {
> >  &pcieport0 {
> >  	reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
> >  	wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
> > +
> > +	port {
> > +		pcieport0_ep: endpoint {
> > +			remote-endpoint = <&m2_e_pcie_ep>;
> > +		};
> > +	};
> 
> This should be defined in the SoC DTSI.
> 
> >  };
> >  
> >  &pcieport1 {
> > @@ -923,3 +986,13 @@ &usb_2_hsphy {
> >  
> >  	status = "okay";
> >  };
> > +
> > +&uart2 {
> > +	status = "okay";
> > +
> > +	port {
> > +		uart2_ep: endpoint {
> > +			remote-endpoint = <&m2_e_uart_ep>;
> > +		};
> > +	};
> 
> On a second thought, it would be logical to move this over there
> as well
> 
> Konrad

The concern I have with moving these to monaco.dtsi is that other
boards sharing the same DTSI (e.g. qcs8300-ride.dts) don't have an
M.2 connector. Adding port/endpoint nodes in the SoC DTSI would
create dangling endpoints on those boards.

The lemans-evk series followed the board-level approach (endpoint
defined in lemans-evk.dts) and was accepted by Bjorn. Would you
prefer a different approach for monaco, or is keeping it in the
EVK DTS acceptable here as well?

-- 
Best Regards,
Wei Deng

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 7/28/26 5:39 AM, Wei Deng wrote:
> Hi Konrad,
> 
> On Mon, 27 Jul 2026 16:43:50 +0200, Konrad Dybcio wrote:
>> On 7/27/26 4:16 PM, Wei Deng wrote:
>>> @@ -644,6 +701,12 @@ &pcie1_phy {
>>>  &pcieport0 {
>>>  	reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
>>>  	wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
>>> +
>>> +	port {
>>> +		pcieport0_ep: endpoint {
>>> +			remote-endpoint = <&m2_e_pcie_ep>;
>>> +		};
>>> +	};

[...]

> The concern I have with moving these to monaco.dtsi is that other
> boards sharing the same DTSI (e.g. qcs8300-ride.dts) don't have an
> M.2 connector. Adding port/endpoint nodes in the SoC DTSI would
> create dangling endpoints on those boards.

Is that a problem?

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

Hi Konrad,

On Tue, 28 Jul 2026 10:11:30 +0200, Konrad Dybcio wrote:
> On 7/28/26 5:39 AM, Wei Deng wrote:
> > The concern I have with moving these to monaco.dtsi is that other
> > boards sharing the same DTSI (e.g. qcs8300-ride.dts) don't have an
> > M.2 connector. Adding port/endpoint nodes in the SoC DTSI would
> > create dangling endpoints on those boards.
> 
> Is that a problem?
> 
> Konrad

Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
I will also split the series into 3 patches to keep the SoC-level
changes separate from the board-level connector description.

-- 
Best Regards,
Wei Deng

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.

After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
uses of_graph_is_present() to detect whether an M.2 connector is present.
Since of_graph_is_present() only checks for a 'port' child node, the empty
anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
path on all monaco boards.

v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.

[1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/

-- 
Best Regards,
Wei Deng

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 8/19/26 4:13 PM, Wei Deng wrote:
> On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
>> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
> 
> After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
> soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
> uses of_graph_is_present() to detect whether an M.2 connector is present.
> Since of_graph_is_present() only checks for a 'port' child node, the empty
> anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
> path on all monaco boards.
> 
> v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.
> 
> [1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/

The series should test of_graph_get_remote_endpoint() instead

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

Hi Konrad,

On Wed, 19 Aug 2026 16:24:35 +0200, Konrad Dybcio wrote:
> On 8/19/26 4:13 PM, Wei Deng wrote:
> > On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
> >> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
> > 
> > After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
> > soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
> > uses of_graph_is_present() to detect whether an M.2 connector is present.
> > Since of_graph_is_present() only checks for a 'port' child node, the empty
> > anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
> > path on all monaco boards.
> > 
> > v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.
> > 
> > [1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
> 
> The series should test of_graph_get_remote_endpoint() instead
> 
> Konrad

Hi Konrad,

Tested: replacing of_graph_is_present() with of_graph_get_remote_endpoint()
in hci_qca.c works correctly. The M.2 pwrseq path is only entered when a
remote-endpoint is actually populated, so boards like qcs8300-ride (soldered
WCN6855, no M.2 connector) are no longer affected.

Hi Mani, Loic,

We are adding M.2 Key E connector support for monaco-evk [2]. Konrad
suggested moving the port/endpoint anchor nodes to the SoC DTSI
(monaco.dtsi) for clean DTS layering, so that board files only need to
fill in remote-endpoint for boards that actually have an M.2 connector.

However, when we did this, BT init broke on qcs8300-ride-sx, a monaco-based
board with a soldered WCN6855 and no M.2 connector. The root cause is that
of_graph_is_present() in hci_qca.c only checks for the presence of a 'port'
child node — it returns true even when the port/endpoint anchors in the DTSI
are empty (no remote-endpoint set). As a result, hci_qca incorrectly enters
the M.2 pwrseq path on all monaco boards.

Konrad suggested using of_graph_get_remote_endpoint() instead, which only
returns non-NULL when a remote-endpoint is actually populated. I tested this
on lemans and it works correctly.

Would it be acceptable to change the M.2 detection in hci_qca.c [1] from:

	if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
		qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
							   "uart");
		if (IS_ERR(qcadev->bt_power->pwrseq))
			return PTR_ERR(qcadev->bt_power->pwrseq);
		break;
	}

to:

	{
		struct device_node *ep, *remote_ep;

		ep = of_graph_get_next_endpoint(
				dev_of_node(&serdev->ctrl->dev), NULL);
		remote_ep = ep ? of_graph_get_remote_endpoint(ep) : NULL;
		of_node_put(ep);

		if (remote_ep) {
			of_node_put(remote_ep);
			qcadev->bt_power->pwrseq = devm_pwrseq_get(
					&serdev->ctrl->dev, "uart");
			if (IS_ERR(qcadev->bt_power->pwrseq))
				return PTR_ERR(qcadev->bt_power->pwrseq);
			break;
		}
	}

[1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20260819141353.96467-1-wei.deng@oss.qualcomm.com/

-- 
Best Regards,
Wei Deng

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Manivannan Sadhasivam]

On Tue, Aug 25, 2026 at 02:57:15PM +0530, Wei Deng wrote:
> Hi Konrad,
> 
> On Wed, 19 Aug 2026 16:24:35 +0200, Konrad Dybcio wrote:
> > On 8/19/26 4:13 PM, Wei Deng wrote:
> > > On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
> > >> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
> > > 
> > > After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
> > > soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
> > > uses of_graph_is_present() to detect whether an M.2 connector is present.
> > > Since of_graph_is_present() only checks for a 'port' child node, the empty
> > > anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
> > > path on all monaco boards.
> > > 
> > > v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.
> > > 
> > > [1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
> > 
> > The series should test of_graph_get_remote_endpoint() instead
> > 
> > Konrad
> 
> Hi Konrad,
> 
> Tested: replacing of_graph_is_present() with of_graph_get_remote_endpoint()
> in hci_qca.c works correctly. The M.2 pwrseq path is only entered when a
> remote-endpoint is actually populated, so boards like qcs8300-ride (soldered
> WCN6855, no M.2 connector) are no longer affected.
> 
> Hi Mani, Loic,
> 
> We are adding M.2 Key E connector support for monaco-evk [2]. Konrad
> suggested moving the port/endpoint anchor nodes to the SoC DTSI
> (monaco.dtsi) for clean DTS layering, so that board files only need to
> fill in remote-endpoint for boards that actually have an M.2 connector.
> 

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

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 9/2/26 3:48 PM, Manivannan Sadhasivam wrote:
> On Tue, Aug 25, 2026 at 02:57:15PM +0530, Wei Deng wrote:
>> Hi Konrad,
>>
>> On Wed, 19 Aug 2026 16:24:35 +0200, Konrad Dybcio wrote:
>>> On 8/19/26 4:13 PM, Wei Deng wrote:
>>>> On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
>>>>> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
>>>>
>>>> After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
>>>> soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
>>>> uses of_graph_is_present() to detect whether an M.2 connector is present.
>>>> Since of_graph_is_present() only checks for a 'port' child node, the empty
>>>> anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
>>>> path on all monaco boards.
>>>>
>>>> v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.
>>>>
>>>> [1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
>>>
>>> The series should test of_graph_get_remote_endpoint() instead
>>>
>>> Konrad
>>
>> Hi Konrad,
>>
>> Tested: replacing of_graph_is_present() with of_graph_get_remote_endpoint()
>> in hci_qca.c works correctly. The M.2 pwrseq path is only entered when a
>> remote-endpoint is actually populated, so boards like qcs8300-ride (soldered
>> WCN6855, no M.2 connector) are no longer affected.
>>
>> Hi Mani, Loic,
>>
>> We are adding M.2 Key E connector support for monaco-evk [2]. Konrad
>> suggested moving the port/endpoint anchor nodes to the SoC DTSI
>> (monaco.dtsi) for clean DTS layering, so that board files only need to
>> fill in remote-endpoint for boards that actually have an M.2 connector.
>>
> 
> 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.

I don't really see a compelling reason to defer re-defining them to each
device DT either..

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Loic Poulain]

Hi Folks,

On Mon, Sep 21, 2026 at 2:38 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 9/2/26 3:48 PM, Manivannan Sadhasivam wrote:
> > On Tue, Aug 25, 2026 at 02:57:15PM +0530, Wei Deng wrote:
> >> Hi Konrad,
> >>
> >> On Wed, 19 Aug 2026 16:24:35 +0200, Konrad Dybcio wrote:
> >>> On 8/19/26 4:13 PM, Wei Deng wrote:
> >>>> On Wed, 29 Jul 2026 08:06:54 +0530, Wei Deng wrote:
> >>>>> Fair point. I will move the port/endpoint anchors to monaco.dtsi in v2.
> >>>>
> >>>> After testing v2 on qcs8300-ride-sx, BT init broke. qcs8300-ride-sx has a
> >>>> soldered WCN6855 and no M.2 Key E connector, but the pending series [1]
> >>>> uses of_graph_is_present() to detect whether an M.2 connector is present.
> >>>> Since of_graph_is_present() only checks for a 'port' child node, the empty
> >>>> anchors in monaco.dtsi caused hci_qca to incorrectly enter the M.2 pwrseq
> >>>> path on all monaco boards.
> >>>>
> >>>> v3 moves the port/endpoint nodes back to monaco-evk.dts. Please review.
> >>>>
> >>>> [1] https://lore.kernel.org/all/20260720-monza-wireless-v5-1-69ec6743543c@oss.qualcomm.com/
> >>>
> >>> The series should test of_graph_get_remote_endpoint() instead
> >>>
> >>> Konrad
> >>
> >> Hi Konrad,
> >>
> >> Tested: replacing of_graph_is_present() with of_graph_get_remote_endpoint()
> >> in hci_qca.c works correctly. The M.2 pwrseq path is only entered when a
> >> remote-endpoint is actually populated, so boards like qcs8300-ride (soldered
> >> WCN6855, no M.2 connector) are no longer affected.
> >>
> >> Hi Mani, Loic,
> >>
> >> We are adding M.2 Key E connector support for monaco-evk [2]. Konrad
> >> suggested moving the port/endpoint anchor nodes to the SoC DTSI
> >> (monaco.dtsi) for clean DTS layering, so that board files only need to
> >> fill in remote-endpoint for boards that actually have an M.2 connector.
> >>
> >
> > 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.
>
> I don't really see a compelling reason to defer re-defining them to each
> device DT either..

Adding an empty port/endpoint at the SoC level is problematic for
uart, port is not always expected, this depends if the uart is exposed
through a connector or to an onboard device. So we may end with an
unconnected endpoint but still have a bluetooth subnode, which can be
a bit confusing... Also why adding a port/endpoint only for a specific
uart in the dts, and not for the others? This is a board/SoC level
choice to use a specific uart for M2 or not.

Regards,
Loic

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 10/13/26 10:13 AM, Loic Poulain wrote:
> Hi Folks,
> 
> On Mon, Sep 21, 2026 at 2:38 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:

[...]

>>>> We are adding M.2 Key E connector support for monaco-evk [2]. Konrad
>>>> suggested moving the port/endpoint anchor nodes to the SoC DTSI
>>>> (monaco.dtsi) for clean DTS layering, so that board files only need to
>>>> fill in remote-endpoint for boards that actually have an M.2 connector.
>>>>
>>>
>>> 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.
>>
>> I don't really see a compelling reason to defer re-defining them to each
>> device DT either..
> 
> Adding an empty port/endpoint at the SoC level is problematic for
> uart, port is not always expected, this depends if the uart is exposed
> through a connector or to an onboard device. So we may end with an
> unconnected endpoint but still have a bluetooth subnode, which can be
> a bit confusing... Also why adding a port/endpoint only for a specific
> uart in the dts, and not for the others? This is a board/SoC level
> choice to use a specific uart for M2 or not.

From my perspective it's removing boilerplate. Currently all USB and
PCIe hosts already define their ports and endpoints in the SoC DTSI
and if they're unconnected, then simply nothing happens.

Both 'ports' and 'endpoints' are an abstract property that signify
'X can be related to Y' and I don't see how that's a problem here given
UART is very much expected to be connected "somewhere" (with the
"somewhere" perhaps being external/a pin header)

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 7/27/26 4:16 PM, Wei Deng wrote:
> 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.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---

[...]

> @@ -644,6 +701,12 @@ &pcie1_phy {
>  &pcieport0 {
>  	reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
>  	wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
> +
> +	port {
> +		pcieport0_ep: endpoint {
> +			remote-endpoint = <&m2_e_pcie_ep>;
> +		};
> +	};

This should be defined in the SoC DTSI.

>  };
>  
>  &pcieport1 {
> @@ -923,3 +986,13 @@ &usb_2_hsphy {
>  
>  	status = "okay";
>  };
> +
> +&uart2 {
> +	status = "okay";
> +
> +	port {
> +		uart2_ep: endpoint {
> +			remote-endpoint = <&m2_e_uart_ep>;
> +		};
> +	};

On a second thought, it would be logical to move this over there
as well

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Dmitry Baryshkov]

On Mon, Jul 27, 2026 at 07:46:32PM +0530, Wei Deng wrote:
> 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.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/monaco-evk.dts | 73 +++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

[PATCH 2/2] arm64: dts: qcom: monaco-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

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.

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco-evk.dts | 73 +++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index 9d17ef7d2caf..87ec0be89ccf 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -21,6 +21,7 @@ aliases {
 		ethernet0 = &ethernet0;
 		i2c1 = &i2c1;
 		serial0 = &uart7;
+		serial1 = &uart2;
 		serial2 = &uart6;
 	};
 
@@ -47,6 +48,38 @@ usb2_con_hs_ep: endpoint {
 		};
 	};
 
+	connector-3 {
+		compatible = "pcie-m2-e-connector";
+		vpcie3v3-supply = <&vreg_wcn_3p3>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_pcie_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&pcieport0_ep>;
+				};
+			};
+
+			port@3 {
+				reg = <3>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_uart_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&uart2_ep>;
+				};
+			};
+		};
+	};
+
 	dmic: audio-codec-0 {
 		compatible = "dmic-codec";
 		#sound-dai-cells = <0>;
@@ -91,6 +124,30 @@ usb2_vbus: regulator-usb2-vbus {
 		enable-active-high;
 	};
 
+	vreg_dcin_12v: regulator-dcin-12v {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_DCIN_12V";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vreg_wcn_3p3: regulator-wcn-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_WCN_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		vin-supply = <&vreg_dcin_12v>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
 	sound {
 		compatible = "qcom,qcs8275-sndcard";
 		model = "MONACO-EVK";
@@ -644,6 +701,12 @@ &pcie1_phy {
 &pcieport0 {
 	reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
 	wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+
+	port {
+		pcieport0_ep: endpoint {
+			remote-endpoint = <&m2_e_pcie_ep>;
+		};
+	};
 };
 
 &pcieport1 {
@@ -923,3 +986,13 @@ &usb_2_hsphy {
 
 	status = "okay";
 };
+
+&uart2 {
+	status = "okay";
+
+	port {
+		uart2_ep: endpoint {
+			remote-endpoint = <&m2_e_uart_ep>;
+		};
+	};
+};

-- 
2.34.1