From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Riana Tauro <riana.tauro@intel.com>,
"Sean C. Dardis" <sean.c.dardis@intel.com>,
Farhan Ali <alifm@linux.ibm.com>,
Benjamin Block <bblock@linux.ibm.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Alek Du <alek.du@intel.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver OHalloran <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
qat-linux@intel.com, Dave Jiang <dave.jiang@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH 1/2] PCI: Ensure error recoverability at all times
Date: Wed, 19 Nov 2025 11:02:23 +0100 [thread overview]
Message-ID: <aR2VrxHGAxwpWQxF@wunner.de> (raw)
In-Reply-To: <20251114233927.GA2340588@bhelgaas>
On Fri, Nov 14, 2025 at 05:39:27PM -0600, Bjorn Helgaas wrote:
> On Fri, Nov 14, 2025 at 07:58:19PM +0100, Lukas Wunner wrote:
> > On Thu, Nov 13, 2025 at 10:15:56AM -0600, Bjorn Helgaas wrote:
> > > It seems like there are two things going on here, and I'm not sure
> > > they're completely compatible:
> > >
> > > 1) Driver calls pci_save_state() to take over device power
> > > management and prevent the PCI core from doing it.
> > >
> > > 2) Driver calls pci_save_state() to capture the device state it
> > > wants to restore when recovering from an error.
> > >
> > > Shouldn't a driver be able to do 2) without also getting 1)?
> >
> > In general, it can:
> >
> > A number of drivers already call pci_save_state() on probe to capture
> > the state for subsequent error recovery. If the driver has modified
> > config space in its probe hook, then calling pci_save_state() continues
> > to make sense. If the driver has *not* modified config space, then the
> > call becomes obsolete once this patch is accepted.
>
> So I guess "state_saved == true" means "driver does its own power
> management and PCI core shouldn't do it", and drivers that want 2) but
> not 1) just need to set state_saved = false after they call
> pci_save_state()?
>
> That makes sense in sort of a weird way that makes my head hurt every
> time I try to understand it.
I agree it defies common sense. So I've just submitted a series
which adds the missing "state_saved = false" in the legacy suspend
and !pm codepaths:
https://lore.kernel.org/r/094f2aad64418710daf0940112abe5a0afdc6bce.1763483367.git.lukas@wunner.de/
After this patch, the flag is always cleared before commencing the
suspend sequence and hence there is no longer a need for drivers to
clear state_saved after they call pci_save_state(). They can just
call pci_save_state() if they've modified Config Space in their
probe hook and be done with it.
> After error recovery, those drivers will see the state the driver
> identified when it called pci_save_state(). But after resume, they
> will see the state the PCI core saved at suspend time. Right?
Correct. The expectation is generally that they're identical.
E.g. I've just double-checked that we're enabling wakeup *after*
pci_save_state() in pci_pm_suspend_noirq(). So when the saved
state is restored on resume and later re-used for error recovery,
we're restoring the device with wakeup disabled, which is the
right thing to do because the device is in D0 after error recovery
issues a reset.
(pci_pm_suspend_noirq() first calls pci_save_state() and then calls
pci_prepare_to_sleep(), which enables wakeup.)
Thanks,
Lukas
next prev parent reply other threads:[~2025-11-19 10:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-12 13:25 [PATCH 0/2] PCI: Universal error recoverability of devices Lukas Wunner
2025-10-12 13:25 ` [PATCH 1/2] PCI: Ensure error recoverability at all times Lukas Wunner
2025-11-12 22:38 ` Bjorn Helgaas
2025-11-13 9:38 ` Lukas Wunner
2025-11-13 16:15 ` Bjorn Helgaas
2025-11-14 18:58 ` Lukas Wunner
2025-11-14 23:39 ` Bjorn Helgaas
2025-11-19 10:02 ` Lukas Wunner [this message]
2025-11-21 17:40 ` Lukas Wunner
2025-11-24 22:11 ` Bjorn Helgaas
2025-11-13 20:49 ` Rafael J. Wysocki
2025-11-13 21:03 ` Rafael J. Wysocki
2025-10-12 13:25 ` [PATCH 2/2] treewide: Drop pci_save_state() after pci_restore_state() Lukas Wunner
2025-11-05 14:22 ` Dave Jiang
2025-11-05 14:33 ` Giovanni Cabiddu
2025-11-24 23:13 ` Bjorn Helgaas
2025-11-14 23:45 ` [PATCH 0/2] PCI: Universal error recoverability of devices Bjorn Helgaas
2025-11-19 9:26 ` Lukas Wunner
2025-11-24 21:42 ` 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=aR2VrxHGAxwpWQxF@wunner.de \
--to=lukas@wunner.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alek.du@intel.com \
--cc=alifm@linux.ibm.com \
--cc=andrew+netdev@lunn.ch \
--cc=bblock@linux.ibm.com \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=giovanni.cabiddu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=jirislaby@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=martin.petersen@oracle.com \
--cc=oohall@gmail.com \
--cc=pabeni@redhat.com \
--cc=qat-linux@intel.com \
--cc=rafael@kernel.org \
--cc=riana.tauro@intel.com \
--cc=schnelle@linux.ibm.com \
--cc=sean.c.dardis@intel.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.