[PATCH v2 2/3] ARM: remove remaining definitions of PLAT_PHYS_OFFSET from <mach/memory.h>

[u.kleine-koenig@pengutronix.de (Uwe Kleine-König)]

Hello Russell,

On Fri, Jul 25, 2014 at 11:09:12AM +0200, Uwe Kleine-K?nig wrote:
> On Fri, Jul 25, 2014 at 01:06:22AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 07, 2014 at 09:13:05AM +0200, Uwe Kleine-K?nig wrote:
> > > The platforms selecting NEED_MACH_MEMORY_H defined the start address of
> > > their physical memory in the respective <mach/memory.h>. With
> > > ARM_PATCH_PHYS_VIRT=y (which is quite common today) this is useless
> > > though because the definition isn't used but determined dynamically.
> > > 
> > > So remove the definitions from all <mach/memory.h> and provide the
> > > Kconfig symbol PHYS_OFFSET with the respective defaults in case
> > > ARM_PATCH_PHYS_VIRT isn't enabled.
> > > 
> > > This allows to drop the dependency of PHYS_OFFSET on !NEED_MACH_MEMORY_H
> > > which prevents compiling an integrator nommu-kernel.
> > > (CONFIG_PAGE_OFFSET which has "default PHYS_OFFSET if !MMU" expanded to
> > > "0x" because CONFIG_PHYS_OFFSET doesn't exist as INTEGRATOR selects
> > > NEED_MACH_MEMORY_H.)
> > 
> > Should I assume that this hasn't been build tested?
> darn, I admit being guilty not retesting it after rebasing to 3.16-rc. I
> think I did test it when I wrote the patch the first time, but you made
> me unsure if I tested all relevant cases. Working on a follow-up patch.
The following patch fixes all defconfigs:

diff --git a/arch/arm/mach-realview/include/mach/memory.h b/arch/arm/mach-realview/include/mach/memory.h
index eb69feb3b804..23e7a313f75d 100644
--- a/arch/arm/mach-realview/include/mach/memory.h
+++ b/arch/arm/mach-realview/include/mach/memory.h
@@ -20,6 +20,8 @@
 #ifndef __ASM_ARCH_MEMORY_H
 #define __ASM_ARCH_MEMORY_H
 
+#ifdef CONFIG_SPARSEMEM
+
 /*
  * Sparsemem definitions for RealView PBX.
  *

PLAT_PHYS_OFFSET then still has this strange value on builds with
ARM_PATCH_PHYS_VIRT=y, but this doesn't matter as the value is unused
then.

Do you squash this into the faulty patch or should I follow up with a
proper patch to repair the mess?

Sorry again
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |