ARM errata corrections

ARM errata corrections

[Shinya Kuribayashi]

Hello Catalin, Will (and Dave, may be interested in),

I've been holding these two patches at hand for more than a year, but
don't want to any further.  This kind of errata updates can be easily
overlooked, or even if proper patches are prepared, it is so easy to
forget to up-port them when upgrading the kernels.

I believe we have many r2pX Cortex-A9 MPcore silicons out there.  Let's
get them corrected in the master.

Could you take a look please?
-- 
Shinya Kuribayashi
Renesas Electronics

[PATCH] ARM: errata: Update the workaround for the 742231 Cortex-A9 erratum

[Shinya Kuribayashi]

Workaround for the 742231 erratum has been updated, which explains
that bit #22 is required only for Cortex-A9 MPcore configuration with
1 single processor and the ACP present.

That means, it's not needed for the SMP kernel.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---

 Since #742231 is associated with SMP, it's safe to remove bit #22
 for now, but I'm concerned that 'MPcore + 1 processor + ACP' case
 still remains as untreated.  Do we need to support the case?

 arch/arm/mm/proc-v7.S |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 2c559ac..8f8fced 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -352,7 +352,6 @@ __v7_setup:
 	teqne	r6, #0x22			@ present in r2p2
 	mrceq	p15, 0, r10, c15, c0, 1		@ read diagnostic register
 	orreq	r10, r10, #1 << 12		@ set bit #12
-	orreq	r10, r10, #1 << 22		@ set bit #22
 	mcreq	p15, 0, r10, c15, c0, 1		@ write diagnostic register
 #endif
 #ifdef CONFIG_ARM_ERRATA_743622
-- 
1.7.8

[PATCH] ARM: errata: Faulty logic in the Store Buffer may lead to data corruption

[Shinya Kuribayashi]

This is an update for the existing software workaround for the 743622
Cortex-A9 erratum (475d92fc6e ARM: 6416/1: errata: faulty hazard checking
in the Store Buffer may lead to data corruption).

According to the later errata notice updates, this erratum turned out
to be present not only in (r2p0..r2p2), but in all r2p* revisions.
Also the errata title is corrected to indicate that the errata leads to
data corruption, and not to a processor deadlock as sometimes mentioned
in previous revisions of the document.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
 arch/arm/Kconfig      |    4 ++--
 arch/arm/mm/proc-v7.S |    4 +---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 776d76b..ed474b6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1268,11 +1268,11 @@ config PL310_ERRATA_727915
 	  Invalidate by Way operation.
 
 config ARM_ERRATA_743622
-	bool "ARM errata: Faulty hazard checking in the Store Buffer may lead to data corruption"
+	bool "ARM errata: Faulty logic in the Store Buffer may lead to data corruption"
 	depends on CPU_V7
 	help
 	  This option enables the workaround for the 743622 Cortex-A9
-	  (r2p0..r2p2) erratum. Under very rare conditions, a faulty
+	  (r2p0..r2p10) erratum. Under very rare conditions, a faulty
 	  optimisation in the Cortex-A9 Store Buffer may lead to data
 	  corruption. This workaround sets a specific bit in the diagnostic
 	  register of the Cortex-A9 which disables the Store Buffer
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 8f8fced..9f1912d 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -355,9 +355,7 @@ __v7_setup:
 	mcreq	p15, 0, r10, c15, c0, 1		@ write diagnostic register
 #endif
 #ifdef CONFIG_ARM_ERRATA_743622
-	teq	r6, #0x20			@ present in r2p0
-	teqne	r6, #0x21			@ present in r2p1
-	teqne	r6, #0x22			@ present in r2p2
+	teq	r5, #0x00200000			@ present in r2p*
 	mrceq	p15, 0, r10, c15, c0, 1		@ read diagnostic register
 	orreq	r10, r10, #1 << 6		@ set bit #6
 	mcreq	p15, 0, r10, c15, c0, 1		@ write diagnostic register
-- 
1.7.8

[PATCH] ARM: errata: Faulty logic in the Store Buffer may lead to data corruption

[Catalin Marinas]

On Tue, Dec 20, 2011 at 08:38:09AM +0000, Shinya Kuribayashi wrote:
> This is an update for the existing software workaround for the 743622
> Cortex-A9 erratum (475d92fc6e ARM: 6416/1: errata: faulty hazard checking
> in the Store Buffer may lead to data corruption).
> 
> According to the later errata notice updates, this erratum turned out
> to be present not only in (r2p0..r2p2), but in all r2p* revisions.
> Also the errata title is corrected to indicate that the errata leads to
> data corruption, and not to a processor deadlock as sometimes mentioned
> in previous revisions of the document.
> 
> Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

[PATCH] ARM: errata: Update the workaround for the 742231 Cortex-A9 erratum

[Catalin Marinas]

On Tue, Dec 20, 2011 at 08:37:42AM +0000, Shinya Kuribayashi wrote:
> Workaround for the 742231 erratum has been updated, which explains
> that bit #22 is required only for Cortex-A9 MPcore configuration with
> 1 single processor and the ACP present.
> 
> That means, it's not needed for the SMP kernel.
> 
> Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
> ---
> 
>  Since #742231 is associated with SMP, it's safe to remove bit #22
>  for now, but I'm concerned that 'MPcore + 1 processor + ACP' case
>  still remains as untreated.  Do we need to support the case?
> 
>  arch/arm/mm/proc-v7.S |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 2c559ac..8f8fced 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -352,7 +352,6 @@ __v7_setup:
>  	teqne	r6, #0x22			@ present in r2p2
>  	mrceq	p15, 0, r10, c15, c0, 1		@ read diagnostic register
>  	orreq	r10, r10, #1 << 12		@ set bit #12
> -	orreq	r10, r10, #1 << 22		@ set bit #22
>  	mcreq	p15, 0, r10, c15, c0, 1		@ write diagnostic register

Most A9 configurations I'm aware of are indeed SMP. But maybe you could
add a !CONFIG_SMP around bit 22 setting, just in case there are
platforms using this together with an ACP.

-- 
Catalin