[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140728181224.GN15536@arm.com>
Date: Mon, 28 Jul 2014 19:12:24 +0100
From: Will Deacon <will.deacon@....com>
To: Konstantin Khlebnikov <k.khlebnikov@...sung.com>
Cc: Russell King <linux@....linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Vitaly Andrianov <vitalya@...com>,
Cyril Chemparathy <cyril@...com>
Subject: Re: [PATCH 1/2] ARM: LPAE: load upper bits of early TTBR0/TTBR1
On Tue, Jul 22, 2014 at 04:36:23PM +0100, Konstantin Khlebnikov wrote:
> This patch fixes booting when idmap pgd lays above 4gb. Commit
> 4756dcbfd37 mostly had fixed this, but it'd failed to load upper bits.
>
> Also this fixes adding TTBR1_OFFSET to TTRR1: if lower part overflows
> carry flag must be added to the upper part.
>
> Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@...sung.com>
> Cc: Cyril Chemparathy <cyril@...com>
> Cc: Vitaly Andrianov <vitalya@...com>
> ---
> arch/arm/mm/proc-v7-3level.S | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
> index 22e3ad6..f0481dd 100644
> --- a/arch/arm/mm/proc-v7-3level.S
> +++ b/arch/arm/mm/proc-v7-3level.S
> @@ -140,12 +140,11 @@ ENDPROC(cpu_v7_set_pte_ext)
> mov \tmp, \ttbr1, lsr #(32 - ARCH_PGD_SHIFT) @ upper bits
> mov \ttbr1, \ttbr1, lsl #ARCH_PGD_SHIFT @ lower bits
> addls \ttbr1, \ttbr1, #TTBR1_OFFSET
> - mcrr p15, 1, \ttbr1, \zero, c2 @ load TTBR1
> + adcls \tmp, \tmp, #0
> + mcrr p15, 1, \ttbr1, \tmp, c2 @ load TTBR1
> mov \tmp, \ttbr0, lsr #(32 - ARCH_PGD_SHIFT) @ upper bits
> mov \ttbr0, \ttbr0, lsl #ARCH_PGD_SHIFT @ lower bits
> - mcrr p15, 0, \ttbr0, \zero, c2 @ load TTBR0
> - mcrr p15, 1, \ttbr1, \zero, c2 @ load TTBR1
> - mcrr p15, 0, \ttbr0, \zero, c2 @ load TTBR0
> + mcrr p15, 0, \ttbr0, \tmp, c2 @ load TTBR0
I must admit, the code you are removing here looks really strange. Was there
a badly resolved conflict somewhere along the way? It would be nice to see
if your fix (which seems ok to me) was actually present in the mailing list
posting of the patch that ended in the above mess.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists