On Fri, Jul 22, 2016 at 02:18:54AM +0200, Rafael J. Wysocki wrote:
My thinking was that one of these two would be preferable:
- Forcing ->target() drivers to install a ->resolve_freq callback, enforcing this at cpufreq driver init time.
That would have been possible, but your series didn't do that.
My understanding is ->target() drivers are deprecated anyway
No, they aren't.
Ok. I didn't follow Documentation/cpu-freq/cpu-drivers.txt section 1.5 then - it suggests something about target() is deprecated, perhaps it's out of date.
There simply are cases in which frequency tables are not workable (like the ACPI CPPC one).
Sure that makes sense.
and theren't aren't many of them, though I don't know offhand exactly how many or how hard it would be to do for each one.
- Forcing callers (schedutil in this case) to check that either ->target() or ->resolve_freq() is implemented. It means catching and scrutinizing future callers of resolve_freq.
But that doesn't reduce the number of checks in cpufreq_driver_resolve_freq().
There still are three choices in there: return a frequency from the table (if present), or call ->resolve_freq (if implemented), or return target_freq (as the last resort).
Sorry, that should've been "check that either ->target_index() or ->resolve_freq() is implemented."
Implementing resolve_freq for the target() drivers and requiring it at driver init time is probably the better way to go though. Perhaps I can work on this at some point.