Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: rafael@kernel.org, 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
Subject: Re: [PATCH v1] PCI/AER: Avoid power state transition during system suspend
Date: Fri, 4 Apr 2025 08:22:53 +0300	[thread overview]
Message-ID: <Z-9srbRKYRMcuksZ@black.fi.intel.com> (raw)
In-Reply-To: <Z-9NPQUMt2s90CAA@wunner.de>

On Fri, Apr 04, 2025 at 05:08:45AM +0200, Lukas Wunner wrote:
> On Thu, Apr 03, 2025 at 01:14:25PM +0530, Raag Jadav wrote:
> > If an error is triggered while system suspend is in progress, any bus
> > level power state transition will result in unpredictable error handling.
> > Mark skip_bus_pm flag as true to avoid this.
> [...]
> > Ideally we'd want to defer recovery until system resume, but this is
> > good enough to prevent device suspend.
> 
> if (system_state == SYSTEM_SUSPEND)
> 
> ... tells you whether the system is suspending, so you could catch that
> in the error recovery code.

Even if we catch it, what'd be the expectation with it?
Do we can simply ignore the error because of system state?

I'm assuming deferring will require a fair bit of revamp (and I'm
not sure if I'm qualified for it).

> Suspend to ACPI state S3 or S4 shouldn't need error recovery through reset
> upon resume because devices are generally reset by BIOS on resume anyway.

Thanks for your input. We have s2idle usecase as well.

So the question here is whether we should allow suspending the device
with errors at all (atleast until successful recovery). Wouldn't the
device resume be unpredictable because of it?

Raag

      reply	other threads:[~2025-04-04  5:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-03  7:44 [PATCH v1] PCI/AER: Avoid power state transition during system suspend Raag Jadav
2025-04-03 18:25 ` Raag Jadav
2025-04-03 18:35 ` Rafael J. Wysocki
2025-04-04  5:26   ` Raag Jadav
2025-04-04  3:08 ` Lukas Wunner
2025-04-04  5:22   ` 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=Z-9srbRKYRMcuksZ@black.fi.intel.com \
    --to=raag.jadav@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox