On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle <steve.muckle@xxxxxxxxxx> wrote:
> On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote:
>> +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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
