[PATCH v3 1/2] ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked

[PATCH v3 1/2] ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked

[Mario Limonciello]

Previously the kernel used to ignore whether the firmware masked CPPC
or CPPCv2 and would just pretend that it worked.

When support for the USB4 bit in _OSC was introduced from commit
9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear")
the kernel began to look at the return when the query bit was clear.

This caused regressions that were misdiagnosed and attempted to be solved
as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities
to the _OSC regardless of the query flag""). This caused a different
regression where non-Intel systems weren't able to negotiate _OSC
properly.

This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same
capabilities to the _OSC regardless of the query flag"") and attempted to
be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not
supported by firmware") but the regression still returned.

These systems with the regression only load support for CPPC from an SSDT
dynamically when _OSC reports CPPC v2.  Avoid the problem by not letting
CPPC satisfy the requirement in `acpi_cppc_processor_probe`.

Reported-by: CUI Hao <cuihao.leo@gmail.com>
Reported-by: maxim.novozhilov@gmail.com
Reported-by: lethe.tree@protonmail.com
Reported-by: garystephenwright@gmail.com
Reported-by: galaxyking0419@gmail.com
Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware")
Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/acpi/bus.c       | 11 +++++------
 drivers/acpi/cppc_acpi.c |  4 +++-
 include/linux/acpi.h     |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 86fa61a21826c..e2db1bdd9dd25 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -298,7 +298,7 @@ EXPORT_SYMBOL_GPL(osc_cpc_flexible_adr_space_confirmed);
 bool osc_sb_native_usb4_support_confirmed;
 EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed);
 
-bool osc_sb_cppc_not_supported;
+bool osc_sb_cppc2_support_acked;
 
 static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
 static void acpi_bus_osc_negotiate_platform_control(void)
@@ -358,11 +358,6 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 		return;
 	}
 
-#ifdef CONFIG_ACPI_CPPC_LIB
-	osc_sb_cppc_not_supported = !(capbuf_ret[OSC_SUPPORT_DWORD] &
-			(OSC_SB_CPC_SUPPORT | OSC_SB_CPCV2_SUPPORT));
-#endif
-
 	/*
 	 * Now run _OSC again with query flag clear and with the caps
 	 * supported by both the OS and the platform.
@@ -376,6 +371,10 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 
 	capbuf_ret = context.ret.pointer;
 	if (context.ret.length > OSC_SUPPORT_DWORD) {
+#ifdef CONFIG_ACPI_CPPC_LIB
+		osc_sb_cppc2_support_acked = capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_CPCV2_SUPPORT;
+#endif
+
 		osc_sb_apei_support_acked =
 			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT;
 		osc_pc_lpi_support_confirmed =
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 903528f7e187e..d64facbda0fb7 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -684,8 +684,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
 	acpi_status status;
 	int ret = -ENODATA;
 
-	if (osc_sb_cppc_not_supported)
+	if (!osc_sb_cppc2_support_acked) {
+		pr_debug("CPPC v2 _OSC not acked\n");
 		return -ENODEV;
+	}
 
 	/* Parse the ACPI _CPC table for this CPU. */
 	status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output,
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4f82a5bc6d987..44975c1bbe12f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,7 +584,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
 extern bool osc_sb_apei_support_acked;
 extern bool osc_pc_lpi_support_confirmed;
 extern bool osc_sb_native_usb4_support_confirmed;
-extern bool osc_sb_cppc_not_supported;
+extern bool osc_sb_cppc2_support_acked;
 extern bool osc_cpc_flexible_adr_space_confirmed;
 
 /* USB4 Capabilities */
-- 
2.25.1

[PATCH v3 2/2] ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported

[Mario Limonciello]

commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and
when CPPC_LIB is supported") added support for claiming to
support CPPC in _OSC on non-Intel platforms.

This unfortunately caused a regression on a vartiety of AMD
platforms in the field because a number of AMD platforms don't set
the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support.

As these AMD platforms already claim CPPC support via a dedicated
MSR from `X86_FEATURE_CPPC`, use this enable this feature rather
than requiring the `_OSC` on platforms with a dedicated MSR.

If there is additional breakage on the shared memory designs also
missing this _OSC, additional follow up changes may be needed.

Fixes: 72f2ecb7ece7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported")
Reported-by: Perry Yuan <perry.yuan@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2->v3
 * Rebase on top of solution for _CPC regression on some Intel systemss
 * Refactor to avoid #ifdef CONFIG_X86

 arch/x86/kernel/acpi/cppc.c |  5 +++++
 drivers/acpi/cppc_acpi.c    | 16 +++++++++++++++-
 include/acpi/cppc_acpi.h    |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 8b8cbf22461a4..20e257db50740 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -11,6 +11,11 @@
 
 /* Refer to drivers/acpi/cppc_acpi.c for the description of functions */
 
+bool cpc_supported_by_cpu(void)
+{
+	return boot_cpu_has(X86_FEATURE_CPPC);
+}
+
 bool cpc_ffh_supported(void)
 {
 	return true;
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index d64facbda0fb7..6ff1901d7d436 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -577,6 +577,19 @@ bool __weak cpc_ffh_supported(void)
 	return false;
 }
 
+/**
+ * cpc_supported_by_cpu() - check if CPPC is supported by CPU
+ *
+ * Check if the architectural support for CPPC is present even
+ * if the _OSC hasn't prescribed it
+ *
+ * Return: true for supported, false for not supported
+ */
+bool __weak cpc_supported_by_cpu(void)
+{
+	return false;
+}
+
 /**
  * pcc_data_alloc() - Allocate the pcc_data memory for pcc subspace
  *
@@ -686,7 +699,8 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
 
 	if (!osc_sb_cppc2_support_acked) {
 		pr_debug("CPPC v2 _OSC not acked\n");
-		return -ENODEV;
+		if (!cpc_supported_by_cpu())
+			return -ENODEV;
 	}
 
 	/* Parse the ACPI _CPC table for this CPU. */
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index c6108581d97dc..d389bab54241d 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -145,6 +145,7 @@ extern bool cppc_allow_fast_switch(void);
 extern int acpi_get_psd_map(unsigned int cpu, struct cppc_cpudata *cpu_data);
 extern unsigned int cppc_get_transition_latency(int cpu);
 extern bool cpc_ffh_supported(void);
+extern bool cpc_supported_by_cpu(void);
 extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
 extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
 #else /* !CONFIG_ACPI_CPPC_LIB */
-- 
2.25.1

Re: [PATCH v3 1/2] ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked

[Mika Westerberg]

On Thu, Jun 30, 2022 at 09:25:27PM -0500, Mario Limonciello wrote:
> Previously the kernel used to ignore whether the firmware masked CPPC
> or CPPCv2 and would just pretend that it worked.
> 
> When support for the USB4 bit in _OSC was introduced from commit
> 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear")
> the kernel began to look at the return when the query bit was clear.
> 
> This caused regressions that were misdiagnosed and attempted to be solved
> as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities
> to the _OSC regardless of the query flag""). This caused a different
> regression where non-Intel systems weren't able to negotiate _OSC
> properly.
> 
> This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same
> capabilities to the _OSC regardless of the query flag"") and attempted to
> be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not
> supported by firmware") but the regression still returned.
> 
> These systems with the regression only load support for CPPC from an SSDT
> dynamically when _OSC reports CPPC v2.  Avoid the problem by not letting
> CPPC satisfy the requirement in `acpi_cppc_processor_probe`.
> 
> Reported-by: CUI Hao <cuihao.leo@gmail.com>
> Reported-by: maxim.novozhilov@gmail.com
> Reported-by: lethe.tree@protonmail.com
> Reported-by: garystephenwright@gmail.com
> Reported-by: galaxyking0419@gmail.com
> Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware")
> Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH v3 1/2] ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked

[CUI Hao]

On Thu, Jun 30, 2022 at 09:25:27PM -0500, Mario Limonciello wrote:
> Previously the kernel used to ignore whether the firmware masked CPPC
> or CPPCv2 and would just pretend that it worked.
> 
> When support for the USB4 bit in _OSC was introduced from commit
> 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear")
> the kernel began to look at the return when the query bit was clear.
> 
> This caused regressions that were misdiagnosed and attempted to be solved
> as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities
> to the _OSC regardless of the query flag""). This caused a different
> regression where non-Intel systems weren't able to negotiate _OSC
> properly.
> 
> This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same
> capabilities to the _OSC regardless of the query flag"") and attempted to
> be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not
> supported by firmware") but the regression still returned.
> 
> These systems with the regression only load support for CPPC from an SSDT
> dynamically when _OSC reports CPPC v2.  Avoid the problem by not letting
> CPPC satisfy the requirement in `acpi_cppc_processor_probe`.
> 
> Reported-by: CUI Hao <cuihao.leo@gmail.com>
> Reported-by: maxim.novozhilov@gmail.com
> Reported-by: lethe.tree@protonmail.com
> Reported-by: garystephenwright@gmail.com
> Reported-by: galaxyking0419@gmail.com
> Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware")
> Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

I tested the patch on 5.19-rc4 kernel, and confirm that it fixes the ACPI errors:
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC] on my ASRock B460M-ITX/ac + i7-10700K machine. New to kernel lists. If my Thunderbird doesn't mangle the text, feel free to add:

Tested-by: CUI Hao <cuihao.leo@gmail.com>