Re: [PATCH] cpufreq: Add user_min/max_freq

[Matthias Kaehlcke <mka@chromium.org>]

On Wed, Oct 30, 2019 at 02:41:49AM +0200, 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. 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.

Yes, this is indeed confusing.

> Introduce two new user_min/max_freq files which only contain the limits
> imposed by userspace, without any aggregation.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> ---
> This was motivated by these discussions:
> 
> * https://patchwork.kernel.org/patch/11078475/#22805379
> * https://patchwork.kernel.org/patch/11171817/#22917099
> 
> Those threads are about devfreq but same issue applies to cpufreq as
> well. Let me know if this solution seems reasonable?
> 
> An alternative would be to make scaling_min/max_freq always read back
> the configured value and introduce new effective_min/max_freq files for
> the aggregate values. That might break existing users (though I'm not
> familiar with any).

It seems there isn't really a perfect solution :(

This change creates a set of new, consistent attributes, but since we
can't make the current min/max attributes read-only userspace will keep
using them forever.

It's somewhat doubtful that userspace can do anything useful with the
current min/max values, since they might change just after being read.
Anything besides monitoring the limits (approximately) would be inherently
broken.

Having min/max return the configured value would be the expected behavior
(IMO), but obviously I also don't know for sure if there are userspace
components relying on the current behavior.