[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[mark.rutland@arm.com (Mark Rutland)]

On Fri, Sep 05, 2014 at 12:05:52PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 12:45:47PM +0200, Robert Richter wrote:
> > On 05.09.14 10:32:40, Russell King - ARM Linux wrote:
> > > On Fri, Sep 05, 2014 at 09:46:42AM +0200, Robert Richter wrote:
> > > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > 
> > > > Increase maximum numbers of cpus to 32. This relates to current
> > > > maximal possible cpu number. Increasing this to 64 cpus will be a
> > > > separate patch not part of this enablement patches.
> > > > 
> > > > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > > ---
> > > >  arch/arm64/Kconfig | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > index fd4e81a4e1ce..77fb82b0f684 100644
> > > > --- a/arch/arm64/Kconfig
> > > > +++ b/arch/arm64/Kconfig
> > > > @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
> > > >  
> > > >  menu "Platform selection"
> > > >  
> > > > +config ARCH_THUNDER
> > > > +	bool "Cavium Inc. Thunder SoC Family"
> > > > +	help
> > > > +	  This enables support for Cavium's Thunder Family of SoCs.
> > > > +
> > > >  config ARCH_VEXPRESS
> > > >  	bool "ARMv8 software model (Versatile Express)"
> > > >  	select ARCH_REQUIRE_GPIOLIB
> > > > @@ -256,6 +261,7 @@ config NR_CPUS
> > > >  	range 2 32
> > > >  	depends on SMP
> > > >  	# These have to remain sorted largest to smallest
> > > > +	default "32" if ARCH_THUNDER
> > > >  	default "8"
> > > 
> > > Why do you need ARCH_THUNDER?  If it's just to change this default,
> > 
> > No, we need it just to enable all our drivers on the SoC. We want to
> > enable the SoC by using defconfig + ARCH_THUNDER. As said in my other
> > mail, I put it here to be able to base all other thunder driver patch
> > sets on this initial base patch set. Otherwise this particular patch
> > and also the dtb patch need to be shipped with all other driver patch
> > sets. This might lead to duplicate submissions of the same patch.
> > 
> > With doing defconfig + ARCH_THUNDER we also want to enable the max
> > number of cpus that is currently supported. I only enable 32 cpus
> > since booting more cpus is untested. There might be problems at the 32
> > cpu boundary. Just setting it to 64 does not mean a kernel will
> > actually boot more than 32 cpus. But if it will be ack'ed, I would be
> > fine to set NR_CPUS to 32 or 64 in general and independent from
> > ARCH_THUNDER.
> > 
> > For simplicity I better drop setting NR_CPUS in this patch.
> 
> So, ARM64 will get a big long list of "config ARCH_foo" options just
> to stuff lots of broken select statements into the configuration.  Yes,
> this may have been the norm with ARM, but it's turned out to be more
> of a problem than a solution, especially as it keeps causing Kconfig
> warnings when things change in the rest of the kernel tree.

Agreed; this seems more pain than it is worth.

> The same is true with defconfigs - Linus threatened to delete all ARM
> defconfigs except one at one point.

IMO we should continue doing what we've done so far and make the ARM64
defconfig work on everything it can by default, no ARCH_* necessary.
That's what most people will build and test and we shouldn't get
platform-specific code (well, drivers) breaking the single image.

For the extreme configurations (really tiny or really big) custom
configuration being necessary is fine. That doesn't have to involve
ARCH_* config options.

If you want to build a custom config then you should have an idea of
what you need. ARCH_* options are only necessary if someone wants a
kernel tuned for a specific SoC but doesn't know anything about that
SoC.

Mark.