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 <[email protected]>
Reported-by: [email protected]
Reported-by: [email protected]
Reported-by: [email protected]
Reported-by: [email protected]
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 <[email protected]>
---
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
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 <[email protected]>
> Reported-by: [email protected]
> Reported-by: [email protected]
> Reported-by: [email protected]
> Reported-by: [email protected]
> 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 <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
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 <[email protected]>
> Reported-by: [email protected]
> Reported-by: [email protected]
> Reported-by: [email protected]
> Reported-by: [email protected]
> 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 <[email protected]>
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 <[email protected]>