[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e8100b0-d87c-413e-bcb1-b91c3ce41633@gmx.de>
Date: Wed, 13 Mar 2024 23:28:55 +0100
From: Armin Wolf <W_Armin@....de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: lenb@...nel.org, linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] ACPI: bus: _OSC fixes
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.
Thanks,
Armin Wolf
Powered by blists - more mailing lists