[Top] [All Lists]

Re: [PATCH] of: Specify initrd location using 64-bit

To: Sebastian Andrzej Siewior <>
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
From: Geert Uytterhoeven <>
Date: Mon, 1 Jul 2013 09:59:33 +0200
Cc: Santosh Shilimkar <>, Nicolas Pitre <>, linux-mips <>, Aurelien Jacquiot <>, Catalin Marinas <>, Will Deacon <>, Max Filippov <>, Paul Mackerras <>, Jonas Bonn <>, Russell King <>,, "the arch/x86 maintainers" <>, "" <>, Rob Herring <>, Grant Likely <>, Jean-Christophe PLAGNIOL-VILLARD <>,, James Hogan <>, devicetree-discuss <>, Rob Herring <>, "" <>, Chris Zankel <>, Vineet Gupta <>, Linux Kernel Mailing List <>, Ralf Baechle <>, "" <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TxVQjSA4mZhCU8JK1LHE+Te+AOwSOzpWCDKBZhjmwYI=; b=uECOImqeW79XintTUg9+fffZPYr3IAhw4ups8HtHv7iEBIraYJdvymrM1mDDpA4vh6 ZvuLBwIcI0IykFnx2SvGJHwSZUIgm/01UZfBTPtRxtxd8C+vh/C5EEN/rttlX08llyyi y6v2uONJg56zHJiKu823CyoAMkoIAwXEFiB9bKzMmIcURINIU0NnaIBPO/I1NtVu1Z48 DMlOBp71Yt/s+DPZMhlolidxTzl4pWHoC2oRe8H24o4w3n47xV5ie4YWHuLXpwqAfCDz /vT3cUYKbWIIgqYKzTcJGx5HX/CgI2uaP7iPrauoCWl0zgwkOHAqGcHZk5eV2nyQxCCS LqfQ==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <>
On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
<> wrote:
> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>> Apart from waste of 32bit, what is the other concern you
>> have ?
> You pass a u64 as a physical address which is represented in other
> parts of the kernel (for a good reason) by phys_addr_t.
>> I really want to converge on this patch because it
>> has been a open ended discussion for quite some time. Does
>> that really break any thing on x86 or your concern is more
>> from semantics of the physical address.
> You want to have your code in so you can continue with your work, that
> is okay. The other two arguments why u64 here is a good thing was "due
> to what I said earlier" and "+1" and I don't have the time to look
> that up.
> There should be no problems on x86 if this goes in as it is now.
> But think about this: What happens if you boot your ARM device without
> PAE and your initrd is in the upper region? If you are lucky the kernel
> looks at a different place where it also has a read permission, notices
> nothing sane is there, writes a message and continues. And if it is not
> allowed to read? It is clearly the user's fault for booting a non-PAE
> kernel.

That's actual the original reason: DT has it as 64 bit, and passes it to a
32 bit kernel when running in 32 bit mode without PAE.



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

<Prev in Thread] Current Thread [Next in Thread>