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(-)
--
2.39.2
The ACPI thermal driver already uses the _TPF ACPI method to retrieve
precise sampling time values, but this is not reported thru _OSC.
Fix this by setting bit 9 ("Fast Thermal Sampling support") when
evaluating _OSC.
Fixes: a2ee7581afd5 ("ACPI: thermal: Add Thermal fast Sampling Period (_TFP) support")
Signed-off-by: Armin Wolf <[email protected]>
---
drivers/acpi/bus.c | 2 ++
include/linux/acpi.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index d9fa730416f1..9c13a4e43fa8 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -316,6 +316,8 @@ static void acpi_bus_osc_negotiate_platform_control(void)
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PAD_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_PROCESSOR))
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PPC_OST_SUPPORT;
+ if (IS_ENABLED(CONFIG_ACPI_THERMAL))
+ capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_FAST_THERMAL_SAMPLING_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_OST_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index a170c389dd74..7727ebbc4219 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -573,6 +573,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
#define OSC_SB_CPCV2_SUPPORT 0x00000040
#define OSC_SB_PCLPI_SUPPORT 0x00000080
#define OSC_SB_OSLPI_SUPPORT 0x00000100
+#define OSC_SB_FAST_THERMAL_SAMPLING_SUPPORT 0x00000200
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000
#define OSC_SB_CPC_FLEXIBLE_ADR_SPACE 0x00004000
--
2.39.2
The code responsible for parsing the available p-states should
have no problems handling more than 16 p-states.
Indicate this by setting bit 10 ("Greater Than 16 p-state support")
when evaluating _OSC.
Signed-off-by: Armin Wolf <[email protected]>
---
drivers/acpi/bus.c | 1 +
include/linux/acpi.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9c13a4e43fa8..d5b0e80dc48e 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -321,6 +321,7 @@ static void acpi_bus_osc_negotiate_platform_control(void)
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_OST_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT;
+ capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_OVER_16_PSTATES_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_PRMT))
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PRM_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_FFH))
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 7727ebbc4219..baa07b5a717f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -574,6 +574,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
#define OSC_SB_PCLPI_SUPPORT 0x00000080
#define OSC_SB_OSLPI_SUPPORT 0x00000100
#define OSC_SB_FAST_THERMAL_SAMPLING_SUPPORT 0x00000200
+#define OSC_SB_OVER_16_PSTATES_SUPPORT 0x00000400
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000
#define OSC_SB_CPC_FLEXIBLE_ADR_SPACE 0x00004000
--
2.39.2
A device driver for the Generic Event Device (ACPI0013) already
exists for quite some time, but support for it was never reported
thru _OSC.
Fix this by setting bit 11 ("Generic Event Device support") when
evaluating _OSC.
Fixes: 3db80c230da1 ("ACPI: implement Generic Event Device")
Signed-off-by: Armin Wolf <[email protected]>
---
drivers/acpi/bus.c | 1 +
include/linux/acpi.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index d5b0e80dc48e..0c48b603098a 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -322,6 +322,7 @@ static void acpi_bus_osc_negotiate_platform_control(void)
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_OST_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_OVER_16_PSTATES_SUPPORT;
+ capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_GED_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_PRMT))
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PRM_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_FFH))
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index baa07b5a717f..aa26259a28b8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -575,6 +575,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
#define OSC_SB_OSLPI_SUPPORT 0x00000100
#define OSC_SB_FAST_THERMAL_SAMPLING_SUPPORT 0x00000200
#define OSC_SB_OVER_16_PSTATES_SUPPORT 0x00000400
+#define OSC_SB_GED_SUPPORT 0x00000800
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000
#define OSC_SB_CPC_FLEXIBLE_ADR_SPACE 0x00004000
--
2.39.2
The ACPI spec says bit 17 should be used to indicate support
for Generic Initiator Affinity Structure in SRAT, but we currently
set bit 13 ("Interrupt ResourceSource support").
Fix this by actually setting bit 17 when evaluating _OSC.
Fixes: 01aabca2fd54 ("ACPI: Let ACPI know we support Generic Initiator Affinity Structures")
Signed-off-by: Armin Wolf <[email protected]>
---
include/linux/acpi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index aa26259a28b8..b99c83968a9d 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -577,8 +577,8 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
#define OSC_SB_OVER_16_PSTATES_SUPPORT 0x00000400
#define OSC_SB_GED_SUPPORT 0x00000800
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
-#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000
#define OSC_SB_CPC_FLEXIBLE_ADR_SPACE 0x00004000
+#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00020000
#define OSC_SB_NATIVE_USB4_SUPPORT 0x00040000
#define OSC_SB_PRM_SUPPORT 0x00200000
#define OSC_SB_FFH_OPR_SUPPORT 0x00400000
--
2.39.2
The ACPI IRQ mapping code supports parsing of ResourceSource,
but this is not reported thru _OSC.
Fix this by setting bit 13 ("Interrupt ResourceSource support")
when evaluating _OSC.
Fixes: d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
Signed-off-by: Armin Wolf <[email protected]>
---
drivers/acpi/bus.c | 1 +
include/linux/acpi.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 0c48b603098a..a87b10eef77d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -323,6 +323,7 @@ static void acpi_bus_osc_negotiate_platform_control(void)
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PCLPI_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_OVER_16_PSTATES_SUPPORT;
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_GED_SUPPORT;
+ capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_IRQ_RESOURCE_SOURCE_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_PRMT))
capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_PRM_SUPPORT;
if (IS_ENABLED(CONFIG_ACPI_FFH))
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b99c83968a9d..d62be29cf7a6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -577,6 +577,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
#define OSC_SB_OVER_16_PSTATES_SUPPORT 0x00000400
#define OSC_SB_GED_SUPPORT 0x00000800
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
+#define OSC_SB_IRQ_RESOURCE_SOURCE_SUPPORT 0x00002000
#define OSC_SB_CPC_FLEXIBLE_ADR_SPACE 0x00004000
#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00020000
#define OSC_SB_NATIVE_USB4_SUPPORT 0x00040000
--
2.39.2
On Sat, Mar 9, 2024 at 9:13 PM Armin Wolf <[email protected]> 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!
Am 12.03.24 um 21:10 schrieb Rafael J. Wysocki:
> On Sat, Mar 9, 2024 at 9:13 PM Armin Wolf <[email protected]> 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
On Wed, Mar 13, 2024 at 11:29 PM Armin Wolf <[email protected]> wrote:
>
> Am 12.03.24 um 21:10 schrieb Rafael J. Wysocki:
>
> > On Sat, Mar 9, 2024 at 9:13 PM Armin Wolf <[email protected]> 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!