On Tue, May 25, 2021 at 03:18:46PM +0000, Limonciello, Mario wrote:

quoted

or by splitting the suspend method in different ones
for different use cases.  Platform-specific code (right now for Intel
and AMD) can then make sure drivers do get the right requests instead of
hardcoding platform information in every driver that wants to be able
to implement intelligent suspend behavior.

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.

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.

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