Hi,

This series is an initial attempt to support the PCIe M.2 connectors in the
kernel and devicetree binding. The PCIe M.2 connectors as defined in the PCI
Express M.2 Specification are widely used in Notebooks/Tablet form factors (even
in PCs). On the ACPI platforms, power to these connectors are mostly handled by
the firmware/BIOS and the kernel never bothered to directly power manage them as
like other PCIe connectors. But on the devicetree platforms, the kernel needs to
power manage these connectors with the help of the devicetree description. But
so far, there is no proper representation of the M.2 connectors in devicetree
binding. This forced the developers to fake the M.2 connectors as PMU nodes [1]
and fixed regulators in devicetree.

So to properly support the M.2 connectors in devicetree platforms, this series
introduces the devicetree binding for Mechanical Key M connector as an example
and also the corresponding pwrseq driver and PCI changes in kernel to driver the
connector.

The Mechanical Key M connector is used to connect SSDs to the host machine over
PCIe/SATA interfaces. Due to the hardware constraints, this series only adds
support for driving the PCIe interface of the connector in the kernel.

Also, the optional interfaces supported by the Key M connectors are not
supported in the driver and left for the future enhancements.

Testing
=======

This series, together with the devicetree changes [2] [3] were tested on the
Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the NVMe SSD connected
over PCIe.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts?h=v6.18-rc4&id=d09ab685a8f51ba412d37305ea62628a01cbea57
[2] https://github.com/Mani-Sadhasivam/linux/commit/40120d02219f34d2040ffa6328f0d406b1e4c04d
[3] https://github.com/Mani-Sadhasivam/linux/commit/ff6c3075836cc794a3700b0ec6a4a9eb21d14c6f

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Changes in v5:
- used of_node_get() and devm_action to free regulators
- Link to v4: https://lore.kernel.org/r/20251228-pci-m2-v4-0-5684868b0d5f@oss.qualcomm.com

Changes in v4:
- Added graph property to SATA in this series and PCI to dtschema:
  https://github.com/devicetree-org/dt-schema/pull/180
- Used 'i2c-parent' instead of SMBus port
- Reworded the -gpios property description
- Rebased on top of v6.19-rc1
- Link to v3: https://lore.kernel.org/r/20251125-pci-m2-v3-0-c528042aea47@oss.qualcomm.com

Changes in v3:
- Changed the VIO supply name as per dtschema
- Added explicit endpoint properties to port 0 node for host I/F
- Used scope based cleanup for OF node in pwrseq driver
- Collected review tags
- Link to v2: https://lore.kernel.org/r/20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com

Changes in v2:
- Incorporated comments from Bartosz and Frank for pwrseq and dt-binding
  patches, especially adding the pwrseq match() code.
- Link to v1: https://lore.kernel.org/r/20251105-pci-m2-v1-0-84b5f1f1e5e8@oss.qualcomm.com

---
Manivannan Sadhasivam (5):
      dt-bindings: ata: sata: Document the graph port
      dt-bindings: connector: Add PCIe M.2 Mechanical Key M connector
      PCI/pwrctrl: Add support for handling PCIe M.2 connectors
      PCI/pwrctrl: Create pwrctrl device if the graph port is found
      power: sequencing: Add the Power Sequencing driver for the PCIe M.2 connectors

 .../devicetree/bindings/ata/sata-common.yaml       |   3 +
 .../bindings/connector/pcie-m2-m-connector.yaml    | 133 ++++++++++++++++
 MAINTAINERS                                        |   7 +
 drivers/pci/probe.c                                |   3 +-
 drivers/pci/pwrctrl/Kconfig                        |   1 +
 drivers/pci/pwrctrl/slot.c                         |  35 ++++-
 drivers/power/sequencing/Kconfig                   |   8 +
 drivers/power/sequencing/Makefile                  |   1 +
 drivers/power/sequencing/pwrseq-pcie-m2.c          | 169 +++++++++++++++++++++
 9 files changed, 354 insertions(+), 6 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251103-pci-m2-7633631b6faa

Best regards,
-- 
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

On Wed, Jan 07, 2026 at 07:41:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> Hi,
> 
> This series is an initial attempt to support the PCIe M.2 connectors in the
> kernel and devicetree binding. The PCIe M.2 connectors as defined in the PCI
> Express M.2 Specification are widely used in Notebooks/Tablet form factors (even
> in PCs). On the ACPI platforms, power to these connectors are mostly handled by
> the firmware/BIOS and the kernel never bothered to directly power manage them as
> like other PCIe connectors. But on the devicetree platforms, the kernel needs to
> power manage these connectors with the help of the devicetree description. But
> so far, there is no proper representation of the M.2 connectors in devicetree
> binding. This forced the developers to fake the M.2 connectors as PMU nodes [1]
> and fixed regulators in devicetree.
> 
> So to properly support the M.2 connectors in devicetree platforms, this series
> introduces the devicetree binding for Mechanical Key M connector as an example
> and also the corresponding pwrseq driver and PCI changes in kernel to driver the
> connector.
> 
> The Mechanical Key M connector is used to connect SSDs to the host machine over
> PCIe/SATA interfaces. Due to the hardware constraints, this series only adds
> support for driving the PCIe interface of the connector in the kernel.
> 
> Also, the optional interfaces supported by the Key M connectors are not
> supported in the driver and left for the future enhancements.

For me, it is not clear if there is a dependency or conflict with your
"major pwrctrl rework series":
[PATCH v4 0/8] PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers

Does one need to go before the other, or are they completely unrelated
and can be merged in any order without conflicts?


Kind regards,
Niklas

On Wed, Jan 07, 2026 at 03:36:31PM +0100, Niklas Cassel wrote:
> On Wed, Jan 07, 2026 at 07:41:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > Hi,
> > 
> > This series is an initial attempt to support the PCIe M.2 connectors in the
> > kernel and devicetree binding. The PCIe M.2 connectors as defined in the PCI
> > Express M.2 Specification are widely used in Notebooks/Tablet form factors (even
> > in PCs). On the ACPI platforms, power to these connectors are mostly handled by
> > the firmware/BIOS and the kernel never bothered to directly power manage them as
> > like other PCIe connectors. But on the devicetree platforms, the kernel needs to
> > power manage these connectors with the help of the devicetree description. But
> > so far, there is no proper representation of the M.2 connectors in devicetree
> > binding. This forced the developers to fake the M.2 connectors as PMU nodes [1]
> > and fixed regulators in devicetree.
> > 
> > So to properly support the M.2 connectors in devicetree platforms, this series
> > introduces the devicetree binding for Mechanical Key M connector as an example
> > and also the corresponding pwrseq driver and PCI changes in kernel to driver the
> > connector.
> > 
> > The Mechanical Key M connector is used to connect SSDs to the host machine over
> > PCIe/SATA interfaces. Due to the hardware constraints, this series only adds
> > support for driving the PCIe interface of the connector in the kernel.
> > 
> > Also, the optional interfaces supported by the Key M connectors are not
> > supported in the driver and left for the future enhancements.
> 
> For me, it is not clear if there is a dependency or conflict with your
> "major pwrctrl rework series":
> [PATCH v4 0/8] PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers
> 
> Does one need to go before the other, or are they completely unrelated
> and can be merged in any order without conflicts?
> 

Only patch 2 has the conflict with pwrctrl rework series, but that is trivial to
fix. Otherwise, both are mostly independent.

- Mani

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