From: Arnd Bergmann <arnd@arndb.de>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Olof Johansson <olof@lixom.net>,
"Jean-Christophe PLAGNIOL-VILLARD" <plagnioj@jcrosoft.com>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
"linux-arm-kernel" <linux-arm-kernel@lists.infradead.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [GIT PULL] at91: soc for 3.10 #2
Date: Wed, 3 Apr 2013 10:02:41 +0000 [thread overview]
Message-ID: <201304031002.41770.arnd@arndb.de> (raw)
In-Reply-To: <515BD8C8.5060701@atmel.com>
On Wednesday 03 April 2013, Nicolas Ferre wrote:
> > Also, USE_OF isn't set at that point (it's controlled by the next
> > section), so it can't be used as a replacement.
> >
> > Also, isn't it a bit backwards in the first place to first set ATAGS
> > vs no-ATAGS, and then get to choose what hardware you want to build
> > for?
>
> True, I was thinking it was a common pattern.
It's not common yet, but I want to get to the point where we can
globally disable ATAGS support for multiplatform kernels and get
only DT-enabled ones. There is no easy rule for when to select
or depend on a global feature, but there are a number of cases where
I think 'depends on' makes more sense in the long run.
Another example is CPU architecture level. Traditionally every
board selects CPU_v6 or CPU_v7, but in ARCH_MULTIPLATFORM, I created
a filter that lets you enable only one of them, and then pick all
the platforms that have the respective CPU, which is much easier
than having to know which platforms might be ARMv6 if you want to
build e.g. a kernel with THUMB2 support but as many boards enabled
as possible.
Arnd
next prev parent reply other threads:[~2013-04-03 10:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 8:52 [GIT PULL] at91: soc for 3.10 #2 Nicolas Ferre
2013-03-27 19:01 ` Arnd Bergmann
2013-03-28 8:57 ` Nicolas Ferre
2013-04-03 0:26 ` Olof Johansson
2013-04-03 7:22 ` Nicolas Ferre
2013-04-03 10:02 ` Arnd Bergmann [this message]
2013-03-28 10:38 ` [GIT PULL v2] " Nicolas Ferre
2013-04-02 17:48 ` Olof Johansson
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=201304031002.41770.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=marc.zyngier@arm.com \
--cc=nicolas.ferre@atmel.com \
--cc=olof@lixom.net \
--cc=plagnioj@jcrosoft.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox