Messages in this thread | | | Date | Sun, 23 Jul 2023 16:05:24 +0100 | From | Mark Brown <> | Subject | Re: [PATCH RESEND RESEND] thermal/of: support thermal zones w/o trips subnode |
| |
On Sun, Jul 23, 2023 at 12:12:49PM +0200, Daniel Lezcano wrote: > On 22/07/2023 22:11, Mark Brown wrote:
> > This makes sense to me - it allows people to see the reported > > temperature even if there's no trips defined which seems more > > helpful than refusing to register.
...
> If the goal is to report the temperature only, then hwmon should be used > instead.
Sure, that doesn't seem to be the case in the impacted systems though - AFAICT the issue with these is that it's a generic SoC DT that's not fully fleshed out, either because more data is needed for the silicon or because the numbers need to be system specific for some reason.
> If the goal is to mitigate by userspace, then the trip point *must* be used > to prevent the userspace polling the temperature. With the trip point the > sensor will be set to fire an interrupt at the given trip temperature.
I'm not clear a trip point prevent userspace polling if it feels so moved? Is it just that it makes it more likely that someone will implement something that polls?
> IOW, trip points are not optional
I can see printing a loud warning given that the system is not fully configured (there's a warning already, I did nearly comment on this patch downgrading it all the way to a debug log), perhaps even suppressing the registraton of the userspace interface, but returning a failure to the registering driver feels like it's escalating the problem and complicating the driver code. Suppressing the registration to userspace seemed like it was adding more complexity in the core but it would avoid any potential confusion for userspace.
For me the main issue is the impact on devices that support multiple thermal zones, in order to avoid having working zones stay registered their drivers will all have to handle the possibility of some of the zones failing to register due to missing configuration which is going to add complexity both at both registration and runtime and be easy to miss. If the core just accepts the zones then whatever complexity there is gets factored out into the core. [unhandled content-type:application/pgp-signature] | |