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

From: [email-masked] (Santosh Shilimkar)
Date: Mon, 1 Jul 2013 09:58:35 -0400

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <[email-masked]> 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.

Regards,
Santosh