From: Rich Hanes <georgebastille@gmail.com>
To: bhelgaas@google.com
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
mario.limonciello@amd.com, stable@vger.kernel.org,
Rich Hanes <georgebastille@gmail.com>
Subject: [PATCH] PCI/PM: Don't call pci_pm_power_up_and_verify_state() for devices already in D0
Date: Wed, 4 Mar 2026 17:03:24 +0000 [thread overview]
Message-ID: <20260304170324.67076-1-georgebastille@gmail.com> (raw)
Commit 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when
initializing") calls pci_pm_power_up_and_verify_state() for every PCI
device at the end of pci_pm_init(). This causes a boot-time regression
on PCIe endpoints that the firmware leaves in D0.
The problem is not the _PS0 call itself — pci_power_up() returns early
when the hardware PM_CTRL register already reads D0. The problem is
that pci_pm_power_up_and_verify_state() unconditionally calls
pci_update_current_state() afterwards, which sets current_state to
PCI_D0 even for devices that were never actually transitioned.
pcie_aspm_init_link_state() later checks current_state when the
pcieport driver binds to the upstream port. From aspm.c:
/* Spec says both ports must be in D0 before enabling PCI PM substates */
if (parent->current_state != PCI_D0 || child->current_state != PCI_D0) {
state &= ~PCIE_LINK_STATE_L1_SS_PCIPM;
When current_state is PCI_D0 (set prematurely by pci_pm_init()), ASPM
enables L1 PM substates including L1.2. L1.2 removes the PCIe
reference clock from the link during idle periods, putting the
downstream device into a D3cold-equivalent state. Without a subsequent
_PS0 call to restore it, the device does not respond to config space
reads when the link returns to L0. pciehp observes this as:
pciehp: Slot(0): Card not present <- L1.2 entry during link retrain
pciehp: Slot(0): Card present
pciehp: Slot(0): Link Up
pciehp: Slot(0): No device found <- device unresponsive in D3cold
Reproduced on a Lenovo ThinkPad with Intel Wireless-AC 7265 (8086:095a)
behind PCIe root port 8086:9d10. The workaround pcie_aspm=off confirms
that suppressing L1 PM substate configuration prevents the failure.
The fix is to read PM_CTRL before calling
pci_pm_power_up_and_verify_state() and skip it when the hardware already
reports D0. This preserves the
_REG notification for devices the firmware leaves in a non-D0 state
(the original motivation for the commit) while leaving current_state as
PCI_UNKNOWN for devices already in D0, which correctly defers L1 PM
substate enablement.
Also add an early return to pci_power_up() to avoid calling
platform_pci_set_power_state() (_PS0) redundantly on devices whose
hardware state is already D0 and whose software state is PCI_UNKNOWN.
Fixes: 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing")
Cc: stable@vger.kernel.org
Cc: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Rich Hanes <georgebastille@gmail.com>
---
drivers/pci/pci.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8479c2e1f74f..e2e11b2884d4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1301,6 +1301,13 @@ int pci_power_up(struct pci_dev *dev)
pci_power_t state;
u16 pmcsr;
+ if (dev->pm_cap && dev->current_state == PCI_UNKNOWN && !pci_dev_is_disconnected(dev)) {
+ pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+ if (!PCI_POSSIBLE_ERROR(pmcsr) && (pmcsr & PCI_PM_CTRL_STATE_MASK) == PCI_D0) {
+ dev->current_state = PCI_D0;
+ return 0;
+ }
+ }
platform_pci_set_power_state(dev, PCI_D0);
if (!dev->pm_cap) {
@@ -3191,7 +3198,27 @@ void pci_pm_init(struct pci_dev *dev)
}
poweron:
- pci_pm_power_up_and_verify_state(dev);
+ /*
+ * Explicitly put the device into D0 to ensure platform power methods
+ * such as _PS0 are called and _REG is notified. Only do this when
+ * the hardware is not already in D0: pcie_aspm_init_link_state()
+ * enables PCIe L1 PM substates (L1.1/L1.2) only when both the
+ * downstream device and its parent report current_state == PCI_D0.
+ * Calling pci_pm_power_up_and_verify_state() for a device already in
+ * D0 would set current_state prematurely, enabling L1.2 before the
+ * driver is ready and causing the device to enter a deep sleep state
+ * it cannot exit without platform intervention (_PS0).
+ */
+ if (dev->pm_cap) {
+ u16 pmcsr;
+
+ pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+ if (PCI_POSSIBLE_ERROR(pmcsr) ||
+ (pmcsr & PCI_PM_CTRL_STATE_MASK) != PCI_D0)
+ pci_pm_power_up_and_verify_state(dev);
+ } else {
+ pci_pm_power_up_and_verify_state(dev);
+ }
pm_runtime_forbid(&dev->dev);
/*
--
2.53.0
next reply other threads:[~2026-03-04 17:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 17:03 Rich Hanes [this message]
2026-03-04 17:52 ` [PATCH] PCI/PM: Don't call pci_pm_power_up_and_verify_state() for devices already in D0 Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260304170324.67076-1-georgebastille@gmail.com \
--to=georgebastille@gmail.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox