[Top] [All Lists]

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

To: unlisted-recipients:; (no To-header on input)
Subject: Re: [PATCH] of: Specify initrd location using 64-bit
From: Santosh Shilimkar <>
Date: Mon, 1 Jul 2013 09:58:35 -0400
Cc: Geert Uytterhoeven <>, Sebastian Andrzej Siewior <>, 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 <>, "" <>
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: <> <> <> <> <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> 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.
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.


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