* Nicolas Pitre [off-list ref] [110209 08:44]:

On Wed, 9 Feb 2011, Russell King - ARM Linux wrote:

quoted

On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:

quoted

* Santosh Shilimkar [off-list ref] [110209 01:59]:

quoted

quoted

From: Dave Martin [mailto:dave.martin at linaro.org]

You could also have a "v7+" unified kernel -- i.e., supporting
OMAP3+4+SMP.
This is what we currently do in Linaro, since we're focusing on v7
and above.

This sounds good way forward considering future OMAP architectures
as well.

But I let Tony comment on this idea.

AFAIK these issues will be hopefully sorted out by the time the
next merge window opens. For the -rc cycle, disabling SMP in
config if ARMv6 is selected should do the trick.

That's not soo easy - as we don't know in the Kconfig whether we include
ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
inflated the v6v7 patchset.

Maybe the best thing to do is:

config CPU_32v6K
        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
resulting undefined instruction traps if they try to run the kernel on
V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
to this.

This should be good enough.  We're looking for a temporary stopgate 
solution to prevent people from corrupting their data, and the real fix 
will be available in the next kernel.

OK. This patch will be needed anyways for the real fixes. And no temporary
apply-undo type patching needed. The only drawback is that omap2420 and
2430 won't boot with omap2plus_defconfig, but that will be only for a
few weeks.

Acked-by: Tony Lindgren <tony@atomide.com>