[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0idAkoiuXgfGYX-a9ZoNeWxw8CjOnTKCU-00BgcpCwisQ@mail.gmail.com>
Date: Wed, 27 Mar 2024 16:41:22 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Armin Wolf <W_Armin@....de>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] ACPI: bus: _OSC fixes
On Wed, Mar 13, 2024 at 11:29 PM Armin Wolf <W_Armin@....de> wrote:
>
> Am 12.03.24 um 21:10 schrieb Rafael J. Wysocki:
>
> > On Sat, Mar 9, 2024 at 9:13 PM Armin Wolf <W_Armin@....de> wrote:
> >> This patch series fixes the handling of various ACPI features bits
> >> when evaluating _OSC.
> >>
> >> The first three patches fix the reporting of various features supported
> >> by the kernel, while the fourth patch corrects the feature bit used to
> >> indicate support for the "Generic Initiator Affinity" in SRAT.
> >>
> >> The last patch fixes the reporting of IRQ ResourceSource support. Unlike
> >> the other feature bits, the ACPI specification states that this feature
> >> bit might be used by the ACPI firmware to indicate whether or not it
> >> supports the usage of IRQ ResourceSource:
> >>
> >> "If not set, the OS may choose to ignore the ResourceSource
> >> parameter in the extended interrupt descriptor."
> >>
> >> Since the code responsible for parsing IRQ ResourceSource already checks
> >> if ResourceSource is present, i assumed that we can omit taking this
> >> into account.
> >>
> >> All patches where tested on a Asus Prime B650-Plus and a Dell Inspiron
> >> 3505.
> >>
> >> Armin Wolf (5):
> >> ACPI: bus: Indicate support for _TFP thru _OSC
> >> ACPI: bus: Indicate support for more than 16 p-states thru _OSC
> >> ACPI: bus: Indicate support for the Generic Event Device thru _OSC
> >> ACPI: Fix Generic Initiator Affinity _OSC bit
> >> ACPI: bus: Indicate support for IRQ ResourceSource thru _OSC
> >>
> >> drivers/acpi/bus.c | 5 +++++
> >> include/linux/acpi.h | 6 +++++-
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> --
> > All of that looks reasonable to me, but do you know about systems in
> > the field where any of these patches actually fix functionality?
> >
> > If not, I'd prefer to queue them up for 6.10 as they are likely to
> > change behavior, at least in corner cases.
> >
> > Thanks!
>
> Hi,
>
> i know no system which even queries those feature bits, so i am fine with
> this landing in 6.10.
Now applied as 6.10 material, thanks!
Powered by blists - more mailing lists