[PATCH 0/2] Errata workaround updates

Hello,

After Russell pointed out that we weren't applying an erratum workaround
in all cases that it was required:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/082730.html

I went back through the documents for PL310 and Cortex-A9 to check that
what we have in Linux matches the latest workarounds. The only other
issue I found was that the PL310 workaround we have for #727915 (added
by Santosh in 2839e06c ("ARM: 6795/1: l2x0: Errata fix for flush by Way
operation can cause data corrupti") will work only on r3p0, leaving r2p0
broken. If anybody has an r2p0 version of the PL310, they may like to
augment the workaround.

While I was at it, I fixed a couple of Kconfig select statements that
needed updating to identify the correct workaround config option.

Cc: Santosh Shilimkar <redacted>

Will Deacon (2):
  ARM: errata: update workaround for A9 erratum #743622
  ARM: errata: fix PL310 erratum #753970 workaround selection

 arch/arm/Kconfig               |    2 +-
 arch/arm/mach-ux500/Kconfig    |    2 +-
 arch/arm/mach-vexpress/Kconfig |    2 +-
 arch/arm/mm/proc-v7.S          |    4 +---
 4 files changed, 4 insertions(+), 6 deletions(-)

-- 
1.7.4.1

Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so
ensure that the workaround is applied regardless of the revision.

Reported-by: Russell King - ARM Linux <redacted>
Signed-off-by: Will Deacon <redacted>
---
 arch/arm/Kconfig      |    2 +-
 arch/arm/mm/proc-v7.S |    4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 24626b0..5133128 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

@@ -1282,7 +1282,7 @@ config ARM_ERRATA_743622
 	depends on CPU_V7
 	help
 	  This option enables the workaround for the 743622 Cortex-A9
-	  (r2p0..r2p2) erratum. Under very rare conditions, a faulty
+	  (r2p*) 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 7e9b5bf..a4d5a76 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S

@@ -234,9 +234,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			@ only 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.4.1

Commit fa0ce403 ("ARM: 7162/1: errata: tidy up Kconfig options for PL310
errata workarounds") introduced a consistent naming scheme for errata
workarounds, but forgot to update the platforms selecting workarounds
using the old names.

This patch updates ux500 and vexpress to select the appropriate PL310
errata workarounds.

Signed-off-by: Will Deacon <redacted>
---
 arch/arm/mach-ux500/Kconfig    |    2 +-
 arch/arm/mach-vexpress/Kconfig |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index a3e0c86..9c8a9e7 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig

@@ -5,7 +5,7 @@ config UX500_SOC_COMMON
 	default y
 	select ARM_GIC
 	select HAS_MTU
-	select ARM_ERRATA_753970
+	select PL310_ERRATA_753970
 	select ARM_ERRATA_754322
 
 menu "Ux500 SoC"

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 9b3d0fb..88c3ba1 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig

@@ -7,7 +7,7 @@ config ARCH_VEXPRESS_CA9X4
 	select ARM_GIC
 	select ARM_ERRATA_720789
 	select ARM_ERRATA_751472
-	select ARM_ERRATA_753970
+	select PL310_ERRATA_753970
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 

-- 
1.7.4.1

Will,

On Wed, Feb 1, 2012 at 7:22 PM, Will Deacon [off-list ref] wrote:

Hello,

After Russell pointed out that we weren't applying an erratum workaround
in all cases that it was required:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/082730.html

I went back through the documents for PL310 and Cortex-A9 to check that
what we have in Linux matches the latest workarounds. The only other
issue I found was that the PL310 workaround we have for #727915 (added
by Santosh in 2839e06c ("ARM: 6795/1: l2x0: Errata fix for flush by Way
operation can cause data corrupti") will work only on r3p0, leaving r2p0
broken. If anybody has an r2p0 version of the PL310, they may like to
augment the workaround.

While I was at it, I fixed a couple of Kconfig select statements that
needed updating to identify the correct workaround config option.

Cc: Santosh Shilimkar <redacted>

Will Deacon (2):
?ARM: errata: update workaround for A9 erratum #743622
?ARM: errata: fix PL310 erratum #753970 workaround selection

The patches look fine to me.
Here is my ack if you need one.
Acked-by: Santosh Shilimkar <redacted>

On Wed, 1 Feb 2012, Will Deacon wrote:

Hello,

After Russell pointed out that we weren't applying an erratum workaround
in all cases that it was required:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/082730.html

I went back through the documents for PL310 and Cortex-A9 to check that
what we have in Linux matches the latest workarounds.

Ideally, you should not limit the workaround only to those revisions 
known to be broken but to any revision.  Only when a particular revision 
is known to be fixed then should it be disabled.


Nicolas

On Wed, Feb 01, 2012 at 04:26:18PM +0000, Nicolas Pitre wrote:

On Wed, 1 Feb 2012, Will Deacon wrote:

quoted

Hello,

After Russell pointed out that we weren't applying an erratum workaround
in all cases that it was required:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/082730.html

I went back through the documents for PL310 and Cortex-A9 to check that
what we have in Linux matches the latest workarounds.

Ideally, you should not limit the workaround only to those revisions 
known to be broken but to any revision.  Only when a particular revision 
is known to be fixed then should it be disabled.

For the general case I'd be inclined to agree, but when it involves poking
undocumented diagnostic registers I get scared and would rather only do it
when we know it's safe (since it could easily cause more problems on other
versions of the CPU).

Will