[PATCH] nvme-pci: set some AMD PCIe downstream storage device to D3 for s2idle

Limonciello, Mario Mario.Limonciello at amd.com
Wed May 26 10:02:08 PDT 2021


[Public]


> >
> > For context, here's the summary from my understanding:
> >
> > We (linux-nvme) received a bug report that a platform fails to resume
> > after idle suspend due to mismatched behavior with the nvme driver.
> >
> > When suspending, the nvme driver checks pm_suspend_via_firmware(). If
> > false, the driver assumes platform firmware will not alter our device's
> > power state after the kernel completes its suspend process.
> >
> > But this platform's SMU firmware will remove power from the device.
> 
> How exactly does it do that?

It's running as a result of a platform driver notifying it to run (amd-pmc).

> 
> In particular, how does it get a chance to run?
> 
> > Since the driver believed that wouldn't happen, the driver did not
> > prepare the device for this powerloss event.
> >
> > It seems that the kernel's assumptions around pm_suspend_via_firmware()
> > and pm_suspend_no_platform() may not accurately reflect what the
> > platform's firmware actually does.
> 
> Note that this is not about whether or not AML will remove power from devices.
> 
> It is about passing control entirely to the platform firmware at the end of the
> suspend transition.
> 
> If instead the kernel executes AML that happens to remove power from some
> devices, that is a totally different case which should not be confused with
> the above.
> 
> > I do not know of a better way to detect if the platform will remove power,
> > so I'm looking at quirks to suppress PM_SUSPEND_FLAG_NO_PLATFORM for
> > this platform. I'm hoping there's a better option, though :)
> 
> Honestly, I'm not sure about the clear understanding of what's really going on
> here.
> 
> 

We'll discuss internally and come back with a different proposal.
Thanks all for your feedback.


More information about the Linux-nvme mailing list