VFP handling in multiplatform feroceon kernels

[catalin.marinas@arm.com (Catalin Marinas)]

On Tue, Jun 24, 2014 at 03:14:23PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 03:10:56PM +0100, Catalin Marinas wrote:
> > On Tue, Jun 24, 2014 at 03:04:14PM +0100, Nicolas Pitre wrote:
> > > On Tue, 24 Jun 2014, 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.
> > > 
> > > Only the early revision did hijack the ARM9 ID but still. We certainly 
> > > can determine at run time if the platform being booted is equiped with a 
> > > Feroceon before user space is started.  In that case I'd suggest some 
> > > runtime code patching to branch to some out-of-line assembly code for 
> > > Feroceon.
> > 
> > You don't even need to branch to out of line assembly, just branch over
> > the imprecise VFP abort handling in arch/arm/vfp/vfphw.S.
> 
> This is not just about VFP - it's much bigger than that.  Feroceon can't
> use proc-arm926.S (it has errata in the cache maintanence instructions)
> which also need handing.  That's why we have a separate implementation
> (proc-feroceon.S) so that ARM926 is not hurt by this stupidity.

As Arnd suggested, we could enable multi-platform only for newer
Feroceon chips which presumably have different id, keeping
CONFIG_CPU_FEROCEON_OLD_ID disabled. The VFP code needs to be changed to
depend on CPU_FEROCEON_OLD_ID, otherwise do proper id checking.

Are there other places where we need to check for CPU_FEROCEON_OLD_ID?

-- 
Catalin