[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: Rob Herring <>
Date: Wed, 12 Sep 2012 17:08:31 -0500
Cc: Cyril Chemparathy <>,,,,,,,,,,,,,,,,, Geert Uytterhoeven <>,,,,,,,,,,,,,,,,,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QQ0noX15Z5BL3V3kLW6FG8GbGxnVnZVlNfZYaapKMjY=; b=bRMOccOwj9JDNzoG7X7DPaR6WkdITRz10oOshhzppzvnMi6tHXxTaHD60gndFb5SIP X1sGIgCiwFSmCzXSlGgZZhDia93m1DIOJ1e5V7yTmW57AKLFI5xyeg74fn97NJk2mxCY OSrE3uQOEC01VKeez3Aojf43Thmi27uG2Bht1cNfrMdU1lA0PFTG7J6D7nA9i8RDijUx 4jSynL2UsxKWp7t9QnReFx8HWTp3C5ddog8AFOpRi7SKiCGJYUBrDWmv95zhGj+ytCCG xXXLQakySWlKF0uL71C6PlRuirciUEBNIlDY4/fICV8ElYjXbG/6/Er2TCl8rF1gajQs XFJQ==
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: <>
References: <> <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
On 09/12/2012 02:58 PM, Sebastian Andrzej Siewior wrote:
> On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
>>>> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
>>>> unsigned long end)
>>>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>> Why not phys_addr_t?
>> The rest of the memory specific bits of the device-tree code use u64 for
>> addresses, and I kept it the same for consistency.
> Geert is right here. If it is a physical address, it should be
> phys_addr_t.

While generally true, for the DT specific code I think it should be a
fixed u64. The size of the address is defined by the FDT, not the
kernel. It is very likely we could have a FDT that specifies addresses
in 64-bit values, but then we boot a kernel is compiled for !LPAE.
phys_addr_t is currently sized based on LPAE setting.

Also, this is how the memory and reserved nodes are handled currently,
so we should be consistent.


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