From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AACEC38BF63; Thu, 16 Apr 2026 13:34:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776346477; cv=none; b=jJROUxeD17HF7QaZRUT0Ip90fGDdQJI8ZhbrwZ4kbMDZALEOMfM5joFqwgfrTnz2ev1rSyflGkL+6BhklDAGqU7Ix31faUdLuVl6a+nNukzIGQBhus9EjXe6Ro7lCZR3gQG/NvzkbwrH/oPINHbYWSnrFV7gjjyvhy5H8Z2S0IU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776346477; c=relaxed/simple; bh=OdPGRiJ2OTAd0wN0VpIuzIvWe5D9n+gShs26W0B8xqs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KN4c0OSYumQWlsmEKCbOgyqyBvvegLoAiFahJmzTq9woCjwVBWA4CUjMhC3VEPLOCm9H44+COB5KEhTUiihz2Glc7ROO9WbbKoRiFQ4LCkRfBFaJzb0sXtpB84b6/C6Pna4aEAGD6v+TFq7bXHp3f+ypIQo7f3Bfjn8+xA64zVw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=EloIX9sM; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="EloIX9sM" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 462291A32F4; Thu, 16 Apr 2026 13:34:34 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 0867F60495; Thu, 16 Apr 2026 13:34:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 360BB10460880; Thu, 16 Apr 2026 15:34:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1776346472; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=3XpbdgVt+Cx8FP8MN9lmm4BPNvobbTQ5J2Ix6m+jMcE=; b=EloIX9sM1QOhKmblue3jMDM5k8KpAKMHSGLQ8TanAuK7ENEV4CJPIMh2MskGhnhqAWn8Yw kUAvaK1IF/Se+k3PBQG/MKIkBmVQpmTrY37v/4rJgCuO1y+r/1Gi1LkS705qt3VLfG8J/t Xh6hvLhGANS4fiHpUfY431EjCRXdb9gafJMTVqrXQqnuY5IB80FZ7/DSZE6NczIytZJkU/ 4zplh8emxfZOdpV5qrGtzBrEKS6pZZFh2AdjAIRSTDrK00XSpARNgEHfGzFQBwyefj3PSo lEtKIt5lgvdG95GPo0kXJtjJ2O6cW+fsn6WroFDb1nkTBbUb0qISYKdg0D0cCg== Date: Thu, 16 Apr 2026 15:34:21 +0200 From: Herve Codina To: Manivannan Sadhasivam Cc: Chen-Yu Tsai , Andy Shevchenko , Manivannan Sadhasivam , Rob Herring , Greg Kroah-Hartman , Jiri Slaby , Nathan Chancellor , Nicolas Schier , Hans de Goede , Ilpo =?UTF-8?B?SsOkcnZpbmVu?= , Mark Pearson , "Derek J. Clark" , Krzysztof Kozlowski , Conor Dooley , Marcel Holtmann , Luiz Augusto von Dentz , Bartosz Golaszewski , Bartosz Golaszewski , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-pm@vger.kernel.org, Stephan Gerhold , Dmitry Baryshkov , linux-acpi@vger.kernel.org, Hans de Goede , Bartosz Golaszewski , Luca Ceresoli Subject: Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree Message-ID: <20260416153421.1692848f@bootlin.com> In-Reply-To: <4yockfx5rjcvfh2n2excrgsknnhi72rv2w7wf7onks2ryt33sm@w7zkcxuc6vem> References: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com> <20260413075459.GA2626902@google.com> <20260415165651.153b573d@bootlin.com> <4yockfx5rjcvfh2n2excrgsknnhi72rv2w7wf7onks2ryt33sm@w7zkcxuc6vem> Organization: Bootlin X-Mailer: Claws Mail 4.3.1 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Hi Manivannan, On Thu, 16 Apr 2026 14:25:39 +0530 Manivannan Sadhasivam wrote: > On Wed, Apr 15, 2026 at 04:56:51PM +0200, Herve Codina wrote: > > Hi Chen, all, > > > > ... > > > > > > > > I'm not arguing for a even more generic "M.2" connector. The "key" is > > > already described in the compatible. I'm saying we should have some way > > > of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C) > > > on the connector so further nodes or properties can be attached to them, > > > either with overlays or dynamically within the kernel. Right now the > > > are only described as individual ports, but we can't actually tie a > > > device to a OF graph port. > > > > > > But maybe I'm overthinking the representation part. AFAICT for Qualcomm's > > > UART-based BT bit part, Mani just had the driver create a device node > > > under the UART (by traversing the OF graph to find the UART). If that's > > > the desired way then the connector binding should mention it. And that > > > works for me. But I think it's messier and also we're missing an > > > opportunity to make the M.2 connector a standardized attachment point > > > for overlays. > > > > > > Mani, could you also chime in a bit on what you envisioned? > > > > > > (Added Luca from Bootlin to CC, as I think there are parallels to the > > > "Hotplug of Non-discoverable Hardware" work) > > > > > > > Related to "Hotplug of Non-discoverable Hardware", > > > > I would add entries for busses in the connector without using an OF graph. > > > > I don't think this is a correct representation. It is non-standard to describe > the device nodes in some other connectors. While it may work with your series in > the future, not something I would bet-on at this point. > > Using OF graph to link the connector nodes look like the cleaner solution to me. In your DT binding, there is the i2c-parent property at connector level. How it is used or planned to be used in order to handle devices available on the board connected to the M2 connector ? > > > For I2C and later SPI, this was is done. > > > > You already have an i2c-parent property but no node where an i2c device > > can be added. > > > > The last discussion related to hotplug, connectors and DT led to the RFC > > series [1]. > > > > It is a huge series. The last patch give a real example of representation: > > https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/ > > > > In your case I would see some thing like: > > > > connector { > > compatible = "pcie-m2-e-connector"; > > vpcie3v3-supply = <&vreg_wcn_3p3>; > > vpcie1v8-supply = <&vreg_l15b_1p8>; > > > > /* > > * If those GPIOs have to be used by components available in > > * the connected board, a Nexus node should be used. > > */ > > w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>; > > w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>; > > viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>; > > uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>; > > sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>; > > sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>; > > > > conn-i2c { > > i2c-parent = <&i2c0>; > > > > /* > > * Here i2c devices available on the board > > * connected to the connector can be described. > > */ > > }; > > > > /* Same kind to description for other busses */ > > conn-pcie { > > pci-parent = <&xxxxx>; > > > > /* > > * The PCIe bus has abilities to discover devices. > > * Not sure this node is needed. > > * > > * If a PCI device need a DT description to describe > > * stuffs behind the device, what has been done for LAN966x > > * could be re-used [2] and [3] > > */ > > I don't think anyone would connect something like LAN966x to the M.2 connector. > M.2 cards have a defined purpose, like NVMe, WLAN etc... If anyone wants to > connect another SoC like LAN966x, they would use non-M.2 connectors. Hum, maybe yes, maybe not. I don't know what kind of hardware could be available on a M2 connector. One think sure is that a PCIe bus is available on the connector and so, potentially all PCI devices could be wired on a M2 form factor. LAN966x in PCI version is just a PCI device. Anyway, Is it allowed to have sub-nodes in a port node ? I mean, can we describe devices connected to a bus described by the port node ? For USB and PCI it is probably not needed for common use cases but having a DT description for devices on PCI and/or USB exists and is supported in the current kernel On SDIO, wireless devices can be described: Documentation/devicetree/bindings/net/wireless/ and so, sub-nodes will be needed. As those devices need an address (reg property), #address-cells and #size-cells will be needed. This will end in a mix of sub-nodes describing devices and a sub-node describing the endpoint connection. #address-cells and #size-cells will conflict at some points. Is a reg value for endpoints has the same characteristics as a reg value for a SDIO device ? How a BT devices is described under the UART available in the M2 connector ? Best regards, Hervé