2.5.64-bk[2-4]: CONFIG_CPU_FREQ_24_API breaks kernel/cpufreq.c compile

2.5.64-bk[2-4]: CONFIG_CPU_FREQ_24_API breaks kernel/cpufreq.c compile

[Adam J. Richter]

	linux-2.5.64-bk2 added the following lines to
cpufreq_add_dev in kernel/cpufreq.c:

#ifdef CONFIG_CPU_FREQ_24_API
        cpu_min_freq[cpu] = cpufreq_driver->policy[cpu].cpuinfo.min_freq;
        cpu_max_freq[cpu] = cpufreq_driver->policy[cpu].cpuinfo.max_freq;
        cpu_cur_freq[cpu] = cpufreq_driver->cpu_cur_freq[cpu];
#endif


	However, cpu_{min,max,cur}_freq are static variables in
drivers/cpufreq/userspace.c.  Making the variables global is not a
sufficient fix, because drivers/cpufreq/userspace.c can be built as
separate module.  So, I guess the variables should be moved to
kernel/cpufreq.c or the code that I quoted above should somehow be
moved.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: 2.5.64-bk[2-4]: CONFIG_CPU_FREQ_24_API breaks kernel/cpufreq.c compile

[Russell King]

On Sun, Mar 09, 2003 at 11:17:29AM -0800, Adam J. Richter wrote:
> 	linux-2.5.64-bk2 added the following lines to
> cpufreq_add_dev in kernel/cpufreq.c:
> 
> #ifdef CONFIG_CPU_FREQ_24_API
>         cpu_min_freq[cpu] = cpufreq_driver->policy[cpu].cpuinfo.min_freq;
>         cpu_max_freq[cpu] = cpufreq_driver->policy[cpu].cpuinfo.max_freq;
>         cpu_cur_freq[cpu] = cpufreq_driver->cpu_cur_freq[cpu];
> #endif
> 
> 
> 	However, cpu_{min,max,cur}_freq are static variables in
> drivers/cpufreq/userspace.c.  Making the variables global is not a
> sufficient fix, because drivers/cpufreq/userspace.c can be built as
> separate module.  So, I guess the variables should be moved to
> kernel/cpufreq.c or the code that I quoted above should somehow be
> moved.

Yes, a known problem.  Please note that Dominik no longer maintains
CPUfreq, please don't copy him with reports anymore.

The above is a result of a mismerge between the CPUfreq bits Dominik
sent me and the bits Dominik sent Linus.  Dominik left a set of seven
patches which need to go in, which davej took care of, but afaik Linus
hasn't accepted them (in fact, Linus has been quiet on the subject.)
Since davej has taken these patches under his wing, I'm not intending
pushing the patches to Linus.

So, this poses us with a small problem...  will it remain broken for
2.5.65 or will Linus merge the required patches...

I'll forward the patches to LKML in a moment.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html