On Wed, Apr 23, 2025 at 9:12 PM Wysocki, Rafael J
<rafael.j.wysocki@xxxxxxxxx> wrote:
>
>
> On 4/22/2025 3:38 PM, Mario Limonciello wrote:
> > From: Mario Limonciello <mario.limonciello@xxxxxxx>
> >
> > AMD BIOS team has root caused an issue that NVME storage failed to come
> > back from suspend to a lack of a call to _REG when NVME device was probed.
> >
> > commit 112a7f9c8edbf ("PCI/ACPI: Call _REG when transitioning D-states")
> > added support for calling _REG when transitioning D-states, but this only
> > works if the device actually "transitions" D-states.
> >
> > commit 967577b062417 ("PCI/PM: Keep runtime PM enabled for unbound PCI
> > devices") added support for runtime PM on PCI devices, but never actually
> > 'explicitly' sets the device to D0.
> >
> > To make sure that devices are in D0 and that platform methods such as
> > _REG are called, explicitly set all devices into D0 during initialization.
> >
> > Fixes: 967577b062417 ("PCI/PM: Keep runtime PM enabled for unbound PCI devices")
> > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
> > ---
> > Note: an earlier internal version of this attempted to do this in local_pci_probe()
> > but this doesn't affect PCI root ports and we need _REG called on the root ports too.
> >
> > drivers/pci/pci.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 53a070394739a..cd87c8370dede 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3266,6 +3266,7 @@ void pci_pm_init(struct pci_dev *dev)
> > pci_read_config_word(dev, PCI_STATUS, &status);
> > if (status & PCI_STATUS_IMM_READY)
> > dev->imm_ready = 1;
> > + pci_set_power_state(dev, PCI_D0);
>
> I'd rather not do this after enabling runtime PM, but at the same time
> doing it before setting up PM would be rather unsafe.
>
> I'd move the pm_runtime_forbid(), pm_runtime_set_active(), and
> pm_runtime_enable() sequence of calls after the pci_set_power_state()
> call above.
Also, I think that pci_pm_power_up_and_verify_state() would be more
suitable for this initial power up because power_state is already 0 at
this point and this case is analogous to post-resume.
