All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: mahesh@linux.ibm.com, oohall@gmail.com, bhelgaas@google.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	ilpo.jarvinen@linux.intel.com, lukas@wunner.de,
	aravind.iddamsetty@linux.intel.com
Subject: Re: [PATCH v2] PCI/PM: Avoid suspending the device with errors
Date: Sat, 26 Apr 2025 23:18:13 +0300	[thread overview]
Message-ID: <aA0_hUh9cUuP-tgV@black.fi.intel.com> (raw)
In-Reply-To: <CAJZ5v0gQ-6ZehL5HNhFvOWDEyXdS++uaMn1AOB7whoMTKzj-ZQ@mail.gmail.com>

On Thu, Apr 24, 2025 at 01:02:58PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 24, 2025 at 7:38 AM Raag Jadav <raag.jadav@intel.com> wrote:
> >
> > On Wed, Apr 23, 2025 at 02:41:52PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Apr 22, 2025 at 3:55 PM Raag Jadav <raag.jadav@intel.com> wrote:
> > > >
> > > > If an error is triggered before or during system suspend, any bus level
> > > > power state transition will result in unpredictable behaviour by the
> > > > device with failed recovery. Avoid suspending such a device and leave
> > > > it in its existing power state.
> > > >
> > > > This only covers the devices that rely on PCI core PM for their power
> > > > state transition.
> > > >
> > > > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> > > > ---
> > > >
> > > > v2: Synchronize AER handling with PCI PM (Rafael)
> > > >
> > > > More discussion on [1].
> > > > [1] https://lore.kernel.org/all/CAJZ5v0g-aJXfVH+Uc=9eRPuW08t-6PwzdyMXsC6FZRKYJtY03Q@mail.gmail.com/
> > > >
> > > >  drivers/pci/pci-driver.c |  3 ++-
> > > >  drivers/pci/pcie/aer.c   | 11 +++++++++++
> > > >  include/linux/aer.h      |  2 ++
> > > >  3 files changed, 15 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > > > index f57ea36d125d..289a1fa7cb2d 100644
> > > > --- a/drivers/pci/pci-driver.c
> > > > +++ b/drivers/pci/pci-driver.c
> > > > @@ -884,7 +884,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
> > > >                 }
> > > >         }
> > > >
> > > > -       if (!pci_dev->state_saved) {
> > > > +       /* Avoid suspending the device with errors */
> > > > +       if (!pci_aer_in_progress(pci_dev) && !pci_dev->state_saved) {
> > >
> > > Apart from the potential raciness mentioned by Bjorn, doing it just
> > > here is questionable because this is not the only place where the PCI
> > > device power state can change.
> > >
> > > It would be better to catch this in pci_set_low_power_state() IMO.
> >
> > I'm not sure if we should prevent power state transition for the users
> > that explicitly want to transition.
> >
> > Also, the device state can potentially be corrupted because of the errors,
> > so we'd probably want to avoid pci_save_state() as well, which is what
> > I attempted here.
> 
> But it's not what the changelog is saying.
> 
> If you want to avoid pci_save_state(), there are also other places
> when it is called and then you also may want to avoid the transition
> because if the state is not saved, it won't be possible to restore it.

Yes, above logic will skip both pci_save_state() and pci_prepare_to_sleep()
and in turn set skip_bus_pm flag to prevent power state transition.

Considering we're targeting only system PM cases, I could find pci_save_state()
being used in pci_pm_suspend_noirq() and pci_pm_freeze_noirq() (excluding
legacy suspend). pci_pm_freeze_noirq() doesn't seem to attempt any power state
transition by itself, so any other cases that you think are worth being covered
here?

Raag

      reply	other threads:[~2025-04-26 20:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-22 13:53 [PATCH v2] PCI/PM: Avoid suspending the device with errors Raag Jadav
2025-04-22 18:01 ` kernel test robot
2025-04-22 19:45 ` Bjorn Helgaas
2025-04-24  5:12   ` Raag Jadav
2025-04-24 10:59     ` Rafael J. Wysocki
2025-04-26 19:24       ` Raag Jadav
2025-04-22 23:39 ` kernel test robot
2025-04-23 12:41 ` Rafael J. Wysocki
2025-04-24  5:38   ` Raag Jadav
2025-04-24 11:02     ` Rafael J. Wysocki
2025-04-26 20:18       ` Raag Jadav [this message]

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=aA0_hUh9cUuP-tgV@black.fi.intel.com \
    --to=raag.jadav@intel.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mahesh@linux.ibm.com \
    --cc=oohall@gmail.com \
    --cc=rafael@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.