[Bug 60839] scaling_max_freq cannot be set to values larger than bios_limit

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60839

Sven Köhler <sven.koehler@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #2 from Sven Köhler <sven.koehler@gmail.com> ---
(In reply to Lan Tianyu from comment #1)
> Hi:
>      This sounds like a user space issue. Bios limit will rise after
> plugging/unplugging AC and laptop-mode-tools also should update
> scaling_max_freq. Cpufreq core schedules freq scope according user space
> configuration. If user space tool doesn't extend the scope according bios
> limit after plugging/unplugging AC, the scope will keep low cpufreq.

First of all, does the kernel provide any hook to run a script every time
bios_limit changes or do you expect userspace to do polling?

Second, you can't be serious that the sysfs interface should remain as
inconsistent as it is now. Clearly, the internal state of scaling_max_freq and
bios_limit can be one, where scaling_max_freq is larger than bios_limit. This
is very clear since I observed that (unless userspace tries to change
scaling_max_freq) the value of scaling_max_freq will increase as bios_limit
increases. At time when bios_limit is low, userspace cannot even find out about
the true state of scaling_max_freq (which is larger than bios_limit) as the
value obtainable via sysfs is always clipped. Obviously, knowing that such a
state exists, it is dubious why it can't be configured.

Thirdly, I'd really like know the rational behind the decision to that 
a) userspace should never be able to observe, that scaling_max_freq is actually
kernel internally larger than bios_limit 
b) userspace should never be able to set scaling_max_freq to a value larger
than bios_limit

IMHO, both (a) and (b) are wrong, in the sense that there is no good reason in
favour of (a) and (b) and many reasons against (a) and (b). A very strong
reason against (a) is the very simple fact that userspace cannot tell whether
the current maximum CPU frequency is limited by the BIOS or the value of
scaling_max_freq.

-- 
You are receiving this mail because:
You are the assignee for the bug.