From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Jul 2013 09:49:23 +0200 (CEST) Received: from www.linutronix.de ([62.245.132.108]:54465 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6823690Ab3GAHtLB0MOd (ORCPT ); Mon, 1 Jul 2013 09:49:11 +0200 Received: from localhost ([127.0.0.1] helo=[172.123.10.21]) by Galois.linutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1UtYqr-0000Vs-UZ; Mon, 01 Jul 2013 09:48:46 +0200 Message-ID: <51D1345B.8020509@linutronix.de> Date: Mon, 01 Jul 2013 09:48:43 +0200 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Santosh Shilimkar CC: Jean-Christophe PLAGNIOL-VILLARD , Grant Likely , Rob Herring , Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , 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 , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [PATCH] of: Specify initrd location using 64-bit References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com> In-Reply-To: <51CE1F92.3070802@ti.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 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: 37234 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: bigeasy@linutronix.de 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Galois.linutronix.de (www.linutronix.de [62.245.132.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 945652C02B1 for ; Mon, 1 Jul 2013 17:49:17 +1000 (EST) Message-ID: <51D1345B.8020509@linutronix.de> Date: Mon, 01 Jul 2013 09:48:43 +0200 From: Sebastian Andrzej Siewior MIME-Version: 1.0 To: Santosh Shilimkar Subject: Re: [PATCH] of: Specify initrd location using 64-bit References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com> In-Reply-To: <51CE1F92.3070802@ti.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , Will Deacon , Max Filippov , Paul Mackerras , Jonas Bonn , Russell King , linux-c6x-dev@linux-c6x.org, x86@kernel.org, arm@kernel.org, Rob Herring , Grant Likely , Jean-Christophe PLAGNIOL-VILLARD , 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 , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: bigeasy@linutronix.de (Sebastian Andrzej Siewior) Date: Mon, 01 Jul 2013 09:48:43 +0200 Subject: [PATCH] of: Specify initrd location using 64-bit In-Reply-To: <51CE1F92.3070802@ti.com> References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com> Message-ID: <51D1345B.8020509@linutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: [PATCH] of: Specify initrd location using 64-bit Date: Mon, 01 Jul 2013 09:48:43 +0200 Message-ID: <51D1345B.8020509@linutronix.de> References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com> <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com> <51CCA67C.2010803@gmail.com> <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51CE1F92.3070802-l0cyMroinI0@public.gmane.org> 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: Santosh Shilimkar Cc: Nicolas Pitre , linux-mips , Aurelien Jacquiot , Catalin Marinas , 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, Grant Likely , 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 , linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org List-Id: devicetree@vger.kernel.org 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