From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE Date: Fri, 29 Jan 2016 23:15:34 +0000 Message-ID: <20160129231534.GT10826@n2100.arm.linux.org.uk> References: <569e1dbb.MgLv8OaZwklOxxtU%fengguang.wu@intel.com> <19656457.qoKNGRmV4Q@wuerfel> <4727572.ddrMioV3Fi@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4727572.ddrMioV3Fi@wuerfel> Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Geert Uytterhoeven , Fengguang Wu , Linux-Arch , Linux MIPS Mailing List , James Hogan , Paul Burton , linux-kbuild , Heinrich Schuchardt , "linux-kernel@vger.kernel.org" , Ralf Baechle , Florian Fainelli , Michal Marek , "linux-arm-kernel@lists.infradead.org" List-Id: linux-arch.vger.kernel.org On Fri, Jan 29, 2016 at 10:54:02PM +0100, Arnd Bergmann wrote: > Now that I think about it, I guess platforms that use values above > 0xfee00000 can also easily get into trouble as that conflicts with the > PCI I/O space, the fixmap or other special areas documented in > Documentation/arm/memory.txt. We have a bunch of those: > > default 0xfee003f8 if DEBUG_FOOTBRIDGE_COM1 > default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART > default 0xfee82340 if ARCH_IOP13XX > default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN > default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN > default 0xfef36000 if DEBUG_HIGHBANK_UART > default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 > default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 > default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 > default 0xfefff700 if ARCH_IOP33X > default 0xff003000 if DEBUG_U300_UART > default 0xffd01000 if DEBUG_HIP01_UART > > The HIP01 is the only one that looks actively dangerous here (clashes with > fixmap), the others are probably all fine but it would be nice to stay out > of that area completely. That's wrong. Given it's PCI bus architecture and it's IO space, at least one of those above is perfectly valid. 0x3f8 into IO space might ring a bell... if not the COM1 certainly should. :) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pandora.arm.linux.org.uk ([78.32.30.218]:45702 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753678AbcA2XPt (ORCPT ); Fri, 29 Jan 2016 18:15:49 -0500 Date: Fri, 29 Jan 2016 23:15:34 +0000 From: Russell King - ARM Linux Subject: Re: [linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE Message-ID: <20160129231534.GT10826@n2100.arm.linux.org.uk> References: <569e1dbb.MgLv8OaZwklOxxtU%fengguang.wu@intel.com> <19656457.qoKNGRmV4Q@wuerfel> <4727572.ddrMioV3Fi@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4727572.ddrMioV3Fi@wuerfel> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Geert Uytterhoeven , Fengguang Wu , Linux-Arch , Linux MIPS Mailing List , James Hogan , Paul Burton , linux-kbuild , Heinrich Schuchardt , "linux-kernel@vger.kernel.org" , Ralf Baechle , Florian Fainelli , Michal Marek , "linux-arm-kernel@lists.infradead.org" Message-ID: <20160129231534.ElXGtA0-kyn7LmkrOL0J6MJHCNPe3ykolSI-M7RNPXE@z> On Fri, Jan 29, 2016 at 10:54:02PM +0100, Arnd Bergmann wrote: > Now that I think about it, I guess platforms that use values above > 0xfee00000 can also easily get into trouble as that conflicts with the > PCI I/O space, the fixmap or other special areas documented in > Documentation/arm/memory.txt. We have a bunch of those: > > default 0xfee003f8 if DEBUG_FOOTBRIDGE_COM1 > default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART > default 0xfee82340 if ARCH_IOP13XX > default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN > default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN > default 0xfef36000 if DEBUG_HIGHBANK_UART > default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 > default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 > default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 > default 0xfefff700 if ARCH_IOP33X > default 0xff003000 if DEBUG_U300_UART > default 0xffd01000 if DEBUG_HIP01_UART > > The HIP01 is the only one that looks actively dangerous here (clashes with > fixmap), the others are probably all fine but it would be nice to stay out > of that area completely. That's wrong. Given it's PCI bus architecture and it's IO space, at least one of those above is perfectly valid. 0x3f8 into IO space might ring a bell... if not the COM1 certainly should. :) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.