Re: How to dynamically disable/enable CPU features?

["Gerhard Pircher" <gerhard_pircher@gmx.net>]

-------- Original-Nachricht --------
> Datum: Sat, 23 Feb 2008 09:32:01 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Milton Miller <miltonm@bga.com>, linuxppc-dev@ozlabs.org
> Betreff: Re: How to dynamically disable/enable CPU features?

> > The flag is in POSSIBLE. I now use this code in the platform probe
> > function to nop out the code affected by the flag:
> > 
> > cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
> > /* Patch out unwanted feature. */
> > do_feature_fixups(cur_cpu_spec->cpu_features,
> > 		  PTRRELOC(&__start___ftr_fixup),
> > 		  PTRRELOC(&__stop___ftr_fixup));
> > 
> > It seems to work so far, but I would like to know if this is the right
> > way to do it, or if calling do_feature_fixups() more than once can have
> > any side effects.
> 
> It's a bit hairy... Things -could- have been nop'ed out by the first
> call as a result of CPU_FTR_NEED_COHERENT being set and the second
> call will not be able to put them back in... now that may not be the
> case (depends what kind of patching is done with that flag) and so
> 'happen' to work for this specific bit but it isn't a nice solution...
I checked this now. Looks like it only needs to nop out some code (mainly
in the hash table code).

> A better long term approach is to look at moving the fixup to after
> the machine probe() after carefully checking whether that can cause
> any problem...
Well, that's a job for an more experienced kernel developer. :)

Thanks!

Gerhard
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger