On 6/4/2021 12:43, Raul Rangel wrote:
On Fri, Jun 4, 2021 at 10:54 AM Mario Limonciello
<mario.limonciello@xxxxxxx> 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.
