Thread (12 messages) flat view 12 messages, 4 authors, 2017-01-04

[PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53

From: f.fainelli@gmail.com (Florian Fainelli)
Date: 2016-12-28 20:18:22
Also in: lkml

On 11/03/2016 10:20 AM, Florian Fainelli wrote:
On 11/03/2016 07:16 AM, Will Deacon wrote:
quoted
On Wed, Nov 02, 2016 at 02:57:26PM -0700, Florian Fainelli wrote:
quoted
On 11/02/2016 02:41 PM, Markus Mayer wrote:
quoted
On 2 November 2016 at 14:27, Will Deacon [off-list ref] wrote:
quoted
On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote:
quoted
The question I am asking is: What do we have to lose by supporting both options?
We end up passing "--fix-cortex-a53" to the linker, without knowing what it
might do in the future.
It seems highly unlikely that such a generic option would be added in
the future, both, because the precedent has been set for topic
specific options, and because they know it has been used in the past,
so they wouldn't add a previously used option to do something
completely different. (And if they really did, then that would be a
huge binutils bug.)

So, we have a trade-off between a real world problem that does
currently exist and avoiding a theoretical issue that may never
materialize.
Agreed, also the way Markus' patch is designed makes it such that we
first try the full and current option name, and if not supported, try
the second (and earlier, now obsolete) option name, so I really don't
see a lot of room for things to go wrong here...
It's not beyond the realms of possibility that ld will grow a
"fix-cortex-a53" option in the future, that enables all of the a53
workarounds. Since ld is the linker supported by the kernel and gold isn't,
I don't want to pass this option down.
No it's entirely reasonable to think this may happen, although:

- this has not happened yet, so once this happens, you will need to cook
a patch for this anyway, and you will be able to gate this catch all
linker option by an appropriate version check presumably

- you would supposedly want a fine grained set of linker options that
are specific to workarounds you have to have enabled, instead of a catch
all "enable all Cortex A53" workarounds
quoted
If you can't change toolchain and you want this worked around, why can't you
either build gold with it enabled by default, or pass the extra flag on the
command line to the kernel build system?
Because that creates a distribution problem and now we have to document
this for people who want to build a kernel on their own, without
necessarily understanding if this is something they might need, or why
this is needed, and why the kernel is not taking care of that on its
own? So yes, this comes down to who is responsible for what, in that
case the kernel's Makefile is the best place where to put such knowledge
as to which workaround needs to be enabled by the linker and it
simplifies things a lot for people.
Was this convincing enough for Catalin to pick Markus' patch or does
that mean this patch needs to remain out of tree for us because of using
a slightly older toolchain?

Thanks
-- 
Florian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help