From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Mark Salter <msalter@redhat.com>,
Aurelien Jacquiot <a-jacquiot@ti.com>,
James Hogan <james.hogan@imgtec.com>,
Michal Simek <monstr@monstr.eu>,
Ralf Baechle <ralf@linux-mips.org>,
Jonas Bonn <jonas@southpole.se>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>, <x86@kernel.org>,
<arm@kernel.org>, Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-c6x-dev@linux-c6x.org>, <linux-mips@linux-mips.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-xtensa@linux-xtensa.org>,
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH v2] of: Specify initrd location using 64-bit
Date: Mon, 22 Jul 2013 10:50:02 -0400 [thread overview]
Message-ID: <51ED469A.9000801@ti.com> (raw)
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring@calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
>
> Nope, 3.12 is fine. Applied.
>
Thanks Grant.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Mark Salter <msalter@redhat.com>,
Aurelien Jacquiot <a-jacquiot@ti.com>,
James Hogan <james.hogan@imgtec.com>,
Michal Simek <monstr@monstr.eu>,
Ralf Baechle <ralf@linux-mips.org>,
Jonas Bonn <jonas@southpole.se>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
x86@kernel.org, arm@kernel.org, Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-c6x-dev@linux-c6x.org, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux-xtensa@linux-xtensa.org,
devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v2] of: Specify initrd location using 64-bit
Date: Mon, 22 Jul 2013 10:50:02 -0400 [thread overview]
Message-ID: <51ED469A.9000801@ti.com> (raw)
Message-ID: <20130722145002.kztdtOuQsE8amqjvXhuQ-JxYCxdgZVIOpo6whNj8IDg@z> (raw)
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring@calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
>
> Nope, 3.12 is fine. Applied.
>
Thanks Grant.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
linux-mips@linux-mips.org, Aurelien Jacquiot <a-jacquiot@ti.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Will Deacon <will.deacon@arm.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Jonas Bonn <jonas@southpole.se>,
Russell King <linux@arm.linux.org.uk>,
linux-c6x-dev@linux-c6x.org, x86@kernel.org, arm@kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Mark Salter <msalter@redhat.com>,
Rob Herring <robherring2@gmail.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
linux-xtensa@linux-xtensa.org,
James Hogan <james.hogan@imgtec.com>,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <rob.herring@calxeda.com>,
linux-arm-kernel@lists.infradead.org,
Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr.eu>,
Vineet Gupta <vgupta@synopsys.com>,
Ralf Baechle <ralf@linux-mips.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] of: Specify initrd location using 64-bit
Date: Mon, 22 Jul 2013 10:50:02 -0400 [thread overview]
Message-ID: <51ED469A.9000801@ti.com> (raw)
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring@calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
>
> Nope, 3.12 is fine. Applied.
>
Thanks Grant.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] of: Specify initrd location using 64-bit
Date: Mon, 22 Jul 2013 10:50:02 -0400 [thread overview]
Message-ID: <51ED469A.9000801@ti.com> (raw)
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring@calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
>
> Nope, 3.12 is fine. Applied.
>
Thanks Grant.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Mark Salter <msalter@redhat.com>,
Aurelien Jacquiot <a-jacquiot@ti.com>,
James Hogan <james.hogan@imgtec.com>,
Michal Simek <monstr@monstr.eu>,
Ralf Baechle <ralf@linux-mips.org>,
Jonas Bonn <jonas@southpole.se>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
x86@kernel.org, arm@kernel.org, Chris Zankel <chris@zankel.net>,
Max
Subject: Re: [PATCH v2] of: Specify initrd location using 64-bit
Date: Mon, 22 Jul 2013 10:50:02 -0400 [thread overview]
Message-ID: <51ED469A.9000801@ti.com> (raw)
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring@calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
>
> Nope, 3.12 is fine. Applied.
>
Thanks Grant.
Regards,
Santosh
next prev parent reply other threads:[~2013-07-22 14:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 18:20 [PATCH v2] of: Specify initrd location using 64-bit Santosh Shilimkar
2013-07-01 18:20 ` Santosh Shilimkar
2013-07-01 18:20 ` Santosh Shilimkar
2013-07-01 18:20 ` Santosh Shilimkar
2013-07-01 18:20 ` Santosh Shilimkar
2013-07-01 21:34 ` Rob Herring
2013-07-01 21:34 ` Rob Herring
2013-07-01 21:34 ` Rob Herring
2013-07-01 21:34 ` Rob Herring
2013-07-20 5:39 ` Grant Likely
2013-07-20 5:39 ` Grant Likely
2013-07-20 5:39 ` Grant Likely
2013-07-20 5:39 ` Grant Likely
2013-07-22 14:50 ` Santosh Shilimkar [this message]
2013-07-22 14:50 ` Santosh Shilimkar
2013-07-22 14:50 ` Santosh Shilimkar
2013-07-22 14:50 ` Santosh Shilimkar
2013-07-22 14:50 ` Santosh Shilimkar
2013-07-02 4:17 ` Vineet Gupta
2013-07-02 4:17 ` Vineet Gupta
2013-07-02 4:17 ` Vineet Gupta
2013-07-02 4:17 ` Vineet Gupta
2013-07-22 15:01 ` Jean-Christophe PLAGNIOL-VILLARD
2013-07-22 15:01 ` Jean-Christophe PLAGNIOL-VILLARD
2013-07-22 15:01 ` Jean-Christophe PLAGNIOL-VILLARD
2013-07-22 15:01 ` Jean-Christophe PLAGNIOL-VILLARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51ED469A.9000801@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=a-jacquiot@ti.com \
--cc=arm@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=chris@zankel.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=geert@linux-m68k.org \
--cc=grant.likely@linaro.org \
--cc=james.hogan@imgtec.com \
--cc=jcmvbkbc@gmail.com \
--cc=jonas@southpole.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-c6x-dev@linux-c6x.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=monstr@monstr.eu \
--cc=msalter@redhat.com \
--cc=nicolas.pitre@linaro.org \
--cc=paulus@samba.org \
--cc=plagnioj@jcrosoft.com \
--cc=ralf@linux-mips.org \
--cc=rob.herring@calxeda.com \
--cc=robherring2@gmail.com \
--cc=vgupta@synopsys.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.