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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJxBNm0y6T7vji6MXgsO65iDJ-tdUEo0cOxkw7EuMKpkg@mail.gmail.com>
Date: Wed, 14 Jan 2026 11:45:42 -0600
From: Rob Herring <robh@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Hans de Goede <hansg@...nel.org>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Mark Pearson <mpearson-lenovo@...ebb.ca>, "Derek J. Clark" <derekjohn.clark@...il.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Marcel Holtmann <marcel@...tmann.org>, Luiz Augusto von Dentz <luiz.dentz@...il.com>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Bartosz Golaszewski <brgl@...nel.org>, linux-serial@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	platform-driver-x86@...r.kernel.org, linux-pci@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	linux-bluetooth@...r.kernel.org, linux-pm@...r.kernel.org, 
	Stephan Gerhold <stephan.gerhold@...aro.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical
 Key E connector

On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@...nel.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@....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@....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