All of lore.kernel.org
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769
Date: Mon, 10 Dec 2012 19:50:06 +0530	[thread overview]
Message-ID: <50C5EF96.2040006@ti.com> (raw)
In-Reply-To: <20121210141604.GN14363@n2100.arm.linux.org.uk>

On Monday 10 December 2012 07:46 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 10, 2012 at 07:40:06PM +0530, Santosh Shilimkar wrote:
>> Whats the stand on such erratas ? I saw on one of thread one of
>> you suggesting to stop patching kernel where secure/non-secure
>> kernel will need different errata WA.
>
> Well, yes, there's that too.  I think were we got to was deciding that
> it is impossible to tell whether an errata is required for any particular
> SoC: even when you know the rXpX number of the core, you don't know if,
> as part of the design, the manufacturer incorporated some fix.
>
> So, the conclusion we came to was that the _only_ place that work-arounds
> like these can be enabled is before we get anywhere near the kernel - in
> whatever pre-kernel code the platform has, and doing whatever platform
> specific magic is required to get those work-arounds enabled.
>
> What that means is that having the work-arounds in the kernel is pretty
> pointless when it's a matter of enabling a bit or two in some secure-only
> register.
>
> I don't think I heard any objections to removing those work-arounds which
> fall into this category from the kernel; I think that's something we need
> to schedule for a few kernel versions time, after we've put them into the
> feature-removal file, and marked them in the config as going away.
>
Thanks for confirming it. All the patches in the $subject series falls
into secure/non-secure category and hence subject to the same issues.

Regards
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "'Catalin Marinas'" <Catalin.Marinas@arm.com>,
	Boojin Kim <boojin.kim@samsung.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	"'Will Deacon'" <will.deacon@arm.com>,
	"'Kukjin Kim'" <kgene.kim@samsung.com>
Subject: Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769
Date: Mon, 10 Dec 2012 19:50:06 +0530	[thread overview]
Message-ID: <50C5EF96.2040006@ti.com> (raw)
In-Reply-To: <20121210141604.GN14363@n2100.arm.linux.org.uk>

On Monday 10 December 2012 07:46 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 10, 2012 at 07:40:06PM +0530, Santosh Shilimkar wrote:
>> Whats the stand on such erratas ? I saw on one of thread one of
>> you suggesting to stop patching kernel where secure/non-secure
>> kernel will need different errata WA.
>
> Well, yes, there's that too.  I think were we got to was deciding that
> it is impossible to tell whether an errata is required for any particular
> SoC: even when you know the rXpX number of the core, you don't know if,
> as part of the design, the manufacturer incorporated some fix.
>
> So, the conclusion we came to was that the _only_ place that work-arounds
> like these can be enabled is before we get anywhere near the kernel - in
> whatever pre-kernel code the platform has, and doing whatever platform
> specific magic is required to get those work-arounds enabled.
>
> What that means is that having the work-arounds in the kernel is pretty
> pointless when it's a matter of enabling a bit or two in some secure-only
> register.
>
> I don't think I heard any objections to removing those work-arounds which
> fall into this category from the kernel; I think that's something we need
> to schedule for a few kernel versions time, after we've put them into the
> feature-removal file, and marked them in the config as going away.
>
Thanks for confirming it. All the patches in the $subject series falls
into secure/non-secure category and hence subject to the same issues.

Regards
Santosh



  reply	other threads:[~2012-12-10 14:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-09 23:58 [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769 Boojin Kim
2012-12-09 23:58 ` Boojin Kim
2012-12-10  0:08 ` Russell King - ARM Linux
2012-12-10  0:08   ` Russell King - ARM Linux
2012-12-10  1:19   ` Boojin Kim
2012-12-10  1:19     ` Boojin Kim
2012-12-10 14:10 ` Santosh Shilimkar
2012-12-10 14:10   ` Santosh Shilimkar
2012-12-10 14:16   ` Russell King - ARM Linux
2012-12-10 14:16     ` Russell King - ARM Linux
2012-12-10 14:20     ` Santosh Shilimkar [this message]
2012-12-10 14:20       ` Santosh Shilimkar

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=50C5EF96.2040006@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.