Patchwork of: Specify initrd location using 64-bit

login
register
mail settings
Submitter Santosh Shilimkar
Date June 21, 2013, 12:52 a.m.
Message ID <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com>
Download mbox | patch
Permalink /patch/253122/
State Changes Requested
Headers show

Comments

Santosh Shilimkar - June 21, 2013, 12:52 a.m.
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.

Patch is refreshed version of Cyril's original patch against 3.10-rcx which
has few more arch's which needs to be patched. Have to drop Cyril's email
id since its broken now.

Boot tested on ARM platform and just build tested for x86 platform.
Technically it should not break anything but cc list check if
it creates any issue for your arch.

Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: x86@kernel.org
Cc: arm@kernel.org
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: bigeasy@linutronix.de
Cc: robherring2@gmail.com
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>

Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-xtensa@linux-xtensa.org
Cc: devicetree-discuss@lists.ozlabs.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arc/mm/init.c            |    3 +--
 arch/arm/mm/init.c            |    2 +-
 arch/arm64/mm/init.c          |    3 +--
 arch/c6x/kernel/devicetree.c  |    3 +--
 arch/metag/mm/init.c          |    3 +--
 arch/microblaze/kernel/prom.c |    3 +--
 arch/mips/kernel/prom.c       |    3 +--
 arch/openrisc/kernel/prom.c   |    3 +--
 arch/powerpc/kernel/prom.c    |    3 +--
 arch/x86/kernel/devicetree.c  |    3 +--
 arch/xtensa/kernel/setup.c    |    3 +--
 drivers/of/fdt.c              |   10 ++++++----
 include/linux/of_fdt.h        |    3 +--
 13 files changed, 18 insertions(+), 27 deletions(-)
Vineet Gupta - June 21, 2013, 4:39 a.m.
Hi Santosh,

On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
> Cc: James Hogan <james.hogan@imgtec.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Jonas Bonn <jonas@southpole.se>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: x86@kernel.org
> Cc: arm@kernel.org
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: bigeasy@linutronix.de
> Cc: robherring2@gmail.com
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-c6x-dev@linux-c6x.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-xtensa@linux-xtensa.org
> Cc: devicetree-discuss@lists.ozlabs.org
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  arch/arc/mm/init.c            |    3 +--
>  arch/arm/mm/init.c            |    2 +-
>  arch/arm64/mm/init.c          |    3 +--
>  arch/c6x/kernel/devicetree.c  |    3 +--
>  arch/metag/mm/init.c          |    3 +--
>  arch/microblaze/kernel/prom.c |    3 +--
>  arch/mips/kernel/prom.c       |    3 +--
>  arch/openrisc/kernel/prom.c   |    3 +--
>  arch/powerpc/kernel/prom.c    |    3 +--
>  arch/x86/kernel/devicetree.c  |    3 +--
>  arch/xtensa/kernel/setup.c    |    3 +--
>  drivers/of/fdt.c              |   10 ++++++----
>  include/linux/of_fdt.h        |    3 +--
>  13 files changed, 18 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..3640c74 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,8 +157,7 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_OF_FLATTREE
> -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)
>  {
>  	pr_err("%s(%lx, %lx)\n", __func__, start, end);
>  }

To avoid gcc warnings, you need to fix the print format specifiers too.

Thx,
-Vineet
James Hogan - June 21, 2013, 8:23 a.m.
On 21/06/13 05:39, Vineet Gupta wrote:
> Hi Santosh,
> 
> On 06/21/2013 06:22 AM, Santosh Shilimkar wrote:
>> Cc: Vineet Gupta <vgupta@synopsys.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Salter <msalter@redhat.com>
>> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
>> Cc: James Hogan <james.hogan@imgtec.com>
>> Cc: Michal Simek <monstr@monstr.eu>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: Jonas Bonn <jonas@southpole.se>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: x86@kernel.org
>> Cc: arm@kernel.org
>> Cc: Chris Zankel <chris@zankel.net>
>> Cc: Max Filippov <jcmvbkbc@gmail.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Cc: bigeasy@linutronix.de
>> Cc: robherring2@gmail.com
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-c6x-dev@linux-c6x.org
>> Cc: linux-mips@linux-mips.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: linux-xtensa@linux-xtensa.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>  arch/arc/mm/init.c            |    3 +--
>>  arch/arm/mm/init.c            |    2 +-
>>  arch/arm64/mm/init.c          |    3 +--
>>  arch/c6x/kernel/devicetree.c  |    3 +--
>>  arch/metag/mm/init.c          |    3 +--
>>  arch/microblaze/kernel/prom.c |    3 +--
>>  arch/mips/kernel/prom.c       |    3 +--
>>  arch/openrisc/kernel/prom.c   |    3 +--
>>  arch/powerpc/kernel/prom.c    |    3 +--
>>  arch/x86/kernel/devicetree.c  |    3 +--
>>  arch/xtensa/kernel/setup.c    |    3 +--
>>  drivers/of/fdt.c              |   10 ++++++----
>>  include/linux/of_fdt.h        |    3 +--
>>  13 files changed, 18 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
>> index 4a17736..3640c74 100644
>> --- a/arch/arc/mm/init.c
>> +++ b/arch/arc/mm/init.c
>> @@ -157,8 +157,7 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>>  #endif
>>  
>>  #ifdef CONFIG_OF_FLATTREE
>> -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)
>>  {
>>  	pr_err("%s(%lx, %lx)\n", __func__, start, end);
>>  }
> 
> To avoid gcc warnings, you need to fix the print format specifiers too.

The same thing goes for arch/metag too.

Cheers
James
Sebastian Siewior - June 21, 2013, 9:04 a.m.
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)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -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)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);

I think it would better to go here for phys_addr_t instead of u64. This
would force you in of_flat_dt_match() to check if the value passed from
DT specifies a memory address outside of 32bit address space and the
kernel can't deal with this because its phys_addr_t is 32bit only due
to a Kconfig switch.

For x86, the initrd has to remain in the 32bit address space so passing
the initrd in the upper range would violate the ABI. Not sure if this
is true for other archs as well (ARM obviously not).

Sebastian
Santosh Shilimkar - June 21, 2013, 5:12 p.m.
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 <vgupta@synopsys.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Mark Salter <msalter@redhat.com>
>>> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
>>> Cc: James Hogan <james.hogan@imgtec.com>
>>> Cc: Michal Simek <monstr@monstr.eu>
>>> Cc: Ralf Baechle <ralf@linux-mips.org>
>>> Cc: Jonas Bonn <jonas@southpole.se>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: x86@kernel.org
>>> Cc: arm@kernel.org
>>> Cc: Chris Zankel <chris@zankel.net>
>>> Cc: Max Filippov <jcmvbkbc@gmail.com>
>>> Cc: Grant Likely <grant.likely@linaro.org>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Cc: bigeasy@linutronix.de
>>> Cc: robherring2@gmail.com
>>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>>>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-c6x-dev@linux-c6x.org
>>> Cc: linux-mips@linux-mips.org
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Cc: linux-xtensa@linux-xtensa.org
>>> Cc: devicetree-discuss@lists.ozlabs.org
>>>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> ---
>>>  arch/arc/mm/init.c            |    3 +--
>>>  arch/arm/mm/init.c            |    2 +-
>>>  arch/arm64/mm/init.c          |    3 +--
>>>  arch/c6x/kernel/devicetree.c  |    3 +--
>>>  arch/metag/mm/init.c          |    3 +--
>>>  arch/microblaze/kernel/prom.c |    3 +--
>>>  arch/mips/kernel/prom.c       |    3 +--
>>>  arch/openrisc/kernel/prom.c   |    3 +--
>>>  arch/powerpc/kernel/prom.c    |    3 +--
>>>  arch/x86/kernel/devicetree.c  |    3 +--
>>>  arch/xtensa/kernel/setup.c    |    3 +--
>>>  drivers/of/fdt.c              |   10 ++++++----
>>>  include/linux/of_fdt.h        |    3 +--
>>>  13 files changed, 18 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
>>> index 4a17736..3640c74 100644
>>> --- a/arch/arc/mm/init.c
>>> +++ b/arch/arc/mm/init.c
>>> @@ -157,8 +157,7 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>>>  #endif
>>>  
>>>  #ifdef CONFIG_OF_FLATTREE
>>> -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)
>>>  {
>>>  	pr_err("%s(%lx, %lx)\n", __func__, start, end);
>>>  }
>>
>> To avoid gcc warnings, you need to fix the print format specifiers too.
> 
> The same thing goes for arch/metag too.
> 
Will update that in next version based on what we will end
after the dicussion. i.e u64 or phys_addr_t

Thanks for comments.

Regards,
Santosh
Santosh Shilimkar - June 21, 2013, 5:20 p.m.
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
>> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
>>  }
>>  
>>  #ifdef CONFIG_BLK_DEV_INITRD
>> -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)
>>  {
>>  	initrd_start = (unsigned long)__va(start);
>>  	initrd_end = (unsigned long)__va(end);
> 
> I think it would better to go here for phys_addr_t instead of u64. This
> would force you in of_flat_dt_match() to check if the value passed from
> DT specifies a memory address outside of 32bit address space and the
> kernel can't deal with this because its phys_addr_t is 32bit only due
> to a Kconfig switch.
> 
> For x86, the initrd has to remain in the 32bit address space so passing
> the initrd in the upper range would violate the ABI. Not sure if this
> is true for other archs as well (ARM obviously not).
> 
That pretty much means phys_addr_t. It will work for me as well but
in last thread from consistency with memory and reserved node, Rob
insisted to keep it as u64. So before I re-spin another version,
would like to here what Rob has to say considering the x86 requirement.

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 ?

Regards,
Santosh
Rob Herring - June 27, 2013, 8:54 p.m.
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/microblaze/kernel/prom.c
>>> +++ b/arch/microblaze/kernel/prom.c
>>> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
>>>  }
>>>  
>>>  #ifdef CONFIG_BLK_DEV_INITRD
>>> -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)
>>>  {
>>>  	initrd_start = (unsigned long)__va(start);
>>>  	initrd_end = (unsigned long)__va(end);
>>
>> I think it would better to go here for phys_addr_t instead of u64. This
>> would force you in of_flat_dt_match() to check if the value passed from
>> DT specifies a memory address outside of 32bit address space and the
>> kernel can't deal with this because its phys_addr_t is 32bit only due
>> to a Kconfig switch.
>>
>> For x86, the initrd has to remain in the 32bit address space so passing
>> the initrd in the upper range would violate the ABI. Not sure if this
>> is true for other archs as well (ARM obviously not).
>>
> That pretty much means phys_addr_t. It will work for me as well but
> in last thread from consistency with memory and reserved node, Rob
> insisted to keep it as u64. So before I re-spin another version,
> would like to here what Rob has to say considering the x86 requirement.
> 
> 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.

Rob
Sebastian Siewior - June 28, 2013, 7:54 a.m.
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 phys_addr_t and not u64
within the kernel. If you go for u64 you may waste 32bit and you need
to check if the running kernel can deal with this.
Why was u64 such a good thing?

> Rob

Sebastian
Grant Likely - June 28, 2013, 9:59 a.m.
On Thu, Jun 27, 2013 at 9:54 PM, Rob Herring <robherring2@gmail.com> 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/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)
>>>>  }
>>>>
>>>>  #ifdef CONFIG_BLK_DEV_INITRD
>>>> -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)
>>>>  {
>>>>     initrd_start = (unsigned long)__va(start);
>>>>     initrd_end = (unsigned long)__va(end);
>>>
>>> I think it would better to go here for phys_addr_t instead of u64. This
>>> would force you in of_flat_dt_match() to check if the value passed from
>>> DT specifies a memory address outside of 32bit address space and the
>>> kernel can't deal with this because its phys_addr_t is 32bit only due
>>> to a Kconfig switch.
>>>
>>> For x86, the initrd has to remain in the 32bit address space so passing
>>> the initrd in the upper range would violate the ABI. Not sure if this
>>> is true for other archs as well (ARM obviously not).
>>>
>> That pretty much means phys_addr_t. It will work for me as well but
>> in last thread from consistency with memory and reserved node, Rob
>> insisted to keep it as u64. So before I re-spin another version,
>> would like to here what Rob has to say considering the x86 requirement.
>>
>> 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

g.
Jean-Christophe PLAGNIOL-VILLARD - June 28, 2013, 1:49 p.m.
On 10:59 Fri 28 Jun     , Grant Likely wrote:
> On Thu, Jun 27, 2013 at 9:54 PM, Rob Herring <robherring2@gmail.com> 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/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)
> >>>>  }
> >>>>
> >>>>  #ifdef CONFIG_BLK_DEV_INITRD
> >>>> -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)
> >>>>  {
> >>>>     initrd_start = (unsigned long)__va(start);
> >>>>     initrd_end = (unsigned long)__va(end);
> >>>
> >>> I think it would better to go here for phys_addr_t instead of u64. This
> >>> would force you in of_flat_dt_match() to check if the value passed from
> >>> DT specifies a memory address outside of 32bit address space and the
> >>> kernel can't deal with this because its phys_addr_t is 32bit only due
> >>> to a Kconfig switch.
> >>>
> >>> For x86, the initrd has to remain in the 32bit address space so passing
> >>> the initrd in the upper range would violate the ABI. Not sure if this
> >>> is true for other archs as well (ARM obviously not).
> >>>
> >> That pretty much means phys_addr_t. It will work for me as well but
> >> in last thread from consistency with memory and reserved node, Rob
> >> insisted to keep it as u64. So before I re-spin another version,
> >> would like to here what Rob has to say considering the x86 requirement.
> >>
> >> 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
> 
+1

fix type

Best Regards,
J.
Santosh Shilimkar - June 28, 2013, 11:43 p.m.
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 <robherring2@gmail.com> 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/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)
>>>>>>  }
>>>>>>
>>>>>>  #ifdef CONFIG_BLK_DEV_INITRD
>>>>>> -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)
>>>>>>  {
>>>>>>     initrd_start = (unsigned long)__va(start);
>>>>>>     initrd_end = (unsigned long)__va(end);
>>>>>
>>>>> I think it would better to go here for phys_addr_t instead of u64. This
>>>>> would force you in of_flat_dt_match() to check if the value passed from
>>>>> DT specifies a memory address outside of 32bit address space and the
>>>>> kernel can't deal with this because its phys_addr_t is 32bit only due
>>>>> to a Kconfig switch.
>>>>>
>>>>> For x86, the initrd has to remain in the 32bit address space so passing
>>>>> the initrd in the upper range would violate the ABI. Not sure if this
>>>>> is true for other archs as well (ARM obviously not).
>>>>>
>>>> That pretty much means phys_addr_t. It will work for me as well but
>>>> in last thread from consistency with memory and reserved node, Rob
>>>> insisted to keep it as u64. So before I re-spin another version,
>>>> would like to here what Rob has to say considering the x86 requirement.
>>>>
>>>> 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
>>
> +1
> 
> fix type
> 
Apart from waste of 32bit, what is the other concern you
have ? 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.

Thanks for help.

Regards,
Santosh
Geert Uytterhoeven - June 29, 2013, 8:34 a.m.
On Sat, Jun 29, 2013 at 1:43 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> 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
>>>
>> +1
>>
>> fix type
>>
> Apart from waste of 32bit, what is the other concern you
> have ? 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.

As the "original reasons" were not in this thread, I had to search a bit.
I suppose you mean this one: https://lkml.org/lkml/2012/9/13/544 ?

Summarized:
| 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Sebastian Siewior - July 1, 2013, 7:48 a.m.
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 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.

> 
> Thanks for help.
> 
> Regards,
> Santosh

Sebastian
Geert Uytterhoeven - July 1, 2013, 7:59 a.m.
On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Sebastian Siewior - July 1, 2013, 8:09 a.m.
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 message and act like no initrd was
specified (instead of passing "something" to the architecture).

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Sebastian
Santosh Shilimkar - July 1, 2013, 1:58 p.m.
On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> 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

Patch

diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 4a17736..3640c74 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -157,8 +157,7 @@  void __init free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_OF_FLATTREE
-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)
 {
 	pr_err("%s(%lx, %lx)\n", __func__, start, end);
 }
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..afeaef7 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@  static int __init parse_tag_initrd2(const struct tag *tag)
 __tagtable(ATAG_INITRD2, parse_tag_initrd2);
 
 #ifdef CONFIG_OF_FLATTREE
-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)
 {
 	phys_initrd_start = start;
 	phys_initrd_size = end - start;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f497ca7..7047708 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -44,8 +44,7 @@  static unsigned long phys_initrd_size __initdata = 0;
 
 phys_addr_t memstart_addr __read_mostly = 0;
 
-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)
 {
 	phys_initrd_start = start;
 	phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@  void __init early_init_devtree(void *params)
 
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
index d05b845..07b4412 100644
--- a/arch/metag/mm/init.c
+++ b/arch/metag/mm/init.c
@@ -419,8 +419,7 @@  void free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_OF_FLATTREE
-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)
 {
 	pr_err("%s(%lx, %lx)\n",
 	       __func__, start, end);
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)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 5712bb5..32b8788 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -58,8 +58,7 @@  void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
index 5869e3f..150215a 100644
--- a/arch/openrisc/kernel/prom.c
+++ b/arch/openrisc/kernel/prom.c
@@ -96,8 +96,7 @@  void __init early_init_devtree(void *params)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..2f3e252 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -550,8 +550,7 @@  void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index b158152..2fbad6b 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -52,8 +52,7 @@  void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-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)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 6dd25ec..d45e602 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -170,8 +170,7 @@  static int __init parse_tag_fdt(const bp_tag_t *tag)
 
 __tagtable(BP_TAG_FDT, parse_tag_fdt);
 
-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)
 {
 	initrd_start = (void *)__va(start);
 	initrd_end = (void *)__va(end);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 808be06..21123b8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -550,7 +550,8 @@  int __init of_flat_dt_match(unsigned long node, const char *const *compat)
  */
 void __init early_init_dt_check_for_initrd(unsigned long node)
 {
-	unsigned long start, end, len;
+	u64 start, end;
+	unsigned long len;
 	__be32 *prop;
 
 	pr_debug("Looking for initrd properties... ");
@@ -558,15 +559,16 @@  void __init early_init_dt_check_for_initrd(unsigned long node)
 	prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
 	if (!prop)
 		return;
-	start = of_read_ulong(prop, len/4);
+	start = of_read_number(prop, len/4);
 
 	prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
 	if (!prop)
 		return;
-	end = of_read_ulong(prop, len/4);
+	end = of_read_number(prop, len/4);
 
 	early_init_dt_setup_initrd_arch(start, end);
-	pr_debug("initrd_start=0x%lx  initrd_end=0x%lx\n", start, end);
+	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
+		 (unsigned long long)start, (unsigned long long)end);
 }
 #else
 inline void early_init_dt_check_for_initrd(unsigned long node)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..4a17939 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -106,8 +106,7 @@  extern u64 dt_mem_next_cell(int s, __be32 **cellp);
  * physical addresses.
  */
 #ifdef CONFIG_BLK_DEV_INITRD
-extern void early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end);
+extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
 #endif
 
 /* Early flat tree scan hooks */