On 10-09-15, 03:41, Rafael J. Wysocki wrote:
I see one. That unfortunately is the acpi-cpufreq driver, but it still is one.
Hmm..
Well, cpufreq_generic_get() does _get_raw(), so I suppose acpi-cpufreq may do that too?
Yeah, it can.
need to get the policy back and so do cpufreq_cpu_get(cpu) on the cpu passed as argument to ->get().
It would be better if we pass them 'policy' directly and drivers can use policy->cpu if that's all they need.
Passing a pointer and dereferencing it is generally less efficient than passing a number. Before the patch the core has to do the dereference before calling ->get, so it likely doesn't matter here, but the code churn from this change is quite substantial and the benefit from it is in the noise IMO.
Hmm.. Actually almost every other callback (bios_limit() is another one), passes the policy to the driver, and I thought always passing the policy will make it more symmetrical. And the expectation that the cpufreq drivers wouldn't need to use policy from the ->get() callback would be wrong. Even if there are only few users today. One is the acpi-cpufreq driver and others are the ones, that are using cpufreq_generic_get() :)
Overall, we need to talk about the design aspect of cpufreq, because there are much more significant issues in it than things like this one.
I agree.