From: Sean Christopherson <seanjc@google.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
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>
Subject: Re: [RFC PATCH] PCI: Support Immediate Readiness on devices without PM capabilities
Date: Thu, 26 Jun 2025 15:17:48 -0700 [thread overview]
Message-ID: <aF3HDIzpe3vnpBdj@google.com> (raw)
In-Reply-To: <20250625230313.GA1593493@bhelgaas>
On Wed, Jun 25, 2025, Bjorn Helgaas wrote:
> On Tue, Jun 24, 2025 at 10:16:37AM -0700, Sean Christopherson wrote:
> > +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;
>
> I would rather just move this PCI_STATUS read to somewhere else. I
> don't think there's a great place to put it. We could put it in
> set_pcie_port_type(), which is sort of a grab bag of PCIe-related
> things.
>
> I don't know if it's necessarily even a PCIe-specific thing, but it
> would be unexpected if somebody made a conventional PCI device that
> set it, since the bit was reserved (and should be zero) in PCI r3.0
> and defined in PCIe r4.0.
>
> Maybe we should put it in pci_setup_device() close to where we call
> pci_intx_mask_broken()?
Any reason not to throw it in pci_init_capabilities()? That has the advantage
of minimizing the travel distance, e.g. to avoid introducing a goof similar to
what happened with 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing").
E.g. something silly like this? Or maybe pci_misc_init() or so?
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 9e42090fb108..4a1ba5c017cd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3205,7 +3205,6 @@ void pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev)
void pci_pm_init(struct pci_dev *dev)
{
int pm;
- u16 status;
u16 pmc;
device_enable_async_suspend(&dev->dev);
@@ -3266,9 +3265,6 @@ void pci_pm_init(struct pci_dev *dev)
pci_pme_active(dev, false);
}
- 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);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4b8693ec9e4c..d33b8af37247 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2595,6 +2595,15 @@ void pcie_report_downtraining(struct pci_dev *dev)
__pcie_print_link_status(dev, false);
}
+static void pci_imm_ready_init(struct pci_dev *dev)
+{
+ u16 status;
+
+ pci_read_config_word(dev, PCI_STATUS, &status);
+ if (status & PCI_STATUS_IMM_READY)
+ dev->imm_ready = 1;
+}
+
static void pci_init_capabilities(struct pci_dev *dev)
{
pci_ea_init(dev); /* Enhanced Allocation */
@@ -2604,6 +2613,7 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
+ pci_imm_ready_init(dev); /* Immediate Ready */
pci_pm_init(dev); /* Power Management */
pci_vpd_init(dev); /* Vital Product Data */
pci_configure_ari(dev); /* Alternative Routing-ID Forwarding */
next prev parent reply other threads:[~2025-06-26 22:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 17:16 [RFC PATCH] PCI: Support Immediate Readiness on devices without PM capabilities Sean Christopherson
2025-06-25 16:32 ` Vipin Sharma
2025-06-25 23:03 ` Bjorn Helgaas
2025-06-26 22:17 ` Sean Christopherson [this message]
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=aF3HDIzpe3vnpBdj@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=helgaas@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.