On Mon, Jan 17, 2022 at 11:52 AM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: > > Currently PCI core forbids RPM and requires opt-in from userspace, > apart from few drivers calling pm_runtime_allow(). Reason is that some > early ACPI PM implementations conflict with RPM, see [0]. > Note that as of today pm_runtime_forbid() is also called for non-ACPI > systems. Maybe it's time to allow RPM per default for non-ACPI systems > and recent enough ACPI versions. Let's allow RPM from ACPI 5.0 which > was published in 2011. > > [0] https://lkml.org/lkml/2020/11/17/1548 > > Signed-off-by: Heiner Kallweit <hkallweit1@xxxxxxxxx> > --- > drivers/pci/pci.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 428afd459..26e3a500c 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -3101,7 +3101,12 @@ void pci_pm_init(struct pci_dev *dev) > u16 status; > u16 pmc; > > - pm_runtime_forbid(&dev->dev); > +#ifdef CONFIG_ACPI > + /* Some early ACPI PM implementations conflict with RPM. */ > + if (acpi_gbl_FADT.header.revision > 0 && > + acpi_gbl_FADT.header.revision < 5) > + pm_runtime_forbid(&dev->dev); > +#endif Well, there are two things here. First, there were systems in which ACPI PM was not ready for changing power states in the S0 system state (ie. run-time) and it was assuming that power states would only be changed during transitions to sleep states (S1 - S4) and to S5. This can be covered by the ACPI revicion check, but I'm not sure if ACPI 5.0 is the right one. Why ACPI 5 and not ACPI 6, for instance? Second, there were PCI devices without ACPI PM where the PCI standard PM didn't work correctly. This is not related to ACPI at all and I'm not sure why the ACPI revision check would be sufficient to cover these cases. > pm_runtime_set_active(&dev->dev); > pm_runtime_enable(&dev->dev); > device_enable_async_suspend(&dev->dev); > -- > 2.34.1 >
