On Wed, 2014-08-06 at 14:58 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2014-08-05 at 19:48 -0500, Scott Wood wrote: > > I'll do s/mmu_allcpus/this_mmu/ but early_init_mmu() needs to do things > > both before and after early_init_mmu_common(). Do you want two new > > functions (before and after) or is it OK to just rename > > early_init_mmu_allcpus() and put a comment before early_init_mmu() > > saying it's just for the boot cpu? > > Do we really need that before/after ? The "after" code is the linear > mapping setup but does it rely on the MAS4 setting done above ?
No, but it relies on the call to map_mem_in_cams() to determine how much memory was able to be mapped. > Otherwise you can do before/after using a separate function > mmu_set_linear_map() OK. > Always nicer to break down too large functions anyway. Usually yes, but it doesn't necessarily help when it's an arbitrary division of a function that is a list of simple things (as opposed to e.g. factoring out the #ifdef CONFIG_PPC_FSL_BOOK3E block into its own function). BTW, is there a particular reason why we need to use memblock_enforce_memory_limit() on FSL_BOOK3E, rather than relying on memblock_set_current_limit()? I see that when memblock_enforce_memory_limit() was added to __early_init_mmu(), memblock_set_current_limit() did not exist. On 32-bit fsl booke uses memblock_set_current_limit() for this. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
