linux-kernel - [PATCH 3/3] PCI/pwrctrl: Support PERST GPIO in slot driver

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: <20251219172222.2808195-3-sean.anderson@linux.dev>
Date: Fri, 19 Dec 2025 12:22:22 -0500
From: Sean Anderson <sean.anderson@...ux.dev>
To: Manivannan Sadhasivam <mani@...nel.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Bartosz Golaszewski <brgl@...nel.org>
Cc: linux-pci@...r.kernel.org,
	Chen-Yu Tsai <wenst@...omium.org>,
	linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
	Brian Norris <briannorris@...omium.org>,
	Niklas Cassel <cassel@...nel.org>,
	Chen-Yu Tsai <wens@...nel.org>,
	Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
	Alex Elder <elder@...cstar.com>,
	Sean Anderson <sean.anderson@...ux.dev>
Subject: [PATCH 3/3] PCI/pwrctrl: Support PERST GPIO in slot driver

On many embedded platforms PERST is controlled by a GPIO. This was
traditionally handled by the host bridge. However, PERST may be released
before slot resources are initialized if there is a pwrctrl device. To
ensure we follow the power sequence, add support for controlling PERST
to the slot driver.

The host bridge could have already grabbed the GPIO. If this happens the
power sequence might be violated but there's really nothing we can do so
we just ignore the GPIO.

PERST must be asserted for at least T_PERST, such as when
entering/exiting S3/S4. As an optimization, we skip this delay when
PERST was already asserted, which may be the case when booting (such as
if the system has a pull-down on the line).

If the link is already up (e.g. the bootloader configured the power
supplies, clocks, and PERST) we will reset the link anyway. I don't
really know how to avoid this. I think we're OK because the root port
will be probed before we probe the endpoint so we shouldn't reset the
link while we're reading the configuration space.

Signed-off-by: Sean Anderson <sean.anderson@...ux.dev>
---

 drivers/pci/pwrctrl/slot.c | 52 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pwrctrl/slot.c b/drivers/pci/pwrctrl/slot.c
index 1c56fcd49f2b..59dc92c4bc04 100644
--- a/drivers/pci/pwrctrl/slot.c
+++ b/drivers/pci/pwrctrl/slot.c
@@ -7,6 +7,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/gpio/consumer.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/pci-pwrctrl.h>
@@ -18,6 +19,7 @@ struct pci_pwrctrl_slot_data {
 	struct pci_pwrctrl ctx;
 	struct regulator_bulk_data *supplies;
 	int num_supplies;
+	struct gpio_desc *perst;
 };
 
 static void devm_pci_pwrctrl_slot_power_off(void *data)
@@ -28,6 +30,13 @@ static void devm_pci_pwrctrl_slot_power_off(void *data)
 	regulator_bulk_free(slot->num_supplies, slot->supplies);
 }
 
+static void devm_pci_pwrctrl_slot_assert_perst(void *data)
+{
+	struct pci_pwrctrl_slot_data *slot = data;
+
+	gpiod_set_value_cansleep(slot->perst, 1);
+}
+
 static int pci_pwrctrl_slot_probe(struct platform_device *pdev)
 {
 	struct pci_pwrctrl_slot_data *slot;
@@ -66,6 +75,14 @@ static int pci_pwrctrl_slot_probe(struct platform_device *pdev)
 				     "Failed to enable slot clock\n");
 	}
 
+	slot->perst = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+	if (IS_ERR(slot->perst)) {
+		/* The PCIe host bridge may have already grabbed the reset */
+		if (PTR_ERR(slot->perst) != -EBUSY)
+			return dev_err_probe(dev, ret, "failed to get PERST\n");
+		slot->perst = NULL;
+	}
+
 	if (slot->num_supplies)
 		/*
 		 * Delay for T_PVPERL. This could be reduced to 1 ms/50 ms
@@ -76,7 +93,40 @@ static int pci_pwrctrl_slot_probe(struct platform_device *pdev)
 		/* Delay for T_PERST-CLK (100 us for all slot types) */
 		delay = 100;
 
-	fsleep(delay)
+	if (slot->perst) {
+		/*
+		 * If PERST is inactive, the following call to
+		 * gpiod_direction_output will be the first time we assert it
+		 * and we will need to delay for T_PERST.
+		 */
+		if (gpiod_get_value_cansleep(slot->perst) != 1)
+			delay = 100000;
+
+		ret = gpiod_direction_output(slot->perst, 1);
+		if (ret) {
+			dev_err(dev, "failed to assert PERST\n");
+			return ret;
+		}
+	}
+
+	fsleep(delay);
+	if (slot->perst) {
+		gpiod_set_value(slot->perst, 0);
+		ret = devm_add_action_or_reset(dev,
+					       devm_pci_pwrctrl_slot_assert_perst,
+					       slot);
+		if (ret)
+			return ret;
+
+		/*
+		 * PCIe section 6.6.1:
+		 * > ... software must wait a minimum of 100 ms before sending a
+		 * > Configuration Request to the device immediately below that
+		 * > Port.
+		 */
+		msleep(100);
+	}
+
 	pci_pwrctrl_init(&slot->ctx, dev);
 
 	ret = devm_pci_pwrctrl_device_set_ready(dev, &slot->ctx);
-- 
2.35.1.1320.gc452695387.dirty