public inbox for linux-trace-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Mario Limonciello (AMD)" <superm1@kernel.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Pavel Machek" <pavel@kernel.org>, "Len Brown" <lenb@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Danilo Krummrich" <dakr@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>
Subject: Re: [PATCH v6 05/11] PCI: PM: Disable device wakeups when halting system through S4 flow
Date: Mon, 8 Sep 2025 16:34:36 -0500	[thread overview]
Message-ID: <20250908213436.GA1465429@bhelgaas> (raw)
In-Reply-To: <20250818020101.3619237-6-superm1@kernel.org>

In subject, s|PCI: PM:|PCI/PM:| to follow previous practice.

On Sun, Aug 17, 2025 at 09:00:55PM -0500, Mario Limonciello (AMD) wrote:
> PCI devices can be programmed as a wakeup source from low power states
> by sysfs.  However when using the S4 flow to go into S5 these wakeup
> sources should be disabled to avoid what users would perceive as
> spurious wakeup events.

Is the "can be programmed vis sysfs" part relevant here?

I think S4 and S5 are ACPI sleep states not applicable to all
platforms.  Is it relevant that we got here via ACPI?

I assume non-ACPI systems can also exercise this path.  Is there a way
to describe this scenario in a way that would apply to all systems?

I'm not sure what "using the S4 flow to go in to S5" means.

It would be nice to have a spec reference or some sort of rationale
for the requirement to disable all wakeup sources in SYSTEM_HALT and
SYSTEM_POWER_OFF.

> Tested-by: Eric Naim <dnaim@cachyos.org>
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> 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);

I guess the suggestion is that we can't wake up at all from
SYSTEM_HALT or SYSTEM_POWER_OFF?  Would both be considered S5?

Does this mean we need a physical power button push to start up again?
I guess ACPI r6.5, sec 16.1.5 kind of suggests that: "hardware does
allow a transition to S0 due to power button press or a Remote Start."

>  	if (pci_has_legacy_pm_support(pci_dev))
>  		return pci_legacy_suspend(dev, PMSG_HIBERNATE);
>  
> -- 
> 2.43.0
> 

  reply	other threads:[~2025-09-08 21:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-18  2:00 [PATCH v6 00/11] Improvements to S5 power consumption Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 01/11] PM: Introduce new PMSG_POWEROFF event Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 02/11] scsi: Add PM_EVENT_POWEROFF into suspend callbacks Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 03/11] usb: sl811-hcd: " Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 04/11] USB: Pass PMSG_POWEROFF event to suspend_common() for poweroff with S4 flow Mario Limonciello (AMD)
2025-08-18 10:50   ` Oliver Neukum
2025-08-18 11:24     ` Mario Limonciello
2025-08-18  2:00 ` [PATCH v6 05/11] PCI: PM: Disable device wakeups when halting system through " Mario Limonciello (AMD)
2025-09-08 21:34   ` Bjorn Helgaas [this message]
2025-09-08 21:51     ` Mario Limonciello (kernel.org)
2025-08-18  2:00 ` [PATCH v6 06/11] PCI: PM: Split out code from pci_pm_suspend_noirq() into helper Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 07/11] PCI: PM: Run bridge power up actions as part of restore phase Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 08/11] PCI: PM: Use pci_power_manageable() in pci_pm_poweroff_noirq() Mario Limonciello (AMD)
2025-08-18  2:00 ` [PATCH v6 09/11] PCI: Put PCIe bridges with downstream devices into D3 at hibernate Mario Limonciello (AMD)
2025-09-08 21:50   ` Bjorn Helgaas
2025-09-08 21:52     ` Mario Limonciello (kernel.org)
2025-08-18  2:01 ` [PATCH v6 10/11] drm/amd: Avoid evicting resources at S5 Mario Limonciello (AMD)
2025-08-18  2:01 ` [PATCH v6 11/11] PM: Use hibernate flows for system power off Mario Limonciello (AMD)
2025-09-03  4:41 ` [PATCH v6 00/11] Improvements to S5 power consumption Mario Limonciello
2025-09-03 11:14   ` Rafael J. Wysocki
2025-09-06 12:20     ` Greg Kroah-Hartman

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=20250908213436.GA1465429@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=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=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