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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140905125147.GC20164@leverpostej>
Date:	Fri, 5 Sep 2014 13:51:47 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Robert Richter <robert.richter@...iumnetworks.com>,
	Robert Richter <rric@...nel.org>,
	Will Deacon <Will.Deacon@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Olof Johansson <olof@...om.net>,
	Radha Mohan Chintakuntla <rchintakuntla@...ium.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium
 Thunder SoC Family

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@...ium.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@...ium.com>
> > > > Signed-off-by: Robert Richter <rrichter@...ium.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/