Subject: Re: [PATCH] cpufreq: Add user_min/max_freq

From: Matthias Kaehlcke <[email-masked]>
Date: Thu, 31 Oct 2019 15:23:56 -0700

On Thu, Oct 31, 2019 at 11:24:31AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, October 30, 2019 1:41:49 AM CET Leonard Crestez wrote:
> > Current values in scaling_min_freq and scaling_max freq can change on
> > the fly due to event such as thermal monitoring.
> 
> Which is intentional.
> 
> > This behavior is confusing for userspace and because once an userspace
> > limit is written to scaling_min/max_freq it is not possible to read it back.
> 
> That can be argued both ways.
> 
> It is also useful to know the effective constraints and arguably the ability
> to read back the values that you have written is mostly needed for debugging
> the code.

Agreed that reading the values back is probably mostly useful for debugging.

Reading the effective constraints is a debugging use case as well, userspace
can't make any decisions based on values which might be in constant flux.

IMO the current interface is completely counterintuitive, I really hope we
wouldn't implement it the same way if given a chance to do it again. If there
is use for reading the effective constraints it should be exposed as a separate
read-only attribute. Keep it simple (when possible).

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel