From mboxrd@z Thu Jan  1 00:00:00 1970
From: tony@atomide.com (Tony Lindgren)
Date: Wed, 14 Nov 2012 12:32:21 -0800
Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
In-Reply-To: <20121114202244.GE3332@n2100.arm.linux.org.uk>
References: <20121114185335.GU6801@atomide.com> <50A3EBCD.3040801@ti.com>
 <20121114202244.GE3332@n2100.arm.linux.org.uk>
Message-ID: <20121114203221.GA6801@atomide.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

* Russell King - ARM Linux <linux@arm.linux.org.uk> [121114 12:24]:
> On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
> > 
> > On 11/14/2012 12:53 PM, Tony Lindgren wrote:
> > > Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
> > > to not boot when enabled. The ARM core on it is an earlier r1p2:
> > > 
> > > CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
> > > 
> > > Unfortunately I don't have the details of errata 751472, but I'm
> > > guessing we need to disable it for r1p*.
> > 
> > I checked the CA9MP errata document and this erratum impacts all
> > r0/r1/r2 CPUs. I am wondering if the problem is because the workaround
> > requires you to set a bit in the Diagnostic Control register and the
> > read-modify-write sequence provided in the workaround is for secure
> > mode. Not sure if there is a non-secure workaround available :-(
> 
> Most likely, and there's not a lot that the kernel can sanely do about
> that.  We have ended up deciding (through being forced to because of
> how the security stuff works) that the stages prior to the kernel will
> implement the work-around enables because those stages are already
> platform specific, and the kernel will implement a "test for the
> work-around already enabled."
> 
> The net result is, if you enable an Errata in the kernel which your
> earlier boot stages has not already configured, the kernel will hang.
> Not much we can do about the hanging aspect, because the kernel takes
> an exception which we can't trap at those early stages in the boot
> process.
> 
> I'm not particularly happy about that design, but that's what we've
> ended up with through the 'design' of the security stuff forced onto
> us.

Checking for the bit already set should work in this case, I'll post
a patch for that shortly.

Regards,

Tony