[PATCH v4 1/2] PCI: add AMD PCIe quirk for nvme shutdown opt

[Liang, Prike]

[AMD Public Use]

> From: Christoph Hellwig <hch at infradead.org>
> Sent: Thursday, April 15, 2021 4:21 PM
> To: Liang, Prike <Prike.Liang at amd.com>
> Cc: linux-nvme at lists.infradead.org; Chaitanya.Kulkarni at wdc.com;
> gregkh at linuxfoundation.org; hch at infradead.org; stable at vger.kernel.org;
> Deucher, Alexander <Alexander.Deucher at amd.com>; S-k, Shyam-sundar
> <Shyam-sundar.S-k at amd.com>
> Subject: Re: [PATCH v4 1/2] PCI: add AMD PCIe quirk for nvme shutdown opt
>
> A cover letter for the series would be really nice.
>
Will add a cover letter patch for overview of issue background.

> On Thu, Apr 15, 2021 at 11:52:04AM +0800, Prike Liang wrote:
> > The NVME device pluged in some AMD PCIE root port will resume timeout
> > from s2idle which caused by NVME power CFG lost in the SMU FW restore.
> > This issue can be workaround by using PCIe power set with simple
> > suspend/resume process path instead of APST. In the onwards ASIC will
> > try do the NVME shutdown save and restore in the BIOS and still need
> > PCIe power setting to resume from RTD3 for s2idle.
> >
> > In this preparation patch add a PCIe quirk for the AMD.
>
> The above looks very hard to understand to me.  It uses some AMD specific
> terms, and also is overly specific to NVMe.  Any other PCIe device not doing a
> runtime-D3 in these slots will have the same problem.
>
Yes, but the other peripheral device seems all can reach its min device power state during s2idle
suspend process. To be honest, I don't dedicate to the NVMe development and only from the NVMe legacy
suspend-resume software sequence can see during this default suspend only do some save-restore
APST link states and the NVMe device still remain in the D0 state and then the device force to safe shutdown in the SMU firmware. Then the NVMe device will keep D0 un-initialize state during s2idle resume and NVMe command request will be performed abnormally and eventually result in accessing timeout.

> So I think you should generalize the flag name and description to describe
> what broken behavior the AMD root port has here, and only cursory refer to
> drivers that are broken by it.
>
Will give more descriptor about the flag usage.

> I'd also much prefer if the flag is used on every pci_dev that is affected by the
> broken behavior rather than requiring another lookup in the driver.
Sorry can't get the meaning, could you give more detail how to implement this?

Thanks,
Prike