From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
provides interfaces like PCIe or SDIO to attach the WiFi devices to the
host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
devices. Spec also provides an optional interface to connect the UIM card,
but that is not covered in this binding.
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-e-connector.yaml | 154 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 155 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
new file mode 100644
index 000000000000..b65b39ddfd19
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCIe M.2 Mechanical Key E Connector
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
+
+description:
+ A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
+ connector. Mechanical Key E connectors are used to connect Wireless
+ Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
+ machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
+
+properties:
+ compatible:
+ const: pcie-m2-e-connector
+
+ vpcie3v3-supply:
+ description: A phandle to the regulator for 3.3v supply.
+
+ vpcie1v8-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: Connector interfaces for Wi-Fi
+
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: PCIe interface
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: SDIO interface
+
+ anyOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connector interfaces for BT
+
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: USB 2.0 interface
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: UART interface
+
+ anyOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: PCM/I2S interface
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: I2C interface
+
+ oneOf:
+ - 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
+
+ w-disable1-gpios:
+ description: GPIO input to W_DISABLE1# signal. This signal is used by the
+ system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
+ Specification r4.0, sec 3.1.12.3 for more details.
+ maxItems: 1
+
+ w-disable2-gpios:
+ description: GPIO input to W_DISABLE2# signal. This signal is used by the
+ system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
+ Specification r4.0, sec 3.1.12.3 for more details.
+ maxItems: 1
+
+ viocfg-gpios:
+ description: GPIO output 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
+
+required:
+ - compatible
+ - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+ # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <&vreg_wcn_3p3>;
+ vpcie1v8-supply = <&vreg_l15b_1p8>;
+ w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie4_port0_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&uart14_ep>;
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2eb7b6d26573..451c54675b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20795,6 +20795,7 @@ PCIE M.2 POWER SEQUENCING
M: Manivannan Sadhasivam <mani@kernel.org>
L: linux-pci@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
F: Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
F: drivers/power/sequencing/pwrseq-pcie-m2.c
--
2.48.1On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > devices. Spec also provides an optional interface to connect the UIM card, > but that is not covered in this binding. > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 155 insertions(+) > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > new file mode 100644 > index 000000000000..b65b39ddfd19 > --- /dev/null > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > @@ -0,0 +1,154 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: PCIe M.2 Mechanical Key E Connector > + > +maintainers: > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > + > +description: > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > + connector. Mechanical Key E connectors are used to connect Wireless > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > + > +properties: > + compatible: > + const: pcie-m2-e-connector > + > + vpcie3v3-supply: > + description: A phandle to the regulator for 3.3v supply. > + > + vpcie1v8-supply: > + description: A phandle to the regulator for VIO 1.8v supply. > + > + ports: Also, nodes go after all properties. > + $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.
On Tue, Jan 13, 2026 at 11:16:01AM -0600, Rob Herring wrote: > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > devices. Spec also provides an optional interface to connect the UIM card, > > but that is not covered in this binding. > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > MAINTAINERS | 1 + > > 2 files changed, 155 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > new file mode 100644 > > index 000000000000..b65b39ddfd19 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > @@ -0,0 +1,154 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: PCIe M.2 Mechanical Key E Connector > > + > > +maintainers: > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > + > > +description: > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > + connector. Mechanical Key E connectors are used to connect Wireless > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > + > > +properties: > > + compatible: > > + const: pcie-m2-e-connector > > + > > + vpcie3v3-supply: > > + description: A phandle to the regulator for 3.3v supply. > > + > > + vpcie1v8-supply: > > + description: A phandle to the regulator for VIO 1.8v supply. > > + > > + ports: > > Also, nodes go after all properties. > Ack. - Mani -- மணிவண்ணன் சதாசிவம்
On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> devices. Spec also provides an optional interface to connect the UIM card,
> but that is not covered in this binding.
>
> 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-e-connector.yaml | 154 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 155 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> new file mode 100644
> index 000000000000..b65b39ddfd19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCIe M.2 Mechanical Key E Connector
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> +
> +description:
> + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> + connector. Mechanical Key E connectors are used to connect Wireless
> + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> +
> +properties:
> + compatible:
> + const: pcie-m2-e-connector
> +
> + vpcie3v3-supply:
> + description: A phandle to the regulator for 3.3v supply.
> +
> + vpcie1v8-supply:
> + description: A phandle to the regulator for VIO 1.8v supply.
I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
may need something in DT to ensure those are powered. However, there's
no guarantee that it's a single 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: Connector interfaces for Wi-Fi
> +
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: PCIe interface
> +
> + endpoint@1:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: SDIO interface
I think I already said this, but multiple endpoints are generally for
something that's muxed. Looking at the connector pinout, PCIe and SDIO
are not muxed. So these 2 should be 2 port nodes.
> +
> + anyOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Connector interfaces for BT
> +
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: USB 2.0 interface
> +
> + endpoint@1:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: UART interface
And UART and USB are not muxed either.
> +
> + anyOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: PCM/I2S interface
> +
> + i2c-parent:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: I2C interface
Move out of 'ports'.
> +
> + oneOf:
> + - 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
> +
> + w-disable1-gpios:
> + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> + Specification r4.0, sec 3.1.12.3 for more details.
> + maxItems: 1
> +
> + w-disable2-gpios:
> + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> + Specification r4.0, sec 3.1.12.3 for more details.
> + maxItems: 1
> +
> + viocfg-gpios:
> + description: GPIO output 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
What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
> +
> +required:
> + - compatible
> + - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> + # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + connector {
> + compatible = "pcie-m2-e-connector";
> + vpcie3v3-supply = <&vreg_wcn_3p3>;
> + vpcie1v8-supply = <&vreg_l15b_1p8>;
> + w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> + w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&pcie4_port0_ep>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&uart14_ep>;
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2eb7b6d26573..451c54675b24 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20795,6 +20795,7 @@ PCIE M.2 POWER SEQUENCING
> M: Manivannan Sadhasivam <mani@kernel.org>
> L: linux-pci@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> F: Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
> F: drivers/power/sequencing/pwrseq-pcie-m2.c
>
>
> --
> 2.48.1
>
On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > devices. Spec also provides an optional interface to connect the UIM card, > > but that is not covered in this binding. > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > MAINTAINERS | 1 + > > 2 files changed, 155 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > new file mode 100644 > > index 000000000000..b65b39ddfd19 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > @@ -0,0 +1,154 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: PCIe M.2 Mechanical Key E Connector > > + > > +maintainers: > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > + > > +description: > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > + connector. Mechanical Key E connectors are used to connect Wireless > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > + > > +properties: > > + compatible: > > + const: pcie-m2-e-connector > > + > > + vpcie3v3-supply: > > + description: A phandle to the regulator for 3.3v supply. > > + > > + vpcie1v8-supply: > > + description: A phandle to the regulator for VIO 1.8v supply. > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > may need something in DT to ensure those are powered. However, there's > no guarantee that it's a single supply. > 1.8v VIO supply is an optional supply and is only required if the platform supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in the example for completeness. > > + > > + 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: Connector interfaces for Wi-Fi > > + > > + properties: > > + endpoint@0: > > + $ref: /schemas/graph.yaml#/properties/endpoint > > + description: PCIe interface > > + > > + endpoint@1: > > + $ref: /schemas/graph.yaml#/properties/endpoint > > + description: SDIO interface > > I think I already said this, but multiple endpoints are generally for > something that's muxed. Looking at the connector pinout, PCIe and SDIO > are not muxed. So these 2 should be 2 port nodes. > Sorry, I didn't know that you were asking for 2 port nodes. Will switch to it. > > + > > + anyOf: > > + - required: > > + - endpoint@0 > > + - required: > > + - endpoint@1 > > + > > + port@1: > > + $ref: /schemas/graph.yaml#/properties/port > > + description: Connector interfaces for BT > > + > > + properties: > > + endpoint@0: > > + $ref: /schemas/graph.yaml#/properties/endpoint > > + description: USB 2.0 interface > > + > > + endpoint@1: > > + $ref: /schemas/graph.yaml#/properties/endpoint > > + description: UART interface > > And UART and USB are not muxed either. > Ack. > > > + > > + anyOf: > > + - required: > > + - endpoint@0 > > + - required: > > + - endpoint@1 > > + > > + port@2: > > + $ref: /schemas/graph.yaml#/properties/port > > + description: PCM/I2S interface > > + > > + i2c-parent: > > + $ref: /schemas/types.yaml#/definitions/phandle > > + description: I2C interface > > Move out of 'ports'. > Ack. > > + > > + oneOf: > > + - 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 > > + > > + w-disable1-gpios: > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > + Specification r4.0, sec 3.1.12.3 for more details. > > + maxItems: 1 > > + > > + w-disable2-gpios: > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > + Specification r4.0, sec 3.1.12.3 for more details. > > + maxItems: 1 > > + > > + viocfg-gpios: > > + description: GPIO output 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 > > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals? > Not sure about vendor defined signals as they can be either GPIO or interface signals. How should them be defined? - Mani -- மணிவண்ணன் சதாசிவம்
On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > > devices. Spec also provides an optional interface to connect the UIM card, > > > but that is not covered in this binding. > > > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > > MAINTAINERS | 1 + > > > 2 files changed, 155 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > new file mode 100644 > > > index 000000000000..b65b39ddfd19 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > @@ -0,0 +1,154 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: PCIe M.2 Mechanical Key E Connector > > > + > > > +maintainers: > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > > + > > > +description: > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > > + connector. Mechanical Key E connectors are used to connect Wireless > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > > + > > > +properties: > > > + compatible: > > > + const: pcie-m2-e-connector > > > + > > > + vpcie3v3-supply: > > > + description: A phandle to the regulator for 3.3v supply. > > > + > > > + vpcie1v8-supply: > > > + description: A phandle to the regulator for VIO 1.8v supply. > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > > may need something in DT to ensure those are powered. However, there's > > no guarantee that it's a single supply. > > > > 1.8v VIO supply is an optional supply and is only required if the platform > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in > the example for completeness. My point is that PERST# and WAKE# supplies could be 2 different 1.8V supplies and those supply the I/O pads of the GPIO pins (and possibly external pull-ups) that drive them. The 1.8V supply doesn't supply 1.8V to the slot, so making it a slot/connector property is wrong. This isn't exactly a new issue. It could be an issue on any binding with GPIOs. Perhaps this needs to be handled within GPIO or pinctrl. > > > + > > > + oneOf: > > > + - 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 > > > + > > > + w-disable1-gpios: > > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > > + Specification r4.0, sec 3.1.12.3 for more details. > > > + maxItems: 1 > > > + > > > + w-disable2-gpios: > > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > > + Specification r4.0, sec 3.1.12.3 for more details. > > > + maxItems: 1 > > > + > > > + viocfg-gpios: > > > + description: GPIO output 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 > > > > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals? > > > > Not sure about vendor defined signals as they can be either GPIO or interface > signals. How should them be defined? That kind of breaks any notion of this being a generic slot/connector. How's the host supposed to know how to connect them? What if a card required them to be driven a certain way before you can discover the card? If they can be GPIOs and can be hooked up to the host system GPIOs, then you should define GPIOs for them. If they aren't GPIOs on a host, then you omit them. Rob
On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote: > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > > > devices. Spec also provides an optional interface to connect the UIM card, > > > > but that is not covered in this binding. > > > > > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > > > MAINTAINERS | 1 + > > > > 2 files changed, 155 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > new file mode 100644 > > > > index 000000000000..b65b39ddfd19 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > @@ -0,0 +1,154 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: PCIe M.2 Mechanical Key E Connector > > > > + > > > > +maintainers: > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > > > + > > > > +description: > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > > > + connector. Mechanical Key E connectors are used to connect Wireless > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > > > + > > > > +properties: > > > > + compatible: > > > > + const: pcie-m2-e-connector > > > > + > > > > + vpcie3v3-supply: > > > > + description: A phandle to the regulator for 3.3v supply. > > > > + > > > > + vpcie1v8-supply: > > > > + description: A phandle to the regulator for VIO 1.8v supply. > > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > > > may need something in DT to ensure those are powered. However, there's > > > no guarantee that it's a single supply. > > > > > > > 1.8v VIO supply is an optional supply and is only required if the platform > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in > > the example for completeness. > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V > supplies and those supply the I/O pads of the GPIO pins (and possibly > external pull-ups) that drive them. The 1.8V supply doesn't supply > 1.8V to the slot, so making it a slot/connector property is wrong. > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and not the whole card/adapter. But I don't get your multiple supplies concern. Spec says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O buffer circuitry operating at 1.8 V." So it implies that either the single supply available to the card through VIO might be used to power the whole I/O circuit logic or the card can derive its own 1.8v supply from 3.3v supply. So how come the card can have 2 different 1.8v supplies powering the I/O circuitry? > This isn't exactly a new issue. It could be an issue on any binding > with GPIOs. Perhaps this needs to be handled within GPIO or pinctrl. > > > > > + > > > > + oneOf: > > > > + - 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 > > > > + > > > > + w-disable1-gpios: > > > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the > > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > > > + Specification r4.0, sec 3.1.12.3 for more details. > > > > + maxItems: 1 > > > > + > > > > + w-disable2-gpios: > > > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the > > > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 > > > > + Specification r4.0, sec 3.1.12.3 for more details. > > > > + maxItems: 1 > > > > + > > > > + viocfg-gpios: > > > > + description: GPIO output 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 > > > > > > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals? > > > > > > > Not sure about vendor defined signals as they can be either GPIO or interface > > signals. How should them be defined? > > That kind of breaks any notion of this being a generic slot/connector. > How's the host supposed to know how to connect them? What if a card > required them to be driven a certain way before you can discover the > card? If they can be GPIOs and can be hooked up to the host system > GPIOs, then you should define GPIOs for them. If they aren't GPIOs on > a host, then you omit them. > Ok, then defining them as 'vendorN-gpios' is fine? - Mani -- மணிவண்ணன் சதாசிவம்
On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote: > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > > > > devices. Spec also provides an optional interface to connect the UIM card, > > > > > but that is not covered in this binding. > > > > > > > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > > > > MAINTAINERS | 1 + > > > > > 2 files changed, 155 insertions(+) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > new file mode 100644 > > > > > index 000000000000..b65b39ddfd19 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > @@ -0,0 +1,154 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: PCIe M.2 Mechanical Key E Connector > > > > > + > > > > > +maintainers: > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > > > > + > > > > > +description: > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > > > > + connector. Mechanical Key E connectors are used to connect Wireless > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > + const: pcie-m2-e-connector > > > > > + > > > > > + vpcie3v3-supply: > > > > > + description: A phandle to the regulator for 3.3v supply. > > > > > + > > > > > + vpcie1v8-supply: > > > > > + description: A phandle to the regulator for VIO 1.8v supply. > > > > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > > > > may need something in DT to ensure those are powered. However, there's > > > > no guarantee that it's a single supply. > > > > > > > > > > 1.8v VIO supply is an optional supply and is only required if the platform > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in > > > the example for completeness. > > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V > > supplies and those supply the I/O pads of the GPIO pins (and possibly > > external pull-ups) that drive them. The 1.8V supply doesn't supply > > 1.8V to the slot, so making it a slot/connector property is wrong. > > > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and > not the whole card/adapter. But I don't get your multiple supplies concern. Spec > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O > buffer circuitry operating at 1.8 V." So it implies that either the single > supply available to the card through VIO might be used to power the whole I/O > circuit logic or the card can derive its own 1.8v supply from 3.3v supply. > > So how come the card can have 2 different 1.8v supplies powering the I/O > circuitry? Is there a pin on the connector for 1.8V supply? I don't have the spec, but the pinout I found[1] didn't show one. If there's a pin, then I have no concern. Rob [1] https://pinoutguide.com/HD/M.2_NGFF_connector_pinout.shtml
On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote: > On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote: > > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > > > > > devices. Spec also provides an optional interface to connect the UIM card, > > > > > > but that is not covered in this binding. > > > > > > > > > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > > > > > MAINTAINERS | 1 + > > > > > > 2 files changed, 155 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..b65b39ddfd19 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > > @@ -0,0 +1,154 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: PCIe M.2 Mechanical Key E Connector > > > > > > + > > > > > > +maintainers: > > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > > > > > + > > > > > > +description: > > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > > > > > + connector. Mechanical Key E connectors are used to connect Wireless > > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + const: pcie-m2-e-connector > > > > > > + > > > > > > + vpcie3v3-supply: > > > > > > + description: A phandle to the regulator for 3.3v supply. > > > > > > + > > > > > > + vpcie1v8-supply: > > > > > > + description: A phandle to the regulator for VIO 1.8v supply. > > > > > > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > > > > > may need something in DT to ensure those are powered. However, there's > > > > > no guarantee that it's a single supply. > > > > > > > > > > > > > 1.8v VIO supply is an optional supply and is only required if the platform > > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in > > > > the example for completeness. > > > > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V > > > supplies and those supply the I/O pads of the GPIO pins (and possibly > > > external pull-ups) that drive them. The 1.8V supply doesn't supply > > > 1.8V to the slot, so making it a slot/connector property is wrong. > > > > > > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and > > not the whole card/adapter. But I don't get your multiple supplies concern. Spec > > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O > > buffer circuitry operating at 1.8 V." So it implies that either the single > > supply available to the card through VIO might be used to power the whole I/O > > circuit logic or the card can derive its own 1.8v supply from 3.3v supply. > > > > So how come the card can have 2 different 1.8v supplies powering the I/O > > circuitry? > > Is there a pin on the connector for 1.8V supply? I don't have the > spec, but the pinout I found[1] didn't show one. If there's a pin, > then I have no concern. > Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since it is optional, it could've been omitted in the design you referenced. So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other 1.8v supplies other than the VIO supply though. - Mani -- மணிவண்ணன் சதாசிவம்
On Fri, Jan 16, 2026 at 8:43 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote: > > On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote: > > > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote: > > > > > > > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote: > > > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote: > > > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined > > > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector > > > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the > > > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT) > > > > > > > devices. Spec also provides an optional interface to connect the UIM card, > > > > > > > but that is not covered in this binding. > > > > > > > > > > > > > > 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-e-connector.yaml | 154 +++++++++++++++++++++ > > > > > > > MAINTAINERS | 1 + > > > > > > > 2 files changed, 155 insertions(+) > > > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > > > new file mode 100644 > > > > > > > index 000000000000..b65b39ddfd19 > > > > > > > --- /dev/null > > > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml > > > > > > > @@ -0,0 +1,154 @@ > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > > +%YAML 1.2 > > > > > > > +--- > > > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > > + > > > > > > > +title: PCIe M.2 Mechanical Key E Connector > > > > > > > + > > > > > > > +maintainers: > > > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> > > > > > > > + > > > > > > > +description: > > > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E > > > > > > > + connector. Mechanical Key E connectors are used to connect Wireless > > > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host > > > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. > > > > > > > + > > > > > > > +properties: > > > > > > > + compatible: > > > > > > > + const: pcie-m2-e-connector > > > > > > > + > > > > > > > + vpcie3v3-supply: > > > > > > > + description: A phandle to the regulator for 3.3v supply. > > > > > > > + > > > > > > > + vpcie1v8-supply: > > > > > > > + description: A phandle to the regulator for VIO 1.8v supply. > > > > > > > > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you > > > > > > may need something in DT to ensure those are powered. However, there's > > > > > > no guarantee that it's a single supply. > > > > > > > > > > > > > > > > 1.8v VIO supply is an optional supply and is only required if the platform > > > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in > > > > > the example for completeness. > > > > > > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V > > > > supplies and those supply the I/O pads of the GPIO pins (and possibly > > > > external pull-ups) that drive them. The 1.8V supply doesn't supply > > > > 1.8V to the slot, so making it a slot/connector property is wrong. > > > > > > > > > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and > > > not the whole card/adapter. But I don't get your multiple supplies concern. Spec > > > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O > > > buffer circuitry operating at 1.8 V." So it implies that either the single > > > supply available to the card through VIO might be used to power the whole I/O > > > circuit logic or the card can derive its own 1.8v supply from 3.3v supply. > > > > > > So how come the card can have 2 different 1.8v supplies powering the I/O > > > circuitry? > > > > Is there a pin on the connector for 1.8V supply? I don't have the > > spec, but the pinout I found[1] didn't show one. If there's a pin, > > then I have no concern. > > > > Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since > it is optional, it could've been omitted in the design you referenced. > > So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other > 1.8v supplies other than the VIO supply though. vpcie1v8 is fine. Rob
© 2016 - 2026 Red Hat, Inc.