From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Lukas Wunner <lukas@wunner.de>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH] PCI: Forbid RPM on ACPI systems before 5.0 only
Date: Tue, 18 Jan 2022 09:06:12 +0100 [thread overview]
Message-ID: <faf0416b-196e-de5b-d858-22767edc604c@gmail.com> (raw)
In-Reply-To: <20220117233522.GA815664@bhelgaas>
On 18.01.2022 00:35, Bjorn Helgaas wrote:
> [+cc Kai-Heng, Lukas, Mika, since they were cc'd or commented on [0] below]
>
> On Mon, Jan 17, 2022 at 11:51:54AM +0100, Heiner Kallweit 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.
>
> Let's reword this to use the positive sense, e.g., something like
> "enable runtime power management for non-ACPI and ACPI 5.0 and newer."
>
> This feels like a potentially significant change that could cause
> breakage.
>
> - How would a user recognize that we're doing something different?
> Maybe we need a note in dmesg?
>
> - If a system broke because of this, what would it look like? How
> would a user notice a problem, and how would he or she connect the
> problem to this change?
>
Don't know what the exact symptoms of the original problem are.
I'd more see a certain risk that this change reveals bugs in RPM usage
of PCI device drivers. There's not a fixed list of potential symptoms.
One example: igb driver caused a hang on system shutdown when RPM was
enabled due to a RTNL deadlock in RPM resume path.
> - Is there a kernel parameter that will get the previous behavior of
> disabling runtime PM as a workaround until a quirk can be added?
> If so, we should probably mention it here. If not, should there
> be?
For each device in sysfs: power/control: "auto" -> "on"
>
>> [0] https://lkml.org/lkml/2020/11/17/1548
>
> Please use an https://lore.kernel.org/r/... link instead.
>
> Let's mention bb910a7040e9 ("PCI/PM Runtime: Make runtime PM of PCI
> devices inactive by default") as well to help connect the dots here.
>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> 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
>> pm_runtime_set_active(&dev->dev);
>> pm_runtime_enable(&dev->dev);
>> device_enable_async_suspend(&dev->dev);
>> --
>> 2.34.1
>>
next prev parent reply other threads:[~2022-01-18 8:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 10:51 [PATCH] PCI: Forbid RPM on ACPI systems before 5.0 only Heiner Kallweit
2022-01-17 23:35 ` Bjorn Helgaas
2022-01-18 8:06 ` Heiner Kallweit [this message]
2022-01-18 16:09 ` Bjorn Helgaas
2022-01-18 16:28 ` Rafael J. Wysocki
2022-01-18 16:56 ` Heiner Kallweit
2022-01-18 17:11 ` Rafael J. Wysocki
2022-01-18 17:42 ` Heiner Kallweit
2022-01-19 19:38 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=faf0416b-196e-de5b-d858-22767edc604c@gmail.com \
--to=hkallweit1@gmail.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.