[PATCH v4 1/3] ACPI: APEI: Adjust for acpi_run_osc logic changes

[PATCH v4 1/3] ACPI: APEI: Adjust for acpi_run_osc logic changes

[Mario Limonciello]

As this function calls the OSC with the OSC_QUERY_ENABLE set in
OSC_QUERY_DWORD, ensure that it continues to operate the same if
the function has returned AE_SUPPORT.

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v3->v4:
* No changes
 drivers/acpi/apei/apei-base.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index c7fdb12c3310..f7d1aa687fd9 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -780,6 +780,7 @@ int apei_osc_setup(void)
 {
 	static u8 whea_uuid_str[] = "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
 	acpi_handle handle;
+	acpi_status status;
 	u32 capbuf[3];
 	struct acpi_osc_context context = {
 		.uuid_str	= whea_uuid_str,
@@ -792,12 +793,12 @@ int apei_osc_setup(void)
 	capbuf[OSC_SUPPORT_DWORD] = 1;
 	capbuf[OSC_CONTROL_DWORD] = 0;
 
-	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle))
-	    || ACPI_FAILURE(acpi_run_osc(handle, &context)))
+	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
 		return -EIO;
-	else {
-		kfree(context.ret.pointer);
-		return 0;
-	}
+	status = acpi_run_osc(handle, &context);
+	if (status != AE_SUPPORT && status != AE_OK)
+		return -EIO;
+	kfree(context.ret.pointer);
+	return 0;
 }
 EXPORT_SYMBOL_GPL(apei_osc_setup);
-- 
2.34.1

[PATCH v4 2/3] ACPI: bus: Allow negotiating OSC capabilities

[Mario Limonciello]

Currently when capabilities have been masked by firmware during a
negotiation with OSC_QUERY_ENABLE set they're silently ignored
by the caller.  If the caller calls `acpi_run_osc` again without
query set and the same capabilities, then they instead get a failure
possibly leading to downstream problems.

So instead when query is set return AE_SUPPORT which callers can then
use for determining that capabilities were masked.

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v3->v4:
* Correct kernel doc for AE_OK/AE_SUPPORT not AE_OK/AE_SUCCESS
 drivers/acpi/bus.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 07f604832fd6..302619ad9d31 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -184,6 +184,18 @@ static void acpi_print_osc_error(acpi_handle handle,
 	pr_debug("\n");
 }
 
+/**
+ * acpi_run_osc - Evaluate the _OSC method for a given ACPI handle
+ * @handle: ACPI handle containing _OSC to evaluate
+ * @context: A structure specifying UUID, revision, and buffer for data
+ *
+ * Used for negotiating with firmware the capabilities that will be used
+ * by the OSPM.  Although the return type is acpi_status, the ACPI_SUCCESS
+ * macro can not be used to determine whether to free the buffer of
+ * returned data.
+ *
+ * The buffer must be freed when this function returns AE_OK or AE_SUPPORT.
+ */
 acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
 {
 	acpi_status status;
@@ -243,16 +255,19 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
 			acpi_print_osc_error(handle, context,
 				"_OSC invalid revision");
 		if (errors & OSC_CAPABILITIES_MASK_ERROR) {
+			acpi_print_osc_error(handle, context, "_OSC capabilities masked");
 			if (((u32 *)context->cap.pointer)[OSC_QUERY_DWORD]
-			    & OSC_QUERY_ENABLE)
-				goto out_success;
-			status = AE_SUPPORT;
-			goto out_kfree;
+			    & OSC_QUERY_ENABLE) {
+				status = AE_SUPPORT;
+				goto out_masked;
+			}
 		}
 		status = AE_ERROR;
 		goto out_kfree;
 	}
-out_success:
+
+	status =  AE_OK;
+out_masked:
 	context->ret.length = out_obj->buffer.length;
 	context->ret.pointer = kmemdup(out_obj->buffer.pointer,
 				       context->ret.length, GFP_KERNEL);
@@ -260,7 +275,6 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
 		status =  AE_NO_MEMORY;
 		goto out_kfree;
 	}
-	status =  AE_OK;
 
 out_kfree:
 	kfree(output.pointer);
-- 
2.34.1

Re: [PATCH v4 2/3] ACPI: bus: Allow negotiating OSC capabilities

[Mika Westerberg]

On Tue, Mar 01, 2022 at 06:49:07AM -0600, Mario Limonciello wrote:
> Currently when capabilities have been masked by firmware during a
> negotiation with OSC_QUERY_ENABLE set they're silently ignored
> by the caller.  If the caller calls `acpi_run_osc` again without
> query set and the same capabilities, then they instead get a failure
> possibly leading to downstream problems.
> 
> So instead when query is set return AE_SUPPORT which callers can then
> use for determining that capabilities were masked.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

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

Re: [PATCH v4 2/3] ACPI: bus: Allow negotiating OSC capabilities

[Qian Cai]

On Tue, Mar 01, 2022 at 06:49:07AM -0600, Mario Limonciello wrote:
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 07f604832fd6..302619ad9d31 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -184,6 +184,18 @@ static void acpi_print_osc_error(acpi_handle handle,
>  	pr_debug("\n");
>  }
>  
> +/**
> + * acpi_run_osc - Evaluate the _OSC method for a given ACPI handle
> + * @handle: ACPI handle containing _OSC to evaluate
> + * @context: A structure specifying UUID, revision, and buffer for data
> + *
> + * Used for negotiating with firmware the capabilities that will be used
> + * by the OSPM.  Although the return type is acpi_status, the ACPI_SUCCESS
> + * macro can not be used to determine whether to free the buffer of
> + * returned data.
> + *
> + * The buffer must be freed when this function returns AE_OK or AE_SUPPORT.
> + */
>  acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
>  {
>  	acpi_status status;
> @@ -243,16 +255,19 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
>  			acpi_print_osc_error(handle, context,
>  				"_OSC invalid revision");
>  		if (errors & OSC_CAPABILITIES_MASK_ERROR) {
> +			acpi_print_osc_error(handle, context, "_OSC capabilities masked");
>  			if (((u32 *)context->cap.pointer)[OSC_QUERY_DWORD]
> -			    & OSC_QUERY_ENABLE)
> -				goto out_success;
> -			status = AE_SUPPORT;
> -			goto out_kfree;
> +			    & OSC_QUERY_ENABLE) {
> +				status = AE_SUPPORT;
> +				goto out_masked;
> +			}
>  		}
>  		status = AE_ERROR;
>  		goto out_kfree;
>  	}
> -out_success:
> +
> +	status =  AE_OK;
> +out_masked:
>  	context->ret.length = out_obj->buffer.length;
>  	context->ret.pointer = kmemdup(out_obj->buffer.pointer,
>  				       context->ret.length, GFP_KERNEL);
> @@ -260,7 +275,6 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
>  		status =  AE_NO_MEMORY;
>  		goto out_kfree;
>  	}
> -	status =  AE_OK;
>  
>  out_kfree:
>  	kfree(output.pointer);

Do we forget to free "context.ret.pointer" in acpi_pci_run_osc() as well
when acpi_run_osc() starts to return AE_SUPPORT? I saw memory leaks on the
latest linux-next which include this series.

# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff07ff968c6e80 (size 128):
  comm "swapper/0", pid 1, jiffies 4294894996 (age 1785.652s)
  hex dump (first 32 bytes):
    11 00 00 00 1f 01 00 00 18 00 00 00 6b 6b 6b 6b  ............kkkk
    6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
  backtrace:
    [<ffffad5bd9d79adc>] __kmalloc_track_caller
    [<ffffad5bd9c439f4>] kmemdup
    [<ffffad5bda97c710>] acpi_run_osc
    acpi_run_osc at drivers/acpi/bus.c:272
    [<ffffad5bdc52f8a8>] acpi_pci_run_osc
    acpi_pci_run_osc at drivers/acpi/pci_root.c:184
    [<ffffad5bdc52fe30>] negotiate_os_control.constprop.0
    acpi_pci_query_osc at drivers/acpi/pci_root.c:205
    (inlined by) acpi_pci_osc_control_set at drivers/acpi/pci_root.c:353
    (inlined by) negotiate_os_control at drivers/acpi/pci_root.c:482
    [<ffffad5bda995748>] acpi_pci_root_add
    [<ffffad5bda982558>] acpi_bus_attach
    [<ffffad5bda9823c8>] acpi_bus_attach
    [<ffffad5bda9823c8>] acpi_bus_attach
    [<ffffad5bda98808c>] acpi_bus_scan
    [<ffffad5bdd9624a0>] acpi_scan_init
    [<ffffad5bdd961e74>] acpi_init
    [<ffffad5bd9595438>] do_one_initcall
    [<ffffad5bdd90201c>] kernel_init_freeable
    [<ffffad5bdc5684e0>] kernel_init
    [<ffffad5bd959841c>] ret_from_fork

[PATCH v4 3/3] ACPI: bus: For platform OSC negotiate capabilities

[Mario Limonciello]

According to the ACPI 6.4 spec:
It is strongly recommended that the OS evaluate _OSC with the Query
Support Flag set until _OSC returns the Capabilities Masked bit clear,
to negotiate the set of features to be granted to the OS for native
support; a platform may require a specific combination of features
to be supported natively by an OS before granting native control
of a given feature. After negotiation with the query flag set,
the OS should evaluate without it so that any negotiated values
can be made effective to hardware.

Currently the code sends the exact same values in both executions of the
_OSC and this leads to some problems on some AMD platforms in certain
configurations.

The following notable capabilities are set by OSPM when query is enabled:
* OSC_SB_PR3_SUPPORT
* OSC_SB_PCLPI_SUPPORT
* OSC_SB_NATIVE_USB4_SUPPORT

The first call to the platform OSC returns back a masked capabilities
error because the firmware did not acknowledge OSC_SB_PCLPI_SUPPORT but
it acknolwedged the others.

The second call to the platform _OSC without the query flag set then
fails because the OSPM still sent the exact same values.  This leads
to not acknowledging OSC_SB_NATIVE_USB4_SUPPORT and later USB4 PCIe
tunnels can't be authorized.

This problem was first introduced by commit 159d8c274fd9 ("ACPI: Pass the
same capabilities to the _OSC regardless of the query flag") which subtly
adjusted the behavior from 719e1f5 ("ACPI: Execute platform _OSC also
with query bit clear").

The _OSC was called exactly 2 times:
 * Once to query and request from firmware
 * Once to commit to firmware without query

To fix this problem, continue to call the _OSC until the firmware has
indicated that capabilities are no longer masked or after an arbitrary
number of negotiation attempts.

Furthermore, to avoid the problem that commit 159d8c274fd9 ("ACPI: Pass
the same capabilities to the _OSC regardless of the query flag")
introduced, explicitly mark support for CPC and CPPCv2 even if they
were masked by the series of query calls due to table loading order on
some systems.

Fixes: 159d8c274fd9 ("ACPI: Pass the same capabilities to the _OSC regardless of the query flag")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v3->v4:
* Don't use ACPI_SUCCESS macro at all to avoid confusion on acpi_run_osc
 drivers/acpi/bus.c | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 302619ad9d31..c60c7c7e0149 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -308,6 +308,8 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 		.cap.pointer = capbuf,
 	};
 	acpi_handle handle;
+	acpi_status status;
+	int i;
 
 	capbuf[OSC_QUERY_DWORD] = OSC_QUERY_ENABLE;
 	capbuf[OSC_SUPPORT_DWORD] = OSC_SB_PR3_SUPPORT; /* _PR3 is in use */
@@ -343,10 +345,34 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
 		return;
 
-	if (ACPI_FAILURE(acpi_run_osc(handle, &context)))
+	/*
+	 * Check if bits were masked, we need to negotiate
+	 * prevent potential endless loop by limited number of
+	 * negotiation cycles.
+	 */
+	for (i = 0; i < 5; i++) {
+		status = acpi_run_osc(handle, &context);
+		if (status == AE_OK || status == AE_SUPPORT) {
+			capbuf_ret = context.ret.pointer;
+			capbuf[OSC_SUPPORT_DWORD] = capbuf_ret[OSC_SUPPORT_DWORD];
+			kfree(context.ret.pointer);
+		}
+		if (status != AE_SUPPORT)
+			break;
+	}
+	if (ACPI_FAILURE(status))
 		return;
 
-	kfree(context.ret.pointer);
+	/*
+	 * Avoid problems with BIOS dynamically loading tables by indicating
+	 * support for CPPC even if it was masked.
+	 */
+#ifdef CONFIG_X86
+	if (boot_cpu_has(X86_FEATURE_HWP)) {
+		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_CPC_SUPPORT;
+		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_CPCV2_SUPPORT;
+	}
+#endif
 
 	/* Now run _OSC again with query flag clear */
 	capbuf[OSC_QUERY_DWORD] = 0;
-- 
2.34.1

Re: [PATCH v4 3/3] ACPI: bus: For platform OSC negotiate capabilities

[Mika Westerberg]

On Tue, Mar 01, 2022 at 06:49:08AM -0600, Mario Limonciello wrote:
> According to the ACPI 6.4 spec:
> It is strongly recommended that the OS evaluate _OSC with the Query
> Support Flag set until _OSC returns the Capabilities Masked bit clear,
> to negotiate the set of features to be granted to the OS for native
> support; a platform may require a specific combination of features
> to be supported natively by an OS before granting native control
> of a given feature. After negotiation with the query flag set,
> the OS should evaluate without it so that any negotiated values
> can be made effective to hardware.
> 
> Currently the code sends the exact same values in both executions of the
> _OSC and this leads to some problems on some AMD platforms in certain
> configurations.
> 
> The following notable capabilities are set by OSPM when query is enabled:
> * OSC_SB_PR3_SUPPORT
> * OSC_SB_PCLPI_SUPPORT
> * OSC_SB_NATIVE_USB4_SUPPORT
> 
> The first call to the platform OSC returns back a masked capabilities
> error because the firmware did not acknowledge OSC_SB_PCLPI_SUPPORT but
> it acknolwedged the others.
> 
> The second call to the platform _OSC without the query flag set then
> fails because the OSPM still sent the exact same values.  This leads
> to not acknowledging OSC_SB_NATIVE_USB4_SUPPORT and later USB4 PCIe
> tunnels can't be authorized.
> 
> This problem was first introduced by commit 159d8c274fd9 ("ACPI: Pass the
> same capabilities to the _OSC regardless of the query flag") which subtly
> adjusted the behavior from 719e1f5 ("ACPI: Execute platform _OSC also
> with query bit clear").
> 
> The _OSC was called exactly 2 times:
>  * Once to query and request from firmware
>  * Once to commit to firmware without query
> 
> To fix this problem, continue to call the _OSC until the firmware has
> indicated that capabilities are no longer masked or after an arbitrary
> number of negotiation attempts.
> 
> Furthermore, to avoid the problem that commit 159d8c274fd9 ("ACPI: Pass
> the same capabilities to the _OSC regardless of the query flag")
> introduced, explicitly mark support for CPC and CPPCv2 even if they
> were masked by the series of query calls due to table loading order on
> some systems.
> 
> Fixes: 159d8c274fd9 ("ACPI: Pass the same capabilities to the _OSC regardless of the query flag")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>

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

Re: [PATCH v4 1/3] ACPI: APEI: Adjust for acpi_run_osc logic changes

[Rafael J. Wysocki]

On Tue, Mar 1, 2022 at 1:52 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> As this function calls the OSC with the OSC_QUERY_ENABLE set in
> OSC_QUERY_DWORD, ensure that it continues to operate the same if
> the function has returned AE_SUPPORT.
>
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> v3->v4:
> * No changes
>  drivers/acpi/apei/apei-base.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
> index c7fdb12c3310..f7d1aa687fd9 100644
> --- a/drivers/acpi/apei/apei-base.c
> +++ b/drivers/acpi/apei/apei-base.c
> @@ -780,6 +780,7 @@ int apei_osc_setup(void)
>  {
>         static u8 whea_uuid_str[] = "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
>         acpi_handle handle;
> +       acpi_status status;
>         u32 capbuf[3];
>         struct acpi_osc_context context = {
>                 .uuid_str       = whea_uuid_str,
> @@ -792,12 +793,12 @@ int apei_osc_setup(void)
>         capbuf[OSC_SUPPORT_DWORD] = 1;
>         capbuf[OSC_CONTROL_DWORD] = 0;
>
> -       if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle))
> -           || ACPI_FAILURE(acpi_run_osc(handle, &context)))
> +       if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
>                 return -EIO;
> -       else {
> -               kfree(context.ret.pointer);
> -               return 0;
> -       }
> +       status = acpi_run_osc(handle, &context);
> +       if (status != AE_SUPPORT && status != AE_OK)
> +               return -EIO;
> +       kfree(context.ret.pointer);
> +       return 0;
>  }
>  EXPORT_SYMBOL_GPL(apei_osc_setup);
> --

Applied as 5.18 material along with the rest of the series.

Thanks!