public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <superm1@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
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:24:29 -0500	[thread overview]
Message-ID: <0bb2cb92-0d31-4e42-b6ef-2cc3fdf0df40@kernel.org> (raw)
In-Reply-To: <20250910171132.GA1541776@bhelgaas>

On 9/10/25 12:11 PM, Bjorn Helgaas wrote:
> 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?

The two functions are kernel_halt() and kernel_power_off().

And looking again, Ahhhh!  kernel_power_off() is the only thing that 
actually leads to machine_power_off().  Halt just stops the CPUs.

I think we should only be using the hibernate flows for SYSTEM_POWER_OFF.

This has implications for a lot of the patches.  Thanks a lot for 
pointing this out. I'll walk the series again and change accordingly.

> 
>>>> 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:24 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
2025-09-10 17:24         ` Mario Limonciello [this message]
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=0bb2cb92-0d31-4e42-b6ef-2cc3fdf0df40@kernel.org \
    --to=superm1@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=helgaas@kernel.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 \
    /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