Re: [linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

From: Russell King - ARM Linux
Date: Fri Jan 29 2016 - 18:15:53 EST

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 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:
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to