[PATCH] ACPI: bus: Avoid misleading _OSC missing-feature errors

[PATCH] ACPI: bus: Avoid misleading _OSC missing-feature errors

[Saverio Miroddi]

The ACPI specification defines OSC_CAPABILITIES_MASK_ERROR to mean that
firmware cleared capability bits requested by the operating system. Some
firmware sets this status during the control request while returning every
requested capability unchanged. On the affected system, the requested and
returned masks were both 0x006a7eff.

Commit e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC
platform features") made all control-response errors produce error-level
messages. Consequently, the inconsistent response above now claims that
features may be missing even though none were removed.

Track whether the response actually clears a requested bit and omit the
error-level messages only if OSC_CAPABILITIES_MASK_ERROR is the sole
error and no capability was cleared. Keep the dynamic-debug diagnostic and
leave the negotiated capability mask and all other error cases unchanged.

Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
Signed-off-by: Saverio Miroddi <saverio.pub2@gmail.com>
---
 drivers/acpi/bus.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a30a904f6535..c13128cbc2f6 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -335,7 +335,8 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
 		.length = bufsize * sizeof(u32),
 	};
 	struct acpi_buffer output;
-	u32 *retbuf, test;
+	u32 *retbuf, test, errors;
+	bool capabilities_masked = false;
 	guid_t guid;
 	int ret, i;
 
@@ -395,16 +396,24 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
 	 * Clear the feature bits in capbuf[] that have not been acknowledged.
 	 * After that, capbuf[] contains the resultant feature mask.
 	 */
-	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++)
+	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++) {
+		if (capbuf[i] & ~retbuf[i])
+			capabilities_masked = true;
+
 		capbuf[i] &= retbuf[i];
+	}
 
-	if (retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK) {
+	errors = retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK;
+	if (errors) {
 		/*
-		 * Complain about the unexpected errors and print diagnostic
-		 * information related to them.
+		 * Some firmware sets OSC_CAPABILITIES_MASK_ERROR without clearing
+		 * any requested capability.  Only complain if another error is
+		 * present or a capability was actually masked.
 		 */
-		acpi_handle_err(handle, "_OSC: errors while processing control request\n");
-		acpi_handle_err(handle, "_OSC: some features may be missing\n");
+		if (errors != OSC_CAPABILITIES_MASK_ERROR || capabilities_masked) {
+			acpi_handle_err(handle, "_OSC: errors while processing control request\n");
+			acpi_handle_err(handle, "_OSC: some features may be missing\n");
+		}
 		acpi_osc_error_check(handle, &guid, rev, &cap, retbuf);
 	}
 
-- 
2.54.0

Re: [PATCH] ACPI: bus: Avoid misleading _OSC missing-feature errors

[Jonathan Cameron]

On Tue, 21 Jul 2026 21:29:14 +0200
Saverio Miroddi <saverio.pub2@gmail.com> wrote:

> The ACPI specification defines OSC_CAPABILITIES_MASK_ERROR to mean that
> firmware cleared capability bits requested by the operating system. Some
> firmware sets this status during the control request while returning every
> requested capability unchanged. On the affected system, the requested and
> returned masks were both 0x006a7eff.

Just to check my understanding.  When a system does this there is no error?
Is it happy with the capabilities requested?  So the return value is simply
a firmware bug? (just one we didn't notice before).

> 
> Commit e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC
> platform features") made all control-response errors produce error-level
> messages. Consequently, the inconsistent response above now claims that
> features may be missing even though none were removed.
> 
> Track whether the response actually clears a requested bit and omit the
> error-level messages only if OSC_CAPABILITIES_MASK_ERROR is the sole
> error and no capability was cleared. Keep the dynamic-debug diagnostic and
> leave the negotiated capability mask and all other error cases unchanged.
> 
> Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
> Signed-off-by: Saverio Miroddi <saverio.pub2@gmail.com>
> ---
>  drivers/acpi/bus.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a30a904f6535..c13128cbc2f6 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -335,7 +335,8 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
>  		.length = bufsize * sizeof(u32),
>  	};
>  	struct acpi_buffer output;
> -	u32 *retbuf, test;
> +	u32 *retbuf, test, errors;
> +	bool capabilities_masked = false;
>  	guid_t guid;
>  	int ret, i;
>  
> @@ -395,16 +396,24 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
>  	 * Clear the feature bits in capbuf[] that have not been acknowledged.
>  	 * After that, capbuf[] contains the resultant feature mask.
>  	 */
> -	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++)
> +	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++) {
> +		if (capbuf[i] & ~retbuf[i])
> +			capabilities_masked = true;
> +
>  		capbuf[i] &= retbuf[i];
> +	}
>  
> -	if (retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK) {
> +	errors = retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK;
> +	if (errors) {
>  		/*
> -		 * Complain about the unexpected errors and print diagnostic
> -		 * information related to them.
> +		 * Some firmware sets OSC_CAPABILITIES_MASK_ERROR without clearing
> +		 * any requested capability.  Only complain if another error is
> +		 * present or a capability was actually masked.

Can you add a clarification here on what we think the firmware is indicating
when it does this.

>  		 */
> -		acpi_handle_err(handle, "_OSC: errors while processing control request\n");
> -		acpi_handle_err(handle, "_OSC: some features may be missing\n");
> +		if (errors != OSC_CAPABILITIES_MASK_ERROR || capabilities_masked) {
> +			acpi_handle_err(handle, "_OSC: errors while processing control request\n");

Related to questions above, but this print is true on any error return even if perhaps
we are sure the next print is not.

> +			acpi_handle_err(handle, "_OSC: some features may be missing\n");
> +		}
>  		acpi_osc_error_check(handle, &guid, rev, &cap, retbuf);
>  	}
>  

Re: [PATCH] ACPI: bus: Avoid misleading _OSC missing-feature errors

[Saverio Miroddi]

Hi!

Yes, that's my understanding, with one qualification: we can only infer this from the returned buffer.

The returned capability mask acknowledges every capability requested by OSPM, while OSC_CAPABILITIES_MASK_ERROR says that at least one requested bit was cleared. Since the requested and returned masks are identical, those two parts of the response are inconsistent. The protocol-visible result acknowledges all requested capabilities, so the status bit appears to be a firmware bug.

I'll clarify this in the comment.

For the logging, I'll keep "_OSC: errors while processing control request" for every error return and condition only "_OSC: some features may be missing". That preserves the firmware error report without claiming that capabilities were removed.

Best,
Saverio

[PATCH v1] ACPI: bus: Avoid confusing complaints regarding missing _OSC features

[Rafael J. Wysocki]

On Tuesday, July 21, 2026 9:29:14 PM CEST Saverio Miroddi wrote:
> The ACPI specification defines OSC_CAPABILITIES_MASK_ERROR to mean that
> firmware cleared capability bits requested by the operating system. Some
> firmware sets this status during the control request while returning every
> requested capability unchanged. On the affected system, the requested and
> returned masks were both 0x006a7eff.
> 
> Commit e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC
> platform features") made all control-response errors produce error-level
> messages. Consequently, the inconsistent response above now claims that
> features may be missing even though none were removed.
> 
> Track whether the response actually clears a requested bit and omit the
> error-level messages only if OSC_CAPABILITIES_MASK_ERROR is the sole
> error and no capability was cleared. Keep the dynamic-debug diagnostic and
> leave the negotiated capability mask and all other error cases unchanged.
> 
> Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
> Signed-off-by: Saverio Miroddi <saverio.pub2@gmail.com>
> ---
>  drivers/acpi/bus.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a30a904f6535..c13128cbc2f6 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -335,7 +335,8 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
>  		.length = bufsize * sizeof(u32),
>  	};
>  	struct acpi_buffer output;
> -	u32 *retbuf, test;
> +	u32 *retbuf, test, errors;
> +	bool capabilities_masked = false;

The existing test variable can be used for this just fine, no need to add more
of them.

>  	guid_t guid;
>  	int ret, i;
>  
> @@ -395,16 +396,24 @@ static int acpi_osc_handshake(acpi_handle handle, const char *uuid_str,
>  	 * Clear the feature bits in capbuf[] that have not been acknowledged.
>  	 * After that, capbuf[] contains the resultant feature mask.
>  	 */
> -	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++)
> +	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++) {
> +		if (capbuf[i] & ~retbuf[i])
> +			capabilities_masked = true;
> +
>  		capbuf[i] &= retbuf[i];
> +	}
>  
> -	if (retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK) {
> +	errors = retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK;
> +	if (errors) {
>  		/*
> -		 * Complain about the unexpected errors and print diagnostic
> -		 * information related to them.
> +		 * Some firmware sets OSC_CAPABILITIES_MASK_ERROR without clearing
> +		 * any requested capability.  Only complain if another error is
> +		 * present or a capability was actually masked.
>  		 */
> -		acpi_handle_err(handle, "_OSC: errors while processing control request\n");
> -		acpi_handle_err(handle, "_OSC: some features may be missing\n");
> +		if (errors != OSC_CAPABILITIES_MASK_ERROR || capabilities_masked) {
> +			acpi_handle_err(handle, "_OSC: errors while processing control request\n");
> +			acpi_handle_err(handle, "_OSC: some features may be missing\n");
> +		}
>  		acpi_osc_error_check(handle, &guid, rev, &cap, retbuf);

And here the debug output is not quite useful if the error is essentially
ignored.

>  	}

So below is my version of this fix, please check it if works for you.

Thanks!

---
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: [PATCH] ACPI: bus: Avoid confusing complaints regarding missing _OSC features

The platform firmware on some platforms sets OSC_CAPABILITIES_MASK_ERROR
in _OSC error bits even though it actually acknowledges all of the
requested features which after commit e5322888e6bf ("ACPI: bus: Rework
the handling of \_SB._OSC platform features") causes the kernel to
complain unnecessarily.

Avoid the confusing complaints by explicitly checking for that case
in acpi_osc_handshake().

Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/bus.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -395,10 +395,18 @@ static int acpi_osc_handshake(acpi_handl
 	 * Clear the feature bits in capbuf[] that have not been acknowledged.
 	 * After that, capbuf[] contains the resultant feature mask.
 	 */
-	for (i = OSC_QUERY_DWORD + 1; i < bufsize; i++)
+	for (i = OSC_QUERY_DWORD + 1, test = 0; i < bufsize; i++) {
+		test |= capbuf[i] & ~retbuf[i];
 		capbuf[i] &= retbuf[i];
+	}
 
-	if (retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK) {
+	/*
+	 * Some platforms set OSC_CAPABILITIES_MASK_ERROR even though they
+	 * acknowledge all of the requested features, so avoid complaining in
+	 * those cases unless any other error bits are also set.
+	 */
+	if ((retbuf[OSC_QUERY_DWORD] & OSC_ERROR_MASK) &&
+	    (test || retbuf[OSC_QUERY_DWORD] != OSC_CAPABILITIES_MASK_ERROR)) {
 		/*
 		 * Complain about the unexpected errors and print diagnostic
 		 * information related to them.

Re: [PATCH v1] ACPI: bus: Avoid confusing complaints regarding missing _OSC features

[Saverio Miroddi]

Hi!

I tested your version on the affected system.  The requested and returned
capability masks are both 0x006a7eff, and the two misleading error messages
no longer appear.  The negotiated capability masks are unchanged.

Tested-by: Saverio Miroddi <saverio.pub2@gmail.com>

Thanks!
Saverio