-------- Original-Nachricht -------- > Datum: Sat, 23 Feb 2008 09:32:01 +1100 > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: Milton Miller <[EMAIL PROTECTED]>, 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
