Re: [PATCH 2/2] thermal/core: Make deprecated cooling device state change from userspace

From: Rafael J. Wysocki
Date: Tue Oct 19 2021 - 09:36:30 EST


On Tue, Oct 19, 2021 at 3:22 PM Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
>
> The cooling devices have their cooling device set_cur_state
> read-writable all the time in the sysfs directory, thus allowing the
> userspace to act on it.
>
> The thermal framework is wrongly used by userspace as a power capping
> framework by acting on the cooling device opaque state. This one then
> competes with the in-kernel governor decision.
>
> We have seen in out-of-tree kernels, a big number of devices which are
> abusely declaring themselves as cooling device just to act on their
> power.
>
> The role of the thermal framework is to protect the junction
> temperature of the silicon.

It's more than that. You also don't want to let the system's skin
temperature get too high, for example.

I would just say that the role of the thermal framework is thermal control.

> Letting the userspace to play with a
> cooling device is wrong and potentially dangerous.

Agreed, although I would say "invalid" instead of "wrong".

> The powercap framework is the right framework to do power capping and
> moreover it deals with the aggregation via the dev pm qos.
>
> As the userspace governor is marked deprecated and about to be
> removed, there is no point to keep this file writable also in the
> future.
>
> Emit a warning and deprecate the interface.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
> ---
> drivers/thermal/thermal_sysfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index 1c4aac8464a7..3f4ea3a283ae 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -610,6 +610,8 @@ cur_state_store(struct device *dev, struct device_attribute *attr,
> unsigned long state;
> int result;
>
> + WARN_ON_ONCE(1, "Setting cooling device state is deprecated\n");
> +

I would use pr_warn_once() instead.

> if (sscanf(buf, "%ld\n", &state) != 1)
> return -EINVAL;
>
> --