[PATCH v2] nvme: Look for StorageD3Enable on companion ACPI device instead

Raul Rangel rrangel at chromium.org
Thu May 27 08:53:20 PDT 2021


On Thu, May 27, 2021 at 8:44 AM Limonciello, Mario
<mario.limonciello at amd.com> wrote:
>
> On 5/27/2021 09:35, Christoph Hellwig wrote:
> > Adding Raul who has been asking for something like this as well.
> >
>
> I thought I already included him on CC.  Sorry if I munged the email or
> something.

I did get V2. Thanks for adding me. I tested this patch out on an AMD
platform that doesn't use the PXSX name and it works as expected.

Acked-by: Raul E Rangel <rrangel at chromium.org>

>
> > I'd also really like to move nvme_acpi_storage_d3 out of the NVMe
> > driver.  The Microsoft document that the original document references
> > makes it very clear that this is not NVMe specific, but also covers
> > at least AHCI.  On top of that the platform simply can't know what kind
> > of PCIe device is in any given slot.  Last but not least this will also
> > allow us to add quirks for devices that fail to properly mark this
> > misfeature in the ACPI tables.
> >
>
> +Bjorn
>
> Back when this feature was first submitted, that was actually the
> initial way that it was done, but Bjorn had preferred to see it move
> into the NVME driver directly:
>
> https://lore.kernel.org/linux-nvme/20200625173053.GA2694537@bjorn-Precision-5520/
>
> Bjorn, are you OK with this coming "back" to PCI based on Christoph's
> comments?

Just to add another data point, we currently use StorageD3Enabled on
PCI SDHCI controllers:
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/coreboot/src/mainboard/google/volteer/variants/baseboard/devicetree.cb;l=504

I would be fine doing that refactor in a follow-up patch.



More information about the Linux-nvme mailing list