From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 Jun 2013 15:56:15 +0200 (CEST) Received: from 15.mo1.mail-out.ovh.net ([188.165.38.232]:47010 "EHLO mo1.mail-out.ovh.net" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S6817387Ab3F1N4OLA0j0 (ORCPT ); Fri, 28 Jun 2013 15:56:14 +0200 Received: from mail405.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 62E9EFFA9C5 for ; Fri, 28 Jun 2013 15:56:13 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Jun 2013 15:56:37 +0200 Received: from ns32433.ovh.net (HELO localhost) (plagnioj%jcrosoft.com@213.251.161.87) by ns0.ovh.net with SMTP; 28 Jun 2013 15:56:35 +0200 Date: Fri, 28 Jun 2013 15:49:31 +0200 From: Jean-Christophe PLAGNIOL-VILLARD To: Grant Likely Cc: Rob Herring , Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , Sebastian Andrzej Siewior , Will Deacon , Max Filippov , Paul Mackerras , Jonas Bonn , Russell King , linux-c6x-dev@linux-c6x.org, x86@kernel.org, arm@kernel.org, linux-xtensa@linux-xtensa.org, James Hogan , devicetree-discuss , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Chris Zankel , Vineet Gupta , Linux Kernel Mailing List , Ralf Baechle , Santosh Shilimkar , "linuxppc-dev@lists.ozlabs.org" X-Ovh-Mailout: 178.32.228.1 (mo1.mail-out.ovh.net) Subject: Re: [PATCH] of: Specify initrd location using 64-bit Message-ID: <20130628134931.GD21034@game.jcrosoft.org> References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://uboot.jcrosoft.org/plagnioj.asc X-PGP-key-fingerprint: 6309 2BBA 16C8 3A07 1772 CC24 DEFC FFA3 279C CE7C User-Agent: Mutt/1.5.20 (2009-06-14) X-Ovh-Tracer-Id: 10766136384433990448 X-Ovh-Remote: 213.251.161.87 (ns32433.ovh.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiiedrleduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiiedrleduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 37205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: plagnioj@jcrosoft.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips 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/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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo1.mail-out.ovh.net (20.mo1.mail-out.ovh.net [188.165.45.168]) by ozlabs.org (Postfix) with ESMTP id A601D2C00A1 for ; Sat, 29 Jun 2013 09:25:51 +1000 (EST) Received: from mail405.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 88134FFA745 for ; Fri, 28 Jun 2013 15:56:13 +0200 (CEST) Date: Fri, 28 Jun 2013 15:49:31 +0200 From: Jean-Christophe PLAGNIOL-VILLARD To: Grant Likely Subject: Re: [PATCH] of: Specify initrd location using 64-bit Message-ID: <20130628134931.GD21034@game.jcrosoft.org> References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , Sebastian Andrzej Siewior , Will Deacon , Max Filippov , Paul Mackerras , Jonas Bonn , Russell King , linux-c6x-dev@linux-c6x.org, x86@kernel.org, arm@kernel.org, Rob Herring , linux-xtensa@linux-xtensa.org, James Hogan , devicetree-discuss , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Chris Zankel , Vineet Gupta , Linux Kernel Mailing List , Ralf Baechle , Santosh Shilimkar , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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/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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD) Date: Fri, 28 Jun 2013 15:49:31 +0200 Subject: [PATCH] of: Specify initrd location using 64-bit In-Reply-To: References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> Message-ID: <20130628134931.GD21034@game.jcrosoft.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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/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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [PATCH] of: Specify initrd location using 64-bit Date: Fri, 28 Jun 2013 15:49:31 +0200 Message-ID: <20130628134931.GD21034@game.jcrosoft.org> References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Grant Likely Cc: Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , Sebastian Andrzej Siewior , Will Deacon , Max Filippov , Paul Mackerras , Jonas Bonn , Russell King , linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org, James Hogan , devicetree-discuss , Rob Herring , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Chris Zankel , Vineet Gupta , Linux Kernel Mailing List , Ralf Baechle Santosh Shilimkar List-Id: devicetree@vger.kernel.org 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/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.