linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Mario Limonciello (AMD)" <superm1@kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Pavel Machek" <pavel@kernel.org>, "Len Brown" <lenb@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"open list:HIBERNATION (aka Software Suspend,
	aka swsusp)" <linux-pm@vger.kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS"
	<amd-gfx@lists.freedesktop.org>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:SCSI SUBSYSTEM" <linux-scsi@vger.kernel.org>,
	"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
	"open list:TRACING" <linux-trace-kernel@vger.kernel.org>,
	"AceLan Kao" <acelan.kao@canonical.com>,
	"Kai-Heng Feng" <kaihengf@nvidia.com>,
	"Mark Pearson" <mpearson-lenovo@squebb.ca>,
	"Merthan Karakaş" <m3rthn.k@gmail.com>,
	"Eric Naim" <dnaim@cachyos.org>,
	"Guilherme G . Piccoli" <gpiccoli@igalia.com>
Subject: Re: [PATCH v7 05/12] PCI/PM: Disable device wakeups when halting or powering off system
Date: Wed, 10 Sep 2025 12:11:32 -0500	[thread overview]
Message-ID: <20250910171132.GA1541776@bhelgaas> (raw)
In-Reply-To: <e1a46ac1-8e43-4a63-bf59-b9a7c04de40a@amd.com>

On Wed, Sep 10, 2025 at 11:52:00AM -0500, Mario Limonciello wrote:
> On 9/10/25 10:06 AM, Bjorn Helgaas wrote:
> > On Tue, Sep 09, 2025 at 02:16:12PM -0500, Mario Limonciello (AMD) wrote:
> > > PCI devices can be configured as wakeup sources from low power states.
> > > However, when the system is halting or powering off such wakeups are
> > > not expected and may lead to spurious behavior.
> > 
> > I'm a little unclear on the nomenclature for these low power states,
> > so I think it would be helpful to connect to the user action, e.g.,
> > suspend/hibernate/etc, and the ACPI state, e.g.,
> > 
> >    ... when the system is hibernating (e.g., transitioning to ACPI S4
> >    and halting) or powering off (e.g., transitioning to ACPI S5 soft
> >    off), such wakeups are not expected ...
> 
> I will try to firm it up in the commit message.  But yes you're getting the
> intent, having a wakeup occur at S5 would be unexpected, and would likely
> change semantics of what people "think" powering off a machine means.
> 
> > When I suspend or power off my laptop from the GUI user interface, I
> > want to know if keyboard or mouse activity will resume or if I need to
> > press the power button.
> 
> The way the kernel is set up today you get a single wakeup sysfs file for a
> device and that wakeup file means 3 things:
> * abort the process of entering a suspend state or hibernate
> * wake up the machine from a suspend state
> * wake up the machine from hibernate
> 
> > > ACPI r6.5, section 16.1.5 notes:
> > > 
> > >      "Hardware does allow a transition to S0 due to power button press
> > >       or a Remote Start."
> > 
> > Important to note here that sec 16.1.5 is specifically for "S5
> > Soft Off State".
> > 
> > S4 is a sleeping state and presumably sec 16.1.6 ("Transitioning
> > from the Working to the Sleeping State") applies.  That section
> > mentions wakeup devices, so it's not obvious to me that PCI device
> > wakeup should be disabled for S4.
> 
> It actually /shouldn't/ be disabled for S4 - it should only be
> disabled for S5.
> 
> Are you implying a bug in the flow?  I didn't think there was one:
> 
> During entering hibernate the poweroff() call will have system_state
> = SYSTEM_SUSPEND so wakeups would be enabled.
> 
> For powering off the system using hibernate flows poweroff() call
> would have system_state = SYSTEM_HALT or SYSTEM_POWER_OFF.

OK.  I assumed that since you check for two states (SYSTEM_HALT or
SYSTEM_POWER_OFF), one must be hibernate (ending up in S4?) and the
other a soft power off (ending up in S5?).

But it sounds like there are two ways to power off.  I'm just confused
about the correspondence between hibernate, soft poweroff, S4, S5,
SYSTEM_HALT, and SYSTEM_POWER_OFF.

*Do* both SYSTEM_HALT and SYSTEM_POWER_OFF lead to S5 on an ACPI
system?  If so, what's the difference between them?

> > > This implies that wakeups from PCI devices should not be relied upon
> > > in these states. To align with this expectation and avoid unintended
> > > wakeups, disable device wakeup capability during these transitions.
> > > 
> > > Tested-by: Eric Naim <dnaim@cachyos.org>
> > > Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > > ---
> > > v7:
> > >   * Reword title
> > >   * Reword commit
> > > v5:
> > >   * Re-order
> > >   * Add tags
> > > v4:
> > >   * https://lore.kernel.org/linux-pci/20250616175019.3471583-1-superm1@kernel.org/
> > > ---
> > >   drivers/pci/pci-driver.c | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > > index 63665240ae87f..f201d298d7173 100644
> > > --- a/drivers/pci/pci-driver.c
> > > +++ b/drivers/pci/pci-driver.c
> > > @@ -1139,6 +1139,10 @@ static int pci_pm_poweroff(struct device *dev)
> > >   	struct pci_dev *pci_dev = to_pci_dev(dev);
> > >   	const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> > > +	if (device_may_wakeup(dev) &&
> > > +	    (system_state == SYSTEM_HALT || system_state == SYSTEM_POWER_OFF))
> > > +		device_set_wakeup_enable(dev, false);
> > > +
> > >   	if (pci_has_legacy_pm_support(pci_dev))
> > >   		return pci_legacy_suspend(dev, PMSG_HIBERNATE);
> > > -- 
> > > 2.43.0
> > > 
> 

  reply	other threads:[~2025-09-10 17:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 19:16 [PATCH v7 00/12] Improvements to S5 power consumption Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 01/12] PM: Introduce new PMSG_POWEROFF event Mario Limonciello (AMD)
2025-09-10 13:58   ` Rafael J. Wysocki
2025-09-10 17:48     ` Mario Limonciello
2025-09-10 18:00       ` Rafael J. Wysocki
2025-09-09 19:16 ` [PATCH v7 02/12] scsi: Add PM_EVENT_POWEROFF into suspend callbacks Mario Limonciello (AMD)
2025-09-10  1:50   ` Martin K. Petersen
2025-09-09 19:16 ` [PATCH v7 03/12] usb: sl811-hcd: " Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 04/12] USB: Pass PMSG_POWEROFF event to suspend_common() Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 05/12] PCI/PM: Disable device wakeups when halting or powering off system Mario Limonciello (AMD)
2025-09-10 15:06   ` Bjorn Helgaas
2025-09-10 16:52     ` Mario Limonciello
2025-09-10 17:11       ` Bjorn Helgaas [this message]
2025-09-10 17:24         ` Mario Limonciello
2025-09-10 17:38           ` Rafael J. Wysocki
2025-09-09 19:16 ` [PATCH v7 06/12] PCI/PM: Split out code from pci_pm_suspend_noirq() into helper Mario Limonciello (AMD)
2025-09-10 14:46   ` Bjorn Helgaas
2025-09-10 16:52     ` Mario Limonciello
2025-09-10 17:35   ` Rafael J. Wysocki
2025-09-09 19:16 ` [PATCH v7 07/12] PCI/PM: Run bridge power up actions as part of restore phase Mario Limonciello (AMD)
2025-09-10 17:48   ` Rafael J. Wysocki
2025-09-09 19:16 ` [PATCH v7 08/12] PCI/PM: Use pci_power_manageable() in pci_pm_poweroff_noirq() Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 09/12] PCI: Put PCIe bridges with downstream devices into D3 at hibernate Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 10/12] drm/amd: Avoid evicting resources at S5 Mario Limonciello (AMD)
2025-09-09 19:16 ` [PATCH v7 11/12] PM: Use hibernate flows for system power off Mario Limonciello (AMD)
2025-09-10 15:18   ` Bjorn Helgaas
2025-09-10 15:36     ` Mario Limonciello
2025-09-09 19:16 ` [PATCH v7 12/12] Documentation: power: Add document on debugging shutdown hangs Mario Limonciello (AMD)
2025-09-10 18:11 ` [PATCH v7 00/12] Improvements to S5 power consumption Rafael J. Wysocki
2025-09-10 18:19   ` Mario Limonciello
2025-09-10 18:23     ` Rafael J. Wysocki

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=20250910171132.GA1541776@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=acelan.kao@canonical.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dnaim@cachyos.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gpiccoli@igalia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kaihengf@nvidia.com \
    --cc=lenb@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m3rthn.k@gmail.com \
    --cc=mario.limonciello@amd.com \
    --cc=martin.petersen@oracle.com \
    --cc=mpearson-lenovo@squebb.ca \
    --cc=pavel@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=superm1@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;
as well as URLs for NNTP newsgroup(s).