| 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
| ||
|
Message-ID: <xyttom64ht5hrrp5hecjqehnyfgsv4mfl2t36e2sveu44ccpjl@lkzquse2kqsx> Date: Wed, 14 Jan 2026 21:44:32 +0530 From: Manivannan Sadhasivam <mani@...nel.org> To: Rob Herring <robh@...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 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. > > + > > + 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 -- மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists