Re: [RFC PATCH] platform/arm64: lenovo-thinkpad-t14s: Adjust thermal trip with platform profile

[Hans de Goede <hansg@kernel.org>]

Hi,

On 14-Oct-26 12:19, Ilpo Järvinen wrote:
> + more people.
> 
> On Thu, 1 Oct 2026, Daniel Lezcano wrote:
> 
>> Tie the keyboard thermal mitigation temperature to the platform profile
>> selected through the ThinkPad embedded controller.
>>
>> The EC reports Fn+L, Fn+M and Fn+H events corresponding to low-power,
>> balanced and performance operating modes. Use these events to update the
>> passive trip point of the "keyboard-thermal" zone to 49.85°C, 57.85°C
>> and 59.85°C respectively.
>>
>> These thresholds match the thermal mitigation temperatures used by the
>> platform for the corresponding operating profiles.
>>
>> Look up the keyboard thermal zone at probe time and locate the passive
>> trip named "keyboard-ec-alert". The trip name is used deliberately so
>> the EC driver can identify the device-tree trip associated with the
>> platform thermal profile without depending on its position in the trip
>> table.
>>
>> Initialize the thermal mitigation threshold to the balanced profile,
>> matching the default platform behaviour, and update the thermal zone
>> whenever a profile change event is reported by the EC so that the new
>> mitigation temperature takes effect immediately.
>>
>> Using the platform_profile API would provide a more appropriate interface
>> for exposing and managing these operating modes. However, while the API
>> itself is generic, the platform profile core implementation currently
>> lives under the ACPI framework. Making it available to device-tree based
>> platforms requires separating the generic infrastructure from ACPI,
>> which is a larger and independent piece of work.
> 
> So the only problem is that platform profile resides underneath acpi 
> namespace in sysfs?

That and that the module_init() for the shared platform-profile code has:

        if (acpi_disabled)
                return -EOPNOTSUPP;

I gave a talk about DT-ACPI hybrid mode for these laptops at plumbers:

https://lpc.events/event/20/contributions/2363/

The conclusions there where that:

1. DT-ACPI hybrid mode is interesting as an experiment and for reverse
engineering but not something we necessarily want in mainline.

2. We do however want to at least load the ACPI tables and make them
available under /sys/firmware/acpi/tables/ so that acpidump will work,
which is useful for improving the DT descriptions.

I believe there is consensus we want to do 2. Which means creating
/sys/firmware/acpi at which point we could just keep 

/sys/firmware/acpi/platform_profile[_choices]

there.

In hindsight it would have been better to have a firmware-type
agnostic place for this.

The question then becomes do we want to move this to
a firmware-type agnostic place with maybe a compat symlink,
or do we keep this as is ?

As mentioned I do expect we will get /sys/firmware/acpi/ on
these laptops even when booted in DT mode even if it is just
to expose the tables.

This means that we could keep things as is and future generation
Snapdragon SoCs for laptops are expected to eventually fully move
to ACPI.

Other ARM64 and Risc-V / Loongson laptops all seem to standardize
on ACPI.

So I think that just keeping this as /sys/firmware/acpi/platform_profile
is ok and we (I) need to move forward with always loading + sysfs
exporting the tables which will allow us to expose
/sys/firmware/acpi/platform_profile even when booted in DT mode.

I realize this will be a bit weird path to use in DT mode, but
it should work fine and these really are ACPI laptops booted in DT
mode, so I think this is fine.

Regards,

Hans