From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D17FB25C80E; Wed, 10 Sep 2025 17:11:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757524295; cv=none; b=RMQ0lJVhfHKrsIuBDNGeQjLo4ajx9FPSda38/sWmvkSwq/gn0Hsp8dczoCzhQGg4q7maU0dx4Cu9w75hv7Yq5uCpVEfk1aFY0KeG0h4zuC+EihbGd0cNT5wMVpgYdWIn+87N/gEtkyWuTsz5e/miTzgzqIe3TVgnksNNt2UQ5aQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757524295; c=relaxed/simple; bh=u8asuC2gU2/ZjNwLkyAWyvgcOHOrCFgpO1+omlyn3is=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=K9cx3jZ2FgKKDZjCzCrkYPxFbngEfwySv0zPyRH5gKKIg602Thy9u9yRQiRtJRS3Y6b5+4bzybvx3pXaEgwzKerwgXauM1BhfyVgiHaTqXHQ84XFovNTmh0a8oAqKuaiOy2AcJwgZBJ4da81yLCqwiyc1QMY9kIgACjiPFyuIoI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XvZ4XwOu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XvZ4XwOu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AA17C4CEEB; Wed, 10 Sep 2025 17:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757524294; bh=u8asuC2gU2/ZjNwLkyAWyvgcOHOrCFgpO1+omlyn3is=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=XvZ4XwOulMW5msvDbsI/wrpR3R0Mmd5sK5AMvGaUghROwrCIbNeiaj/sUnfo4R9JA zbzfmGxRD7L8sqqOewL/zNsU/FPLrP3NI66PXKHv9fx45IwE1OT/+zhHjV/YCJMfK3 taVgETSVPDgrfbbD2D0bEBDHgH50tW2SfC0pe4uH7jZZZ4u7bmvbLRbT0/8eT38KER mcFbsqC7CgTLlg889isJCpKaHQuKb4Ys9HWno/45u3JHCfbG56OVWlPH+EpLVeZq0o zj+cL2yeR1LjENXsceUodY06I+x/8N0kGf7wH9wMHJrc6CXRt7YpXuXuZ7LH+XlsbN HgtduWtHAzdlg== Date: Wed, 10 Sep 2025 12:11:32 -0500 From: Bjorn Helgaas To: Mario Limonciello Cc: "Mario Limonciello (AMD)" , "Rafael J . Wysocki" , Greg Kroah-Hartman , Danilo Krummrich , Bjorn Helgaas , Pavel Machek , Len Brown , Christian =?utf-8?B?S8O2bmln?= , "James E . J . Bottomley" , "Martin K . Petersen" , Steven Rostedt , "open list:HIBERNATION (aka Software Suspend, aka swsusp)" , "open list:RADEON and AMDGPU DRM DRIVERS" , "open list:DRM DRIVERS" , "open list:PCI SUBSYSTEM" , "open list:SCSI SUBSYSTEM" , "open list:USB SUBSYSTEM" , "open list:TRACING" , AceLan Kao , Kai-Heng Feng , Mark Pearson , Merthan =?utf-8?Q?Karaka=C5=9F?= , Eric Naim , "Guilherme G . Piccoli" Subject: Re: [PATCH v7 05/12] PCI/PM: Disable device wakeups when halting or powering off system Message-ID: <20250910171132.GA1541776@bhelgaas> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 > > > Signed-off-by: Mario Limonciello (AMD) > > > --- > > > 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 > > > >