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