From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH 1/2] PCI: Avoid pointless capability searches
Date: Thu, 13 Feb 2025 10:38:50 -0600 [thread overview]
Message-ID: <20250213163850.GA114277@bhelgaas> (raw)
In-Reply-To: <7dbb0d8b-3708-60ba-ee9e-78aa48bee160@linux.intel.com>
On Thu, Feb 13, 2025 at 03:52:05PM +0200, Ilpo Järvinen wrote:
> On Fri, 7 Feb 2025, Bjorn Helgaas wrote:
> > Many of the save/restore functions in the pci_save_state() and
> > pci_restore_state() paths depend on both a PCI capability of the device and
> > a pci_cap_saved_state structure to hold the configuration data, and they
> > skip the operation if either is missing.
> >
> > Look for the pci_cap_saved_state first so if we don't have one, we can skip
> > searching for the device capability, which requires several slow config
> > space accesses.
> > +++ b/drivers/pci/vc.c
> > @@ -355,20 +355,17 @@ int pci_save_vc_state(struct pci_dev *dev)
> > int i;
> >
> > for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
> > - int pos, ret;
> > struct pci_cap_saved_state *save_state;
> > + int pos, ret;
> > +
> > + save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > + if (!save_state)
> > + return -ENOMEM;
> >
> > pos = pci_find_ext_capability(dev, vc_caps[i].id);
> > if (!pos)
> > continue;
> >
> > - save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > - if (!save_state) {
> > - pci_err(dev, "%s buffer not found in %s\n",
> > - vc_caps[i].name, __func__);
> > - return -ENOMEM;
> > - }
>
> I think this order change will cause a functional change because
> pci_allocate_vc_save_buffers() only allocated for those capabilities that
> are exist for dev. Thus, the loop will prematurely exit.
Oof, thank you for catching this! I'll drop this for now.
It would be nice to make pci_save_vc_state() parallel with
pci_restore_vc_state() (and with most other pci_save_*_state()
functions) and have it return void. But pci_save_state() returns the
pci_save_vc_state() return value, and there are ~20 pci_save_state()
callers that pay attention to that return value.
I'm not convinced there's real value in pci_save_state() error
returns, given that so few callers check it, but it definitely
requires more analysis before removing it.
> > ret = pci_vc_do_save_buffer(dev, pos, save_state, true);
> > if (ret) {
> > pci_err(dev, "%s save unsuccessful %s\n",
> > @@ -392,12 +389,15 @@ void pci_restore_vc_state(struct pci_dev *dev)
> > int i;
> >
> > for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
> > - int pos;
> > struct pci_cap_saved_state *save_state;
> > + int pos;
> > +
> > + save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > + if (!save_state)
> > + continue;
> >
> > pos = pci_find_ext_capability(dev, vc_caps[i].id);
> > - save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > - if (!save_state || !pos)
> > + if (!pos)
> > continue;
> >
> > pci_vc_do_save_buffer(dev, pos, save_state, false);
> >
>
> --
> i.
>
next prev parent reply other threads:[~2025-02-13 16:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 5:03 [PATCH 0/2] PCI: Avoid capability searches in save/restore state Bjorn Helgaas
2025-02-08 5:03 ` [PATCH 1/2] PCI: Avoid pointless capability searches Bjorn Helgaas
2025-02-13 13:52 ` Ilpo Järvinen
2025-02-13 16:38 ` Bjorn Helgaas [this message]
2025-02-14 14:20 ` Ilpo Järvinen
2025-02-08 5:03 ` [PATCH 2/2] PCI: Cache offset of Resizable BAR capability Bjorn Helgaas
2025-02-13 13:54 ` Ilpo Järvinen
2025-02-12 22:35 ` [PATCH 0/2] PCI: Avoid capability searches in save/restore state 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=20250213163850.GA114277@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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 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.