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

2013-07-01 Thread Santosh Shilimkar
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 whi

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

2013-07-01 Thread Sebastian Andrzej Siewior
On 07/01/2013 09:59 AM, Geert Uytterhoeven wrote: > 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. And I think the DT code should check if the u64 fits in phys_addr_t and if does not it should write an error messa

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

2013-07-01 Thread Geert Uytterhoeven
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)

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

2013-07-01 Thread Sebastian Andrzej Siewior
On 06/29/2013 01:43 AM, Santosh Shilimkar wrote: > > Sebastian, > > 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 pa

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

2013-06-29 Thread Geert Uytterhoeven
On Sat, Jun 29, 2013 at 1:43 AM, Santosh Shilimkar 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. >>> >>> +1 >

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

2013-06-28 Thread Santosh Shilimkar
Sebastian, On Friday 28 June 2013 09:49 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 10:59 Fri 28 Jun , Grant Likely wrote: >> On Thu, Jun 27, 2013 at 9:54 PM, Rob Herring wrote: >>> On 06/21/2013 12:20 PM, Santosh Shilimkar wrote: On Friday 21 June 2013 05:04 AM, Sebastian Andrzej

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

2013-06-28 Thread Jean-Christophe PLAGNIOL-VILLARD
On 10:59 Fri 28 Jun , Grant Likely wrote: > On Thu, Jun 27, 2013 at 9:54 PM, Rob Herring wrote: > > 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

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

2013-06-28 Thread Grant Likely
On Thu, Jun 27, 2013 at 9:54 PM, Rob Herring wrote: > 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/

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

2013-06-28 Thread Sebastian Andrzej Siewior
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 represente

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

2013-06-27 Thread Rob Herring
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 >>> --- a/arch/mi

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

2013-06-21 Thread Santosh Shilimkar
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/

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

2013-06-21 Thread Santosh Shilimkar
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: A

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

2013-06-21 Thread Sebastian Andrzej Siewior
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

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

2013-06-21 Thread James Hogan
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 Baechle

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

2013-06-20 Thread Vineet Gupta
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 > Cc

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

2013-06-20 Thread Santosh Shilimkar
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 th