[GIT PULL] Integrator multiplatform migration for v3.19

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Thu, Nov 06, 2014 at 12:33:51PM +0100, Arnd Bergmann wrote:
> On Thursday 06 November 2014 10:52:47 Russell King - ARM Linux wrote:
> > Unfortunately, this totally screws multiplatform support - with this
> > merged, we now can enable all CPUs from ARM720T upwards into a single
> > kernel - and that is illegal.
> > 
> > The problem is that Integrator can be ARM720T all the way up to ARMv6.
> > So, when ARCH_INTEGRATOR is enabled, you are presented with the
> > individual CPUs which the platform supports as options to select.
> > This results in randconfig seeing all the CPU options, which it can
> > then enable, resulting in:
> > 
> > CONFIG_CPU_ARM720T=y
> > CONFIG_CPU_ARM920T=y
> > CONFIG_CPU_ARM922T=y
> > CONFIG_CPU_ARM926T=y
> > CONFIG_CPU_ARM1020=y
> > CONFIG_CPU_ARM1022=y
> > CONFIG_CPU_ARM1026=y
> > CONFIG_CPU_V6=y
> > CONFIG_CPU_V6K=y
> > CONFIG_CPU_V7=y
> > 
> > which then causes:
> > 
> > arch/arm/include/asm/cmpxchg.h:114:2: error: #error "SMP is not supported on this platform"
> > arch/arm/include/asm/atomic.h:137:2: error: #error SMP not supported on pre-ARMv6 CPUs
> > 
> > Integrator doesn't fit into the "is it a pre-ARMv6 or not" platform
> > structure chosen in the early days of multiplatform support, because
> > it straddles that boundary.
> 
> I've thought about this issue before but hadn't realized that the patches
> as they went into arm-soc already cause the problem.
> 
> I think it would be best to replace all the lines like
> 
> 	bool "Support ARM926T processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB
> 
> with
> 
> 	bool "Support ARM926T processor" if ARCH_MULTI_V5 || MACH_REALVIEW_EB
> 
> and ignore whether ARCH_INTEGRATOR is set or not. Since we have the
> generic default platform for multiplatform kernels now, in theory you
> could always have any other CPU enabled without even needing an
> ARCH_* symbol, as long as the drivers are all present.

I don't like this.  The reason the config is structured like this is to:

1. Hide symbols which are not user selectable, but are force-selected in
   the Kconfig.
2. Only present the processors which are appropriate for the platform.

By removing ARCH_INTEGRATOR from the option, you're making the symbol
visible, and sometimes it'll be forced-enabled, other times it'll be
inappropriately visible.  There's absolutely no point offering ARM926T
for a PXA platform for example.

Conversely, there's no point offering support for Xscale CPUs if you
have the PXA platform enabled - it can never be disabled in that
circumstance, and offering it is nothing but shere noise.  The last
thing that Kconfig needs is yet more shite unchangeable options
appearing in the list - it's already enough of a nightmare today
without having this kind of crap added to it.

The answer is of course /not/ to remove ARCH_INTEGRATOR but to make
the processor options depend on !ARCH_MULTIPLATFORM || ARCH_MULTI_xx -
thus, allowing them to be selected in non-multi-platform environments,
and also only in their appropriate multi-platform environment.  That
means we get the best of all worlds.

It also means that people selecting the CPUs directly better do so only
according to the multiplatform CPU architecture selected, which I think
would be a useful side effect of this.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.