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

[Manivannan Sadhasivam <mani@kernel.org>]

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

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