Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Manivannan Sadhasivam]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >  .../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@xxxxxxxxxxxxxxxx>
> > > > +
> > > > +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

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