From: Mario Limonciello <mario.limonciello@amd.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Hans de Goede <hansg@kernel.org>
Subject: Re: [PATCH v1 1/2] ACPI: bus: Adjust error handling in acpi_run_osc()
Date: Tue, 16 Dec 2025 16:04:24 -0600 [thread overview]
Message-ID: <5536fc1a-4bc9-413e-a903-08090217979b@amd.com> (raw)
In-Reply-To: <6225184.lOV4Wx5bFT@rafael.j.wysocki>
On 12/16/2025 2:17 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Some platform firmware incorrectly sets the OSC_CAPABILITIES_MASK_ERROR
> bit in its _OSC return buffer even if no support bits have been actually
> masked, which causes acpi_run_osc() to return an error when executed
> with OSC_QUERY_ENABLE clear in the OC capabilities buffer. As a result,
> the OS assumes that the _OSC evaluation has failed and the platform has
> not acknowledged any capabilities, while the platform assumes that it
> actually has acknowledged some of them. This confusion may lead to
> missing functionality (and possibly other issues) down the road.
>
> To address this problem, adjust acpi_run_osc() to avoid returning an
> error when OSC_CAPABILITIES_MASK_ERROR is set in the return buffer
> and OSC_QUERY_ENABLE is clear in the OC capabilities, but all of the
> bits in the support mask supplied by the OS are also set in the bit
> mask returned by the platform firmware.
If possible can you add some more context to explain which _OSC was
behaving this way? And if it's production hardware what hardware was
affected?
It sounds like a viable workaround, I just want to make sure that if we
have to change this again later we have more information to look back upon.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/bus.c | 23 +++++++++++++++--------
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -240,9 +240,13 @@ acpi_status acpi_run_osc(acpi_handle han
> status = AE_TYPE;
> goto out_kfree;
> }
> + if (out_obj->buffer.length <= OSC_SUPPORT_DWORD) {
> + status = AE_BAD_DATA;
> + goto out_kfree;
> + }
> /* Need to ignore the bit0 in result code */
> errors = *((u32 *)out_obj->buffer.pointer) & ~(1 << 0);
> - if (errors) {
> + if (errors & ~OSC_CAPABILITIES_MASK_ERROR) {
> if (errors & OSC_REQUEST_ERROR)
> acpi_print_osc_error(handle, context,
> "_OSC request failed");
> @@ -252,17 +256,20 @@ acpi_status acpi_run_osc(acpi_handle han
> if (errors & OSC_INVALID_REVISION_ERROR)
> acpi_print_osc_error(handle, context,
> "_OSC invalid revision");
> - if (errors & OSC_CAPABILITIES_MASK_ERROR) {
> - if (((u32 *)context->cap.pointer)[OSC_QUERY_DWORD]
> - & OSC_QUERY_ENABLE)
> - goto out_success;
> + status = AE_ERROR;
> + goto out_kfree;
> + }
> + if (errors) {
> + u32 retbuf = ((u32 *)out_obj->buffer.pointer)[OSC_SUPPORT_DWORD];
> + u32 capbuf = ((u32 *)context->cap.pointer)[OSC_SUPPORT_DWORD];
> + u32 querybuf = ((u32 *)context->cap.pointer)[OSC_QUERY_DWORD];
> +
> + /* OSC_CAPABILITIES_MASK_ERROR is set in errors. */
> + if (!(querybuf & OSC_QUERY_ENABLE) && (capbuf & retbuf) != capbuf) {
> status = AE_SUPPORT;
> goto out_kfree;
> }
> - status = AE_ERROR;
> - goto out_kfree;
> }
> -out_success:
> context->ret.length = out_obj->buffer.length;
> context->ret.pointer = kmemdup(out_obj->buffer.pointer,
> context->ret.length, GFP_KERNEL);
>
>
>
next prev parent reply other threads:[~2025-12-16 22:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 20:15 [PATCH v1 0/2] ACPI: bus: Adjustments related to \_SB._OSC Rafael J. Wysocki
2025-12-16 20:17 ` [PATCH v1 1/2] ACPI: bus: Adjust error handling in acpi_run_osc() Rafael J. Wysocki
2025-12-16 22:04 ` Mario Limonciello [this message]
2025-12-17 12:15 ` Rafael J. Wysocki
2025-12-16 20:18 ` [PATCH v1 2/2] ACPI: bus: Adjust acpi_bus_osc_negotiate_platform_control() Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5536fc1a-4bc9-413e-a903-08090217979b@amd.com \
--to=mario.limonciello@amd.com \
--cc=hansg@kernel.org \
--cc=helgaas@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox