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

[Herve Codina]

Hi Manivannan,

On Thu, 16 Apr 2026 14:25:39 +0530
Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:

> On Wed, Apr 15, 2026 at 04:56:51PM +0200, Herve Codina wrote:
> > 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.
> >   
> 
> I don't think this is a correct representation. It is non-standard to describe
> the device nodes in some other connectors. While it may work with your series in
> the future, not something I would bet-on at this point.
> 
> Using OF graph to link the connector nodes look like the cleaner solution to me.

In your DT binding, there is the i2c-parent property at connector level.

How it is used or planned to be used in order to handle devices available on the
board connected to the M2 connector ?

> 
> > 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@xxxxxxxxxxx/
> > 
> > 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]
> > 		 */  
> 
> I don't think anyone would connect something like LAN966x to the M.2 connector.
> M.2 cards have a defined purpose, like NVMe, WLAN etc... If anyone wants to
> connect another SoC like LAN966x, they would use non-M.2 connectors.

Hum, maybe yes, maybe not. I don't know what kind of hardware could be available
on a M2 connector.

One think sure is that a PCIe bus is available on the connector and so, potentially
all PCI devices could be wired on a M2 form factor.

LAN966x in PCI version is just a PCI device.

Anyway, Is it allowed to have sub-nodes in a port node ?

I mean, can we describe devices connected to a bus described by the port node ?

For USB and PCI it is probably not needed for common use cases but having a DT
description for devices on PCI and/or USB exists and is supported in the current
kernel

On SDIO, wireless devices can be described:
  Documentation/devicetree/bindings/net/wireless/

and so, sub-nodes will be needed.

As those devices need an address (reg property), #address-cells and
#size-cells will be needed.

This will end in a mix of sub-nodes describing devices and a sub-node
describing the endpoint connection.

#address-cells and #size-cells will conflict at some points.

Is a reg value for endpoints has the same characteristics as a reg value
for a SDIO device ?

How a BT devices is described under the UART available in the M2
connector ?

Best regards,
Hervé