All of lore.kernel.org
 help / color / mirror / Atom feed
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 v2.1 2/8] ACPI: bus: Rework printing debug messages on _OSC errors
Date: Tue, 23 Dec 2025 11:13:31 +0000	[thread overview]
Message-ID: <20251223111331.000054da@huawei.com> (raw)
In-Reply-To: <10794028.nUPlyArG6x@rafael.j.wysocki>

On Mon, 22 Dec 2025 20:11:08 +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
> before printing one or more of them.
> 
> This avoids
>  * dumping _OSC request data multiple times when there are
>    multiple error bits set in the return buffer,
>  * wrapping message lines on terminals with 80 character line width,
>  * mixing up unrelated messages by printing full lines only,
> and generally helps to make the messages easier to parse.
> 
> Also, use %pUL for UUID printing instead of printing UUIDs as strings
> and include the revision number into the dumped _OSC request data.
> 
> This is how the debug printout looks like when the
> OSC_REQUEST_ERROR and OSC_INVALID_REVISION_ERROR bits
> are set in the return buffer before the change:
> 
>  ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC request failed
>  ACPI: _OSC request data:
>  ACPI:  1
>  ACPI:  2e7eff
>  ACPI: 
>  ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC invalid revision
>  ACPI: _OSC request data:
>  ACPI:  1
>  ACPI:  2e7eff
>  ACPI:
> 
> and this is how it is going to look like afterward:
> 
>  ACPI: \_SB_: ACPI: _OSC: UUID: 0811B06E-4A27-44F9-8D60-3CBBC22E7B48, rev: 1
>  ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 0: [00000001]
>  ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 1: [002e7eff]
>  ACPI: \_SB_: ACPI: _OSC: request failed
>  ACPI: \_SB_: ACPI: _OSC: invalid revision
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

  reply	other threads:[~2025-12-23 11:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-22 18:58 [PATCH v2.1 0/8] ACPI: bus: Rework of the \_SB._OSC handling Rafael J. Wysocki
2025-12-22 19:05 ` [PATCH v2.1 1/8] ACPI: bus: Fix handling of _OSC errors in acpi_run_osc() Rafael J. Wysocki
2025-12-23 11:12   ` Jonathan Cameron
2025-12-23 16:13     ` Rafael J. Wysocki
2025-12-22 19:11 ` [PATCH v2.1 2/8] ACPI: bus: Rework printing debug messages on _OSC errors Rafael J. Wysocki
2025-12-23 11:13   ` Jonathan Cameron [this message]
2025-12-22 19:14 ` [PATCH v2.1 3/8] ACPI: bus: Split _OSC evaluation out of acpi_run_osc() Rafael J. Wysocki
2025-12-23 11:18   ` Jonathan Cameron
2025-12-22 19:17 ` [PATCH v2.1 4/8] ACPI: bus: Split _OSC error processing " Rafael J. Wysocki
2025-12-22 19:18 ` [PATCH v2.1 5/8] ACPI: bus: Rename label and use ACPI_FREE() in acpi_run_osc() Rafael J. Wysocki
2025-12-22 19:21 ` [PATCH v2.1 6/8] ACPI: bus: Rework the handling of \_SB._OSC platform features Rafael J. Wysocki
2025-12-23 11:25   ` Jonathan Cameron
2025-12-22 19:23 ` [PATCH v2.1 7/8] ACPI: bus: Adjust feature mask creation for \_SB._OSC Rafael J. Wysocki
2025-12-23 11:26   ` Jonathan Cameron
2025-12-22 19:26 ` [PATCH v2.1 8/8] ACPI: bus: Rework the handling of \_SB._OSC USB4 features 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=20251223111331.000054da@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.