Re: [PATCH v2 8/9] thermal: of: Set THERMAL_TRIP_FLAG_RW_TEMP directly

[Rafael J. Wysocki]

On Thu, Feb 22, 2024 at 2:48 PM Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
>
> On 12/02/2024 19:40, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >
> > It is now possible to flag trip points with THERMAL_TRIP_FLAG_RW_TEMP
> > to allow their temperature to be set from user space via sysfs instead
> > of using a nonzero writable trips mask during thermal zone registration,
> > so make the OF thermal code do that.
> >
> > No intentional functional impact.
> >
> > Note that this change is requisite for dropping the mask argument from
> > thermal_zone_device_register_with_trips() going forward.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > ---
> >
> > v1 -> v2: Rename trip flag (Stanislaw).
> >
> > ---
> >   drivers/thermal/thermal_of.c |    8 ++++----
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > Index: linux-pm/drivers/thermal/thermal_of.c
> > ===================================================================
> > --- linux-pm.orig/drivers/thermal/thermal_of.c
> > +++ linux-pm/drivers/thermal/thermal_of.c
> > @@ -117,6 +117,8 @@ static int thermal_of_populate_trip(stru
> >               return ret;
> >       }
> >
> > +     trip->flags = THERMAL_TRIP_FLAG_RW_TEMP;
> > +
> >       return 0;
> >   }
>
> Even if you are not at the origin of this default behavior. I'm
> wondering if we should be more protective against changes from userspace
> when the firmware is telling us to protect the silicon at a specific
> temperature.
>
> What do you think if we set the THERMAL_TRIP_FLAG_RW_TEMP only if the
> trip point is not bound to a cooling device?
>
> So trip points without associated cooling device can be writable but
> others can be considered as managed by the kernel and no modifiable.

This sounds reasonable to me.

This is mostly relevant to thermal_of anyway, because the other
drivers asking for writable trip temperature seem to want it
regardless.

> (This comment does not put in question this patch BTW)

OK