Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp231887ybi; Thu, 13 Jun 2019 15:00:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqwSGPFJ8qX2BygorXBLST1gXEa16ntT8Y5m7ZhAz+qictCYlgR6/WErjvFVva2DoraFlXb3 X-Received: by 2002:a63:c0e:: with SMTP id b14mr13895964pgl.4.1560463216014; Thu, 13 Jun 2019 15:00:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560463216; cv=none; d=google.com; s=arc-20160816; b=CQW7zJFL1vZJlecJacl2TMG641ha9EgKaFCAbA1a1HfX6AT1xo/wMk2e6CApCXVwJ4 vKjL3qrRfVDsuF6AnAJtdPealBJrvwRX+fgjs3pMrL5K9WlC4PppepP3UW7WWvswQiXM /t1h4kk4luz/i2Vp394nszxBLaNv2fQZyaxFJEG5FpBx3YLK5rrFT3n3fmV56Tjtu3/J vGA8syC+rvf2slZPPoJTgqBdZHWRhqyXUKgCuYThW1RdvyApcrGz+7ogZVwb4/MdTrbE GKHuTKB8bFSLfvvfMGcpIVpakUKvGiGPl1gvwFjddSrgWA7/pSbd8mOLmSlXnCMntYDU msPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=bwdPJHamskJ0ho+f7tngXkmu8W2xs2LTL4fiX22N1v4=; b=LqRl3swWLXFx00y6Uum2y7r9fEsQHDXkhaOzVAc6NhAAFDt82eVHj0kXLdo6lblSn7 XBMSiY57aW0mohv7ZpdxEdheyGpawtvCl4UhUTDJZIdAaVVRAaAXm/BTibilygV0vfcq lSGojjdaHIcAr0PZBvhoLF1Zv9RV+cnFUNFXnp5bemFnT14X5VO4OjtLEXfLTPkv3ckt AR/Bx/ju885ghzsMQCQL4fwcJhh+NfgLubimZf9aYUXGsjWjhx3v1+B1KGg93xEN4VOZ VYkMFxjtQ+VZXa2fDj6Hru5maLxHwEJYp9HEoHl7Ns+DbhE0ul2d95gEJRYVbm5Ic5Wp Behw== 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 v4si525896plp.404.2019.06.13.15.00.00; Thu, 13 Jun 2019 15:00:15 -0700 (PDT) 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 S1728477AbfFMV7s (ORCPT + 99 others); Thu, 13 Jun 2019 17:59:48 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:49658 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728025AbfFMV7s (ORCPT ); Thu, 13 Jun 2019 17:59:48 -0400 Received: from 79.184.253.190.ipv4.supernova.orange.pl (79.184.253.190) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.267) id 0423c3e6485434c2; Thu, 13 Jun 2019 23:59:45 +0200 From: "Rafael J. Wysocki" To: Linux PCI , Bjorn Helgaas Cc: Linux PM , Linux ACPI , LKML , Mika Westerberg , Keith Busch , Kai-Heng Feng Subject: [PATCH v2] PCI: PM: Skip devices in D0 for suspend-to-idle Date: Thu, 13 Jun 2019 23:59:45 +0200 Message-ID: <1668247.RaJIPSxJUN@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue") attempted to avoid a problem with devices whose drivers want them to stay in D0 over suspend-to-idle and resume, but it did not go as far as it should with that. Namely, first of all, the power state of a PCI bridge with a downstream device in D0 must be D0 (based on the PCI PM spec r1.2, sec 6, table 6-1, if the bridge is not in D0, there can be no PCI transactions on its secondary bus), but that is not actively enforced during system-wide PM transitions, so use the skip_bus_pm flag introduced by commit d491f2b75237 for that. Second, the configuration of devices left in D0 (whatever the reason) during suspend-to-idle need not be changed and attempting to put them into D0 again by force is pointless, so explicitly avoid doing that. Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue") Reported-by: Kai-Heng Feng Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Tested-by: Kai-Heng Feng --- drivers/pci/pci-driver.c | 47 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 35 insertions(+), 12 deletions(-) Index: linux-pm/drivers/pci/pci-driver.c =================================================================== --- linux-pm.orig/drivers/pci/pci-driver.c +++ linux-pm/drivers/pci/pci-driver.c @@ -524,7 +524,6 @@ static void pci_pm_default_resume_early( pci_power_up(pci_dev); pci_restore_state(pci_dev); pci_pme_restore(pci_dev); - pci_fixup_device(pci_fixup_resume_early, pci_dev); } /* @@ -842,18 +841,16 @@ static int pci_pm_suspend_noirq(struct d if (pci_dev->skip_bus_pm) { /* - * The function is running for the second time in a row without + * Either the device is a bridge with a child in D0 below it, or + * the function is running for the second time in a row without * going through full resume, which is possible only during - * suspend-to-idle in a spurious wakeup case. Moreover, the - * device was originally left in D0, so its power state should - * not be changed here and the device register values saved - * originally should be restored on resume again. + * suspend-to-idle in a spurious wakeup case. The device should + * be in D0 at this point, but if it is a bridge, it may be + * necessary to save its state. */ - pci_dev->state_saved = true; - } else if (pci_dev->state_saved) { - if (pci_dev->current_state == PCI_D0) - pci_dev->skip_bus_pm = true; - } else { + if (!pci_dev->state_saved) + pci_save_state(pci_dev); + } else if (!pci_dev->state_saved) { pci_save_state(pci_dev); if (pci_power_manageable(pci_dev)) pci_prepare_to_sleep(pci_dev); @@ -862,6 +859,22 @@ static int pci_pm_suspend_noirq(struct d dev_dbg(dev, "PCI PM: Suspend power state: %s\n", pci_power_name(pci_dev->current_state)); + if (pci_dev->current_state == PCI_D0) { + pci_dev->skip_bus_pm = true; + /* + * Per PCI PM r1.2, table 6-1, a bridge must be in D0 if any + * downstream device is in D0, so avoid changing the power state + * of the parent bridge by setting the skip_bus_pm flag for it. + */ + if (pci_dev->bus->self) + pci_dev->bus->self->skip_bus_pm = true; + } + + if (pci_dev->skip_bus_pm && !pm_suspend_via_firmware()) { + dev_dbg(dev, "PCI PM: Skipped\n"); + goto Fixup; + } + pci_pm_set_unknown_state(pci_dev); /* @@ -909,7 +922,16 @@ static int pci_pm_resume_noirq(struct de if (dev_pm_smart_suspend_and_suspended(dev)) pm_runtime_set_active(dev); - pci_pm_default_resume_early(pci_dev); + /* + * In the suspend-to-idle case, devices left in D0 during suspend will + * stay in D0, so it is not necessary to restore or update their + * configuration here and attempting to put them into D0 again may + * confuse some firmware, so avoid doing that. + */ + if (!pci_dev->skip_bus_pm || pm_suspend_via_firmware()) + pci_pm_default_resume_early(pci_dev); + + pci_fixup_device(pci_fixup_resume_early, pci_dev); if (pci_has_legacy_pm_support(pci_dev)) return pci_legacy_resume_early(dev); @@ -1200,6 +1222,7 @@ static int pci_pm_restore_noirq(struct d } pci_pm_default_resume_early(pci_dev); + pci_fixup_device(pci_fixup_resume_early, pci_dev); if (pci_has_legacy_pm_support(pci_dev)) return pci_legacy_resume_early(dev);