public inbox for linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox