+++ /dev/null
-From 32cd0e7c2ba83070ef63507abb061bc2d6193bd7 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 9 Jun 2021 13:40:18 -0500
-Subject: ACPI: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hint
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit 6485fc18faa01e8845b1e5bb55118e633f84d1f2 ]
-
-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: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com>
-CC: Alexander Deucher <Alexander.Deucher@amd.com>
-CC: Prike Liang <prike.liang@amd.com>
-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@amd.com>
-Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Tested-by: Julian Sikorski <belegdol@gmail.com>
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/device_pm.c | 3 +++
- drivers/acpi/internal.h | 9 +++++++++
- drivers/acpi/x86/utils.c | 25 +++++++++++++++++++++++++
- 3 files changed, 37 insertions(+)
-
-diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
-index fcb10697ed7bb..c672e1d0c4fdf 100644
---- a/drivers/acpi/device_pm.c
-+++ b/drivers/acpi/device_pm.c
-@@ -1351,6 +1351,9 @@ bool acpi_storage_d3(struct device *dev)
- struct acpi_device *adev = ACPI_COMPANION(dev);
- u8 val;
-
-+ if (force_storage_d3())
-+ return true;
-+
- if (!adev)
- return false;
- if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
-diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
-index 62b6b36f3a37c..c58b910946fdb 100644
---- a/drivers/acpi/internal.h
-+++ b/drivers/acpi/internal.h
-@@ -236,6 +236,15 @@ static inline int suspend_nvs_save(void) { return 0; }
- static inline void suspend_nvs_restore(void) {}
- #endif
-
-+#ifdef CONFIG_X86
-+bool force_storage_d3(void);
-+#else
-+static inline bool force_storage_d3(void)
-+{
-+ return false;
-+}
-+#endif
-+
- /*--------------------------------------------------------------------------
- Device properties
- -------------------------------------------------------------------------- */
-diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
-index 697a6b12d6b96..70a5eba7afc6f 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -135,3 +135,28 @@ bool acpi_device_always_present(struct acpi_device *adev)
-
- return ret;
- }
-+
-+/*
-+ * 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 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.
-+ *
-+ * The Microsoft documentation for StorageD3Enable mentioned that Windows has
-+ * a hardcoded allowlist for D3 support, which was used for these platforms.
-+ *
-+ * This allows quirking on Linux in a similar fashion.
-+ */
-+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 */
-+ {}
-+};
-+
-+bool force_storage_d3(void)
-+{
-+ return x86_match_cpu(storage_d3_cpu_ids);
-+}
---
-2.43.0
-
+++ /dev/null
-From 3511a4f82bbe3ef6b365350afc0dfd821f0c6970 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 9 Jun 2021 13:40:17 -0500
-Subject: ACPI: Check StorageD3Enable _DSD property in ACPI code
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit 2744d7a0733503931b71c00d156119ced002f22c ]
-
-Although first implemented for NVME, this check may be usable by
-other drivers as well. Microsoft's specification explicitly mentions
-that is may be usable by SATA and AHCI devices. Google also indicates
-that they have used this with SDHCI in a downstream kernel tree that
-a user can plug a storage device into.
-
-Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
-Suggested-by: Keith Busch <kbusch@kernel.org>
-CC: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com>
-CC: Alexander Deucher <Alexander.Deucher@amd.com>
-CC: Rafael J. Wysocki <rjw@rjwysocki.net>
-CC: Prike Liang <prike.liang@amd.com>
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/device_pm.c | 29 +++++++++++++++++++++++++++++
- drivers/nvme/host/pci.c | 28 +---------------------------
- include/linux/acpi.h | 5 +++++
- 3 files changed, 35 insertions(+), 27 deletions(-)
-
-diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
-index 72e6fad39a5e1..fcb10697ed7bb 100644
---- a/drivers/acpi/device_pm.c
-+++ b/drivers/acpi/device_pm.c
-@@ -1331,4 +1331,33 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
- return 1;
- }
- EXPORT_SYMBOL_GPL(acpi_dev_pm_attach);
-+
-+/**
-+ * acpi_storage_d3 - Check if D3 should be used in the suspend path
-+ * @dev: Device to check
-+ *
-+ * Return %true if the platform firmware wants @dev to be programmed
-+ * into D3hot or D3cold (if supported) in the suspend path, or %false
-+ * when there is no specific preference. On some platforms, if this
-+ * hint is ignored, @dev may remain unresponsive after suspending the
-+ * platform as a whole.
-+ *
-+ * Although the property has storage in the name it actually is
-+ * applied to the PCIe slot and plugging in a non-storage device the
-+ * same platform restrictions will likely apply.
-+ */
-+bool acpi_storage_d3(struct device *dev)
-+{
-+ struct acpi_device *adev = ACPI_COMPANION(dev);
-+ u8 val;
-+
-+ if (!adev)
-+ return false;
-+ if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
-+ &val))
-+ return false;
-+ return val == 1;
-+}
-+EXPORT_SYMBOL_GPL(acpi_storage_d3);
-+
- #endif /* CONFIG_PM */
-diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
-index 58aad5e03d045..145db8bf3acc5 100644
---- a/drivers/nvme/host/pci.c
-+++ b/drivers/nvme/host/pci.c
-@@ -2829,32 +2829,6 @@ static unsigned long check_vendor_combination_bug(struct pci_dev *pdev)
- return 0;
- }
-
--#ifdef CONFIG_ACPI
--static bool nvme_acpi_storage_d3(struct pci_dev *dev)
--{
-- struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
-- u8 val;
--
-- /*
-- * Look for _DSD property specifying that the storage device on the port
-- * must use D3 to support deep platform power savings during
-- * suspend-to-idle.
-- */
--
-- if (!adev)
-- return false;
-- if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
-- &val))
-- return false;
-- return val == 1;
--}
--#else
--static inline bool nvme_acpi_storage_d3(struct pci_dev *dev)
--{
-- return false;
--}
--#endif /* CONFIG_ACPI */
--
- static void nvme_async_probe(void *data, async_cookie_t cookie)
- {
- struct nvme_dev *dev = data;
-@@ -2902,7 +2876,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-
- quirks |= check_vendor_combination_bug(pdev);
-
-- if (!noacpi && nvme_acpi_storage_d3(pdev)) {
-+ if (!noacpi && acpi_storage_d3(&pdev->dev)) {
- /*
- * Some systems use a bios work around to ask for D3 on
- * platforms that support kernel managed suspend.
-diff --git a/include/linux/acpi.h b/include/linux/acpi.h
-index 65a6b75b55c32..af1ccf307e4ec 100644
---- a/include/linux/acpi.h
-+++ b/include/linux/acpi.h
-@@ -945,6 +945,7 @@ int acpi_dev_resume(struct device *dev);
- int acpi_subsys_runtime_suspend(struct device *dev);
- int acpi_subsys_runtime_resume(struct device *dev);
- int acpi_dev_pm_attach(struct device *dev, bool power_on);
-+bool acpi_storage_d3(struct device *dev);
- #else
- static inline int acpi_dev_runtime_suspend(struct device *dev) { return 0; }
- static inline int acpi_dev_runtime_resume(struct device *dev) { return 0; }
-@@ -954,6 +955,10 @@ static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
- {
- return 0;
- }
-+static inline bool acpi_storage_d3(struct device *dev)
-+{
-+ return false;
-+}
- #endif
-
- #if defined(CONFIG_ACPI) && defined(CONFIG_PM_SLEEP)
---
-2.43.0
-
+++ /dev/null
-From 4515a5ad58f9950ae264ddd30a86849a484b1d8d Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Thu, 15 Sep 2022 13:23:14 -0500
-Subject: ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for
- StorageD3Enable
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit 018d6711c26e4bd26e20a819fcc7f8ab902608f3 ]
-
-Dell Inspiron 14 2-in-1 has two ACPI nodes under GPP1 both with _ADR of
-0, both without _HID. It's ambiguous which the kernel should take, but
-it seems to take "DEV0". Unfortunately "DEV0" is missing the device
-property `StorageD3Enable` which is present on "NVME".
-
-To avoid this causing problems for suspend, add a quirk for this system
-to behave like `StorageD3Enable` property was found.
-
-Link: https://bugzilla.kernel.org/show_bug.cgi?id=216440
-Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/x86/utils.c | 19 ++++++++++++++++++-
- 1 file changed, 18 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
-index 70a5eba7afc6f..0bf27e66ed0e3 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -156,7 +156,24 @@ static const struct x86_cpu_id storage_d3_cpu_ids[] = {
- {}
- };
-
-+static const struct dmi_system_id force_storage_d3_dmi[] = {
-+ {
-+ /*
-+ * _ADR is ambiguous between GPP1.DEV0 and GPP1.NVME
-+ * but .NVME is needed to get StorageD3Enable node
-+ * https://bugzilla.kernel.org/show_bug.cgi?id=216440
-+ */
-+ .matches = {
-+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 2-in-1"),
-+ }
-+ },
-+ {}
-+};
-+
- bool force_storage_d3(void)
- {
-- return x86_match_cpu(storage_d3_cpu_ids);
-+ const struct dmi_system_id *dmi_id = dmi_first_match(force_storage_d3_dmi);
-+
-+ return dmi_id || x86_match_cpu(storage_d3_cpu_ids);
- }
---
-2.43.0
-
+++ /dev/null
-From 859f8af79ee0213426f15c3ef5fc4c66fafd67f4 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Fri, 14 Oct 2022 07:11:36 -0500
-Subject: ACPI: x86: Add another system to quirk list for forcing
- StorageD3Enable
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit 2124becad797245d49252d2d733aee0322233d7e ]
-
-commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1
-for StorageD3Enable") introduced a quirk to allow a system with ambiguous
-use of _ADR 0 to force StorageD3Enable.
-
-Julius Brockmann reports that Inspiron 16 5625 suffers that same symptoms.
-Add this other system to the list as well.
-
-Link: https://bugzilla.kernel.org/show_bug.cgi?id=216440
-Reported-and-tested-by: Julius Brockmann <mail@juliusbrockmann.com>
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/x86/utils.c | 6 ++++++
- 1 file changed, 6 insertions(+)
-
-diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
-index 0bf27e66ed0e3..f83fff9024611 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -168,6 +168,12 @@ static const struct dmi_system_id force_storage_d3_dmi[] = {
- DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 2-in-1"),
- }
- },
-+ {
-+ .matches = {
-+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 16 5625"),
-+ }
-+ },
- {}
- };
-
---
-2.43.0
-
+++ /dev/null
-From 5ab21e8046f0dbbca2fc0a99cca32237f7bf02dc Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Thu, 9 May 2024 13:45:02 -0500
-Subject: ACPI: x86: Force StorageD3Enable on more products
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit e79a10652bbd320649da705ca1ea0c04351af403 ]
-
-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: All applicable <stable@vger.kernel.org>
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Acked-by: Hans de Goede <hdegoede@redhat.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- 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 353b3bb017f55..759baec32257e 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -137,16 +137,16 @@ bool acpi_device_always_present(struct acpi_device *adev)
- }
-
- /*
-- * 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.
- *
-@@ -159,17 +159,13 @@ bool acpi_device_always_present(struct acpi_device *adev)
- * 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;
- }
---
-2.43.0
-
+++ /dev/null
-From bcc7b6a947bd28fa57419a4942516a632e775e91 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Tue, 28 Feb 2023 16:11:28 -0600
-Subject: ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3Enable
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit e2a56364485e7789e7b8f342637c7f3a219f7ede ]
-
-commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1
-for StorageD3Enable") introduced a quirk to allow a system with ambiguous
-use of _ADR 0 to force StorageD3Enable.
-
-It was reported that several more Dell systems suffered the same symptoms.
-As the list is continuing to grow but these are all Cezanne systems,
-instead add Cezanne to the CPU list to apply the StorageD3Enable property
-and remove the whole list.
-
-It was also reported that an HP system only has StorageD3Enable on the ACPI
-device for the first NVME disk, not the second.
-
-Link: https://bugzilla.kernel.org/show_bug.cgi?id=217003
-Link: https://bugzilla.kernel.org/show_bug.cgi?id=216773
-Reported-by: David Alvarez Lombardi <dqalombardi@proton.me>
-Reported-by: dbilios@stdio.gr
-Reported-and-tested-by: Elvis Angelaccio <elvis.angelaccio@kde.org>
-Tested-by: victor.bonnelle@proton.me
-Tested-by: hurricanepootis@protonmail.com
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/x86/utils.c | 37 +++++++++++++------------------------
- 1 file changed, 13 insertions(+), 24 deletions(-)
-
-diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
-index f83fff9024611..b8510bbc4bd6c 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -149,37 +149,26 @@ bool acpi_device_always_present(struct acpi_device *adev)
- * a hardcoded allowlist for D3 support, which was used for these platforms.
- *
- * This allows quirking on Linux in a similar fashion.
-+ *
-+ * Cezanne systems shouldn't *normally* need this as the BIOS includes
-+ * StorageD3Enable. But for two reasons we have added it.
-+ * 1) The BIOS on a number of Dell systems have ambiguity
-+ * between the same value used for _ADR on ACPI nodes GPP1.DEV0 and GPP1.NVME.
-+ * GPP1.NVME is needed to get StorageD3Enable node set properly.
-+ * https://bugzilla.kernel.org/show_bug.cgi?id=216440
-+ * 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.
- */
- 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 */
-- {}
--};
--
--static const struct dmi_system_id force_storage_d3_dmi[] = {
-- {
-- /*
-- * _ADR is ambiguous between GPP1.DEV0 and GPP1.NVME
-- * but .NVME is needed to get StorageD3Enable node
-- * https://bugzilla.kernel.org/show_bug.cgi?id=216440
-- */
-- .matches = {
-- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-- DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 2-in-1"),
-- }
-- },
-- {
-- .matches = {
-- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-- DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 16 5625"),
-- }
-- },
-+ X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne */
- {}
- };
-
- bool force_storage_d3(void)
- {
-- const struct dmi_system_id *dmi_id = dmi_first_match(force_storage_d3_dmi);
--
-- return dmi_id || x86_match_cpu(storage_d3_cpu_ids);
-+ return x86_match_cpu(storage_d3_cpu_ids);
- }
---
-2.43.0
-
+++ /dev/null
-From 82d4a0126a64cd71b7a4cd9a1a0c29051f4d28ef Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Fri, 31 Mar 2023 11:08:42 -0500
-Subject: ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit 10b6b4a8ac6120ec36555fd286eed577f7632e3b ]
-
-Picasso was the first APU that introduced s2idle support from AMD,
-and it was predating before vendors started to use `StorageD3Enable`
-in their firmware.
-
-Windows doesn't have problems with this hardware and NVME so it was
-likely on the list of hardcoded CPUs to use this behavior in Windows.
-
-Add it to the list for Linux to avoid NVME resume issues.
-
-Reported-by: Stuart Axon <stuaxo2@yahoo.com>
-Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/x86/utils.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
-index b8510bbc4bd6c..353b3bb017f55 100644
---- a/drivers/acpi/x86/utils.c
-+++ b/drivers/acpi/x86/utils.c
-@@ -162,6 +162,7 @@ bool acpi_device_always_present(struct acpi_device *adev)
- disk in the system.
- */
- 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 */
---
-2.43.0
-
+++ /dev/null
-From 646be86913cf168e11272d59a323fc44737788ce Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 20 May 2020 15:02:01 +0300
-Subject: iio: dac: ad5592r-base: Replace indio_dev->mlock with own device lock
-
-From: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
-
-[ Upstream commit 33c53cbf8f7bc8d62f6146a19da97c8594376ff0 ]
-
-As part of the general cleanup of indio_dev->mlock, this change replaces
-it with a local lock on the device's state structure.
-This also removes unused iio_dev pointers.
-
-Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
-Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-Stable-dep-of: 279428df8883 ("iio: dac: ad5592r: fix temperature channel scaling value")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/iio/dac/ad5592r-base.c | 30 +++++++++++++++---------------
- drivers/iio/dac/ad5592r-base.h | 1 +
- 2 files changed, 16 insertions(+), 15 deletions(-)
-
-diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
-index 87a51a85a642d..d9c1242db99f1 100644
---- a/drivers/iio/dac/ad5592r-base.c
-+++ b/drivers/iio/dac/ad5592r-base.c
-@@ -157,7 +157,6 @@ static void ad5592r_gpio_cleanup(struct ad5592r_state *st)
- static int ad5592r_reset(struct ad5592r_state *st)
- {
- struct gpio_desc *gpio;
-- struct iio_dev *iio_dev = iio_priv_to_dev(st);
-
- gpio = devm_gpiod_get_optional(st->dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(gpio))
-@@ -167,10 +166,10 @@ static int ad5592r_reset(struct ad5592r_state *st)
- udelay(1);
- gpiod_set_value(gpio, 1);
- } else {
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
- /* Writing this magic value resets the device */
- st->ops->reg_write(st, AD5592R_REG_RESET, 0xdac);
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
- }
-
- udelay(250);
-@@ -198,7 +197,6 @@ static int ad5592r_set_channel_modes(struct ad5592r_state *st)
- const struct ad5592r_rw_ops *ops = st->ops;
- int ret;
- unsigned i;
-- struct iio_dev *iio_dev = iio_priv_to_dev(st);
- u8 pulldown = 0, tristate = 0, dac = 0, adc = 0;
- u16 read_back;
-
-@@ -248,7 +246,7 @@ static int ad5592r_set_channel_modes(struct ad5592r_state *st)
- }
- }
-
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
-
- /* Pull down unused pins to GND */
- ret = ops->reg_write(st, AD5592R_REG_PULLDOWN, pulldown);
-@@ -286,7 +284,7 @@ static int ad5592r_set_channel_modes(struct ad5592r_state *st)
- ret = -EIO;
-
- err_unlock:
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
- return ret;
- }
-
-@@ -315,11 +313,11 @@ static int ad5592r_write_raw(struct iio_dev *iio_dev,
- if (!chan->output)
- return -EINVAL;
-
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
- ret = st->ops->write_dac(st, chan->channel, val);
- if (!ret)
- st->cached_dac[chan->channel] = val;
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
- return ret;
- case IIO_CHAN_INFO_SCALE:
- if (chan->type == IIO_VOLTAGE) {
-@@ -334,12 +332,12 @@ static int ad5592r_write_raw(struct iio_dev *iio_dev,
- else
- return -EINVAL;
-
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
-
- ret = st->ops->reg_read(st, AD5592R_REG_CTRL,
- &st->cached_gp_ctrl);
- if (ret < 0) {
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
- return ret;
- }
-
-@@ -361,7 +359,7 @@ static int ad5592r_write_raw(struct iio_dev *iio_dev,
-
- ret = st->ops->reg_write(st, AD5592R_REG_CTRL,
- st->cached_gp_ctrl);
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
-
- return ret;
- }
-@@ -383,7 +381,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
-
- switch (m) {
- case IIO_CHAN_INFO_RAW:
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
-
- if (!chan->output) {
- ret = st->ops->read_adc(st, chan->channel, &read_val);
-@@ -420,7 +418,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- } else {
- int mult;
-
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
-
- if (chan->output)
- mult = !!(st->cached_gp_ctrl &
-@@ -438,7 +436,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- case IIO_CHAN_INFO_OFFSET:
- ret = ad5592r_get_vref(st);
-
-- mutex_lock(&iio_dev->mlock);
-+ mutex_lock(&st->lock);
-
- if (st->cached_gp_ctrl & AD5592R_REG_CTRL_ADC_RANGE)
- *val = (-34365 * 25) / ret;
-@@ -451,7 +449,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- }
-
- unlock:
-- mutex_unlock(&iio_dev->mlock);
-+ mutex_unlock(&st->lock);
- return ret;
- }
-
-@@ -626,6 +624,8 @@ int ad5592r_probe(struct device *dev, const char *name,
- iio_dev->info = &ad5592r_info;
- iio_dev->modes = INDIO_DIRECT_MODE;
-
-+ mutex_init(&st->lock);
-+
- ad5592r_init_scales(st, ad5592r_get_vref(st));
-
- ret = ad5592r_reset(st);
-diff --git a/drivers/iio/dac/ad5592r-base.h b/drivers/iio/dac/ad5592r-base.h
-index 4774e4cd9c114..23dac2f1ff8a1 100644
---- a/drivers/iio/dac/ad5592r-base.h
-+++ b/drivers/iio/dac/ad5592r-base.h
-@@ -52,6 +52,7 @@ struct ad5592r_state {
- struct regulator *reg;
- struct gpio_chip gpiochip;
- struct mutex gpio_lock; /* Protect cached gpio_out, gpio_val, etc. */
-+ struct mutex lock;
- unsigned int num_channels;
- const struct ad5592r_rw_ops *ops;
- int scale_avail[2][2];
---
-2.43.0
-
+++ /dev/null
-From 3594da85e46301f66c2496daa2462b6e80480277 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 1 May 2024 11:05:54 -0400
-Subject: iio: dac: ad5592r: fix temperature channel scaling value
-
-From: Marc Ferland <marc.ferland@sonatest.com>
-
-[ Upstream commit 279428df888319bf68f2686934897301a250bb84 ]
-
-The scale value for the temperature channel is (assuming Vref=2.5 and
-the datasheet):
-
- 376.7897513
-
-When calculating both val and val2 for the temperature scale we
-use (3767897513/25) and multiply it by Vref (here I assume 2500mV) to
-obtain:
-
- 2500 * (3767897513/25) ==> 376789751300
-
-Finally we divide with remainder by 10^9 to get:
-
- val = 376
- val2 = 789751300
-
-However, we return IIO_VAL_INT_PLUS_MICRO (should have been NANO) as
-the scale type. So when converting the raw temperature value to the
-'processed' temperature value we will get (assuming raw=810,
-offset=-753):
-
- processed = (raw + offset) * scale_val
- = (810 + -753) * 376
- = 21432
-
- processed += div((raw + offset) * scale_val2, 10^6)
- += div((810 + -753) * 789751300, 10^6)
- += 45015
- ==> 66447
- ==> 66.4 Celcius
-
-instead of the expected 21.5 Celsius.
-
-Fix this issue by changing IIO_VAL_INT_PLUS_MICRO to
-IIO_VAL_INT_PLUS_NANO.
-
-Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
-Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
-Link: https://lore.kernel.org/r/20240501150554.1871390-1-marc.ferland@sonatest.com
-Cc: <Stable@vger.kernel.org>
-Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/iio/dac/ad5592r-base.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
-index 5c242479bb811..75025be02dd29 100644
---- a/drivers/iio/dac/ad5592r-base.c
-+++ b/drivers/iio/dac/ad5592r-base.c
-@@ -414,7 +414,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- s64 tmp = *val * (3767897513LL / 25LL);
- *val = div_s64_rem(tmp, 1000000000LL, val2);
-
-- return IIO_VAL_INT_PLUS_MICRO;
-+ return IIO_VAL_INT_PLUS_NANO;
- }
-
- mutex_lock(&st->lock);
---
-2.43.0
-
+++ /dev/null
-From b04e1709abfa39367c0df54a653e8733e1041229 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Mon, 6 Jul 2020 14:02:58 +0300
-Subject: iio: dac: ad5592r: un-indent code-block for scale read
-
-From: Alexandru Ardelean <alexandru.ardelean@analog.com>
-
-[ Upstream commit b004fe33034cc64f72c20923be71cf1e6c9a624c ]
-
-The next rework may require an unindentation of a code block in
-ad5592r_read_raw(), which would make review a bit more difficult.
-
-This change unindents the code block for reading the scale of the
-non-temperature channels.
-
-Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
-Link: https://lore.kernel.org/r/20200706110259.23947-2-alexandru.ardelean@analog.com
-Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-Stable-dep-of: 279428df8883 ("iio: dac: ad5592r: fix temperature channel scaling value")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/iio/dac/ad5592r-base.c | 26 ++++++++++++--------------
- 1 file changed, 12 insertions(+), 14 deletions(-)
-
-diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
-index d9c1242db99f1..5c242479bb811 100644
---- a/drivers/iio/dac/ad5592r-base.c
-+++ b/drivers/iio/dac/ad5592r-base.c
-@@ -377,7 +377,7 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- {
- struct ad5592r_state *st = iio_priv(iio_dev);
- u16 read_val;
-- int ret;
-+ int ret, mult;
-
- switch (m) {
- case IIO_CHAN_INFO_RAW:
-@@ -415,23 +415,21 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
- *val = div_s64_rem(tmp, 1000000000LL, val2);
-
- return IIO_VAL_INT_PLUS_MICRO;
-- } else {
-- int mult;
-+ }
-
-- mutex_lock(&st->lock);
-+ mutex_lock(&st->lock);
-
-- if (chan->output)
-- mult = !!(st->cached_gp_ctrl &
-- AD5592R_REG_CTRL_DAC_RANGE);
-- else
-- mult = !!(st->cached_gp_ctrl &
-- AD5592R_REG_CTRL_ADC_RANGE);
-+ if (chan->output)
-+ mult = !!(st->cached_gp_ctrl &
-+ AD5592R_REG_CTRL_DAC_RANGE);
-+ else
-+ mult = !!(st->cached_gp_ctrl &
-+ AD5592R_REG_CTRL_ADC_RANGE);
-
-- *val *= ++mult;
-+ *val *= ++mult;
-
-- *val2 = chan->scan_type.realbits;
-- ret = IIO_VAL_FRACTIONAL_LOG2;
-- }
-+ *val2 = chan->scan_type.realbits;
-+ ret = IIO_VAL_FRACTIONAL_LOG2;
- break;
- case IIO_CHAN_INFO_OFFSET:
- ret = ad5592r_get_vref(st);
---
-2.43.0
-
+++ /dev/null
-From dd8d9169375a725cadd5e3635342a6e2d483cf4c Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 3 Jun 2020 15:56:53 -0700
-Subject: mm: memblock: replace dereferences of memblock_region.nid with API
- calls
-
-From: Mike Rapoport <rppt@linux.ibm.com>
-
-[ Upstream commit d622abf74f3d81365e41c3bfdbbda50ecd99ba3d ]
-
-Patch series "mm: rework free_area_init*() funcitons".
-
-After the discussion [1] about removal of CONFIG_NODES_SPAN_OTHER_NODES
-and CONFIG_HAVE_MEMBLOCK_NODE_MAP options, I took it a bit further and
-updated the node/zone initialization.
-
-Since all architectures have memblock, it is possible to use only the
-newer version of free_area_init_node() that calculates the zone and node
-boundaries based on memblock node mapping and architectural limits on
-possible zone PFNs.
-
-The architectures that still determined zone and hole sizes can be
-switched to the generic code and the old code that took those zone and
-hole sizes can be simply removed.
-
-And, since it all started from the removal of
-CONFIG_NODES_SPAN_OTHER_NODES, the memmap_init() is now updated to iterate
-over memblocks and so it does not need to perform early_pfn_to_nid() query
-for every PFN.
-
-[1] https://lore.kernel.org/lkml/1585420282-25630-1-git-send-email-Hoan@os.amperecomputing.com
-
-This patch (of 21):
-
-There are several places in the code that directly dereference
-memblock_region.nid despite this field being defined only when
-CONFIG_HAVE_MEMBLOCK_NODE_MAP=y.
-
-Replace these with calls to memblock_get_region_nid() to improve code
-robustness and to avoid possible breakage when
-CONFIG_HAVE_MEMBLOCK_NODE_MAP will be removed.
-
-Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Tested-by: Hoan Tran <hoan@os.amperecomputing.com> [arm64]
-Reviewed-by: Baoquan He <bhe@redhat.com>
-Cc: Brian Cain <bcain@codeaurora.org>
-Cc: Catalin Marinas <catalin.marinas@arm.com>
-Cc: "David S. Miller" <davem@davemloft.net>
-Cc: Geert Uytterhoeven <geert@linux-m68k.org>
-Cc: Greentime Hu <green.hu@gmail.com>
-Cc: Greg Ungerer <gerg@linux-m68k.org>
-Cc: Guan Xuetao <gxt@pku.edu.cn>
-Cc: Guo Ren <guoren@kernel.org>
-Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
-Cc: Helge Deller <deller@gmx.de>
-Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
-Cc: Jonathan Corbet <corbet@lwn.net>
-Cc: Ley Foon Tan <ley.foon.tan@intel.com>
-Cc: Mark Salter <msalter@redhat.com>
-Cc: Matt Turner <mattst88@gmail.com>
-Cc: Max Filippov <jcmvbkbc@gmail.com>
-Cc: Michael Ellerman <mpe@ellerman.id.au>
-Cc: Michal Hocko <mhocko@kernel.org>
-Cc: Michal Simek <monstr@monstr.eu>
-Cc: Mike Rapoport <rppt@kernel.org>
-Cc: Nick Hu <nickhu@andestech.com>
-Cc: Paul Walmsley <paul.walmsley@sifive.com>
-Cc: Richard Weinberger <richard@nod.at>
-Cc: Rich Felker <dalias@libc.org>
-Cc: Russell King <linux@armlinux.org.uk>
-Cc: Stafford Horne <shorne@gmail.com>
-Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-Cc: Tony Luck <tony.luck@intel.com>
-Cc: Vineet Gupta <vgupta@synopsys.com>
-Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
-Link: http://lkml.kernel.org/r/20200412194859.12663-1-rppt@kernel.org
-Link: http://lkml.kernel.org/r/20200412194859.12663-2-rppt@kernel.org
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-Stable-dep-of: 3ac36aa73073 ("x86/mm/numa: Use NUMA_NO_NODE when calling memblock_set_node()")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- arch/arm64/mm/numa.c | 9 ++++++---
- arch/x86/mm/numa.c | 6 ++++--
- mm/memblock.c | 8 +++++---
- mm/page_alloc.c | 4 ++--
- 4 files changed, 17 insertions(+), 10 deletions(-)
-
-diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
-index 53ebb4babf3a7..58c83c2b8748f 100644
---- a/arch/arm64/mm/numa.c
-+++ b/arch/arm64/mm/numa.c
-@@ -354,13 +354,16 @@ static int __init numa_register_nodes(void)
- struct memblock_region *mblk;
-
- /* Check that valid nid is set to memblks */
-- for_each_memblock(memory, mblk)
-- if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
-+ for_each_memblock(memory, mblk) {
-+ int mblk_nid = memblock_get_region_node(mblk);
-+
-+ if (mblk_nid == NUMA_NO_NODE || mblk_nid >= MAX_NUMNODES) {
- pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
-- mblk->nid, mblk->base,
-+ mblk_nid, mblk->base,
- mblk->base + mblk->size - 1);
- return -EINVAL;
- }
-+ }
-
- /* Finally register nodes. */
- for_each_node_mask(nid, numa_nodes_parsed) {
-diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
-index 7316dca7e846a..bd52ce954d59a 100644
---- a/arch/x86/mm/numa.c
-+++ b/arch/x86/mm/numa.c
-@@ -502,8 +502,10 @@ static void __init numa_clear_kernel_node_hotplug(void)
- * reserve specific pages for Sandy Bridge graphics. ]
- */
- for_each_memblock(reserved, mb_region) {
-- if (mb_region->nid != MAX_NUMNODES)
-- node_set(mb_region->nid, reserved_nodemask);
-+ int nid = memblock_get_region_node(mb_region);
-+
-+ if (nid != MAX_NUMNODES)
-+ node_set(nid, reserved_nodemask);
- }
-
- /*
-diff --git a/mm/memblock.c b/mm/memblock.c
-index a75cc65f03307..d2d85d4d16b74 100644
---- a/mm/memblock.c
-+++ b/mm/memblock.c
-@@ -1170,13 +1170,15 @@ void __init_memblock __next_mem_pfn_range(int *idx, int nid,
- {
- struct memblock_type *type = &memblock.memory;
- struct memblock_region *r;
-+ int r_nid;
-
- while (++*idx < type->cnt) {
- r = &type->regions[*idx];
-+ r_nid = memblock_get_region_node(r);
-
- if (PFN_UP(r->base) >= PFN_DOWN(r->base + r->size))
- continue;
-- if (nid == MAX_NUMNODES || nid == r->nid)
-+ if (nid == MAX_NUMNODES || nid == r_nid)
- break;
- }
- if (*idx >= type->cnt) {
-@@ -1189,7 +1191,7 @@ void __init_memblock __next_mem_pfn_range(int *idx, int nid,
- if (out_end_pfn)
- *out_end_pfn = PFN_DOWN(r->base + r->size);
- if (out_nid)
-- *out_nid = r->nid;
-+ *out_nid = r_nid;
- }
-
- /**
-@@ -1730,7 +1732,7 @@ int __init_memblock memblock_search_pfn_nid(unsigned long pfn,
- *start_pfn = PFN_DOWN(type->regions[mid].base);
- *end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size);
-
-- return type->regions[mid].nid;
-+ return memblock_get_region_node(&type->regions[mid]);
- }
- #endif
-
-diff --git a/mm/page_alloc.c b/mm/page_alloc.c
-index 0ad582945f54d..4a649111178cc 100644
---- a/mm/page_alloc.c
-+++ b/mm/page_alloc.c
-@@ -7214,7 +7214,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
- if (!memblock_is_hotpluggable(r))
- continue;
-
-- nid = r->nid;
-+ nid = memblock_get_region_node(r);
-
- usable_startpfn = PFN_DOWN(r->base);
- zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
-@@ -7235,7 +7235,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
- if (memblock_is_mirror(r))
- continue;
-
-- nid = r->nid;
-+ nid = memblock_get_region_node(r);
-
- usable_startpfn = memblock_region_memory_base_pfn(r);
-
---
-2.43.0
-
+++ /dev/null
-From 6d757e8f7b67bc8abe6313bfa8a59cee44697ea7 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Thu, 9 Jul 2020 11:43:33 -0700
-Subject: nvme-pci: add support for ACPI StorageD3Enable property
-
-From: David E. Box <david.e.box@linux.intel.com>
-
-[ Upstream commit df4f9bc4fb9cb338b1c21cf99c6e905d3b78e91d ]
-
-This patch implements a solution for a BIOS hack used on some currently
-shipping Intel systems to change driver power management policy for PCIe
-NVMe drives. Some newer Intel platforms, like some Comet Lake systems,
-require that PCIe devices use D3 when doing suspend-to-idle in order to
-allow the platform to realize maximum power savings. This is particularly
-needed to support ATX power supply shutdown on desktop systems. In order to
-ensure this happens for root ports with storage devices, Microsoft
-apparently created this ACPI _DSD property as a way to influence their
-driver policy. To my knowledge this property has not been discussed with
-the NVME specification body.
-
-Though the solution is not ideal, it addresses a problem that also affects
-Linux since the NVMe driver's default policy of using NVMe APST during
-suspend-to-idle prevents the PCI root port from going to D3 and leads to
-higher power consumption for these platforms. The power consumption
-difference may be negligible on laptop systems, but many watts on desktop
-systems when the ATX power supply is blocked from powering down.
-
-The patch creates a new nvme_acpi_storage_d3 function to check for the
-StorageD3Enable property during probe and enables D3 as a quirk if set. It
-also provides a 'noacpi' module parameter to allow skipping the quirk if
-needed.
-
-Tested with:
- - PM961 NVMe SED Samsung 512GB
- - INTEL SSDPEKKF512G8
-
-Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
-Signed-off-by: David E. Box <david.e.box@linux.intel.com>
-Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/acpi/property.c | 3 ++
- drivers/nvme/host/pci.c | 63 +++++++++++++++++++++++++++++++++++++++++
- 2 files changed, 66 insertions(+)
-
-diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
-index 5906e247b9fa1..11274df95289b 100644
---- a/drivers/acpi/property.c
-+++ b/drivers/acpi/property.c
-@@ -45,6 +45,9 @@ static const guid_t prp_guids[] = {
- /* Thunderbolt GUID for WAKE_SUPPORTED: 6c501103-c189-4296-ba72-9bf5a26ebe5d */
- GUID_INIT(0x6c501103, 0xc189, 0x4296,
- 0xba, 0x72, 0x9b, 0xf5, 0xa2, 0x6e, 0xbe, 0x5d),
-+ /* Storage device needs D3 GUID: 5025030f-842f-4ab4-a561-99a5189762d0 */
-+ GUID_INIT(0x5025030f, 0x842f, 0x4ab4,
-+ 0xa5, 0x61, 0x99, 0xa5, 0x18, 0x97, 0x62, 0xd0),
- };
-
- /* ACPI _DSD data subnodes GUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
-diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
-index 486e44d20b430..db81403a4286c 100644
---- a/drivers/nvme/host/pci.c
-+++ b/drivers/nvme/host/pci.c
-@@ -4,6 +4,7 @@
- * Copyright (c) 2011-2014, Intel Corporation.
- */
-
-+#include <linux/acpi.h>
- #include <linux/aer.h>
- #include <linux/async.h>
- #include <linux/blkdev.h>
-@@ -78,6 +79,10 @@ static unsigned int poll_queues;
- module_param(poll_queues, uint, 0644);
- MODULE_PARM_DESC(poll_queues, "Number of queues to use for polled IO.");
-
-+static bool noacpi;
-+module_param(noacpi, bool, 0444);
-+MODULE_PARM_DESC(noacpi, "disable acpi bios quirks");
-+
- struct nvme_dev;
- struct nvme_queue;
-
-@@ -2824,6 +2829,54 @@ static unsigned long check_vendor_combination_bug(struct pci_dev *pdev)
- return 0;
- }
-
-+#ifdef CONFIG_ACPI
-+static bool nvme_acpi_storage_d3(struct pci_dev *dev)
-+{
-+ struct acpi_device *adev;
-+ struct pci_dev *root;
-+ acpi_handle handle;
-+ acpi_status status;
-+ u8 val;
-+
-+ /*
-+ * Look for _DSD property specifying that the storage device on the port
-+ * must use D3 to support deep platform power savings during
-+ * suspend-to-idle.
-+ */
-+ root = pcie_find_root_port(dev);
-+ if (!root)
-+ return false;
-+
-+ adev = ACPI_COMPANION(&root->dev);
-+ if (!adev)
-+ return false;
-+
-+ /*
-+ * The property is defined in the PXSX device for South complex ports
-+ * and in the PEGP device for North complex ports.
-+ */
-+ status = acpi_get_handle(adev->handle, "PXSX", &handle);
-+ if (ACPI_FAILURE(status)) {
-+ status = acpi_get_handle(adev->handle, "PEGP", &handle);
-+ if (ACPI_FAILURE(status))
-+ return false;
-+ }
-+
-+ if (acpi_bus_get_device(handle, &adev))
-+ return false;
-+
-+ if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
-+ &val))
-+ return false;
-+ return val == 1;
-+}
-+#else
-+static inline bool nvme_acpi_storage_d3(struct pci_dev *dev)
-+{
-+ return false;
-+}
-+#endif /* CONFIG_ACPI */
-+
- static void nvme_async_probe(void *data, async_cookie_t cookie)
- {
- struct nvme_dev *dev = data;
-@@ -2871,6 +2924,16 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-
- quirks |= check_vendor_combination_bug(pdev);
-
-+ if (!noacpi && nvme_acpi_storage_d3(pdev)) {
-+ /*
-+ * Some systems use a bios work around to ask for D3 on
-+ * platforms that support kernel managed suspend.
-+ */
-+ dev_info(&pdev->dev,
-+ "platform quirk: setting simple suspend\n");
-+ quirks |= NVME_QUIRK_SIMPLE_SUSPEND;
-+ }
-+
- /*
- * Double check that our mempool alloc size will cover the biggest
- * command we support.
---
-2.43.0
-
+++ /dev/null
-From d488eb35bf24e2acbcb0c4da033107b1309a958a Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Fri, 28 May 2021 11:02:34 -0500
-Subject: nvme-pci: look for StorageD3Enable on companion ACPI device instead
-
-From: Mario Limonciello <mario.limonciello@amd.com>
-
-[ Upstream commit e21e0243e7b0f1c2a21d21f4d115f7b37175772a ]
-
-The documentation around the StorageD3Enable property hints that it
-should be made on the PCI device. This is where newer AMD systems set
-the property and it's required for S0i3 support.
-
-So rather than look for nodes of the root port only present on Intel
-systems, switch to the companion ACPI device for all systems.
-David Box from Intel indicated this should work on Intel as well.
-
-Link: https://lore.kernel.org/linux-nvme/YK6gmAWqaRmvpJXb@google.com/T/#m900552229fa455867ee29c33b854845fce80ba70
-Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
-Fixes: df4f9bc4fb9c ("nvme-pci: add support for ACPI StorageD3Enable property")
-Suggested-by: Liang Prike <Prike.Liang@amd.com>
-Acked-by: Raul E Rangel <rrangel@chromium.org>
-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-Reviewed-by: David E. Box <david.e.box@linux.intel.com>
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- drivers/nvme/host/pci.c | 24 +-----------------------
- 1 file changed, 1 insertion(+), 23 deletions(-)
-
-diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
-index db81403a4286c..58aad5e03d045 100644
---- a/drivers/nvme/host/pci.c
-+++ b/drivers/nvme/host/pci.c
-@@ -2832,10 +2832,7 @@ static unsigned long check_vendor_combination_bug(struct pci_dev *pdev)
- #ifdef CONFIG_ACPI
- static bool nvme_acpi_storage_d3(struct pci_dev *dev)
- {
-- struct acpi_device *adev;
-- struct pci_dev *root;
-- acpi_handle handle;
-- acpi_status status;
-+ struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
- u8 val;
-
- /*
-@@ -2843,28 +2840,9 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev)
- * must use D3 to support deep platform power savings during
- * suspend-to-idle.
- */
-- root = pcie_find_root_port(dev);
-- if (!root)
-- return false;
-
-- adev = ACPI_COMPANION(&root->dev);
- if (!adev)
- return false;
--
-- /*
-- * The property is defined in the PXSX device for South complex ports
-- * and in the PEGP device for North complex ports.
-- */
-- status = acpi_get_handle(adev->handle, "PXSX", &handle);
-- if (ACPI_FAILURE(status)) {
-- status = acpi_get_handle(adev->handle, "PEGP", &handle);
-- if (ACPI_FAILURE(status))
-- return false;
-- }
--
-- if (acpi_bus_get_device(handle, &adev))
-- return false;
--
- if (fwnode_property_read_u8(acpi_fwnode_handle(adev), "StorageD3Enable",
- &val))
- return false;
---
-2.43.0
-
perf-core-fix-missing-wakeup-when-waiting-for-contex.patch
pci-add-pci_error_response-and-related-definitions.patch
x86-amd_nb-check-for-invalid-smn-reads.patch
-iio-dac-ad5592r-base-replace-indio_dev-mlock-with-ow.patch
-iio-dac-ad5592r-un-indent-code-block-for-scale-read.patch
-iio-dac-ad5592r-fix-temperature-channel-scaling-valu.patch
-mm-memblock-replace-dereferences-of-memblock_region..patch
-x86-mm-numa-use-numa_no_node-when-calling-memblock_s.patch
-nvme-pci-add-support-for-acpi-storaged3enable-proper.patch
-nvme-pci-look-for-storaged3enable-on-companion-acpi-.patch
-acpi-check-storaged3enable-_dsd-property-in-acpi-cod.patch
-acpi-add-quirks-for-amd-renoir-lucienne-cpus-to-forc.patch
-acpi-x86-add-a-quirk-for-dell-inspiron-14-2-in-1-for.patch
-acpi-x86-add-another-system-to-quirk-list-for-forcin.patch
-acpi-x86-utils-add-cezanne-to-the-list-for-forcing-s.patch
-acpi-x86-utils-add-picasso-to-the-list-for-forcing-s.patch
-acpi-x86-force-storaged3enable-on-more-products.patch
+++ /dev/null
-From c301d88e8887294170e6809c9d9410a3e4a95c16 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Wed, 29 May 2024 09:42:05 +0200
-Subject: x86/mm/numa: Use NUMA_NO_NODE when calling memblock_set_node()
-
-From: Jan Beulich <jbeulich@suse.com>
-
-[ Upstream commit 3ac36aa7307363b7247ccb6f6a804e11496b2b36 ]
-
-memblock_set_node() warns about using MAX_NUMNODES, see
-
- e0eec24e2e19 ("memblock: make memblock_set_node() also warn about use of MAX_NUMNODES")
-
-for details.
-
-Reported-by: Narasimhan V <Narasimhan.V@amd.com>
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Cc: stable@vger.kernel.org
-[bp: commit message]
-Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
-Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
-Tested-by: Paul E. McKenney <paulmck@kernel.org>
-Link: https://lore.kernel.org/r/20240603141005.23261-1-bp@kernel.org
-Link: https://lore.kernel.org/r/abadb736-a239-49e4-ab42-ace7acdd4278@suse.com
-Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- arch/x86/mm/numa.c | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
-index bd52ce954d59a..badfa96aac320 100644
---- a/arch/x86/mm/numa.c
-+++ b/arch/x86/mm/numa.c
-@@ -504,7 +504,7 @@ static void __init numa_clear_kernel_node_hotplug(void)
- for_each_memblock(reserved, mb_region) {
- int nid = memblock_get_region_node(mb_region);
-
-- if (nid != MAX_NUMNODES)
-+ if (nid != NUMA_NO_NODE)
- node_set(nid, reserved_nodemask);
- }
-
-@@ -624,9 +624,9 @@ static int __init numa_init(int (*init_func)(void))
- nodes_clear(node_online_map);
- memset(&numa_meminfo, 0, sizeof(numa_meminfo));
- WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.memory,
-- MAX_NUMNODES));
-+ NUMA_NO_NODE));
- WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.reserved,
-- MAX_NUMNODES));
-+ NUMA_NO_NODE));
- /* In case that parsing SRAT failed. */
- WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
- numa_reset_distance();
---
-2.43.0
-
projects / thirdparty / kernel / stable-queue.git / commitdiff
