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

Rafael J. Wysocki rjw at rjwysocki.net
Wed May 26 10:27:43 PDT 2021


On Wednesday, May 26, 2021 7:02:08 PM CEST Limonciello, Mario wrote:
> [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).

I guess this happens in one of the amd-pmc driver's system-wide suspend
callbacks.  Which one?

> > 
> > 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.
> 

OK






More information about the Linux-nvme mailing list