public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: holler@ahsoftware.de (Alexander Holler)
To: linux-arm-kernel@lists.infradead.org
Subject: arm erratas (config options)
Date: Fri, 22 Jun 2012 12:05:44 +0200	[thread overview]
Message-ID: <4FE44378.9050803@ahsoftware.de> (raw)

Hello,

I'm currious why there exists config options for the various arm 
erratas. Isn't it possible to identify the variant and revision of the 
cores and enable the necessary workarounds automatically?

And would it be possible to use only one term (at least inside the 
kernel) to describe the arm-variations?

E.g. /proc/cpuinfo talks about variant and revision while all the help 
texts for the erratas are talking about rNpM (which I would translate to 
"revision" and "patch level", without knowing the real meanings).

This makes it necessary to translate "variant" to 'r' and "revision" to 
'p', which isn't really obvious (because most people would translate 
"revision" to 'r' and would wonder how to find the value for 'p' in 
/proc/cpuinfo or somewhere else).

Another source of confusion about which arm erratas should be enabled 
for a specific processor is that not all the help texts for the erratas 
are clear about which variants and revisions are effected. E.g. the help 
texts for erratas 460075 or 458693 are talking about r2p0, but they 
doesn't mention if older variants (e.g. r1p3) get hit by these erratas 
too. The help texts for other erratas (e.g. 743622 and 754322) are 
talking about r2p*, which I would interpret that this errata applies 
only to variant 2, but I would never be sure (reading only the help text).

So without actually reading the erratas (and not only the help texts) I 
assume most people, including me ;) , just don't know if it's necessary 
to enable the workaround for a specific errata (besides that people 
would need to understand whats written in the erratas or help texts itself).

Just enabling all workarounds can't be the answer, otherwise the config 
options for those erratas wouldn't be necessary at all.

Assuming that the list of erratas will grow further, the problem will 
just get worse if nobody defines some rules about how the help texts 
should be written to leave no questions about when one has to enable an 
option.

Just my 2?. ;)

Regards,

Alexander

             reply	other threads:[~2012-06-22 10:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 10:05 Alexander Holler [this message]
2012-06-22 10:35 ` arm erratas (config options) Russell King - ARM Linux
2012-06-22 11:28   ` Alexander Holler
2012-06-22 12:57   ` Måns Rullgård

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=4FE44378.9050803@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox