linux-kernel - Re: [PATCH v3] PCI / ACPI: PM: Take _S0W of the target bridge into account in acpi_pci_bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0ijTE4A8Q8kLD4xXAqqzEmfXewjtiG7gimg30etk+BKZQ@mail.gmail.com>
Date:   Thu, 12 Jan 2023 21:31:42 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pci@...r.kernel.org,
        "Limonciello, Mario" <mario.limonciello@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Mehta Sanju <Sanju.Mehta@....com>,
        Lukas Wunner <lukas@...ner.de>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux PM <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v3] PCI / ACPI: PM: Take _S0W of the target bridge into
 account in acpi_pci_bridge_d3(()

On Thu, Jan 12, 2023 at 9:21 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
>
> On Wed, Jan 11, 2023 at 11:38:55AM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > It is generally questionable to allow a PCI bridge to go into D3 if
> > it has _S0W returning D2 or a shallower power state, so modify
> > acpi_pci_bridge_d3(() to always take the return value of _S0W for the
> > target bridge into accout.  That is, make it return 'false' if _S0W
> > returns D2 or a shallower power state for the target bridge regardless
> > of its ancestor PCIe Root Port properties.  Of course, this also causes
> > 'false' to be returned if the PCIe Root Port itself is the target and
> > its _S0W returns D2 or a shallower power state.
> >
> > However, still allow bridges without _S0W that are power-manageable via
> > ACPI to enter D3 to retain the current code behavior in that case.
> >
> > Link: https://lore.kernel.org/linux-pci/20221031223356.32570-1-mario.limonciello@amd.com/
> > Reported-by: Mario Limonciello <mario.limonciello@....com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >
> > v2 -> v3:
> >    * Use rpadev for the ACPI companion of the Root Port in acpi_pci_bridge_d3(()
> >      to avoid confusion.
> >    * Make the function evaluating _S0W return the value produced by it or "unknown
> >      state" on errors and let its caller deal with that value.
> >
> > ---
> >  drivers/acpi/device_pm.c |   19 +++++++++++++++++++
> >  drivers/pci/pci-acpi.c   |   45 +++++++++++++++++++++++++++++++--------------
> >  include/acpi/acpi_bus.h  |    1 +
> >  3 files changed, 51 insertions(+), 14 deletions(-)
> >
> > Index: linux-pm/drivers/pci/pci-acpi.c
> > ===================================================================
> > --- linux-pm.orig/drivers/pci/pci-acpi.c
> > +++ linux-pm/drivers/pci/pci-acpi.c
> > @@ -976,24 +976,41 @@ bool acpi_pci_power_manageable(struct pc
> >  bool acpi_pci_bridge_d3(struct pci_dev *dev)
> >  {
> >       struct pci_dev *rpdev;
> > -     struct acpi_device *adev;
> > -     acpi_status status;
> > -     unsigned long long state;
> > +     struct acpi_device *adev, *rpadev;
> >       const union acpi_object *obj;
> >
> >       if (acpi_pci_disabled || !dev->is_hotplug_bridge)
> >               return false;
> >
> > -     /* Assume D3 support if the bridge is power-manageable by ACPI. */
> > -     if (acpi_pci_power_manageable(dev))
> > -             return true;
> > +     adev = ACPI_COMPANION(&dev->dev);
> > +     if (adev) {
> > +             /*
> > +              * If the bridge has _S0W, whether or not it can go into D3
> > +              * depends on what is returned by that object.  In particular,
> > +              * if the power state returned by _S0W is D2 or shallower,
> > +              * entering D3 should not be allowed.
> > +              */
> > +             if (acpi_dev_power_state_for_wake(adev) <= ACPI_STATE_D3_HOT)
>
> The comment suggests that this should check for "<= ACPI_STATE_D2"
> (not ACPI_STATE_D3_HOT).  Or is there some subtlety here that I'm
> missing?

No, this is a mistake.  I'll send a v4.