All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Rob Herring <robherring2@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Tony Lindgren <tony@atomide.com>,
	Dave Martin <dave.martin@linaro.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Jon Hunter <jon-hunter@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Date: Fri, 16 Nov 2012 10:05:50 +0000	[thread overview]
Message-ID: <20121116100550.GI3332@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <50A50C24.9010702@gmail.com>

On Thu, Nov 15, 2012 at 09:37:08AM -0600, Rob Herring wrote:
> >> Does that work for Versatile Express CA9? It needs ARM_ERRATA_751472.
> > 
> > On VE Linux runs in secure mode, so it's fine.
> 
> WTF? You are contradicting yourself.

No, it's already been explained; the problem is lack of understanding.

Versatile Express does indeed run in secure mode; it doesn't have any
secure monitor present.  OMAP and many other platforms run in non-secure
mode.

The work-arounds are applied to secure mode registers which are sensitive
to writes in the following manner:
- we check the revision of the CPU to see whether the workaround is
  applicable.  If it is, then...
  - the register is read.
  - the bit(s) are checked to see whether the work-around has already been
    applied.
  - the bit(s) is set to the appropriate state.
  - the register is written _if_ the work-around has not already been applied.

That means a platform running in secure mode gets the work-arounds applied
as appropriate for the CPU.  It also means that a platform running in non-
secure mode won't boot if the work-around has not already been applied.
That is a good thing; some work-arounds fix data corrupting bugs, and we
don't want an unsafe kernel running on such platforms.

So, we don't detect whether we're running in secure mode or not; as I've
already stated, we don't have a way to do that.  We instead only apply
work-arounds which aren't already enabled prior to the kernel booting.
So, even on a secure mode platform, we will avoid writing the bits if the
work-around has already been applied.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Date: Fri, 16 Nov 2012 10:05:50 +0000	[thread overview]
Message-ID: <20121116100550.GI3332@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <50A50C24.9010702@gmail.com>

On Thu, Nov 15, 2012 at 09:37:08AM -0600, Rob Herring wrote:
> >> Does that work for Versatile Express CA9? It needs ARM_ERRATA_751472.
> > 
> > On VE Linux runs in secure mode, so it's fine.
> 
> WTF? You are contradicting yourself.

No, it's already been explained; the problem is lack of understanding.

Versatile Express does indeed run in secure mode; it doesn't have any
secure monitor present.  OMAP and many other platforms run in non-secure
mode.

The work-arounds are applied to secure mode registers which are sensitive
to writes in the following manner:
- we check the revision of the CPU to see whether the workaround is
  applicable.  If it is, then...
  - the register is read.
  - the bit(s) are checked to see whether the work-around has already been
    applied.
  - the bit(s) is set to the appropriate state.
  - the register is written _if_ the work-around has not already been applied.

That means a platform running in secure mode gets the work-arounds applied
as appropriate for the CPU.  It also means that a platform running in non-
secure mode won't boot if the work-around has not already been applied.
That is a good thing; some work-arounds fix data corrupting bugs, and we
don't want an unsafe kernel running on such platforms.

So, we don't detect whether we're running in secure mode or not; as I've
already stated, we don't have a way to do that.  We instead only apply
work-arounds which aren't already enabled prior to the kernel booting.
So, even on a secure mode platform, we will avoid writing the bits if the
work-around has already been applied.

  parent reply	other threads:[~2012-11-16 10:06 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14 18:53 [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p* Tony Lindgren
2012-11-14 18:53 ` Tony Lindgren
2012-11-14 19:01 ` Russell King - ARM Linux
2012-11-14 19:01   ` Russell King - ARM Linux
2012-11-14 19:19   ` Tony Lindgren
2012-11-14 19:19     ` Tony Lindgren
2012-11-14 19:06 ` Jon Hunter
2012-11-14 19:06   ` Jon Hunter
2012-11-14 19:21   ` Tony Lindgren
2012-11-14 19:21     ` Tony Lindgren
2012-11-14 20:22   ` Russell King - ARM Linux
2012-11-14 20:22     ` Russell King - ARM Linux
2012-11-14 20:32     ` Tony Lindgren
2012-11-14 20:32       ` Tony Lindgren
2012-11-14 21:57       ` Rob Herring
2012-11-14 21:57         ` Rob Herring
2012-11-14 22:21         ` Tony Lindgren
2012-11-14 22:21           ` Tony Lindgren
2012-11-15  0:54           ` Rob Herring
2012-11-15  0:54             ` Rob Herring
2012-11-15  2:08             ` Tony Lindgren
2012-11-15  2:08               ` Tony Lindgren
2012-11-15 11:01             ` Catalin Marinas
2012-11-15 11:01               ` Catalin Marinas
2012-11-15 12:41               ` Siarhei Siamashka
2012-11-15 12:41                 ` Siarhei Siamashka
2012-11-15 13:36                 ` Russell King - ARM Linux
2012-11-15 13:36                   ` Russell King - ARM Linux
2012-11-15 13:52                 ` Catalin Marinas
2012-11-15 13:52                   ` Catalin Marinas
2012-11-15 15:14                   ` Måns Rullgård
2012-11-15 15:14                     ` Måns Rullgård
2012-11-15 14:31               ` Rob Herring
2012-11-15 14:31                 ` Rob Herring
2012-11-15 14:37                 ` Catalin Marinas
2012-11-15 14:37                   ` Catalin Marinas
2012-11-15 15:37                   ` Rob Herring
2012-11-15 15:37                     ` Rob Herring
2012-11-15 16:06                     ` Catalin Marinas
2012-11-15 16:06                       ` Catalin Marinas
2012-11-16 10:05                     ` Russell King - ARM Linux [this message]
2012-11-16 10:05                       ` Russell King - ARM Linux
2012-11-16 17:13                       ` Tony Lindgren
2012-11-16 17:13                         ` Tony Lindgren
2012-11-16 18:41                         ` Russell King - ARM Linux
2012-11-16 18:41                           ` Russell King - ARM Linux
2012-11-16  9:59                 ` Russell King - ARM Linux
2012-11-16  9:59                   ` Russell King - ARM Linux
2012-11-16 18:09                   ` Catalin Marinas
2012-11-16 18:09                     ` Catalin Marinas
2012-11-16 18:39                     ` Russell King - ARM Linux
2012-11-16 18:39                       ` Russell King - ARM Linux
2012-11-17 10:46                       ` Catalin Marinas
2012-11-17 10:46                         ` Catalin Marinas
2012-11-15  9:22           ` Russell King - ARM Linux
2012-11-15  9:22             ` Russell King - ARM Linux
2012-12-12  0:46         ` Jon Masters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121116100550.GI3332@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=Will.Deacon@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@linaro.org \
    --cc=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robherring2@gmail.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.