From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <scottwood@freescale.com>
Received: from na01-bn1-obe.outbound.protection.outlook.com
 (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by lists.ozlabs.org (Postfix) with ESMTPS id 60BA91A007B
 for <linuxppc-dev@lists.ozlabs.org>; Thu,  7 Aug 2014 06:09:27 +1000 (EST)
Message-ID: <1407355754.7427.36.camel@snotra.buserror.net>
Subject: Re: [PATCH 2/2] powerpc/nohash: Split __early_init_mmu() into boot
 and secondary
From: Scott Wood <scottwood@freescale.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 6 Aug 2014 15:09:14 -0500
In-Reply-To: <1407301138.3073.68.camel@pasglop>
References: <1406948861-11322-1-git-send-email-scottwood@freescale.com>
 <1406948861-11322-2-git-send-email-scottwood@freescale.com>
 <1407213410.19150.65.camel@pasglop>
 <1407286090.7427.19.camel@snotra.buserror.net>
 <1407301138.3073.68.camel@pasglop>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Cc: linuxppc-dev@lists.ozlabs.org
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.lists.ozlabs.org>
List-Unsubscribe: <https://lists.ozlabs.org/options/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>
List-Archive: <http://lists.ozlabs.org/pipermail/linuxppc-dev/>
List-Post: <mailto:linuxppc-dev@lists.ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>
List-Subscribe: <https://lists.ozlabs.org/listinfo/linuxppc-dev>,
 <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>

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