All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
Date: Fri, 5 Sep 2014 15:22:46 +0100	[thread overview]
Message-ID: <20140905142245.GG20164@leverpostej> (raw)
In-Reply-To: <7863371.EMkUuntQWU@wuerfel>

Hi Arnd,

[...]

> A common pattern these days is to do dependencies like
> 
> arch/*/Kconfig:
> 	config ARCH_FOO
> 	bool "Enable support for Foo platform"
> 	help
> 	  ...
> 
> 
> drivers/*/Kconfig
> 	config SUBSYS_FOO
> 	bool "SUBSYS driver for Foo"
> 	depends on ARCH_FOO || COMPILE_TEST
> 	depends on OF && REGULATOR && GENERIC_PHY # or whatever

Russell's comments w.r.t. Kconfig warnings when config names change
still holds regardless of select vs depends on.

> That way we can enable everything in the defconfig, but someone
> who likes to build a more specialized kernel can disable the
> other platforms and won't get the drivers that are specific to
> those.
> 
> I personally think this is a bit more verbose than what we need, but
> I don't strongly object doing it that way.

You'd still be able to do this without ARCH_FOO, though you would need
to know which drivers are necessary for a particular SoC. That seems to
be the way things are handled on x86; I don't recall having to select
support for specific machines there, just the individual drivers.

> The code size really should not matter much on ARM64 though: it's
> unlikely we will see a lot of systems with less than a few gigabytes
> of memory, and I expect that a generic kernel would be e.g. 6 MB
> instead of 4 MB for a platform specific kernel.

Agreed. If there kernel size begins looking unwieldy we either need to
be compiling more things as modules or a more drastic kernel weight loss
program.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Robert Richter <rric@kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Robert Richter <robert.richter@caviumnetworks.com>,
	Olof Johansson <olof@lixom.net>,
	Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Subject: Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
Date: Fri, 5 Sep 2014 15:22:46 +0100	[thread overview]
Message-ID: <20140905142245.GG20164@leverpostej> (raw)
In-Reply-To: <7863371.EMkUuntQWU@wuerfel>

Hi Arnd,

[...]

> A common pattern these days is to do dependencies like
> 
> arch/*/Kconfig:
> 	config ARCH_FOO
> 	bool "Enable support for Foo platform"
> 	help
> 	  ...
> 
> 
> drivers/*/Kconfig
> 	config SUBSYS_FOO
> 	bool "SUBSYS driver for Foo"
> 	depends on ARCH_FOO || COMPILE_TEST
> 	depends on OF && REGULATOR && GENERIC_PHY # or whatever

Russell's comments w.r.t. Kconfig warnings when config names change
still holds regardless of select vs depends on.

> That way we can enable everything in the defconfig, but someone
> who likes to build a more specialized kernel can disable the
> other platforms and won't get the drivers that are specific to
> those.
> 
> I personally think this is a bit more verbose than what we need, but
> I don't strongly object doing it that way.

You'd still be able to do this without ARCH_FOO, though you would need
to know which drivers are necessary for a particular SoC. That seems to
be the way things are handled on x86; I don't recall having to select
support for specific machines there, just the individual drivers.

> The code size really should not matter much on ARM64 though: it's
> unlikely we will see a lot of systems with less than a few gigabytes
> of memory, and I expect that a generic kernel would be e.g. 6 MB
> instead of 4 MB for a platform specific kernel.

Agreed. If there kernel size begins looking unwieldy we either need to
be compiling more things as modules or a more drastic kernel weight loss
program.

Mark.

  reply	other threads:[~2014-09-05 14:22 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  7:46 [PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family Robert Richter
2014-09-05  7:46 ` Robert Richter
2014-09-05  7:46 ` [PATCH v2 1/4] arm64, thunder: Add Kconfig option for " Robert Richter
2014-09-05  7:46   ` Robert Richter
2014-09-05  8:39   ` Will Deacon
2014-09-05  8:39     ` Will Deacon
2014-09-05  9:21     ` Robert Richter
2014-09-05  9:21       ` Robert Richter
2014-09-05  9:25       ` Will Deacon
2014-09-05  9:25         ` Will Deacon
2014-09-05  9:36         ` Mark Rutland
2014-09-05  9:36           ` Mark Rutland
2014-09-05 10:51           ` Robert Richter
2014-09-05 10:51             ` Robert Richter
2014-09-05  9:32   ` Russell King - ARM Linux
2014-09-05  9:32     ` Russell King - ARM Linux
2014-09-05 10:45     ` Robert Richter
2014-09-05 10:45       ` Robert Richter
2014-09-05 11:05       ` Russell King - ARM Linux
2014-09-05 11:05         ` Russell King - ARM Linux
2014-09-05 12:51         ` Mark Rutland
2014-09-05 12:51           ` Mark Rutland
2014-09-05 14:04           ` Arnd Bergmann
2014-09-05 14:04             ` Arnd Bergmann
2014-09-05 14:22             ` Mark Rutland [this message]
2014-09-05 14:22               ` Mark Rutland
2014-09-05 16:25               ` Arnd Bergmann
2014-09-05 16:25                 ` Arnd Bergmann
2014-09-08 11:01                 ` Robert Richter
2014-09-08 11:01                   ` Robert Richter
2014-09-08 12:29                   ` Arnd Bergmann
2014-09-08 12:29                     ` Arnd Bergmann
2014-09-08 18:25                   ` Rob Herring
2014-09-08 18:25                     ` Rob Herring
2014-09-05  7:46 ` [PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC Robert Richter
2014-09-05  7:46   ` Robert Richter
2014-09-05 11:21   ` Arnd Bergmann
2014-09-05 11:21     ` Arnd Bergmann
2014-09-05 11:21     ` Arnd Bergmann
2014-09-11 14:51     ` Robert Richter
2014-09-11 14:51       ` Robert Richter
2014-09-11 14:51       ` Robert Richter
2014-09-05  7:46 ` [PATCH v2 3/4] arm64, thunder: Document devicetree bindings " Robert Richter
2014-09-05  7:46   ` Robert Richter
2014-09-05  8:42   ` Will Deacon
2014-09-05  8:42     ` Will Deacon
2014-09-05  8:42     ` Will Deacon
2014-09-05  9:32     ` Robert Richter
2014-09-05  9:32       ` Robert Richter
2014-09-05  9:39       ` Mark Rutland
2014-09-05  9:39         ` Mark Rutland
2014-09-05  9:39         ` Mark Rutland
2014-09-08  7:54         ` Robert Richter
2014-09-08  7:54           ` Robert Richter
2014-09-08  7:54           ` Robert Richter
2014-09-05  7:46 ` [PATCH v2 4/4] arm64, defconfig: Enable Cavium Thunder SoC in defconfig Robert Richter
2014-09-05  7:46   ` Robert Richter
2014-09-05  8:42 ` [PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family Will Deacon
2014-09-05  8:42   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140905142245.GG20164@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.