* Sebastian Reichel <s...@kernel.org> [150405 06:40]:
> Hi,
> 
> On Sun, Apr 05, 2015 at 06:13:47AM +0200, Matthijs van Duin wrote:
> > On 4 April 2015 at 00:52, Tony Lindgren <t...@atomide.com> wrote:
> > > Right, it affects n900 for sure. My point is that it also seems to
> > > affect 37xx versions not listed to suffer from this issue.
> > 
> > They shouldn't... erratum 430973 only affected Cortex-A8 r1, and the
> > dm37xx should have an r3p2 right?
> > 
> > A word of caution though: at least on the DM814x and AM335x, secure
> > ROM sets bit 6 (IBE) in the Auxiliary Control Register, thereby
> > enabling BTB invalidate instructions (which normally execute as nops).
> > This is presumably a leftover of the erratum 430973 workaround, but it
> > means there is a risk of running afoul of erratum 687067 if BTB
> > invalidate by MVA instructions are actually used.
> > 
> > I would actually suggest clearing IBE if it set on Cortex-A8 r2 or
> > later processors and a secure monitor call is available to do so
> > (there is on the DM814x and AM335x, dunno about the 37xx), also for
> > performance reasons: BTB invalidates are quite expensive instructions
> > (when enabled).
> 
> So if I understand the issue correct, it would be ok to enable the
> 430973 workaround in cpu_v7_switch_mm for arm multiplatform kernels
> (mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB). On unaffected
> Cortex-A8 platforms the IBE bit should be unset (resulting in a nop
> instead of the BTB flush).

Well we only want to enable for cortex-a8 revisions affected by
430973, so a custom cpu_v7_switch_mm seems like the way to go there.

And then we need checks for clearing IBE for unaffected cortex-a8
revisions. I'll check to today if I have IBE bit set on the systems
where I'm seeing issues that should not be affected by 430973.
 
> So assuming, that the same is true for non Cortex-A8 platforms: Can
> the workaround simply be enabled by default if CPU_V7 is selected?

It should be enabled conditionally.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to