[PATCH RFC 0/3] PCI/pwrctrl: Allow pwrctrl framework to control PERST# GPIO if available
From: Manivannan Sadhasivam
Date: Mon Jul 07 2025 - 14:18:59 EST
Hi,
This series is an RFC to propose pwrctrl framework to control the PERST# GPIO
instead of letting the controller drivers to do so (which is a mistake btw).
Right now, the pwrctrl framework is controlling the power supplies to the
components (endpoints and such), but it is not controlling PERST#. This was
pointed out by Brian during a related conversation [1]. But we cannot just move
the PERST# control from controller drivers due to the following reasons:
1. Most of the controller drivers need to assert PERST# during the controller
initialization sequence. This is mostly as per their hardware reference manual
and should not be changed.
2. Controller drivers still need to toggle PERST# when pwrctrl is not used i.e.,
when the power supplies are not accurately described in PCI DT node. This can
happen on unsupported platforms and also for platforms with legacy DTs.
For this reason, I've kept the PERST# retrieval logic in the controller drivers
and just passed the gpio descriptors (for each slot) to the pwrctrl framework.
This will allow both the controller drivers and pwrctrl framework to share the
PERST# (which is ugly but can't be avoided). But care must be taken to ensure
that the controller drivers only assert PERST# and not deassert when pwrctrl is
used. I've added the change for the Qcom driver as a reference. The Qcom driver
is a slight mess because, it now has to support both new DT binding (PERST# and
PHY in Root Port node) and legacy (both in Host Bridge node). So I've allowed
the PERST# control only for the new binding (which is always going to use
pwrctrl framework to control the component supplies).
Testing
=======
This series is tested on Lenovo Thinkpad T14s laptop (with out-of-tree patch
enabling PCIe WLAN card) and on RB3 Gen2 with TC9563 switch (also with the not
yet merged series [2]). A big take away from this series is that, it is now
possible to get rid of the controversial {start/stop}_link() callback proposed
in the above mentioned switch pwrctrl driver [3].
- Mani
[1] https://lore.kernel.org/linux-pci/Z_6kZ7x7gnoH-P7x@xxxxxxxxxx/
[2] https://lore.kernel.org/linux-pci/20250412-qps615_v4_1-v5-0-5b6a06132fec@xxxxxxxxxxxxxxxx/
[3] https://lore.kernel.org/linux-pci/20250412-qps615_v4_1-v5-4-5b6a06132fec@xxxxxxxxxxxxxxxx/
Signed-off-by: Manivannan Sadhasivam <mani@xxxxxxxxxx>
---
Manivannan Sadhasivam (3):
PCI/pwrctrl: Move pci_pwrctrl_init() before turning ON the supplies
PCI/pwrctrl: Allow pwrctrl core to control PERST# GPIO if available
PCI: qcom: Allow pwrctrl framework to control PERST#
drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-qcom.c | 26 ++++++++++++++-
drivers/pci/pwrctrl/core.c | 39 +++++++++++++++++++++++
drivers/pci/pwrctrl/pci-pwrctrl-pwrseq.c | 4 +--
drivers/pci/pwrctrl/slot.c | 4 +--
include/linux/pci-pwrctrl.h | 2 ++
include/linux/pci.h | 2 ++
8 files changed, 74 insertions(+), 5 deletions(-)
---
base-commit: 00f0defc332be94b7f1fdc56ce7dcb6528cdf002
change-id: 20250707-pci-pwrctrl-perst-bdc6e36a335c
Best regards,
--
Manivannan Sadhasivam <mani@xxxxxxxxxx>