Re: Move of powerpc/cell cpufreq drivers

[Arnd Bergmann <arnd@arndb.de>]

On Friday 28 March 2014, Jean Delvare wrote:
> Le Friday 28 March 2014 à 19:02 +0100, Arnd Bergmann a écrit :
> > On Friday 28 March 2014, Jean Delvare wrote:
> > 
> > > The current situation is kind of odd, because CPU_FREQ_CBE_PMI (bool)
> > > depends on CPU_FREQ_CBE (tristate) so it is possible to have
> > > CPU_FREQ_CBE=m and CPU_FREQ_CBE_PMI=y. If ppc_cbe_cpufreq_pmi really
> > > depends on ppc_cbe_cpufreq, then that will fail, as ppc_cbe_cpufreq as
> > > a module may not be loaded when ppc_cbe_cpufreq_pmi is initialized. The
> > > compiler would complain about missing symbols. So I suspect this
> > > dependency doesn't actually exist, otherwise after one year someone
> > > would have noticed the build breakage, right?
> > 
> > I believe CPU_FREQ_CBE can be built with support for CPU_FREQ_CBE_PMI
> > or without, but if the PMI code is a module, then CPU_FREQ_CBE
> > cannot be 'y'.        
> > 
> > > As a conclusion I believe the following changes should be applied:
> > > * CPU_FREQ_CBE_PMI should be changed to a tristate.
> > > * CPU_FREQ_CBE_PMI should not depend on CPU_FREQ_CBE.
> > > 
> > > I can write and submit the patches once it is confirmed that this
> > > changes are the right way to fix the problem.
> > 
> > If you do this, you should also add
> > 
> >       depends on CPU_FREQ_CBE_PMI || !CPU_FREQ_CBE_PMI
> > 
> > to the CPU_FREQ_CBE option, to correctly handle the dependency.
> 
> Ah, my bad, I thought both modules were more or less independent, I
> didn't realize ppc_cbe_cpufreq_pmi was actually a helper "module" for
> ppc_cbe_cpufreq when enabled.
> 
> Thinking about it some more, I think this would be much more simple to
> build ppc_cbe_cpufreq_pmi.c as an object that would part of
> ppc_cbe_cpufreq.ko. That is, build everything as a single module in the
> end. That would solve the cross-dependency issue, and the code in
> ppc_cbe_cpufreq_pmi would no longer have to be built-in.
> 
> But well, I don't really have the time to look into this, especially as
> I don't even have a powerpc machine at hand to test the changes. So if
> nobody cares, things will have to stay the way they are.

Fine with me.

> > I don't actually see a problem with the current code, other than
> > that CPU_FREQ_CBE_PMI could in theory be a module. This code is
> > used only for an IBM machine that has been end-of-service for
> > a couple of years. If anyone still wants to build kernels for
> > it, they probably want it built-in anyway, and not have
> > the same kernel run on other machines.
> 
> Thanks for pointing this out. I don't know much about powerpc hardware
> so I didn't realize that. We indeed ended up disabling this driver
> altogether in our default ppc kernel config. Which was the easiest way
> to solve our problem after all :-)

You probably want to disable all of PPC_CELL anyway, which implies
disabling this driver. There are a few hacks that get enabled if you
want Cell support that have a small impact on performance on other
platforms, and I don't expect anyone to run distro kernels on
these machines any more.

	Arnd