[PATCH] ARM: clean-up common multi-platform kconfig options

[Rob Herring]

On Fri, Dec 6, 2013 at 10:41 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 06 December 2013, Rob Herring wrote:
>> On Thu, Dec 5, 2013 at 3:50 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> > On Thursday 05 December 2013, Rob Herring wrote:
>> >> On Thu, Dec 5, 2013 at 2:25 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> >> > On Thursday 05 December 2013, Rob Herring wrote:
>> >> >> select ARM_AMBA
>> >> >> select ARM_GIC if CPU_V7
>> >> >> select HAVE_SMP if CPU_V7
>> >> >> select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7
>> >> >> select ARCH_HAS_CPUFREQ
>> >> >> select ARCH_HAS_OPP
>> >> >
>> >> > Not sure about ARM_GIC and HAVE_SMP, as they won't typically be
>> >> > set on Cortex-A8, Scorpion and PJ4. The other suggestions sound
>> >> > good, and your patch looks fine as well.
>> >>
>> >> HAVE_SMP only enables visibility of the SMP kconfig option. That could
>> >> cause randconfig builds that would not boot if SMP_ON_UP was not
>> >> enabled, but a "select SMP_ON_UP if SMP" here would fix that though.
>> >
>> > Ok, I see. "select HAVE_SMP if CPU_V7" maybe "select HAVE_SMP if
>> > ARCH_MULTI_V7" sounds reasonable then, at least I'd prefer that over
>> > the "select SMP_ON_UP if SMP" option, which would make having SMP_ON_UP
>> > as an option pointless, since you could no longer turn it off.
>> >
>> > If you set HAVE_SMP for CPU_V7, it would be logical to also set it for
>> > CPU_V6K, although I'm unsure if we actually still support any SMP V6K
>> > platforms in practice: CNS3xxx is the only such platform I'm aware of,
>> > and the SMP support for that one was never merged (it's in openwrt
>> > though).
>>
>> We should be able to boot an SMP kernel on it whether or not the
>> platform has SMP support added, right?
>
> Yes, although I don't think anyone has ever tried to boot a UP_ON_SMP
> kernel on ARMv5 or earlier. We don't allow that combination at the
> moment, and it would be pointless.

I meant an SMP capable platform (v6K+ h/w) should boot an SMP kernel
build whether or not that platform has added smp_ops yet.

>> Practically every v6 platform selects v6K. We should probably default
>> to V6K for ARCH_MULTI_V6 and let platforms select CPU_V6 instead if
>> needed. I believe that will give the v6 versions of code only as
>> needed and will give better versions of code if only v6K is selected.
>> imx31 is one that doesn't select v6K, but only very early revs did not
>> have v6K version of the 1136. I don't think any of those parts went
>> into production (maybe into the original Zune?).
>
> Interesting, I had no idea that plain ARMv6 was this rare.

What I said is not quite right. I think the correct statement is most
of ARM11 (1136 r1px and 1176) is v6K but without the SMP extensions.
AFAICT, only ARM11 MPCore is full v6K. The 1136 and 1176 do have
clrex, double/half/byte exclusives, TEX remapping, and thread ID regs,
but do not have sev and wfe/wfi instructions. SMP_ON_UP should be
enough to handle the sev/wfe instruction differences. So I still think
we really want to be selecting CPU_V6K by default.

> If we could show that all supported platforms are actually v6K anyway
> and that nobody has any plans to add new ones, doing away with
> v6 in favor of v6k would clean up a lot of confusing (i.e. possibly
> wrong) Kconfig logic.
>
>> I assume we expect a v6 SMP kernel to run on a non-v6K v6 platform?
>
> Actually, as far as I can see:
>
> config SMP
>         bool "Symmetric Multi-Processing"
>         depends on CPU_V6K || CPU_V7
>         depends on HAVE_SMP
>
> This prevents you from building a plain v6 SMP kernel, and we've
> had a variation of that since CONFIG_SMP was first marked non-BROKEN.

I'm saying a v6k enabled kernel would not work on pure v6 h/w. But
since all implementations appear to support doubleword exclusives and
there may not be any pure v6 only h/w, then we may never have a
problem with the code below.

>> if so, doing more digging I think we have a problem with
>> __kuser_cmpxchg64 on a v6 only platform with v6K enabled in the
>> kernel. Adding Nico since he wrote this. The code is ifdef'ed like
>> this:
>>
>> #if defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
>> (only true for pre-v6)
>> ...
>> #elif defined(CONFIG_CPU_32v6K)
>> (true when v6K gets enabled)
>> ...
>> #elif !defined(CONFIG_SMP)
>> #ifdef CONFIG_MMU
>> (this is the correct condition for a v6 only platform)
>> ...
>> #else
>> #warning "NPTL on non MMU needs fixing"
>> ...
>> #endif
>> #else
>> #error "incoherent kernel configuration"
>> #endif
>>
>> Any build with v6K enabled will get the double exclusive instructions
>> which won't work on v6 only platforms. It seems we need some
>> ALT_SMP/ALT_UP magic here.
>
> The above code can already be simplified a lot, since the pre-v6 and
> pre-v6k v6 cases are dead code. There are comments in Kconfig like this:
>
> config TLS_REG_EMUL
>         bool
>         select NEED_KUSER_HELPERS
>         help
>           An SMP system using a pre-ARMv6 processor (there are apparently
>           a few prototypes like that in existence) and therefore access to
>           that required register must be emulated.
>
> config NEEDS_SYSCALL_FOR_CMPXCHG
>         bool
>         select NEED_KUSER_HELPERS
>         help
>           SMP on a pre-ARMv6 processor?  Well OK then.
>           Forget about fast user space cmpxchg support.
>           It is just not possible.
>
>
> added in a commit from Nico back in 2005:
>
>     [PATCH] ARM: 2663/1: straightify TLS register emulation a bit more
>
>     Patch from Nicolas Pitre
>
>     This better express things, and should cover RMK's weird SMP toys.
>
> I don't know what "weird toys" he is referring to, but maybe he or Russell
> can shed some light on that and whether we'd expect to see support for
> them added in the future. If anyone else but Russell were to propose
> adding new platforms like those, I'd probably say no (or possibly
> NOOOOoooo) anyway.
>
>         Arnd