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 4/4] ARM: hwcap: disable HWCAP_SWP if the CPU advertises it has exclusives
Date: Sat, 05 Jul 2014 20:46:30 +0200	[thread overview]
Message-ID: <5465358.odbrXXiqgi@wuerfel> (raw)
In-Reply-To: <20140704214847.GL21766@n2100.arm.linux.org.uk>

On Friday 04 July 2014 22:48:47 Russell King - ARM Linux wrote:
> On Fri, Jul 04, 2014 at 10:58:04PM +0200, Arnd Bergmann wrote:
> > On Friday 04 July 2014 21:51:44 Russell King - ARM Linux wrote:
> > > Hmm, we need guidance from ARM people on that.
> > > 
> > > There may well be a better way to detect between ARMv6 and ARMv6K, which
> > > is given by the architecture spec.  G7.3 of an early DDI0406 says that
> > > the MPIDR (mp affinity register) aliases to MIDR for ARMv6, but is of
> > > course implemented for ARMv6K.
> > > 
> > > This seems to be carried through to the latest ARM ARM.  So it seems
> > > this would be a more correct way to tell ARMv6 from ARMv6K.
> > > 
> > > If so, we can certainly expand cpu_architecture() to detect between the
> > > two and add a CPU_ARCH_ARMv6K in there.
> > > 
> > > Let's see what Will has to say about that when he's next around...
> > > though I think it'll require another trawl through lots of
> > > documentation.
> > 
> > I was thinking of a simpler check in __get_cpu_architecture, just
> > checking if the CPUID is ARM1136r0 since that is the only ARMv6
> > CPU core we support. Anything else that we currently report as
> > ARMv6 is actually ARMv6K.
> 
> I'm not prepared to use that as the basis for detecting between V6 and
> V6K at the moment - we don't know that for sure.  There seems to be
> some Samsung platforms which are V6 (at least they don't select V6K).

I believe we looked at that in the past and concluded it was a bug
and should be changed to V6K to reflect the actual hardware.

> Either way, this isn't something we should rush into, because it has
> the capability to break all sorts of stuff.  For example, merely
> deciding to add a CPU_ARCH_ARMv6K results in a change to /proc/cpuinfo
> (changing the "CPU architecture:" line) which is a user visible change.

Agreed, that should certainly not be done as part  of the HWCAP_SWP
change, regardless of whether we end up doing it later or in what form
we do it.

> We also have two ways to detect CPU_ARCH_ARMv6 - that needs careful
> thought as well.  We also have a number of places which test for
> equality with ARMv6, rather than less than or greater-or-equal.
> 
> Then there's all the ifdefs on CPU_V6K...

Right, good point.

> This is not something I want to rush into, and I certainly don't want
> to make assumptions such as "ARMv6 === ARM1136 r0" - and I certainly
> don't want to get stuck in a corner by making some changes and then
> finding out that they're wrong later down the line when we can't then
> fix it without more user visible churn.

Ok.

	Arnd

  reply	other threads:[~2014-07-05 18:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 19:51 [PATCH 0/4] ABI updates Russell King - ARM Linux
2014-07-04 19:52 ` [PATCH 1/4] ARM: alignment: save last kernel aligned fault location Russell King
2014-07-04 19:52 ` [PATCH 2/4] ARM: SWP emulation: always enable when SMP is enabled Russell King
2014-07-04 19:52 ` [PATCH 3/4] ARM: SWP emulation: only initialise on ARMv7 CPUs Russell King
2014-07-04 19:52 ` [PATCH 4/4] ARM: hwcap: disable HWCAP_SWP if the CPU advertises it has exclusives Russell King
2014-07-04 20:11   ` Arnd Bergmann
2014-07-04 20:51     ` Russell King - ARM Linux
2014-07-04 20:58       ` Arnd Bergmann
2014-07-04 21:48         ` Russell King - ARM Linux
2014-07-05 18:46           ` Arnd Bergmann [this message]
2014-07-07 11:02         ` Catalin Marinas
2014-07-07 11:17           ` Russell King - ARM Linux
2014-07-07 12:05             ` Catalin Marinas
2014-07-07 13:13               ` Russell King - ARM Linux
2014-07-07 13:46                 ` Catalin Marinas
2014-07-07 15:31                   ` Russell King - ARM Linux
2014-07-07 15:59                     ` Catalin Marinas
2014-07-07 16:31                       ` Russell King - ARM Linux
2014-07-07 17:50                         ` Catalin Marinas
2014-07-07  9:34       ` Will Deacon
2014-07-07  9:41         ` Russell King - ARM Linux
2014-07-07  9:51           ` Will Deacon
2014-07-04 20:12 ` [PATCH 0/4] ABI updates Arnd Bergmann
2014-07-07 11:19 ` Tony Lindgren
2014-07-07 11:23   ` Russell King - ARM Linux
2014-07-07 13:23     ` Tony Lindgren
2014-07-07 13:52 ` Catalin Marinas

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=5465358.odbrXXiqgi@wuerfel \
    --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.