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: VFP handling in multiplatform feroceon kernels
Date: Tue, 24 Jun 2014 15:57:23 +0200	[thread overview]
Message-ID: <4163058.utc3hnZrND@wuerfel> (raw)
In-Reply-To: <20140624134249.GB4489@arm.com>

On Tuesday 24 June 2014 14:42:49 Catalin Marinas wrote:
> On Tue, Jun 24, 2014 at 02:17:06PM +0100, Arnd Bergmann wrote:
> > Since 3.16, we have the ability to build a multiplatform kernel
> > that includes both kirkwood (feroceon) and some other ARMv5 CPU.
> > 
> > I accidentally stumbled over a bug in the VFP code that looks
> > like it will break at least ARM9 VFP support if CPU_FEROCEON
> > is also enabled, introduced by this (old) commit:
> 
> I would argue that the bug is in the CPU (feroceon). See the end of this
> email:
> 
> http://www.spinics.net/lists/arm-kernel/msg41460.html
> 
> and my follow-up. Basically you can't avoid the conditional compilation
> as Feroceon doesn't follow the VFP sub-architecture spec and doesn't
> present itself as a different CPU from an _ARM_ 9. Unless things have
> changed with Marvell's hardware implementation and they got a new id, I
> suggest you don't enable this for multi-platform.

We only support multiplatform configurations with Feroceon variants
that identify as Marvell-made, not the fake ARM CPU ID, and we already
rely on detecting the correct CPU type in other places, so we can e.g.
set up the cache correctly.

For all I can tell, the problem now exists only if you enable the
kirkwood platform, which does have its own ID. If this gets made
conditional on the CPU ID, we probably still also need to leave your
existing hack in place for the case of CONFIG_CPU_FEROCEON_OLD_ID
on a feroceon-only kernel.

	Arnd

  reply	other threads:[~2014-06-24 13:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 13:17 VFP handling in multiplatform feroceon kernels Arnd Bergmann
2014-06-24 13:31 ` Andrew Lunn
2014-06-24 13:47   ` Arnd Bergmann
2014-06-24 13:42 ` Catalin Marinas
2014-06-24 13:57   ` Arnd Bergmann [this message]
2014-06-24 14:04   ` Nicolas Pitre
2014-06-24 14:10     ` Catalin Marinas
2014-06-24 14:14       ` Russell King - ARM Linux
2014-06-24 14:25         ` Catalin Marinas
2014-06-24 14:32           ` Arnd Bergmann
2014-06-24 14:45             ` Nicolas Pitre
2014-06-24 14:35           ` Russell King - ARM Linux
2014-06-24 14:56             ` Nicolas Pitre
2014-06-24 15:01               ` Arnd Bergmann
2014-06-24 14:49       ` Nicolas Pitre
2014-06-24 14:56         ` Arnd Bergmann
2014-06-24 14:08 ` Russell King - ARM Linux

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=4163058.utc3hnZrND@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