On 27/04/16 09:05, Benjamin Herrenschmidt wrote: > On Wed, 2016-04-27 at 08:16 +1000, Balbir Singh wrote: >> >> On 27/04/16 07:05, Benjamin Herrenschmidt wrote: >>> >>> On Tue, 2016-04-26 at 21:54 +0530, Aneesh Kumar K.V wrote: >>>> >>>> This add generic mmu_feature_enabled() function that get patched >>>> to take right code path based on the feature bit enabled. The >>>> main >>>> difference between the existing mmu_has_feature() function is the >>>> hot patching using jump label framework. >>>> >>>> The implementation wraps around mmu_has_feature so that we can >>>> use >>>> this in early bootup code before we do the hotpatching. >>> I'd rather we make mmu_has_feature() use jump labels and is the >>> "main" >>> API to be used by most code. If we have a need for a lower-level >>> version for use by early boot code, call it __mmu_has_feature(). >>> >>> This is more in-line with existing kernel practices and avoids >>> having >>> two APIs that somewhat look the same where it's not clear which one >>> should be used. >>> >> Makes sense, but I suspect its a larger impact with loads of testing >> required across platforms. Should this be done incrementally? > > What kind of impact do you expect ? >
Just basic testing across CPUs with various mm features enabled/disabled. Just for sanity Balbir _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
