All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: clean-up common multi-platform kconfig options
Date: Sun, 8 Dec 2013 04:39:45 +0100	[thread overview]
Message-ID: <201312080439.46063.arnd@arndb.de> (raw)
In-Reply-To: <20131207181052.GR4360@n2100.arm.linux.org.uk>

On Saturday 07 December 2013, Russell King - ARM Linux wrote:
> So, as far as I'm aware, today, a kernel which has V6, V6K and V7
> will work across all those CPUs.
> 
> What's rather annoying in this thread is that you and Arnd are running
> around seemingly making decisions on this without bothering to find out
> the details, in persuit of endless cleanups.  Where is this heading?

I admit that we've been stumbling a bit in the dark at some points, but
that doesn't mean every idea ends up in a patch that even gets submitted.

What I've concluded so far is (please correct any statements that you
find are wrong):

* there is no harm in "select HAVE_SMP if CPU_V7" for multiplatform, as
  was the original suggestion. Whether we want to actually do that is
  open for discussion when someone submits a patch.

* It was a mistake (I guess mine) to 'select CPU_V6' from ARCH_MULTI_V6,
  since that makes V6K based platforms slower without a reason, and we
  probably want to do something else.

* A kernel which enables V6, V6K and V7 has a broken kuser_cmpxchg64
  implementation on pre-V6K CPUs.

* Most platforms (possibly every one but OMAP2) that select CPU_V6
  today are actually V6K compatible. It's probably worth asking those
  V6 platform maintainers to change their CPU selection after confirming
  that they are V6K-only.

* I'm still trying to understand the full implications of
  CONFIG_CPU_USE_DOMAIN, but according to the comment in 247055aa21ffe
  "ARM: 6384/1: Remove the domain switching on ARMv6k/v7 CPUs", it seems
  to be a bug to enable this on v6k or v7 CPUs, which we currently do
  whenever CPU_V6 (implied by CONFIG_MULTI_V6) is enabled.

	Arnd

  parent reply	other threads:[~2013-12-08  3:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 16:58 [PATCH] ARM: clean-up common multi-platform kconfig options Rob Herring
2013-12-05 20:25 ` Arnd Bergmann
2013-12-05 21:34   ` Rob Herring
2013-12-05 21:50     ` Arnd Bergmann
2013-12-06  4:10       ` Rob Herring
2013-12-06 16:41         ` Arnd Bergmann
2013-12-06 16:59           ` Nicolas Pitre
2013-12-06 20:01           ` Rob Herring
2013-12-07  4:52             ` Arnd Bergmann
2013-12-07 17:41               ` Tony Lindgren
2013-12-07 18:10             ` Russell King - ARM Linux
2013-12-07 20:49               ` Rob Herring
2013-12-08  2:21                 ` Nicolas Pitre
2013-12-08  3:02                   ` Arnd Bergmann
2013-12-08  3:39               ` Arnd Bergmann [this message]
2013-12-07 18:02           ` Russell King - ARM Linux
2013-12-07 18:31             ` Arnd Bergmann
2013-12-11 16:41 ` Michal Simek

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=201312080439.46063.arnd@arndb.de \
    --to=arnd@arndb.de \
    --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.