From 730643d33e2d9ae52d974201b5017d8c3efe5aa5 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 14 Apr 2022 15:04:13 +0200 Subject: PCI/PM: Resume subordinate bus in bus type callbacks Calling pci_resume_bus() on the secondary bus from pci_power_up() as it is done now is questionable, because it depends on the mandatory bridge power-up delays that are only covered by the PCI bus type PM callbacks. For this reason, move the subordinate bus resume to those callbacks too and use the observation that if a bridge is being powered-up during resume from system-wide suspend, it may be still desirable to runtime-resume its subordinate bus after completing the system-wide transition (in case the resume of the devices on that bus is skipped during it). Link: https://lore.kernel.org/r/3190097.aeNJFYEL58@kreacher Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg --- drivers/pci/pci.c | 15 --------------- 1 file changed, 15 deletions(-) (limited to 'drivers/pci/pci.c') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 9ecce435fb3f..e6c7f48e8b07 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1310,21 +1310,6 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout) int pci_power_up(struct pci_dev *dev) { pci_platform_power_transition(dev, PCI_D0); - - /* - * Mandatory power management transition delays are handled in - * pci_pm_resume_noirq() and pci_pm_runtime_resume() of the - * corresponding bridge. - */ - if (dev->runtime_d3cold) { - /* - * When powering on a bridge from D3cold, the whole hierarchy - * may be powered on into D0uninitialized state, resume them to - * give them a chance to suspend again - */ - pci_resume_bus(dev->subordinate); - } - return pci_raw_set_power_state(dev, PCI_D0); } -- cgit v1.2.3-59-g8ed1b