Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Linux ACPI <linux-acpi@vger.kernel.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
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>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: [PATCH v2.1 0/8] ACPI: bus: Rework of the \_SB._OSC handling
Date: Mon, 22 Dec 2025 19:58:23 +0100	[thread overview]
Message-ID: <2413407.ElGaqSPkdT@rafael.j.wysocki> (raw)

Hi All,

This is an update of

https://lore.kernel.org/linux-acpi/5049211.GXAFRqVoOG@rafael.j.wysocki/

and the version is 2.1 because I've already posted a v2 of the first patch:

https://lore.kernel.org/linux-acpi/5967663.DvuYhMxLoT@rafael.j.wysocki/

which is updated again (in a minor way) is this series.

The original motivation was to make the _OSC evaluation more robust against
platform firmware deficiencies related to setting error bits in _OSC return
buffers by mistake (which apparently don't affect alternative OSes), but
since it can be argued that the current implementation of acpi_run_osc()
does not follow the specification exactly (see the changelog of patch
[1/8] for details), this is now more in the fixes territory.  However,
all of the patches except for the [1/8] can be regarded as cleanups and
optimizations.

The essential changes takes place in patch [1/8] this time.  It fixes
the error handling in acpi_run_osc() to remove inconsistencies from it
and follow the _OSC definition more closely, which also addresses the
"robustness" issue as kind of a side effect.

The second one reworks the printing of debug messages from acpi_run_osc()
for clarity, like in v1.  Patch [3/8] splits the _OSC evaluation code out
of acpi_run_osc() (so it can be used in other functions), and patch [4/8]
splits the handling of _OSC error bits out of it (for the same purpose).
Patch [5/8] is just a by-the-way simple cleanup.

Patch [6/8] introduces a new helper function for handling _OSC handshakes
in a generic way that should allow some code duplication and unnecessary
overhead to be avoided going forward and makes the \_SB._OSC platform
features handling code use it.

Patch [7/8] is a cleanup on top of the previous one, and patch [8/8]
updates the USB4 \_SB._OSC features handling to use the new function
introduced in patch [6/8].

Thanks!




             reply	other threads:[~2025-12-22 19:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-22 18:58 Rafael J. Wysocki [this message]
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
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=2413407.ElGaqSPkdT@rafael.j.wysocki \
    --to=rafael@kernel.org \
    --cc=hansg@kernel.org \
    --cc=helgaas@kernel.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --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