On Fri, Jun 4, 2021 at 6:54 PM Mario Limonciello <mario.limonciello@xxxxxxx> wrote: > > AMD systems from Renoir and Lucienne require that the NVME controller > is put into D3 over a Modern Standby / suspend-to-idle > cycle. This is "typically" accomplished using the `StorageD3Enable` > property in the _DSD, but this property was introduced after many > of these systems launched and most OEM systems don't have it in > their BIOS. > > On AMD Renoir without these drives going into D3 over suspend-to-idle > the resume will fail with the NVME controller being reset and a trace > like this in the kernel logs: > ``` > [ 83.556118] nvme nvme0: I/O 161 QID 2 timeout, aborting > [ 83.556178] nvme nvme0: I/O 162 QID 2 timeout, aborting > [ 83.556187] nvme nvme0: I/O 163 QID 2 timeout, aborting > [ 83.556196] nvme nvme0: I/O 164 QID 2 timeout, aborting > [ 95.332114] nvme nvme0: I/O 25 QID 0 timeout, reset controller > [ 95.332843] nvme nvme0: Abort status: 0x371 > [ 95.332852] nvme nvme0: Abort status: 0x371 > [ 95.332856] nvme nvme0: Abort status: 0x371 > [ 95.332859] nvme nvme0: Abort status: 0x371 > [ 95.332909] PM: dpm_run_callback(): pci_pm_resume+0x0/0xe0 returns -16 > [ 95.332936] nvme 0000:03:00.0: PM: failed to resume async: error -16 > ``` > > The Microsoft documentation for StorageD3Enable mentioned that Windows has > a hardcoded allowlist for D3 support, which was used for these platforms. > Introduce quirks to hardcode them for Linux as well. > > As this property is now "standardized", OEM systems using AMD Cezanne and > newer APU's have adopted this property, and quirks like this should not be > necessary. > > CC: Julian Sikorski <belegdol@xxxxxxxxx> > CC: Shyam-sundar S-k <Shyam-sundar.S-k@xxxxxxx> > CC: Alexander Deucher <Alexander.Deucher@xxxxxxx> > CC: Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> > CC: Prike Liang <prike.liang@xxxxxxx> > Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx> > --- > drivers/acpi/device_pm.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > Changes from v4->v5: > * Add this patch back in as it's been made apparent that the > system needs to be hardcoded for these. > Changes: > - Drop Cezanne - it's now covered by StorageD3Enable > - Rebase ontop of acpi_storage_d3 outside of NVME > > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c > index 1edb68d00b8e..8fd2a15bf478 100644 > --- a/drivers/acpi/device_pm.c > +++ b/drivers/acpi/device_pm.c > @@ -20,6 +20,10 @@ > #include <linux/pm_runtime.h> > #include <linux/suspend.h> > > +#ifdef CONFIG_X86 > +#include <asm/cpu_device_id.h> > +#endif This is a generic file, not x86 (or any other arch-specific) #ifdeffery in it, please. There is the x86/ subdir under drivers/acpi/ for x86-specific stuff. > + > #include "internal.h" > > /** > @@ -1341,6 +1345,15 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) > } > EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); > > + > +#ifdef CONFIG_X86 > +static const struct x86_cpu_id storage_d3_cpu_ids[] = { > + X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */ > + X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */ > + {} > +}; > +#endif > + > /** > * acpi_storage_d3 - Check if a storage device should use D3. > * @dev: Device to check > @@ -1356,6 +1369,12 @@ bool acpi_storage_d3(struct device *dev) > struct acpi_device *adev = ACPI_COMPANION(dev); > u8 val; > > +#ifdef CONFIG_X86 > + /* Devices requiring D3, but from before StorageD3Enable was "standardized" */ > + if (x86_match_cpu(storage_d3_cpu_ids)) > + return true; > +#endif > + > if (!adev) > return false; > if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable", > -- > 2.25.1 >
