On Tue, May 25, 2021 at 06:27:52PM +0000, Limonciello, Mario wrote:

[AMD Official Use Only]

quoted

quoted

This seems like a gross assumption though that evicting the quirks into a
central place that every driver needs to behave the same.  AMD's case is
specific to NVME, particularly because APST will be used otherwise.

I don't think you mean APST. That feature enables controller power state
autonomy, and we do not messed with that on the driver's suspend path.

Relying upon the drive to go into the appropriate low power state via APST is one
aspect of it, and then ASPM for the PCIe link state.

That's not quite accurate. The driver has no use for APST in the s2idle
path. We use explicit host managed power settings here, and this works
the same with controllers that don't even support the optional APST
feature.

quoted

We do use the explicit nvme specific host managed power state feature,
though.

But I also don't see why this is specific to nvme. Are you saying that
if a some other protocol device was in the same slot, it would be okay
to use its protocol specific power settings? That doesn't sound right

Maybe Prike can comment more here, but all of these s2idle designs we're talking
about are mobile designs without external PCIe.  OEMs make the decisions on
what PCIe devices are chosen and how they go into the lowest state. 

While assuming nvme might be a plausible design choice, for any device
type occupying the slot, any driver bound to it needs to make the device
ready for cold before letting the s2idle process proceed. That's why the
quirk shouldn't be nvme driver specific.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme