From: Sean Christopherson <seanjc@google.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
David Matlack <dmatlack@google.com>,
Vipin Sharma <vipinsh@google.com>,
Aaron Lewis <aaronlewis@google.com>,
Sean Christopherson <seanjc@google.com>
Subject: [RFC PATCH] PCI: Support Immediate Readiness on devices without PM capabilities
Date: Tue, 24 Jun 2025 10:16:37 -0700 [thread overview]
Message-ID: <20250624171637.485616-1-seanjc@google.com> (raw)
Query support for Immediate Readiness irrespective of whether or not the
device supports PM capabilities, as nothing in the PCIe spec suggests that
Immediate Readiness is in any way dependent on PM functionality.
Opportunistically add a comment to explain why "errors" during PM setup
are effectively ignored.
Fixes: d6112f8def51 ("PCI: Add support for Immediate Readiness")
Cc: David Matlack <dmatlack@google.com>
Cc: Vipin Sharma <vipinsh@google.com>
Cc: Aaron Lewis <aaronlewis@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
RFC as I'm not entirely sure this is useful/correct.
Found by inspection when debugging a VFIO VF passthrough issue that turned out
to be 907a7a2e5bf4 ("PCI/PM: Set up runtime PM even for devices without PCI PM").
The folks on the Cc list are looking at parallelizing VF assignment to avoid
serializing the 100ms wait on FLR. I'm hoping we'll get lucky and the VFs in
question do (or can) support PCI_STATUS_IMM_READY.
drivers/pci/pci.c | 40 +++++++++++++++++++++++++---------------
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 9e42090fb108..cd91adbf0269 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3198,33 +3198,22 @@ void pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev)
pci_update_current_state(pci_dev, PCI_D0);
}
-/**
- * pci_pm_init - Initialize PM functions of given PCI device
- * @dev: PCI device to handle.
- */
-void pci_pm_init(struct pci_dev *dev)
+static void __pci_pm_init(struct pci_dev *dev)
{
int pm;
- u16 status;
u16 pmc;
- device_enable_async_suspend(&dev->dev);
- dev->wakeup_prepared = false;
-
- dev->pm_cap = 0;
- dev->pme_support = 0;
-
/* find PCI PM capability in list */
pm = pci_find_capability(dev, PCI_CAP_ID_PM);
if (!pm)
- goto poweron;
+ return;
/* Check device's ability to generate PME# */
pci_read_config_word(dev, pm + PCI_PM_PMC, &pmc);
if ((pmc & PCI_PM_CAP_VER_MASK) > 3) {
pci_err(dev, "unsupported PM cap regs version (%u)\n",
pmc & PCI_PM_CAP_VER_MASK);
- goto poweron;
+ return;
}
dev->pm_cap = pm;
@@ -3265,11 +3254,32 @@ void pci_pm_init(struct pci_dev *dev)
/* Disable the PME# generation functionality */
pci_pme_active(dev, false);
}
+}
+
+/**
+ * pci_pm_init - Initialize PM functions of given PCI device
+ * @dev: PCI device to handle.
+ */
+void pci_pm_init(struct pci_dev *dev)
+{
+ u16 status;
+
+ device_enable_async_suspend(&dev->dev);
+ dev->wakeup_prepared = false;
+
+ dev->pm_cap = 0;
+ dev->pme_support = 0;
+
+ /*
+ * Note, support for the PCI PM spec is optional for legacy PCI devices
+ * and for VFs. Continue on even if no PM capabilities are supported.
+ */
+ __pci_pm_init(dev);
pci_read_config_word(dev, PCI_STATUS, &status);
if (status & PCI_STATUS_IMM_READY)
dev->imm_ready = 1;
-poweron:
+
pci_pm_power_up_and_verify_state(dev);
pm_runtime_forbid(&dev->dev);
pm_runtime_set_active(&dev->dev);
base-commit: 86731a2a651e58953fc949573895f2fa6d456841
--
2.50.0.714.g196bf9f422-goog
next reply other threads:[~2025-06-24 17:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 17:16 Sean Christopherson [this message]
2025-06-25 16:32 ` Vipin Sharma
2025-06-25 23:03 ` Bjorn Helgaas
2025-06-26 22:17 ` Sean Christopherson
2025-06-27 15:51 ` Bjorn Helgaas
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=20250624171637.485616-1-seanjc@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=vipinsh@google.com \
/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
all inboxes | Powered by JetHome®