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
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
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)
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
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
>
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
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
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/
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
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
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/
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
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
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
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
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
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
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 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 globall
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 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_
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 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
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 early_init_dt_setup
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 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
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 early_init
27 matches
Mail list logo
