Re: [PATCH 0/3] ACPI: thermal: Properly support the _SCP control method

[Armin Wolf <W_Armin@gmx.de>]

Am 28.04.25 um 14:34 schrieb Rafael J. Wysocki:

> On Mon, Apr 28, 2025 at 2:31 PM Armin Wolf <W_Armin@gmx.de> wrote:
>> Am 27.04.25 um 00:52 schrieb Armin Wolf:
>>
>>> Am 26.04.25 um 15:12 schrieb Rafael J. Wysocki:
>>>
>>>> On Sat, Apr 26, 2025 at 1:20 AM Armin Wolf <W_Armin@gmx.de> wrote:
>>>>> Am 10.04.25 um 18:54 schrieb Armin Wolf:
>>>>>
>>>>>> The ACPI specification defines an interface for the operating system
>>>>>> to change the preferred cooling mode of a given ACPI thermal zone.
>>>>>> This interface takes the form of a special ACPI control method called
>>>>>> _SCP (see section 11.4.13 for details) and is already supported by the
>>>>>> ACPI thermal driver.
>>>>>>
>>>>>> However this support as many issues:
>>>>>>
>>>>>>     - the kernel advertises support for the "3.0 _SCP Extensions"
>>>>>> yet the
>>>>>>       ACPI thermal driver does not support those extensions. This may
>>>>>>       confuse the ACPI firmware.
>>>>>>
>>>>>>     - the execution of the _SCP control method happens after the driver
>>>>>>       retrieved the trip point values. This conflicts with the ACPI
>>>>>>       specification:
>>>>>>
>>>>>>         "OSPM will automatically evaluate _ACx and _PSV objects after
>>>>>>          executing _SCP."
>>>>>>
>>>>>>     - the cooling mode is hardcoded to active cooling and cannot be
>>>>>>       changed by the user.
>>>>>>
>>>>>> Those issues are fixed in this patch series. In the end the user
>>>>>> will be able to tell the ACPI firmware wether he prefers active or
>>>>>> passive cooling. This setting will also be interesting for
>>>>>> applications like TLP (https://linrunner.de/tlp/index.html).
>>>>>>
>>>>>> The whole series was tested on various devices supporting the _SCP
>>>>>> control method and on a device without the _SCP control method and
>>>>>> appears to work flawlessly.
>>>>> Any updates on this? I can proof that the new interface for setting
>>>>> the cooling mode
>>>>> works. Additionally the first two patches fix two issues inside the
>>>>> underlying code
>>>>> itself, so having them inside the mainline tree would be beneficial
>>>>> to users.
>>>> Sure.
>>>>
>>>> I'm going to get to them next week, probably on Monday.
>>> Ok, thanks.
>>>
>>> Armin Wolf
>>>
>> I am a bit ashamed of myself but i think we need to put this patch series on hold after all :(.
>>
>> The reason of this is that i am confused by the ACPI specification regarding _SCP:
>>
>>          11.1.2.1. OSPM Change of Cooling Policy
>>
>>          When OSPM changes the platform’s cooling policy from one cooling mode to the other, the following occurs:
>>
>>          1. OSPM notifies the platform of the new cooling mode by running the Set Cooling Policy (_SCP) control method in all thermal zones and invoking the OS-specific Set Cooling Policy interface to all participating devices in each thermal zone.
>>
>>          2. Thresholds are updated in the hardware and OSPM is notified of the change.
>>
>>          3. OSPM re-evaluates the active and passive cooling temperature trip points for the zone and all devices in the zone to obtain the new temperature thresholds.
>>
>> This section of the ACPI specification tells me that we need to evaluate the _SCP control method of all ACPI thermal zones
>> at the same time, yet section 11.4.13. tells me that each _SCP control methods belongs to the individual thermal zone.
>>
>> The reason why i am concerned by this is because Windows adheres to section 11.1.2.1. and only exposes this setting
>> as a global tunable. This might cause device manufacturers to depend on this behavior and lead to strange things
>> should two thermal zones have different _SCP settings.
>>
>> I will ask the UEFI mailing list which behavior is expected by the ACPI specification. Until then i suggest that
>> we put this patch series on hold.
> Sure, no problem.
>
> Please resend it when you think it is good to go.
>
> Thanks!

Alright, the UEFI mailing list gave no response, so i am kind of stuck.

It seems that many firmware implementation only have a single cooling policy register which is set by all _SCP control methods inside the whole system.
The reason for this seems to be that Windows threats this setting as global, but the ACPI specification seemingly does not directly mandate this.

Do you thing we should take the risk and allow users to control each _SCP instance manually?

Apart from that the first two patches should be safe, so you can still pick them. Only the last patch needs some more work.

Thanks,
Armin Wolf