Thermal driver with safeguards

Thermal driver with safeguards

[Werner Sembach]

Hi,

given a pair of a temperature sensor and a fan, I want to implement a driver. 
that allows userspace to directly control the fan if it wants to. But have a 
minimum fan speed when certain high temperatures are reached to avoid crashes or 
hardware damage.

e.g.

- temperature of target die is 80°C -> fan speed must be at least 30%

- temperature of target die is 90°C -> fan speed must be at least 40%

- temperature of target die is 105°C -> fan speed must be 100%

- temperature of target die is 110°C -> device shuts off to protect the hardware

Would the thermal subsystem be the right place for this to implement this 
protection in driver?

It already has functions around periodic temperature polling and trip points.

Kind regards,

Werner Sembach

Re: Thermal driver with safeguards

[Werner Sembach]

Hi Rafael,

Am 02.12.24 um 15:52 schrieb Werner Sembach:
> Hi,
>
> given a pair of a temperature sensor and a fan, I want to implement a driver. 
> that allows userspace to directly control the fan if it wants to. But have a 
> minimum fan speed when certain high temperatures are reached to avoid crashes 
> or hardware damage.
>
> e.g.
>
> - temperature of target die is 80°C -> fan speed must be at least 30%
>
> - temperature of target die is 90°C -> fan speed must be at least 40%
>
> - temperature of target die is 105°C -> fan speed must be 100%
>
> - temperature of target die is 110°C -> device shuts off to protect the hardware
>
> Would the thermal subsystem be the right place for this to implement this 
> protection in driver?
>
> It already has functions around periodic temperature polling and trip points.
>
> Kind regards,
>
> Werner Sembach
>
Sorry for bumping, just wanted to make sure that it doesn't get lost because of 
the holidays, as the question is still relevant for me for rewriting and 
upstreaming tuxedo-drivers.

Best regards,

Werner

Re: Thermal driver with safeguards

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

Hi!

> > given a pair of a temperature sensor and a fan, I want to implement a
> > driver. that allows userspace to directly control the fan if it wants
> > to. But have a minimum fan speed when certain high temperatures are
> > reached to avoid crashes or hardware damage.
> > 
> > e.g.
> > 
> > - temperature of target die is 80°C -> fan speed must be at least 30%
> > 
> > - temperature of target die is 90°C -> fan speed must be at least 40%
> > 
> > - temperature of target die is 105°C -> fan speed must be 100%
> > 
> > - temperature of target die is 110°C -> device shuts off to protect the hardware
> > 
> > Would the thermal subsystem be the right place for this to implement
> > this protection in driver?

Best place to implement this would be hardware... It should
self-protect.

Next best place is embedded controller.

Yes, kernel can probably do that, too, but then you risk running "hot"
when kernel panics, when someone boots 2.16 kernel, or DOS or ...

Best regards,

								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Thermal driver with safeguards

[Werner Sembach]

Hi,

Am 13.01.25 um 23:17 schrieb Pavel Machek:
> Hi!
>
>>> given a pair of a temperature sensor and a fan, I want to implement a
>>> driver. that allows userspace to directly control the fan if it wants
>>> to. But have a minimum fan speed when certain high temperatures are
>>> reached to avoid crashes or hardware damage.
>>>
>>> e.g.
>>>
>>> - temperature of target die is 80°C -> fan speed must be at least 30%
>>>
>>> - temperature of target die is 90°C -> fan speed must be at least 40%
>>>
>>> - temperature of target die is 105°C -> fan speed must be 100%
>>>
>>> - temperature of target die is 110°C -> device shuts off to protect the hardware
>>>
>>> Would the thermal subsystem be the right place for this to implement
>>> this protection in driver?
> Best place to implement this would be hardware... It should
> self-protect.
Don't know what you mean by this: The lowest level of logic that could handle 
something like this is the EC firmware.
>
> Next best place is embedded controller.

I agree, but I'm working on upstreaming a driver that is also for devices that 
are multiple years out of production. They will not get a firmware update.

Also for new devices the EC firmware is usually delivered as a binary blob by 
the mainboard ODMs.

So the lowest possible level of logic I as a developer can actually do something 
about this lack of protection is the kernel.

Please don't assume that we, as in TUXEDO Computers, do not try to talk to the 
ODMs about this and other problems we see with the EC firmware. We do. But 
matter of fact is, that all this does not help with devices out now. These need 
to be fixed in driver instead.

Best regards,

Werner Sembach

>
> Yes, kernel can probably do that, too, but then you risk running "hot"
> when kernel panics, when someone boots 2.16 kernel, or DOS or ...
>
> Best regards,
>
> 								Pavel

Re: Thermal driver with safeguards

[Daniel Lezcano]

On 02/12/2024 15:52, Werner Sembach wrote:
> Hi,
> 
> given a pair of a temperature sensor and a fan, I want to implement a 
> driver. that allows userspace to directly control the fan if it wants 
> to. But have a minimum fan speed when certain high temperatures are 
> reached to avoid crashes or hardware damage.

 From the userspace, use directly the thermal-engine which is currently 
under development [1]. You can add your platform specific code in a 
plugin while the thermal engine will catch all the thermal events and 
pass them to it [2].

The thermal engine has a configuration file which will setup the thermal 
framework to be woken up at different temperatures.

The thermal engine will be proposed for a distro package, so the 
platform support will be automatically supported.

Beside the trip points can be setup in the device to act on higher 
temperature.

What is unclear is how the fan is managed. I suggest to have a look at 
pwm-fan.c in drivers/hwmon

> e.g.
> 
> - temperature of target die is 80°C -> fan speed must be at least 30%
> 
> - temperature of target die is 90°C -> fan speed must be at least 40%
> 
> - temperature of target die is 105°C -> fan speed must be 100%
> 
> - temperature of target die is 110°C -> device shuts off to protect the 
> hardware
> 
> Would the thermal subsystem be the right place for this to implement 
> this protection in driver?
> 
> It already has functions around periodic temperature polling and trip 
> points.

[1] https://github.com/Linaro/libpm/tree/master
[2] 
https://github.com/Linaro/libpm/blob/master/thermal-engine/plugins/te-plugin-example-game.c


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal driver with safeguards

[Werner Sembach]

Hi Daniel,

Am 09.01.25 um 22:36 schrieb Daniel Lezcano:
> On 02/12/2024 15:52, Werner Sembach wrote:
>> Hi,
>>
>> given a pair of a temperature sensor and a fan, I want to implement a driver. 
>> that allows userspace to directly control the fan if it wants to. But have a 
>> minimum fan speed when certain high temperatures are reached to avoid crashes 
>> or hardware damage.
>
> From the userspace, use directly the thermal-engine which is currently under 
> development [1]. You can add your platform specific code in a plugin while the 
> thermal engine will catch all the thermal events and pass them to it [2].
>
> The thermal engine has a configuration file which will setup the thermal 
> framework to be woken up at different temperatures.
That still requires to trust userspace/the user to not write dangerous values 
directly to sysfs?
>
> The thermal engine will be proposed for a distro package, so the platform 
> support will be automatically supported.
>
> Beside the trip points can be setup in the device to act on higher temperature.
As far as i can tell these trip points only notify userspace but you can't 
attach code executed in kernel to it.
>
> What is unclear is how the fan is managed. I suggest to have a look at 
> pwm-fan.c in drivers/hwmon

I already looked at hwmon, but that basically just writes trough values from and 
to userspace and has no kernel side management of temperatures and fan speeds 
whatsoever.

Kind regards,

Werner

>
>> e.g.
>>
>> - temperature of target die is 80°C -> fan speed must be at least 30%
>>
>> - temperature of target die is 90°C -> fan speed must be at least 40%
>>
>> - temperature of target die is 105°C -> fan speed must be 100%
>>
>> - temperature of target die is 110°C -> device shuts off to protect the hardware
>>
>> Would the thermal subsystem be the right place for this to implement this 
>> protection in driver?
>>
>> It already has functions around periodic temperature polling and trip points.
>
> [1] https://github.com/Linaro/libpm/tree/master
> [2] 
> https://github.com/Linaro/libpm/blob/master/thermal-engine/plugins/te-plugin-example-game.c
>
>

Re: Thermal driver with safeguards

[Daniel Lezcano]

On 10/01/2025 17:56, Werner Sembach wrote:
> Hi Daniel,
> 
> Am 09.01.25 um 22:36 schrieb Daniel Lezcano:
>> On 02/12/2024 15:52, Werner Sembach wrote:
>>> Hi,
>>>
>>> given a pair of a temperature sensor and a fan, I want to implement a 
>>> driver. that allows userspace to directly control the fan if it wants 
>>> to. But have a minimum fan speed when certain high temperatures are 
>>> reached to avoid crashes or hardware damage.
>>
>> From the userspace, use directly the thermal-engine which is currently 
>> under development [1]. You can add your platform specific code in a 
>> plugin while the thermal engine will catch all the thermal events and 
>> pass them to it [2].
>>
>> The thermal engine has a configuration file which will setup the 
>> thermal framework to be woken up at different temperatures.
> That still requires to trust userspace/the user to not write dangerous 
> values directly to sysfs?

No, it is not a trip point but temperature thresholds. So if the 
firmware defines trip points, the userspace can not change them.

Userspace thresholds are new : https://lwn.net/Articles/986009/

>> The thermal engine will be proposed for a distro package, so the 
>> platform support will be automatically supported.
>>
>> Beside the trip points can be setup in the device to act on higher 
>> temperature.
> As far as i can tell these trip points only notify userspace but you 
> can't attach code executed in kernel to it.

[ ... ]

>> What is unclear is how the fan is managed. I suggest to have a look at 
>> pwm-fan.c in drivers/hwmon
> 
> I already looked at hwmon, but that basically just writes trough values 
> from and to userspace and has no kernel side management of temperatures 
> and fan speeds whatsoever.

IIUC, you request was about having the userspace to deal with a fan and 
the kernel to be a safe guard, so taking over the thermal management 
when the temperature is too high.

Obviously the monitored temperature must be for a device with a "slow" 
temperature motion, userspace temperature management is not suitable for 
fast temperature transitions.

The thermal engine can for example configure different temperatures, 
let's say: 43°C, 44°C, 46°C, 49°C and 54°C.

Then the DT describes additional trip points for mitigation, one trip 
point for mitigation could be enough (eg 80°C). One for "hot" to send to 
the thermal engine a notification about getting really high so it can do 
some userspace action like killing an application, and finally a 
"critical" trip point to shutdown the system.

The fan would be a cooling device with 0-100 values representing the 
speed in percentage. The trip point at 80°C would be associated with the 
fan with the <0, 100> cooling states.

The dynamic of the thermal management could be the following:

The temperature is changing and stays in the [35°C - 60°C] boundaries. 
The thermal engine receives the events at the different aforementioned 
temperatures and manage to act on the pwm fan via hwmon.

For any reason the temperature goes above 80°C, at this moment the 
kernel takes over the management and will increase/decrease the fan 
speed between the 0% - 100% limits until the temperature goes below the 
80°C.

If it continues to increase and reaches the "hot" trip point, then an 
events is sent to the userspace which should take an action to reduce 
the temperature (kill the application, reduce the battery charge, drop 
the frame rates, etc ...).

If it continues to increase and reaches the "critical" trip point, then 
the system shuts down.

If the temperature decreases and goes below 80°C, then it returns to the 
normal state and the thermal engine can continue its work.

Does it make sense ?


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal driver with safeguards

[Werner Sembach]

Am 10.01.25 um 18:43 schrieb Daniel Lezcano:
> On 10/01/2025 17:56, Werner Sembach wrote:
>> Hi Daniel,
>>
>> Am 09.01.25 um 22:36 schrieb Daniel Lezcano:
>>> On 02/12/2024 15:52, Werner Sembach wrote:
>>>> Hi,
>>>>
>>>> given a pair of a temperature sensor and a fan, I want to implement a 
>>>> driver. that allows userspace to directly control the fan if it wants to. 
>>>> But have a minimum fan speed when certain high temperatures are reached to 
>>>> avoid crashes or hardware damage.
>>>
>>> From the userspace, use directly the thermal-engine which is currently under 
>>> development [1]. You can add your platform specific code in a plugin while 
>>> the thermal engine will catch all the thermal events and pass them to it [2].
>>>
>>> The thermal engine has a configuration file which will setup the thermal 
>>> framework to be woken up at different temperatures.
>> That still requires to trust userspace/the user to not write dangerous values 
>> directly to sysfs?
>
> No, it is not a trip point but temperature thresholds. So if the firmware 
> defines trip points, the userspace can not change them.
>
> Userspace thresholds are new : https://lwn.net/Articles/986009/
>
>>> The thermal engine will be proposed for a distro package, so the platform 
>>> support will be automatically supported.
>>>
>>> Beside the trip points can be setup in the device to act on higher temperature.
>> As far as i can tell these trip points only notify userspace but you can't 
>> attach code executed in kernel to it.
>
> [ ... ]
>
>>> What is unclear is how the fan is managed. I suggest to have a look at 
>>> pwm-fan.c in drivers/hwmon
>>
>> I already looked at hwmon, but that basically just writes trough values from 
>> and to userspace and has no kernel side management of temperatures and fan 
>> speeds whatsoever.
>
> IIUC, you request was about having the userspace to deal with a fan and the 
> kernel to be a safe guard, so taking over the thermal management when the 
> temperature is too high.
Not completely taking over, just enforcing a min speed.
>
> Obviously the monitored temperature must be for a device with a "slow" 
> temperature motion, userspace temperature management is not suitable for fast 
> temperature transitions.
>
> The thermal engine can for example configure different temperatures, let's 
> say: 43°C, 44°C, 46°C, 49°C and 54°C.
>
> Then the DT describes additional trip points for mitigation, one trip point 
> for mitigation could be enough (eg 80°C). One for "hot" to send to the thermal 
> engine a notification about getting really high so it can do some userspace 
> action like killing an application, and finally a "critical" trip point to 
> shutdown the system.
I guess with DT you mean device table. I deal with a driver for x86 notebooks so 
there is not DT.
>
> The fan would be a cooling device with 0-100 values representing the speed in 
> percentage. The trip point at 80°C would be associated with the fan with the 
> <0, 100> cooling states.
>
> The dynamic of the thermal management could be the following:
>
> The temperature is changing and stays in the [35°C - 60°C] boundaries. The 
> thermal engine receives the events at the different aforementioned 
> temperatures and manage to act on the pwm fan via hwmon.
>
> For any reason the temperature goes above 80°C, at this moment the kernel 
> takes over the management and will increase/decrease the fan speed between the 
> 0% - 100% limits until the temperature goes below the 80°C.
>
> If it continues to increase and reaches the "hot" trip point, then an events 
> is sent to the userspace which should take an action to reduce the temperature 
> (kill the application, reduce the battery charge, drop the frame rates, etc ...).
>
> If it continues to increase and reaches the "critical" trip point, then the 
> system shuts down.
>
> If the temperature decreases and goes below 80°C, then it returns to the 
> normal state and the thermal engine can continue its work.
>
> Does it make sense ?
>
>