Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree

[Herve Codina <herve.codina@bootlin.com>]

Hi Chen, all,

...
 
> 
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
> 
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
> 
> Mani, could you also chime in a bit on what you envisioned?
> 
> (Added Luca from Bootlin to CC, as I think there are parallels to the
>  "Hotplug of Non-discoverable Hardware" work)
>

Related to "Hotplug of Non-discoverable Hardware",

I would add entries for busses in the connector without using an OF graph.

For I2C and later SPI, this was is done.

You already have an i2c-parent property but no node where an i2c device
can be added.

The last discussion related to hotplug, connectors and DT led to the RFC
series [1].

It is a huge series. The last patch give a real example of representation:
  https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/

In your case I would see some thing like:

    connector {
        compatible = "pcie-m2-e-connector";
        vpcie3v3-supply = <&vreg_wcn_3p3>;
        vpcie1v8-supply = <&vreg_l15b_1p8>;

	/*
	 * If those GPIOs have to be used by components available in
	 * the connected board, a Nexus node should be used.
         */
        w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
        w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
        viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
        uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
        sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
        sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;

	conn-i2c {
		i2c-parent = <&i2c0>;

		/*
 		 * Here i2c devices available on the board
		 * connected to the connector can be described.
		 */
	};

	/* Same kind to description for other busses */
	conn-pcie {
		pci-parent = <&xxxxx>;

		/*
		 * The PCIe bus has abilities to discover devices.
		 * Not sure this node is needed.
		 *
		 * If a PCI device need a DT description to describe
		 * stuffs behind the device, what has been done for LAN966x
		 * could be re-used [2] and [3]
		 */
	};

	conn_uart {
		uart-parent = <&uart-ctrl>;

		/* uart child (maybe a serdes) should be describe here
	};

	...
    };

Of course, some DT symbols need to be exported in order to have them usable from
the DT describing the connected board.

This notion of exported symbol is not yet available upstream and is the purpose of
the RFC series [1].

[1] https://lore.kernel.org/all/20260112142009.1006236-1-herve.codina@bootlin.com/
[2] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.c
[3] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.dtso

Feel free to ask for more specific question if needed.

Best regards,
Hervé

> 
> Thanks
> ChenYu
> 
> 
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.  
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >  



-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com