https://bugzilla.kernel.org/show_bug.cgi?id=60839 Sven Köhler <sven.koehler@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #2 from Sven Köhler <sven.koehler@xxxxxxxxx> --- (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.-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
