| Message ID | 4412361.LvFx2qVVIh@kreacher (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v1] PCI: PM: Power up all devices during runtime resume | expand |
On Wed, Apr 06, 2022 at 09:00:52PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Currently, endpoint devices may not be powered up entirely during > runtime resume that follows a D3hot -> D0 transition of the parent > bridge. > > Namely, even if the power state of an endpoint device, as indicated > by its PCI_PM_CTRL register, is D0 after powering up its parent > bridge, it may be still necessary to bring its ACPI companion into > D0 and that should be done before accessing it. However, the current > code assumes that reading the PCI_PM_CTRL register is sufficient to > establish the endpoint device's power state, which may lead to > problems. > > Address that by forcing a power-up of all PCI devices, including the > platform firmware part of it, during runtime resume. > > Link: https://lore.kernel.org/linux-pm/11967527.O9o76ZdvQC@kreacher > Fixes: 5775b843a619 ("PCI: Restore config space on runtime resume despite being unbound") > Reported-by: Abhishek Sahu <abhsahu@nvidia.com> > Tested-by: Abhishek Sahu <abhsahu@nvidia.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
On Wed, Apr 06, 2022 at 09:00:52PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Currently, endpoint devices may not be powered up entirely during > runtime resume that follows a D3hot -> D0 transition of the parent > bridge. > > Namely, even if the power state of an endpoint device, as indicated > by its PCI_PM_CTRL register, is D0 after powering up its parent > bridge, it may be still necessary to bring its ACPI companion into > D0 and that should be done before accessing it. However, the current > code assumes that reading the PCI_PM_CTRL register is sufficient to > establish the endpoint device's power state, which may lead to > problems. > > Address that by forcing a power-up of all PCI devices, including the > platform firmware part of it, during runtime resume. > > Link: https://lore.kernel.org/linux-pm/11967527.O9o76ZdvQC@kreacher > Fixes: 5775b843a619 ("PCI: Restore config space on runtime resume despite being unbound") > Reported-by: Abhishek Sahu <abhsahu@nvidia.com> > Tested-by: Abhishek Sahu <abhsahu@nvidia.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Applied with Mika's reviewed-by to pci/pm for v5.19, thanks! > --- > drivers/pci/pci-driver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-pm/drivers/pci/pci-driver.c > =================================================================== > --- linux-pm.orig/drivers/pci/pci-driver.c > +++ linux-pm/drivers/pci/pci-driver.c > @@ -1312,7 +1312,7 @@ static int pci_pm_runtime_resume(struct > * to a driver because although we left it in D0, it may have gone to > * D3cold when the bridge above it runtime suspended. > */ > - pci_restore_standard_config(pci_dev); > + pci_pm_default_resume_early(pci_dev); > > if (!pci_dev->driver) > return 0; > > >
On Thu, Apr 7, 2022 at 5:49 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Wed, Apr 06, 2022 at 09:00:52PM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Currently, endpoint devices may not be powered up entirely during > > runtime resume that follows a D3hot -> D0 transition of the parent > > bridge. > > > > Namely, even if the power state of an endpoint device, as indicated > > by its PCI_PM_CTRL register, is D0 after powering up its parent > > bridge, it may be still necessary to bring its ACPI companion into > > D0 and that should be done before accessing it. However, the current > > code assumes that reading the PCI_PM_CTRL register is sufficient to > > establish the endpoint device's power state, which may lead to > > problems. > > > > Address that by forcing a power-up of all PCI devices, including the > > platform firmware part of it, during runtime resume. > > > > Link: https://lore.kernel.org/linux-pm/11967527.O9o76ZdvQC@kreacher > > Fixes: 5775b843a619 ("PCI: Restore config space on runtime resume despite being unbound") > > Reported-by: Abhishek Sahu <abhsahu@nvidia.com> > > Tested-by: Abhishek Sahu <abhsahu@nvidia.com> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Applied with Mika's reviewed-by to pci/pm for v5.19, thanks! This doesn't compile when CONFIG_PM_SLEEP in uset, sorry about this. I'll send a v2, but if you prefer an incremental fix, please let me know. > > > --- > > drivers/pci/pci-driver.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-pm/drivers/pci/pci-driver.c > > =================================================================== > > --- linux-pm.orig/drivers/pci/pci-driver.c > > +++ linux-pm/drivers/pci/pci-driver.c > > @@ -1312,7 +1312,7 @@ static int pci_pm_runtime_resume(struct > > * to a driver because although we left it in D0, it may have gone to > > * D3cold when the bridge above it runtime suspended. > > */ > > - pci_restore_standard_config(pci_dev); > > + pci_pm_default_resume_early(pci_dev); > > > > if (!pci_dev->driver) > > return 0; > > > > > >
Index: linux-pm/drivers/pci/pci-driver.c =================================================================== --- linux-pm.orig/drivers/pci/pci-driver.c +++ linux-pm/drivers/pci/pci-driver.c @@ -1312,7 +1312,7 @@ static int pci_pm_runtime_resume(struct * to a driver because although we left it in D0, it may have gone to * D3cold when the bridge above it runtime suspended. */ - pci_restore_standard_config(pci_dev); + pci_pm_default_resume_early(pci_dev); if (!pci_dev->driver) return 0;