[PATCH v5 2/2] acpi: PM: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hint

Limonciello, Mario mario.limonciello at amd.com
Fri Jun 4 10:57:55 PDT 2021


On 6/4/2021 12:43, Raul Rangel wrote:
> On Fri, Jun 4, 2021 at 10:54 AM Mario Limonciello
> <mario.limonciello at amd.com> wrote:
> 
>> +
>> +#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
>> +
> 
> Is this the same matching logic that Windows is using?
> 

I don't have access to confirm their logic for it - but they do have an 
allowlist that was used for systems before StorageD3Enable was 
introduced as well as a registry key to override it in Windows.

In Linux we can do it a number of ways:

* Detect the CPU in RN/LCN platforms
   - Like I did in this patch

* Detect some other PCI device only present in RN/LCN platforms and set 
this hint
   - Like some earlier versions of this patch series from Prike did

* Introduce a tri-state module parameter like d3=auto,off,on
   - Set up logic behind auto to use acpi_storage_d3 primarily and look 
at a quirk list as a fallback if that was false.

* Add a compile time option to include these quirks in either acpi or 
nvme.ko only if a user selected them.

* Enumerate all the field systems SMBIOS we can find with these CPUs
   - Expect this to be a large quirk list.

I don't have a strong opinion between those two first options, but 
suspect the 3rd through 5th aren't really acceptable or scalable.

I'm open to other suggestions but testers of the patches thus far have 
made it clear that /something/ needs to be done to avoid the problems on 
RN with Linux though.



More information about the Linux-nvme mailing list