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

[Loic Poulain]

On Thu, Oct 22, 2026 at 11:34 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> 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)

Yes, but in the UART case, where the connection can be represented in
different ways, we can end up with devices being described as both
unconnected (no remote endpoint) and connected (via a child device).
We can probably live with that, but if we go in this direction, we
should consider adding a port/endpoint definition for every UART
instance in the DTSI for consistency. The same would apply to I2C once
endpoint support is available there as well.

Regards,
Loic

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

[Konrad Dybcio]

On 10/22/26 3:08 PM, Loic Poulain wrote:
> On Thu, Oct 22, 2026 at 11:34 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> 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)
> 
> Yes, but in the UART case, where the connection can be represented in
> different ways, we can end up with devices being described as both
> unconnected (no remote endpoint) and connected (via a child device).
> We can probably live with that, but if we go in this direction, we
> should consider adding a port/endpoint definition for every UART
> instance in the DTSI for consistency. The same would apply to I2C once
> endpoint support is available there as well.

Guess so!

Konrad

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

[Manivannan Sadhasivam]

On Thu, Oct 22, 2026 at 03:08:44PM +0200, Loic Poulain wrote:
> On Thu, Oct 22, 2026 at 11:34 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
> >
> > 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)
> 
> Yes, but in the UART case, where the connection can be represented in
> different ways, we can end up with devices being described as both
> unconnected (no remote endpoint) and connected (via a child device).
> We can probably live with that, but if we go in this direction, we
> should consider adding a port/endpoint definition for every UART
> instance in the DTSI for consistency. The same would apply to I2C once
> endpoint support is available there as well.
> 

Yeah, that's also one of the thing I really hate. For getting rid of
boilerplate, we will be just introducing dead nodes :/

- Mani

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

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

[Konrad Dybcio]

On 10/26/26 1:13 PM, Manivannan Sadhasivam wrote:
> On Thu, Oct 22, 2026 at 03:08:44PM +0200, Loic Poulain wrote:
>> On Thu, Oct 22, 2026 at 11:34 AM Konrad Dybcio
>> <konrad.dybcio@oss.qualcomm.com> wrote:
>>>
>>> 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)
>>
>> Yes, but in the UART case, where the connection can be represented in
>> different ways, we can end up with devices being described as both
>> unconnected (no remote endpoint) and connected (via a child device).
>> We can probably live with that, but if we go in this direction, we
>> should consider adding a port/endpoint definition for every UART
>> instance in the DTSI for consistency. The same would apply to I2C once
>> endpoint support is available there as well.
>>
> 
> Yeah, that's also one of the thing I really hate. For getting rid of
> boilerplate, we will be just introducing dead nodes :/

I disagree about this being a problem, but I won't block further.

Konrad