On 06/27/2013 10:54 PM, Rob Herring wrote:
>> Rob,
>> Are you ok with phys_addr_t since your concern was about rest
>> of the memory specific bits of the device-tree code use u64 ?
>
> No. I still think it should be u64 for same reasons I said originally.
The physical address space is
On 06/27/2013 10:54 PM, Rob Herring wrote:
Rob,
Are you ok with phys_addr_t since your concern was about rest
of the memory specific bits of the device-tree code use u64 ?
No. I still think it should be u64 for same reasons I said originally.
The physical address space is represented by
On 06/21/2013 12:20 PM, Santosh Shilimkar wrote:
> On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
>> On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
>>> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
>>> index 0a2c68f..62e2e8f 100644
>>> ---
On 06/21/2013 12:20 PM, Santosh Shilimkar wrote:
On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
---
On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
> On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
>> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
>> index 0a2c68f..62e2e8f 100644
>> --- a/arch/microblaze/kernel/prom.c
>> +++
Vineet, James,
On Friday 21 June 2013 04:23 AM, James Hogan wrote:
> On 21/06/13 05:39, Vineet Gupta wrote:
>> Hi Santosh,
>>
>> On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
>>> Cc: Vineet Gupta
>>> Cc: Russell King
>>> Cc: Catalin Marinas
>>> Cc: Will Deacon
>>> Cc: Mark Salter
>>> Cc:
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 0a2c68f..62e2e8f 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void
On 21/06/13 05:39, Vineet Gupta wrote:
> Hi Santosh,
>
> On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
>> Cc: Vineet Gupta
>> Cc: Russell King
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Mark Salter
>> Cc: Aurelien Jacquiot
>> Cc: James Hogan
>> Cc: Michal Simek
>> Cc: Ralf
On 21/06/13 05:39, Vineet Gupta wrote:
Hi Santosh,
On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Mark Salter
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
Vineet, James,
On Friday 21 June 2013 04:23 AM, James Hogan wrote:
On 21/06/13 05:39, Vineet Gupta wrote:
Hi Santosh,
On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
Hi Santosh,
On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Salter
> Cc: Aurelien Jacquiot
> Cc: James Hogan
> Cc: Michal Simek
> Cc: Ralf Baechle
> Cc: Jonas Bonn
> Cc: Benjamin Herrenschmidt
>
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
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
Hi Santosh,
On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Mark Salter msal...@redhat.com
Cc: Aurelien Jacquiot
On 09/13/2012 01:47 AM, Sebastian Andrzej Siewior wrote:
> On 09/13/2012 12:08 AM, Rob Herring wrote:
>>> 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
On 09/13/2012 12:08 AM, Rob Herring wrote:
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
On 09/13/2012 12:08 AM, Rob Herring wrote:
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
On 09/13/2012 01:47 AM, Sebastian Andrzej Siewior wrote:
On 09/13/2012 12:08 AM, Rob Herring wrote:
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
On 9/12/2012 4:23 PM, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
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
On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
> On Wed, 12 Sep 2012, Rob Herring wrote:
>
>> On 09/12/2012 11:05 AM, Cyril Chemparathy 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
On Wed, 12 Sep 2012, Rob Herring wrote:
> On 09/12/2012 11:05 AM, Cyril Chemparathy 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.
> >
>
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
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
On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy 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.
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy 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
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
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
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@ti.com 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
On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@ti.com 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
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
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
On Wed, 12 Sep 2012, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
On Wed, 12 Sep 2012, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
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
On 9/12/2012 4:23 PM, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy 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
38 matches
Mail list logo
