On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle [off-list ref] wrote:

On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote:

quoted

+void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+{
+     struct freq_update_hook *hook;
+
+#ifdef CONFIG_LOCKDEP
+     WARN_ON(debug_locks && !rcu_read_lock_sched_held());
+#endif
+
+     hook = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_freq_update_hook));
+     /*
+      * If this isn't inside of an RCU-sched read-side critical section, hook
+      * may become NULL after the check below.
+      */
+     if (hook) {
+             if (hook->update_util)
+                     hook->update_util(hook, time, util, max);
+             else
+                     hook->func(hook, time);
+     }

Is it worth having two hook types?

Well, that's why I said "maybe over the top" in the changelog comments. :-)

If we want to isolate the "old" governors from util/max entirely, then yes.

If we don't care that much, then no.

I'm open to both possibilities.

Thanks,
Rafael