Re: [PATCH v2 1/4] dt-bindings: connector: Add PCIe M.2 Mechanical Key M connector

[Manivannan Sadhasivam]

On Sun, Nov 09, 2025 at 10:13:59PM +0200, Dmitry Baryshkov wrote:
> On Sun, Nov 09, 2025 at 09:48:02PM +0530, Manivannan Sadhasivam wrote:
> > On Sat, Nov 08, 2025 at 08:10:54PM +0200, Dmitry Baryshkov wrote:
> > > On Sat, Nov 08, 2025 at 08:53:19AM +0530, Manivannan Sadhasivam wrote:
> > > > Add the devicetree binding for PCIe M.2 Mechanical Key M connector defined
> > > > in the PCI Express M.2 Specification, r4.0, sec 5.3. This connector
> > > > provides interfaces like PCIe and SATA to attach the Solid State Drives
> > > > (SSDs) to the host machine along with additional interfaces like USB, and
> > > > SMB for debugging and supplementary features. At any point of time, the
> > > > connector can only support either PCIe or SATA as the primary host
> > > > interface.
> > > > 
> > > > The connector provides a primary power supply of 3.3v, along with an
> > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > 1.8v sideband signaling.
> > > > 
> > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > grained power management.
> > > > 
> > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >  .../bindings/connector/pcie-m2-m-connector.yaml    | 122 +++++++++++++++++++++
> > > >  1 file changed, 122 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
> > > > new file mode 100644
> > > > index 0000000000000000000000000000000000000000..be0a3b43e8fd2a2a3b76cad4808ddde79dceaa21
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
> > > > @@ -0,0 +1,122 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-m-connector.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: PCIe M.2 Mechanical Key M Connector
> > > > +
> > > > +maintainers:
> > > > +  - Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxxxxxxxx>
> > > > +
> > > > +description:
> > > > +  A PCIe M.2 M connector node represents a physical PCIe M.2 Mechanical Key M
> > > > +  connector. The Mechanical Key M connectors are used to connect SSDs to the
> > > > +  host system over PCIe/SATA interfaces. These connectors also offer optional
> > > > +  interfaces like USB, SMB.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: pcie-m2-m-connector
> > > 
> > > Is a generic compatible enough here? Compare this to the USB connectors,
> > > which, in case of an independent USB-B connector controlled/ing GPIOs,
> > > gets additional gpio-usb-b-connector?
> > > 
> > 
> > I can't comment on it as I've not seen such usecases as of now. But I do think
> > that this generic compatible should satisfy most of the design requirements. If
> > necessity arises, a custom compatible could be introduced with this generic one
> > as a fallback.
> 
> Ack
> 
> > 
> > > > +
> > > > +  vpcie3v3-supply:
> > > > +    description: A phandle to the regulator for 3.3v supply.
> > > > +
> > > > +  vio1v8-supply:
> > > > +    description: A phandle to the regulator for VIO 1.8v supply.
> > > > +
> > > > +  ports:
> > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > +    description: OF graph bindings modeling the interfaces exposed on the
> > > > +      connector. Since a single connector can have multiple interfaces, every
> > > > +      interface has an assigned OF graph port number as described below.
> > > > +
> > > > +    properties:
> > > > +      port@0:
> > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > +        description: PCIe/SATA interface
> > > 
> > > Should it be defined as having two endpoints: one for PCIe, one for
> > > SATA?
> > > 
> > 
> > I'm not sure. From the dtschema of the connector node:
> > 
> > "If a single port is connected to more than one remote device, an 'endpoint'
> > child node must be provided for each link"
> > 
> > Here, a single port is atmost connected to only one endpoint and that endpoint
> > could PCIe/SATA. So IMO, defining two endpoint nodes doesn't fit here.
> 
> I think this needs to be better defined. E.g. there should be either one
> endpoint going to the shared SATA / PCIe MUX, which should then be
> controlled somehow, in a platform-specific way (how?) or there should be
> two endpoints defined, e.g. @0 for SATA and @1 for PCIe (should we
> prevent powering up M.2 if PEDET points out the unsupported function?).
> (Note: these questions might be the definitive point for the bare
> m2-m-connector vs gpio-m2-m-connector: the former one defines just the
> M.2 signals, letting e.g. UEFI or PCIe controller to react to them, the
> latter one defines how to control MUXes, the behaviour wrt PEDET, etc.,
> performing all those actions in OS driver).
> 

In the case of an external GPIO controlled MUX for PCIe/SATA interface, I would
assume that the MUX will be controlled by the PEDET itself. PEDET will be driven
low by the card if it uses SATA, pulled high (NC) if it uses PCIe. Then that
signal will help the MUX to route the proper interface to the connector.

Even in that case, there should be a single endpoint coming from the MUX to the
connector.

> Likewise, for USB you specify just the port, but is it just USB 2.0 or
> USB 3.0 port? In the latter case we should have two endpoints defined,
> one for DP/DM and another one for SS singnals.
> 

The M.2 spec limits the USB interface to 2.0 for Key M. I missed mentioning it.

- Mani

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