From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux ACPI <linux-acpi@vger.kernel.org>,
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>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH v1 2/8] ACPI: bus: Rework printing debug messages on _OSC errors
Date: Fri, 19 Dec 2025 12:33:19 +0000 [thread overview]
Message-ID: <20251219123319.00001e98@huawei.com> (raw)
In-Reply-To: <3036574.e9J7NaK4W3@rafael.j.wysocki>
On Thu, 18 Dec 2025 21:35:27 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Instead of using one function, acpi_print_osc_error(), for printing a
> debug message and dumping the _OSC request data in one go, use
> acpi_handle_debug() directly for printing messages and a separate
> function called acpi_dump_osc_data() for dumping the _OSC request data
> after printing one or more of them.
>
> This allows the message printing in the _OSC handling code to be
> organized so that the messages printed by it are easier to parse.
Hi Rafael,
Perhaps an example of the print to motivate this change clearly?
The absence of a guid on the error string line for instance may
or may not bother people. It's there in the dump but that comes
after the error print I think.
Thanks,
Jonathan
>
> Also, use %pUL for UUID printing instead of printing UUIDs as strings
> and include the revision number into the dumped _OSC request data.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/bus.c | 35 ++++++++++++++++-------------------
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -180,18 +180,15 @@ void acpi_bus_detach_private_data(acpi_h
> }
> EXPORT_SYMBOL_GPL(acpi_bus_detach_private_data);
>
> -static void acpi_print_osc_error(acpi_handle handle,
> - struct acpi_osc_context *context, char *error)
> +static void acpi_dump_osc_data(acpi_handle handle, const guid_t *guid, int rev,
> + struct acpi_buffer *cap)
> {
> + u32 *capbuf = cap->pointer;
> int i;
>
> - acpi_handle_debug(handle, "(%s): %s\n", context->uuid_str, error);
> -
> - pr_debug("_OSC request data:");
> - for (i = 0; i < context->cap.length; i += sizeof(u32))
> - pr_debug(" %x", *((u32 *)(context->cap.pointer + i)));
> -
> - pr_debug("\n");
> + for (i = 0; i < cap->length / sizeof(u32); i++)
> + acpi_handle_debug(handle, "(%pUL, %d): capabilities DWORD %i: [%08x]\n",
> + guid, rev, i, capbuf[i]);
> }
>
> #define OSC_ERROR_MASK (OSC_REQUEST_ERROR | OSC_INVALID_UUID_ERROR | \
> @@ -239,8 +236,8 @@ acpi_status acpi_run_osc(acpi_handle han
> out_obj = output.pointer;
> if (out_obj->type != ACPI_TYPE_BUFFER
> || out_obj->buffer.length != context->cap.length) {
> - acpi_print_osc_error(handle, context,
> - "_OSC evaluation returned wrong type");
> + acpi_handle_debug(handle, "_OSC evaluation returned wrong type");
> + acpi_dump_osc_data(handle, &guid, context->rev, &context->cap);
> status = AE_TYPE;
> goto out_kfree;
> }
> @@ -252,18 +249,18 @@ acpi_status acpi_run_osc(acpi_handle han
>
> if (errors) {
> if (errors & OSC_REQUEST_ERROR)
> - acpi_print_osc_error(handle, context,
> - "_OSC request failed");
> + acpi_handle_debug(handle, "_OSC request failed");
> +
> if (errors & OSC_INVALID_UUID_ERROR)
> - acpi_print_osc_error(handle, context,
> - "_OSC invalid UUID");
> + acpi_handle_debug(handle, "_OSC invalid UUID");
> +
> if (errors & OSC_INVALID_REVISION_ERROR)
> - acpi_print_osc_error(handle, context,
> - "_OSC invalid revision");
> + acpi_handle_debug(handle, "_OSC invalid revision");
> +
> if (errors & OSC_CAPABILITIES_MASK_ERROR)
> - acpi_print_osc_error(handle, context,
> - "_OSC capability bits masked");
> + acpi_handle_debug(handle, "_OSC capability bits masked");
>
> + acpi_dump_osc_data(handle, &guid, context->rev, &context->cap);
> status = AE_ERROR;
> goto out_kfree;
> }
>
>
>
>
next prev parent reply other threads:[~2025-12-19 12:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 20:29 [PATCH v1 0/8] ACPI: bus: Rework of the \_SB._OSC handling Rafael J. Wysocki
2025-12-18 20:34 ` [PATCH v1 1/8] ACPI: bus: Fix handling of _OSC errors in acpi_run_osc() Rafael J. Wysocki
2025-12-19 12:26 ` Jonathan Cameron
2025-12-19 20:38 ` Rafael J. Wysocki
2025-12-19 21:28 ` [PATCH v2] " Rafael J. Wysocki
2025-12-22 11:18 ` Jonathan Cameron
2025-12-22 17:57 ` Rafael J. Wysocki
2025-12-18 20:35 ` [PATCH v1 2/8] ACPI: bus: Rework printing debug messages on _OSC errors Rafael J. Wysocki
2025-12-19 12:33 ` Jonathan Cameron [this message]
2025-12-19 17:20 ` Rafael J. Wysocki
2025-12-18 20:36 ` [PATCH v1 3/8] ACPI: bus: Split _OSC evaluation out of acpi_run_osc() Rafael J. Wysocki
2025-12-19 12:44 ` Jonathan Cameron
2025-12-19 17:22 ` Rafael J. Wysocki
2025-12-18 20:36 ` [PATCH v1 4/8] ACPI: bus: Split _OSC error processing " Rafael J. Wysocki
2025-12-19 12:46 ` Jonathan Cameron
2025-12-19 17:24 ` Rafael J. Wysocki
2025-12-18 20:37 ` [PATCH v1 5/8] ACPI: bus: Rename label and use ACPI_FREE() in acpi_run_osc() Rafael J. Wysocki
2025-12-19 12:47 ` Jonathan Cameron
2025-12-18 20:39 ` [PATCH v1 6/8] ACPI: bus: Rework the handling of \_SB._OSC platform features Rafael J. Wysocki
2025-12-19 12:56 ` Jonathan Cameron
2025-12-19 17:48 ` Rafael J. Wysocki
2025-12-18 20:41 ` [PATCH v1 7/8] ACPI: bus: Adjust feature mask creation for \_SB._OSC Rafael J. Wysocki
2025-12-19 12:58 ` Jonathan Cameron
2025-12-18 20:42 ` [PATCH v1 8/8] ACPI: bus: Rework the handling of \_SB._OSC USB4 features Rafael J. Wysocki
2025-12-19 12:59 ` Jonathan Cameron
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=20251219123319.00001e98@huawei.com \
--to=jonathan.cameron@huawei.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=mario.limonciello@amd.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.