[PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*

[Catalin Marinas]

On 16 November 2012 18:39, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Nov 16, 2012 at 06:09:28PM +0000, Catalin Marinas wrote:
>> On Fri, Nov 16, 2012 at 09:59:21AM +0000, Russell King - ARM Linux wrote:
>> > On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
>> > > So we should make all these work-arounds depend on !MULTI_PLATFORM then.
>> >
>> > No, because some of the work-arounds don't require setting bits in magic
>> > registers.
>> >
>> > Also realise this: we test for the revision of the CPU to which they're
>> > applicable before attempting to set them.  If you have a work-around
>> > enabled in the kernel, and it fails at boot, _that_ is an indicator not
>> > that the kernel is doing something wrong, but that you need to ensure
>> > that the work-around has been applied by the earlier stages.
>> >
>> > It's not about "but platform X doesn't need it" - it's about platform X
>> > not having the earlier stages updated to fix the errata.
>>
>> There is another aspect. Many CPUs in the field, even if they are a
>> certain rxpy revision, have ECO fixes applied for critical bugs and
>> don't require the workaround. Sometimes those undocumented bits have
>> considerable performance impact and vendors may apply an ECO (unless
>> they are very late in the tape-out process). But the ECO fix does not
>> change the CPU revision, hence the workaround becomes platform specific.
>>
>> That's why I think it's better if those workarounds are just pushed to
>> the boot-loader for multi-platform kernels. Linux could still check the
>> bits and warn about them rather than failing to boot.
>
> ... and that's a U-turn if ever there was one... it's ARM Ltd who've been
> pushing to have these work-arounds in the kernel in the first place.

I wouldn't say it's a U-turn. ARM Ltd never had an official position
(i.e. document) on where the secure-only workarounds should be
implemented (but I think there should have been one). The most
convenient for me and SoC vendors was to push the workarounds into the
kernel, together with other run-time workarounds (which we must keep
in the kernel anyway).

> Should we just remove all the work-arounds, and require boot loaders,
> including the one on Versatile platforms, to implement this?  Why should
> we treat secure platforms be any different from the non-secure ones in
> this regard?  After all, this _does_ stand in the way of a single kernel
> image working properly on secure and non-secure platforms.

I'll ack this (but not all SoC vendors will agree). ARM Ltd, with the
introduction of TZ in ARMv6, made it clear that a general-purpose OS
should not differentiate between secure and non-secure worlds (no
register to read the state from). Furthermore, with the virtualisation
extensions (ARMv7, ARMv8), the general-purpose OS is supposed to run
in non-secure mode. This means that the place for secure-only
workarounds is outside the OS kernel.

> The more this thread progresses, the more I think the decision to put
> errata into the kernel was the wrong one.

Not entirely. This started at a time when we didn't have TZ (ARM1136).
We may also use Linux as a bootloader (kexec) and it's not clear
whether we need a pre-bootloader. But I think for now we could just
make the secure-only boot-time workarounds depend on
!ARCH_MULTIPLATFORM. For newer cores like Cortex-A15/A7 where we know
that Linux always runs in NS mode, don't add new secure-only
workarounds.

For AArch64 I will not merge any secure-only errata workarounds. I'll
leave this to the firmware (can be UEFI or a bootloader). The same for
other implementation-defined bits like SMP/nAMP which Linux can't
touch while in NS mode.

-- 
Catalin