ARM errata 430973 on multi platform kernels (was: OMAP3-N900: Add microphone bias voltages)

From: Sebastian Reichel <sre@kernel.org>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	Pavel Machek <pavel@ucw.cz>
Subject: ARM errata 430973 on multi platform kernels (was: OMAP3-N900: Add microphone bias voltages)
Date: Fri, 3 Apr 2015 18:35:54 +0200	[thread overview]
Message-ID: <20150403163553.GA16247@earth> (raw)
In-Reply-To: <20150401194734.GT10805@atomide.com>

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

Hi,

On Wed, Apr 01, 2015 at 12:47:36PM -0700, Tony Lindgren wrote:
> > > OK I think debian is using v3.16 kernel
> > 
> > Yes. It will be used for Debian jessie (not yet released) and the
> > N900 related drivers are enabled in the armmp flavour. Unfortunately
> > it does not work together with thumb using userland because the
> > errata 430973 workaround is not enabled.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768890
> 
> Hmm I believe many ARMv8 boards will be randomly oopsing
> with armhf without that. I sort of recall random oopses just
> with running apt-get update on ARMv8 omaps on armhf without that:

Since I don't know of any ARMv8 omaps, I will read ARMv8 as ARMv7.

And yes, for armhf userland one gets random oopses at least on the
Nokia N900. AFAIK this is not true for all ARMv7 processors
(especially non omaps), though.

> http://www.spinics.net/lists/linux-omap/msg108511.html
> 
> See also 5c86c5339c56 ("ARM: omap2plus_defconfig: Enable ARM erratum
> 430973 for omap3").

For me the random oopses occur without this config flag and are
fixed by it. The workaround is not very suitable for multi platform
kernels, though, since its enabled also for unaffected platforms.

As far as I can see the CONFIG_ARM_ERRATA_430973 flag is checked
in proc-v7.S and in proc-v7-2level.S. I think the first file is
irrelevant, since it can be fixed later (see workaround in
nokia_n900_legacy_init in pdata-quirks.c).

So basically the problem comes down to proc-v7-2level.S

> I wonder if the ARMv8 revision range might be wrong 430973 in
> kernel or errata?

what revision range? I think the errata is enabled unconditionally
or disabled completly.

> Also I recall that 430973 change to the
> arch/arm/mm/proc-v7-2level.S fixed the issue, this should be
> verified though.

If I understand the errata correctly the BTAC/BTB flushing is
important. It would be nice if it could be limited to affected
devices, though.

> > I guess it should be tried to change the workaround, so that it does
> > only change the behaviour of affected platforms. Otherwise its a
> > hard decision for distributions to enable the workaround.
> 
> Well we should figure out first why flush BTAC/BTB is needed in
> cpu_v7_switch_mm.. And if what I'm describing above is still
> reproducable.

Reading the help text in the kernel the flushing is the actual
workaround. The other changes only make it possible to do the
flushing.

Maybe an option would be to provide two cpu_v7_switch_mm
implementations (one with the errata and one without). Then
the system can start with the simple implementation. Once
the boot as progressed far enough to know, that the hardware
is affected by the errata, it could switch to the implementation
with the flushing.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]