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@oss.qualcomm.com>
---
 .../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@oss.qualcomm.com>
+
+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
+
+  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
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: USB interface
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: SMB interface
+
+    required:
+      - port@0
+
+  clocks:
+    description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
+      the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
+      more details.
+    maxItems: 1
+
+  pedet-gpios:
+    description: GPIO controlled connection to PEDET signal. This signal is used
+      by the host systems to determine the communication protocol that the M.2
+      card uses; SATA signaling (low) or PCIe signaling (high). Refer, PCI
+      Express M.2 Specification r4.0, sec 3.3.4.2 for more details.
+    maxItems: 1
+
+  led1-gpios:
+    description: GPIO controlled connection to LED_1# signal. This signal is
+      used by the M.2 card to indicate the card status via the system mounted
+      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
+      details.
+    maxItems: 1
+
+  viocfg-gpios:
+    description: GPIO controlled connection to IO voltage configuration
+      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
+      host system that the card supports an independent IO voltage domain for
+      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
+      3.1.15.1 for more details.
+    maxItems: 1
+
+  pwrdis-gpios:
+    description: GPIO controlled connection to Power Disable (PWRDIS) signal.
+      This signal is used by the host system to disable power on the M.2 card.
+      Refer, PCI Express M.2 Specification r4.0, sec 3.3.5.2 for more details.
+    maxItems: 1
+
+  pln-gpios:
+    description: GPIO controlled connection to Power Loss Notification (PLN#)
+      signal. This signal is use to notify the M.2 card by the host system that
+      the power loss event is expected to occur. Refer, PCI Express M.2
+      Specification r4.0, sec 3.2.17.1 for more details.
+    maxItems: 1
+
+  plas3-gpios:
+    description: GPIO controlled connection to Power Loss Acknowledge (PLA_S3#)
+      signal. This signal is used by the M.2 card to notify the host system, the
+      status of the M.2 card's preparation for power loss.
+    maxItems: 1
+
+required:
+  - compatible
+  - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+  # PCI M.2 Key M connector for SSDs with PCIe interface
+  - |
+    connector {
+        compatible = "pcie-m2-m-connector";
+        vpcie3v3-supply = <&vreg_nvme>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+
+                endpoint {
+                    remote-endpoint = <&pcie6_port0_ep>;
+                };
+            };
+        };
+    };

-- 
2.48.1

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@oss.qualcomm.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  .../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@oss.qualcomm.com>
> +
> +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
> +
> +  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
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: USB interface
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: SMB interface
> +
> +    required:
> +      - port@0
> +
> +  clocks:
> +    description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> +      the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> +      more details.
> +    maxItems: 1
> +
> +  pedet-gpios:
> +    description: GPIO controlled connection to PEDET signal. This signal is used
> +      by the host systems to determine the communication protocol that the M.2
> +      card uses; SATA signaling (low) or PCIe signaling (high). Refer, PCI
> +      Express M.2 Specification r4.0, sec 3.3.4.2 for more details.
> +    maxItems: 1
> +
> +  led1-gpios:
> +    description: GPIO controlled connection to LED_1# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  viocfg-gpios:
> +    description: GPIO controlled connection to IO voltage configuration
> +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> +      host system that the card supports an independent IO voltage domain for
> +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> +      3.1.15.1 for more details.
> +    maxItems: 1
> +
> +  pwrdis-gpios:
> +    description: GPIO controlled connection to Power Disable (PWRDIS) signal.
> +      This signal is used by the host system to disable power on the M.2 card.
> +      Refer, PCI Express M.2 Specification r4.0, sec 3.3.5.2 for more details.
> +    maxItems: 1
> +
> +  pln-gpios:
> +    description: GPIO controlled connection to Power Loss Notification (PLN#)
> +      signal. This signal is use to notify the M.2 card by the host system that
> +      the power loss event is expected to occur. Refer, PCI Express M.2
> +      Specification r4.0, sec 3.2.17.1 for more details.
> +    maxItems: 1
> +
> +  plas3-gpios:
> +    description: GPIO controlled connection to Power Loss Acknowledge (PLA_S3#)
> +      signal. This signal is used by the M.2 card to notify the host system, the
> +      status of the M.2 card's preparation for power loss.
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  # PCI M.2 Key M connector for SSDs with PCIe interface
> +  - |
> +    connector {
> +        compatible = "pcie-m2-m-connector";
> +        vpcie3v3-supply = <&vreg_nvme>;
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                endpoint {
> +                    remote-endpoint = <&pcie6_port0_ep>;
> +                };
> +            };
> +        };
> +    };
>
> --
> 2.48.1
>

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@oss.qualcomm.com>
> ---
>  .../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@oss.qualcomm.com>
> +
> +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
> +
> +  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.

FYI I just added vpcie1v8-supply to the core DT schema [1]. vpcie1v8
instead of vio1v8 was requested by Rob.

[1] https://github.com/devicetree-org/dt-schema/pull/176

> +
> +  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
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: USB interface
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: SMB interface
> +
> +    required:
> +      - port@0
> +
> +  clocks:
> +    description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> +      the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> +      more details.
> +    maxItems: 1
> +
> +  pedet-gpios:
> +    description: GPIO controlled connection to PEDET signal. This signal is used
> +      by the host systems to determine the communication protocol that the M.2
> +      card uses; SATA signaling (low) or PCIe signaling (high). Refer, PCI
> +      Express M.2 Specification r4.0, sec 3.3.4.2 for more details.
> +    maxItems: 1
> +
> +  led1-gpios:
> +    description: GPIO controlled connection to LED_1# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  viocfg-gpios:
> +    description: GPIO controlled connection to IO voltage configuration
> +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> +      host system that the card supports an independent IO voltage domain for
> +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> +      3.1.15.1 for more details.
> +    maxItems: 1
> +
> +  pwrdis-gpios:
> +    description: GPIO controlled connection to Power Disable (PWRDIS) signal.
> +      This signal is used by the host system to disable power on the M.2 card.
> +      Refer, PCI Express M.2 Specification r4.0, sec 3.3.5.2 for more details.
> +    maxItems: 1
> +
> +  pln-gpios:
> +    description: GPIO controlled connection to Power Loss Notification (PLN#)
> +      signal. This signal is use to notify the M.2 card by the host system that
> +      the power loss event is expected to occur. Refer, PCI Express M.2
> +      Specification r4.0, sec 3.2.17.1 for more details.
> +    maxItems: 1
> +
> +  plas3-gpios:
> +    description: GPIO controlled connection to Power Loss Acknowledge (PLA_S3#)
> +      signal. This signal is used by the M.2 card to notify the host system, the
> +      status of the M.2 card's preparation for power loss.
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  # PCI M.2 Key M connector for SSDs with PCIe interface
> +  - |
> +    connector {
> +        compatible = "pcie-m2-m-connector";
> +        vpcie3v3-supply = <&vreg_nvme>;
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                endpoint {
> +                    remote-endpoint = <&pcie6_port0_ep>;
> +                };
> +            };
> +        };
> +    };
> 
> -- 
> 2.48.1
>

On Wed, Nov 12, 2025 at 11:57:17AM +0800, Chen-Yu Tsai 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@oss.qualcomm.com>
> > ---
> >  .../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@oss.qualcomm.com>
> > +
> > +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
> > +
> > +  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.
> 
> FYI I just added vpcie1v8-supply to the core DT schema [1]. vpcie1v8
> instead of vio1v8 was requested by Rob.
> 

Ok, thanks for doing it. I will change the property name in v3 and in the
follow-up series.

- Mani

> [1] https://github.com/devicetree-org/dt-schema/pull/176
> 
> > +
> > +  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
> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: USB interface
> > +
> > +      port@2:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: SMB interface
> > +
> > +    required:
> > +      - port@0
> > +
> > +  clocks:
> > +    description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > +      the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > +      more details.
> > +    maxItems: 1
> > +
> > +  pedet-gpios:
> > +    description: GPIO controlled connection to PEDET signal. This signal is used
> > +      by the host systems to determine the communication protocol that the M.2
> > +      card uses; SATA signaling (low) or PCIe signaling (high). Refer, PCI
> > +      Express M.2 Specification r4.0, sec 3.3.4.2 for more details.
> > +    maxItems: 1
> > +
> > +  led1-gpios:
> > +    description: GPIO controlled connection to LED_1# signal. This signal is
> > +      used by the M.2 card to indicate the card status via the system mounted
> > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > +      details.
> > +    maxItems: 1
> > +
> > +  viocfg-gpios:
> > +    description: GPIO controlled connection to IO voltage configuration
> > +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> > +      host system that the card supports an independent IO voltage domain for
> > +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> > +      3.1.15.1 for more details.
> > +    maxItems: 1
> > +
> > +  pwrdis-gpios:
> > +    description: GPIO controlled connection to Power Disable (PWRDIS) signal.
> > +      This signal is used by the host system to disable power on the M.2 card.
> > +      Refer, PCI Express M.2 Specification r4.0, sec 3.3.5.2 for more details.
> > +    maxItems: 1
> > +
> > +  pln-gpios:
> > +    description: GPIO controlled connection to Power Loss Notification (PLN#)
> > +      signal. This signal is use to notify the M.2 card by the host system that
> > +      the power loss event is expected to occur. Refer, PCI Express M.2
> > +      Specification r4.0, sec 3.2.17.1 for more details.
> > +    maxItems: 1
> > +
> > +  plas3-gpios:
> > +    description: GPIO controlled connection to Power Loss Acknowledge (PLA_S3#)
> > +      signal. This signal is used by the M.2 card to notify the host system, the
> > +      status of the M.2 card's preparation for power loss.
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - vpcie3v3-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  # PCI M.2 Key M connector for SSDs with PCIe interface
> > +  - |
> > +    connector {
> > +        compatible = "pcie-m2-m-connector";
> > +        vpcie3v3-supply = <&vreg_nvme>;
> > +
> > +        ports {
> > +            #address-cells = <1>;
> > +            #size-cells = <0>;
> > +
> > +            port@0 {
> > +                reg = <0>;
> > +
> > +                endpoint {
> > +                    remote-endpoint = <&pcie6_port0_ep>;
> > +                };
> > +            };
> > +        };
> > +    };
> > 
> > -- 
> > 2.48.1
> > 

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

Hi,

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@oss.qualcomm.com>
> ---
>  .../bindings/connector/pcie-m2-m-connector.yaml    | 122 +++++++++++++++++++++
>  1 file changed, 122 insertions(+)

I would expect something similar to usb-connector.yaml, i.e. m2-connector.yaml,
which then defines

compatible:
  enum:
    - m2-a-connector
    - m2-b-connector
    - m2-e-connector
    - m2-m-connector

(also not sure if we need the PCIe prefix, it just seems to make the
name longer)

Greetings,

-- Sebastian

On Sun, Nov 09, 2025 at 07:34:09PM +0100, Sebastian Reichel wrote:
> Hi,
> 
> 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@oss.qualcomm.com>
> > ---
> >  .../bindings/connector/pcie-m2-m-connector.yaml    | 122 +++++++++++++++++++++
> >  1 file changed, 122 insertions(+)
> 
> I would expect something similar to usb-connector.yaml, i.e. m2-connector.yaml,
> which then defines
> 
> compatible:
>   enum:
>     - m2-a-connector
>     - m2-b-connector
>     - m2-e-connector
>     - m2-m-connector

The interfaces of each Key greatly varies as per the spec. So I was planning to
use a separate schema for each one of them to avoid clutter.

> 
> (also not sure if we need the PCIe prefix, it just seems to make the
> name longer)
> 

The M.2 card is always connected to the PCIe connector even if the interface
could use something else other than PCIe. So having the 'pcie' prefix seems
logical to me.

- Mani

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

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@oss.qualcomm.com>
> ---
>  .../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@oss.qualcomm.com>
> +
> +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?

> +
> +  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?

> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: USB interface
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: SMB interface
> +
> +    required:
> +      - port@0
> +
> +  clocks:
> +    description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> +      the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> +      more details.
> +    maxItems: 1
> +
> +  pedet-gpios:
> +    description: GPIO controlled connection to PEDET signal. This signal is used
> +      by the host systems to determine the communication protocol that the M.2
> +      card uses; SATA signaling (low) or PCIe signaling (high). Refer, PCI
> +      Express M.2 Specification r4.0, sec 3.3.4.2 for more details.
> +    maxItems: 1
> +
> +  led1-gpios:
> +    description: GPIO controlled connection to LED_1# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  viocfg-gpios:
> +    description: GPIO controlled connection to IO voltage configuration
> +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> +      host system that the card supports an independent IO voltage domain for
> +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> +      3.1.15.1 for more details.
> +    maxItems: 1
> +
> +  pwrdis-gpios:
> +    description: GPIO controlled connection to Power Disable (PWRDIS) signal.
> +      This signal is used by the host system to disable power on the M.2 card.
> +      Refer, PCI Express M.2 Specification r4.0, sec 3.3.5.2 for more details.
> +    maxItems: 1
> +
> +  pln-gpios:
> +    description: GPIO controlled connection to Power Loss Notification (PLN#)
> +      signal. This signal is use to notify the M.2 card by the host system that
> +      the power loss event is expected to occur. Refer, PCI Express M.2
> +      Specification r4.0, sec 3.2.17.1 for more details.
> +    maxItems: 1
> +
> +  plas3-gpios:
> +    description: GPIO controlled connection to Power Loss Acknowledge (PLA_S3#)
> +      signal. This signal is used by the M.2 card to notify the host system, the
> +      status of the M.2 card's preparation for power loss.
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  # PCI M.2 Key M connector for SSDs with PCIe interface
> +  - |
> +    connector {
> +        compatible = "pcie-m2-m-connector";
> +        vpcie3v3-supply = <&vreg_nvme>;
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                endpoint {
> +                    remote-endpoint = <&pcie6_port0_ep>;
> +                };
> +            };
> +        };
> +    };
> 
> -- 
> 2.48.1
> 

-- 
With best wishes
Dmitry

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@oss.qualcomm.com>
> > ---
> >  .../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@oss.qualcomm.com>
> > +
> > +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.

> > +
> > +  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.

- Mani

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

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@oss.qualcomm.com>
> > > ---
> > >  .../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@oss.qualcomm.com>
> > > +
> > > +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).

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.

-- 
With best wishes
Dmitry

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@oss.qualcomm.com>
> > > > ---
> > > >  .../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@oss.qualcomm.com>
> > > > +
> > > > +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

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

On Tue, Nov 11, 2025 at 07:19:45PM +0530, Manivannan Sadhasivam wrote:
> 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@oss.qualcomm.com>
> > > > > ---
> > > > >  .../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@oss.qualcomm.com>
> > > > > +
> > > > > +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.

How would you model this in the actual DT? We don't have separate
PCIe/SATA muxes in DT, do we?

> 
> > 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.

-- 
With best wishes
Dmitry

On Wed, Nov 12, 2025 at 10:12:36PM +0200, Dmitry Baryshkov wrote:
> On Tue, Nov 11, 2025 at 07:19:45PM +0530, Manivannan Sadhasivam wrote:
> > 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@oss.qualcomm.com>
> > > > > > ---
> > > > > >  .../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@oss.qualcomm.com>
> > > > > > +
> > > > > > +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.
> 
> How would you model this in the actual DT? We don't have separate
> PCIe/SATA muxes in DT, do we?

Do we have to describe it? On an x86 system, does something have to 
describe what's connected? Wouldn't you try a PCIe link and then a SATA 
link if the PCIe link doesn't come up?

Rob

On Wed, Nov 12, 2025 at 10:12:36PM +0200, Dmitry Baryshkov wrote:
> On Tue, Nov 11, 2025 at 07:19:45PM +0530, Manivannan Sadhasivam wrote:
> > 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@oss.qualcomm.com>
> > > > > > ---
> > > > > >  .../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@oss.qualcomm.com>
> > > > > > +
> > > > > > +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.
> 
> How would you model this in the actual DT? We don't have separate
> PCIe/SATA muxes in DT, do we?
> 

I think I got it wrong here. Even in the case of MUX, the actual endpoint link
should exist between PCIe and SATA nodes to the connector node. So yes, having 2
endpoint nodes makes sense.

- Mani

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