linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Limonciello, Mario" <mario.limonciello@amd.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Mehta Sanju <Sanju.Mehta@amd.com>, Lukas Wunner <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] PCI/ACPI: PCI/ACPI: Validate devices with power resources support D3
Date: Fri, 11 Nov 2022 15:42:09 -0600	[thread overview]
Message-ID: <20221111214209.GA748269@bhelgaas> (raw)
In-Reply-To: <5754039e-e3c6-cdb8-8d64-6332b0093940@amd.com>

On Fri, Nov 11, 2022 at 12:58:28PM -0600, Limonciello, Mario wrote:
> On 11/11/2022 11:41, Bjorn Helgaas wrote:
> > On Mon, Oct 31, 2022 at 05:33:55PM -0500, Mario Limonciello wrote:
> > > Firmware typically advertises that ACPI devices that represent PCIe
> > > devices can support D3 by a combination of the value returned by
> > > _S0W as well as the HotPlugSupportInD3 _DSD [1].
> > > 
> > > `acpi_pci_bridge_d3` looks for this combination but also contains
> > > an assumption that if an ACPI device contains power resources the PCIe
> > > device it's associated with can support D3.  This was introduced
> > > from commit c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for
> > > D3 if power managed by ACPI").
> > > 
> > > Some firmware configurations for "AMD Pink Sardine" do not support
> > > wake from D3 in _S0W for the ACPI device representing the PCIe root
> > > port used for tunneling. The PCIe device will still be opted into
> > > runtime PM in the kernel [2] because of the logic within
> > > `acpi_pci_bridge_d3`. This currently happens because the ACPI
> > > device contains power resources.

Wait.  Is this as simple as just recognizing that:

  _PS0 means the OS has a knob to put the device in D0, but it doesn't
  mean the device can wake itself from a low-power state.  The OS has
  to use _S0W to learn the device's ability to wake itself.

If that's enough, maybe we don't need to complicate this with all the
Thunderbolt and device link stuff.  Which would be great, because the
code change itself has nothing to do with those things.

Bjorn

  reply	other threads:[~2022-11-11 21:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 22:33 [PATCH v5] PCI/ACPI: PCI/ACPI: Validate devices with power resources support D3 Mario Limonciello
2022-11-11 17:41 ` Bjorn Helgaas
2022-11-11 18:58   ` Limonciello, Mario
2022-11-11 21:42     ` Bjorn Helgaas [this message]
2022-11-14 15:33       ` Rafael J. Wysocki
2022-11-14 15:37         ` Limonciello, Mario
2022-11-14 16:54           ` Bjorn Helgaas
2022-11-16  0:37         ` Bjorn Helgaas
2022-11-16  2:31           ` Limonciello, Mario
2022-11-16 12:00           ` Rafael J. Wysocki
2022-11-16 23:28             ` Bjorn Helgaas
2022-11-17 17:01               ` Rafael J. Wysocki
2022-11-17 22:16                 ` Bjorn Helgaas
2022-11-18 13:16                   ` Rafael J. Wysocki
2022-11-18 20:23                     ` Bjorn Helgaas
2022-11-18 21:13                       ` Rafael J. Wysocki
2022-11-21 14:33                         ` Rafael J. Wysocki
2022-11-21 22:17                           ` Bjorn Helgaas
2023-01-02 16:34                             ` Rafael J. Wysocki
2023-01-02 16:59                               ` Rafael J. Wysocki
2023-01-03 22:44                                 ` Limonciello, Mario
2023-01-10 18:02                                 ` Rafael J. Wysocki
2023-01-10 20:55                                 ` Bjorn Helgaas
2023-01-11 10:56                                   ` Rafael J. Wysocki
2023-01-12 20:13                                     ` Bjorn Helgaas
2023-01-11 10:38                               ` [PATCH v3] PCI / ACPI: PM: Take _S0W of the target bridge into account in acpi_pci_bridge_d3(() Rafael J. Wysocki
2023-01-12 20:21                                 ` Bjorn Helgaas
2023-01-12 20:31                                   ` Rafael J. Wysocki
2023-01-12 20:51                               ` [PATCH v4] " Rafael J. Wysocki
2023-01-12 22:01                                 ` Bjorn Helgaas
2023-01-12 22:09                                   ` Limonciello, Mario
2023-01-12 22:40                                     ` Bjorn Helgaas
2023-01-12 22:45                                       ` Limonciello, Mario
2023-01-13 17:51                                         ` Bjorn Helgaas
2023-01-13 17:53                                           ` Limonciello, Mario

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=20221111214209.GA748269@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Sanju.Mehta@amd.com \
    --cc=bhelgaas@google.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mario.limonciello@amd.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).