On 21-07-16, 16:21, Steve Muckle wrote: > On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote: > > Okay, but in that case shouldn't we do something like this: > > > > unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy, > > unsigned int target_freq) > > { > > target_freq = clamp_val(target_freq, policy->min, policy->max); > > policy->cached_target_freq = target_freq; > > > > if (cpufreq_driver->target_index) { > > policy->cached_resolved_idx = > > cpufreq_frequency_table_target(policy, > > target_freq, > > > > CPUFREQ_RELATION_L); > > return > > policy->freq_table[policy->cached_resolved_idx].frequency; > > } > > > > if (cpufreq_driver->resolve_freq) > > return cpufreq_driver->resolve_freq(policy, target_freq); > > } > > Thanks for the review. > > My thinking (noted in the commit text) was that the caller of > cpufreq_driver_resolve_freq() would verify that the driver supported the > proper calls before using this API.
Okay, but the caller isn't doing that today. Right? > This way it can be checked once, > presumably in a governor's init routine. Checking the pointer over and > over again in a fast path is wasteful. But we just can not assume the callers to always check that the driver has a ->target() and no ->resolve_freq(), and in that case not to call this routine. We would be forced to add a WARN_ON() in that case here to make sure we aren't trying to access a NULL ->resolve_freq. Over that, it will be used for a very small number of drivers which still use the ->target() callback and anyway we are going to do a function call for them. We can add a likely() here if that helps, but some sort of checking is surely required IMO. And, this is a core API, which can be used for other governor's tomorrow :) -- viresh