From: Mario Limonciello <mario.limonciello@amd.com>
To: "Rafael J. Wysocki (Intel)" <rafael@kernel.org>,
Keng-Yu Lin <keng-yu.lin@hpe.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Matthew Ruffell <matthew.ruffell@canonical.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
andy.liang@hpe.com, david.chang@hpe.com, s.collins@hpe.com,
jenifer.golmitz@hpe.com, pravallika.kamma@hpe.com,
zhen-dong.lai@hpe.com, zachary.pabor-ext@hpe.com,
stable@vger.kernel.org
Subject: Re: [PATCH v2] PCI/PM: Restore BARs after powering up during enumeration
Date: Mon, 12 Oct 2026 12:09:11 -0500 [thread overview]
Message-ID: <642c49e1-7d47-44fd-b597-e5ff0877bb56@amd.com> (raw)
In-Reply-To: <CAJZ5v0iGhqaF1m-Vc2xdXQXj_BxPFFWCBTP=Ypg_gWQEqWkNfg@mail.gmail.com>
On 10/12/26 06:34, Rafael J. Wysocki (Intel) wrote:
> On Mon, Oct 12, 2026 at 12:47 PM Keng-Yu Lin <keng-yu.lin@hpe.com> wrote:
>>
>> Commit 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when
>> initializing") added pci_pm_power_up_and_verify_state() to pci_pm_init().
>> The helper ignores pci_power_up()'s return value indicating that BARs
>> need restoring. Its resume callers restore saved configuration
>> afterwards; pci_pm_init() does not.
>>
>> D3hot-to-D0 may reset a device and lose its BARs (PCI PM 1.2, sec 5.4.1).
>> After enumeration powers it up, pci_enable_device() reads D0 and skips
>> the full power-up path. Previously, a device still in D3hot at enable
>> time took that path, including BAR restoration.
>>
>> On AMD Venice SP7, two AMD xHCI controllers [1022:17d2] are in runtime
>> D3hot with No_Soft_Reset clear before kdump. Diagnostic reads on
>> v7.3-rc6-37 show the following for 0000:01:00.4 in the crash kernel:
>>
>> PMCSR BAR0
>> before the platform power call 0003 f4100004
>> after the platform power call 0003 f4100004
>> after native D0 power-up 0000 00000004
>>
>> The upper BAR DWORD stays zero. pci_power_up() returns 1, but the BAR
>> address remains zero while dev->resource[0] still contains 0xf4100000.
>> Without BAR restoration, the last console messages are around:
>>
>> pci 0000:01:00.4: enabling device (0000 -> 0002)
>>
>> Restoring both controllers' BARs gives matching readbacks and allows
>> kdump to save a vmcore and reboot. An AMD Turin xHCI [1022:1557] shows
>> the same BAR loss; restoring its BAR also allows kdump to complete.
>>
>> Use pci_set_full_power_state() in pci_pm_init() to power up the device
>> and restore its BARs when needed. It already checks the native power
>> state before restoring and updates ASPM when link state is present.
>> Leave pci_pm_power_up_and_verify_state() unchanged for the resume
>> callers, which restore saved configuration afterwards.
>>
>> Read the initial power state first, as pci_enable_device_flags() does.
>
> Is this really necessary or even useful before pci_set_full_power_state()?
>
> pci_power_up() updates dev->current_state regardless of its previous
> value AFAICS.
>
To add to this comment; I would expect that if it's an ACPI device that
it is currently in ACPI_STATE_UNKNOWN at the time this function is
called. So it should be a no-op for those devices.
I'd say you can just update current state since you're forcing it to D0.
>> Otherwise, PCI_UNKNOWN can request a BAR restore even for devices
>> already in D0. Keep the final pci_update_current_state() call so the
>> final cached state still accounts for platform power and failed config
>> reads.
>>
>> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
>> Fixes: 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Keng-Yu Lin <keng-yu.lin@hpe.com>
>> ---
>>
>> Changes in v2:
>> - Use pci_set_full_power_state() in pci_pm_init(), following Mario's
>> suggestion to reuse the existing BAR restore code.
>> - Leave the shared resume helper and its interface unchanged.
>> - Keep the initial state readback and the final platform-aware refresh.
>>
>> Unlike v1, BAR restoration uses the full helper's native PMCSR check.
>> It also updates ASPM when link state exists.
>>
>> Tested v2 with kdump on both systems. Normal boots made no BAR writes
>> from this path. The crash kernels wrote only the cleared xHCI BARs:
>> two on Venice SP7 and one on Turin. All readbacks matched. kdump saved
>> 2.53 GB and 1.10 GB vmcores respectively before rebooting.
>>
>> v1: https://lore.kernel.org/r/20261008133708.947908-1-keng-yu.lin@hpe.com/
>> Review: https://lore.kernel.org/r/04f5463b-f123-4079-9286-06a241976d3a@amd.com/
>>
>> drivers/pci/pci.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 8cc6a89130b5..d3a5871e1b36 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3255,7 +3255,9 @@ void pci_pm_init(struct pci_dev *dev)
>> }
>>
>> poweron:
>> - pci_pm_power_up_and_verify_state(dev);
>> + pci_update_current_state(dev, dev->current_state);
>> + pci_set_full_power_state(dev, false);
>> + pci_update_current_state(dev, PCI_D0);
>> pm_runtime_forbid(&dev->dev);
>>
>> /*
>>
>> base-commit: 7b63ef2d55f24519e7e9e5f4d15dbea03f126e40
>> --
>> 2.43.0
prev parent reply other threads:[~2026-10-12 17:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 10:46 Keng-Yu Lin
2026-10-12 11:34 ` Rafael J. Wysocki (Intel)
2026-10-12 17:09 ` Mario Limonciello [this message]
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=642c49e1-7d47-44fd-b597-e5ff0877bb56@amd.com \
--to=mario.limonciello@amd.com \
--cc=andy.liang@hpe.com \
--cc=bhelgaas@google.com \
--cc=david.chang@hpe.com \
--cc=jenifer.golmitz@hpe.com \
--cc=keng-yu.lin@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew.ruffell@canonical.com \
--cc=pravallika.kamma@hpe.com \
--cc=rafael@kernel.org \
--cc=s.collins@hpe.com \
--cc=stable@vger.kernel.org \
--cc=zachary.pabor-ext@hpe.com \
--cc=zhen-dong.lai@hpe.com \
/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
all inboxes | Powered by JetHome®