Received: by 10.223.185.116 with SMTP id b49csp6024527wrg; Thu, 8 Mar 2018 00:05:11 -0800 (PST) X-Google-Smtp-Source: AG47ELv2zpVf4B0XULBZctYUIe6KkecabrOIl1fwMmgDqXkZyeGTwoUFTQnn+g5vzAyEjrjG5iiA X-Received: by 2002:a17:902:5819:: with SMTP id m25-v6mr22913631pli.248.1520496311431; Thu, 08 Mar 2018 00:05:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520496311; cv=none; d=google.com; s=arc-20160816; b=ouh2XQyazZz3VI4sVg8Rhm3EG+E7h4G50LGIiS8+x6gdUd78MVF5SPI3cVSLAHfC67 ycOrMmzesYoxfGxwouZKotg7fgi1jhnLI39+z9aechtxdlN3e4WSy1RVGwXVKt37fHdy 6Q9SbTVmhVpj5DIfG5YSD6CL6wDOGqDTZqmlIioI9045RjWdrrlpHWr0lFouXXBzfV8Y EwIf0eOKhTdLM3Saf6/4tJ0ThLG4L6QVZNe4kAPoS35obEdTvEjCU+wx1B+o8FPFtmtQ KM7lMVquNQb+D/mAEyuYcTKyexJyPGR7+Sv3m60KhnPyxyaRfU/L1DCi+sbkGejOvTZF gVHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=9/yuFanhZwgf0CeQJ5VeylbXZiIvu2qmuzPumxUXXmk=; b=W5dP1we3EDGXmHGrFqA/Zu85XNuOH46gmUzuATpXcfO3RuHv5WyVMrLQTcyLyFFwTb saZdyMnNJlVWCtsashenH4Skrj8Lik950rScGGB7V6iVQSg5c0cLP3egqiYCQ6+RJk5U eygn9UobwHeonXrdKR6lDT35ScTNyYvfa6BR27Ee8gro561iQ7JmHwRKA00IDJ/OiGoo 71AqdhCqr2L8qxT823EuwZEjlek4tN4b3Tff/ZXfOE0yBXWH0R2Z0ykeQdRZ9HRKi2DL HB/9rIXONQc1LcH+4bVf9Z2cb3vw2Wfoo2nmhDUqCx20h5CZQt1SBut60IjIdmjSIMvN P8uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5-v6si14550350plt.235.2018.03.08.00.04.57; Thu, 08 Mar 2018 00:05:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935396AbeCHIDg (ORCPT + 99 others); Thu, 8 Mar 2018 03:03:36 -0500 Received: from bmailout1.hostsharing.net ([83.223.95.100]:51613 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755144AbeCHIDd (ORCPT ); Thu, 8 Mar 2018 03:03:33 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 9AEA630002434; Thu, 8 Mar 2018 09:03:31 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 583681C9F9; Thu, 8 Mar 2018 09:03:31 +0100 (CET) Date: Thu, 8 Mar 2018 09:03:31 +0100 From: Lukas Wunner To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Keith Busch , Sinan Kaya Subject: Re: [PATCH v1 2/9] PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver Message-ID: <20180308080331.GA5671@wunner.de> References: <152040297576.240786.1532465558381209070.stgit@bhelgaas-glaptop.roam.corp.google.com> <152040321483.240786.16597888035806933750.stgit@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152040321483.240786.16597888035806933750.stgit@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 07, 2018 at 12:13:34AM -0600, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system > resume") added a .resume_noirq() callback to the PCIe port driver to clear > the PME Status bit during resume to work around a BIOS issue. > > The BIOS evidently enabled PME interrupts for ACPI-based runtime wakeups > but did not clear the PME Status bit during resume, which meant PMEs after > resume did not trigger interrupts because PME Status did not transition > from cleared to set. > > The fix was in the PCIe port driver, so it worked when CONFIG_PCIEPORTBUS > was set. But I think we *always* want the fix because the platform may use > PME interrupts even if Linux is built without the PCIe port driver. > > Move the fix from the port driver to the PCI core so we can work around > this "PME doesn't work after waking from a sleep state" issue regardless of > CONFIG_PCIEPORTBUS. > > Signed-off-by: Bjorn Helgaas > --- > drivers/pci/pci-driver.c | 14 ++++++++++++++ > drivers/pci/pcie/portdrv_pci.c | 15 --------------- > 2 files changed, 14 insertions(+), 15 deletions(-) > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > index 3bed6beda051..bf0704b75f79 100644 > --- a/drivers/pci/pci-driver.c > +++ b/drivers/pci/pci-driver.c > @@ -525,6 +525,18 @@ static void pci_pm_default_resume_early(struct pci_dev *pci_dev) > pci_fixup_device(pci_fixup_resume_early, pci_dev); > } > > +static void pcie_resume_early(struct pci_dev *pci_dev) > +{ > + /* > + * Some BIOSes forget to clear Root PME Status bits after system wakeup > + * which breaks ACPI-based runtime wakeup on PCI Express, so clear those > + * bits now just in case (shouldn't hurt). > + */ > + if (pci_is_pcie(pci_dev) && > + pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT) > + pcie_clear_root_pme_status(pci_dev); > +} > + > /* > * Default "suspend" method for devices that have no driver provided suspend, > * or not even a driver at all (second part). > @@ -873,6 +885,8 @@ static int pci_pm_resume_noirq(struct device *dev) > if (pci_has_legacy_pm_support(pci_dev)) > return pci_legacy_resume_early(dev); > > + pcie_resume_early(pci_dev); I'm wondering if it would be better to implement this as a PCI quirk: DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY(PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_BRIDGE_PCI, 8, ...) Then it would also be executed for the ->restore_noirq phase, not only ->resume_noirq. And it could be constrained to only the affected PCI or DMI IDs. However it would then also be executed on ->runtime_resume, I'm not sure if that's a problem or not. Thanks, Lukas > + > if (drv && drv->pm && drv->pm->resume_noirq) > error = drv->pm->resume_noirq(dev); > > diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c > index 4413dd85e923..f91afd09e356 100644 > --- a/drivers/pci/pcie/portdrv_pci.c > +++ b/drivers/pci/pcie/portdrv_pci.c > @@ -62,20 +62,6 @@ static int pcie_portdrv_restore_config(struct pci_dev *dev) > } > > #ifdef CONFIG_PM > -static int pcie_port_resume_noirq(struct device *dev) > -{ > - struct pci_dev *pdev = to_pci_dev(dev); > - > - /* > - * Some BIOSes forget to clear Root PME Status bits after system wakeup > - * which breaks ACPI-based runtime wakeup on PCI Express, so clear those > - * bits now just in case (shouldn't hurt). > - */ > - if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT) > - pcie_clear_root_pme_status(pdev); > - return 0; > -} > - > static int pcie_port_runtime_suspend(struct device *dev) > { > return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY; > @@ -103,7 +89,6 @@ static const struct dev_pm_ops pcie_portdrv_pm_ops = { > .thaw = pcie_port_device_resume, > .poweroff = pcie_port_device_suspend, > .restore = pcie_port_device_resume, > - .resume_noirq = pcie_port_resume_noirq, > .runtime_suspend = pcie_port_runtime_suspend, > .runtime_resume = pcie_port_runtime_resume, > .runtime_idle = pcie_port_runtime_idle, >