On 11-07-19, 16:58, Janakarajan Natarajan wrote:
> On 7/11/2019 1:12 AM, Viresh Kumar wrote:
> > On 10-07-19, 18:37, Natarajan, Janakarajan wrote:
> >> +static int amd_cpufreq_cpu_init(struct cpufreq_policy *policy)
> >> +{
> >> + return 0;
> >> +}
> >> +
> >> +static int amd_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> >> +{
> >> + return 0;
> >> +}
> >> +
> >> +static int amd_cpufreq_cpu_verify(struct cpufreq_policy *policy)
> >> +{
> >> + return 0;
> >> +}
> >> +
> >> +static int amd_cpufreq_cpu_target_index(struct cpufreq_policy *policy,
> >> + unsigned int index)
> >> +{
> >> + return 0;
> >> +}
> > All empty helpers ? There is nothing you need to do ?
>
>
> When we posted v2 of this patchset, Rafael let us know that he was
> uncomfortable
>
> going behind the (acpi-cpufreq) drivers back by letting the user
> communicate directly
>
> with the platform. That's the reason we have an empty driver whose
> primary purpose
>
> is to expose sysfs entries for the user.
I read his comments now and what he suggested is:
"What about handling this like the others do, through a proper cpufreq
driver?"
I am not sure if he meant something like that you have here. Only one
cpufreq driver can be registered at any point of time with the kernel,
and so if this one is there then acpi-cpufreq or intel-pstate can't be
there. Who will do DVFS ?
--
viresh
