summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-08-16 12:56:46 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-08-24 13:07:16 +0200
commit77f57b8a45c8d8e505385be19e8f735639bb3cd1 (patch)
tree310946a619d6d6f3ab6dcf7cae8012825591f125
parent8f908e1867653b43b2b81534823c276aef6d8995 (diff)
downloadlinux-stable-77f57b8a45c8d8e505385be19e8f735639bb3cd1.tar.gz
linux-stable-77f57b8a45c8d8e505385be19e8f735639bb3cd1.tar.bz2
linux-stable-77f57b8a45c8d8e505385be19e8f735639bb3cd1.zip
PCI / ACPI / PM: Resume all bridges on suspend-to-RAM
commit 9d64b539b738fc181442caab95f1f76d9bd58539 upstream. Commit 26112ddc254c (PCI / ACPI / PM: Resume bridges w/o drivers on suspend-to-RAM) attempted to fix a functional regression resulting from commit c62ec4610c40 (PM / core: Fix direct_complete handling for devices with no callbacks) by resuming PCI bridges without drivers (that is, "parallel PCI" ones) during system-wide suspend if the target system state is not ACPI S0 (working state). That turns out insufficient, however, as it is reported that, at least in one case, the platform firmware gets confused if a PCIe root port is suspended before entering the ACPI S3 sleep state. That issue was exposed by commit 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed PCIe ports to stay in runtime suspend during system-wide suspend (which is OK for suspend-to-idle, but turns out to be problematic otherwise). For this reason, drop the driver check from acpi_pci_need_resume() and resume all bridges (including PCIe ports with drivers) during system-wide suspend if the target system state is not ACPI S0. [If the target system state is ACPI S0, it means suspend-to-idle and the platform firmware is not going to be invoked to actually suspend the system, so there is no need to resume the bridges in that case.] Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675 Reported-by: teika kazura <teika@gmx.com> Tested-by: teika kazura <teika@gmx.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc254c (PCI / ACPI / PM: Resume bridges ...) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r--drivers/pci/pci-acpi.c6
1 files changed, 2 insertions, 4 deletions
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 054974055ea4..41d24b273d6f 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -601,13 +601,11 @@ static bool acpi_pci_need_resume(struct pci_dev *dev)
/*
* In some cases (eg. Samsung 305V4A) leaving a bridge in suspend over
* system-wide suspend/resume confuses the platform firmware, so avoid
- * doing that, unless the bridge has a driver that should take care of
- * the PM handling. According to Section 16.1.6 of ACPI 6.2, endpoint
+ * doing that. According to Section 16.1.6 of ACPI 6.2, endpoint
* devices are expected to be in D3 before invoking the S3 entry path
* from the firmware, so they should not be affected by this issue.
*/
- if (pci_is_bridge(dev) && !dev->driver &&
- acpi_target_system_state() != ACPI_STATE_S0)
+ if (pci_is_bridge(dev) && acpi_target_system_state() != ACPI_STATE_S0)
return true;
if (!adev || !acpi_device_power_manageable(adev))