From: Hans de Goede <hdegoede@redhat.com>
To: Mario Limonciello <mario.limonciello@amd.com>, rafael@kernel.org
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Yilin.Chen@amd.com, Randy.Perez@amd.com, Michael.Chiu@amd.com,
stable@vger.kernel.org
Subject: Re: [PATCH] ACPI: x86: Force StorageD3Enable on more products
Date: Sun, 12 May 2024 21:05:29 +0200 [thread overview]
Message-ID: <c9e4b02d-6e3a-4813-8c87-769944176ff2@redhat.com> (raw)
In-Reply-To: <20240509184502.52480-1-mario.limonciello@amd.com>
Hi,
On 5/9/24 8:45 PM, Mario Limonciello wrote:
> A Rembrandt-based HP thin client is reported to have problems where
> the NVME disk isn't present after resume from s2idle.
>
> This is because the NVME disk wasn't put into D3 at suspend, and
> that happened because the StorageD3Enable _DSD was missing in the BIOS.
>
> As AMD's architecture requires that the NVME is in D3 for s2idle, adjust
> the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT
> advertises low power idle support.
>
> This will ensure that any future products with this BIOS deficiency don't
> need to be added to the allow list of overrides.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Thanks, patch looks good to me:
Acked-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/acpi/x86/utils.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
> index 90c3d2eab9e9..7507a7706898 100644
> --- a/drivers/acpi/x86/utils.c
> +++ b/drivers/acpi/x86/utils.c
> @@ -197,16 +197,16 @@ bool acpi_device_override_status(struct acpi_device *adev, unsigned long long *s
> }
>
> /*
> - * AMD systems from Renoir and Lucienne *require* that the NVME controller
> + * AMD systems from Renoir onwards *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 that is checked via the `acpi_storage_d3` function
> - * but this property was introduced after many of these systems launched
> - * and most OEM systems don't have it in their BIOS.
> + * but some OEM systems still don't have it in their BIOS.
> *
> * The Microsoft documentation for StorageD3Enable mentioned that Windows has
> - * a hardcoded allowlist for D3 support, which was used for these platforms.
> + * a hardcoded allowlist for D3 support as well as a registry key to override
> + * the BIOS, which has been used for these cases.
> *
> * This allows quirking on Linux in a similar fashion.
> *
> @@ -219,19 +219,15 @@ bool acpi_device_override_status(struct acpi_device *adev, unsigned long long *s
> * https://bugzilla.kernel.org/show_bug.cgi?id=216773
> * https://bugzilla.kernel.org/show_bug.cgi?id=217003
> * 2) On at least one HP system StorageD3Enable is missing on the second NVME
> - disk in the system.
> + * disk in the system.
> + * 3) On at least one HP Rembrandt system StorageD3Enable is missing on the only
> + * NVME device.
> */
> -static const struct x86_cpu_id storage_d3_cpu_ids[] = {
> - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 24, NULL), /* Picasso */
> - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */
> - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */
> - X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne */
> - {}
> -};
> -
> bool force_storage_d3(void)
> {
> - return x86_match_cpu(storage_d3_cpu_ids);
> + if (!cpu_feature_enabled(X86_FEATURE_ZEN))
> + return false;
> + return acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0;
> }
>
> /*
prev parent reply other threads:[~2024-05-12 19:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 18:45 [PATCH] ACPI: x86: Force StorageD3Enable on more products Mario Limonciello
2024-05-12 19:05 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9e4b02d-6e3a-4813-8c87-769944176ff2@redhat.com \
--to=hdegoede@redhat.com \
--cc=Michael.Chiu@amd.com \
--cc=Randy.Perez@amd.com \
--cc=Yilin.Chen@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).