From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
Date: Wed, 4 Jan 2017 11:49:21 +0000 [thread overview]
Message-ID: <20170104114920.GB18193@arm.com> (raw)
In-Reply-To: <c4f5b650-b210-8332-e6f2-4ad9634818b9@gmail.com>
Hi Florian,
On Wed, Dec 28, 2016 at 12:17:23PM -0800, Florian Fainelli wrote:
> On 11/03/2016 10:20 AM, Florian Fainelli wrote:
> > On 11/03/2016 07:16 AM, Will Deacon wrote:
> >> 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?
I thought more about this last night, and there are two questions that
might sway me:
1. How prevalent is the binary toolchain with this issue? Is it, for
example, shipping as part of a publicly available LTS distribution?
I know you quoted some Linaro build, but I can't actually find those
binaries on their website.
2. Could we extend the Makefile magic to detect that, not only is
--fix-cortex-a53-843419 unsupported, but also that the linker is
in fact gold?
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Markus Mayer <markus.mayer@broadcom.com>,
Markus Mayer <code@mmayer.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
Date: Wed, 4 Jan 2017 11:49:21 +0000 [thread overview]
Message-ID: <20170104114920.GB18193@arm.com> (raw)
In-Reply-To: <c4f5b650-b210-8332-e6f2-4ad9634818b9@gmail.com>
Hi Florian,
On Wed, Dec 28, 2016 at 12:17:23PM -0800, Florian Fainelli wrote:
> On 11/03/2016 10:20 AM, Florian Fainelli wrote:
> > On 11/03/2016 07:16 AM, Will Deacon wrote:
> >> 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?
I thought more about this last night, and there are two questions that
might sway me:
1. How prevalent is the binary toolchain with this issue? Is it, for
example, shipping as part of a publicly available LTS distribution?
I know you quoted some Linaro build, but I can't actually find those
binaries on their website.
2. Could we extend the Makefile magic to detect that, not only is
--fix-cortex-a53-843419 unsupported, but also that the linker is
in fact gold?
Will
next prev parent reply other threads:[~2017-01-04 11:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 19:44 [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53 Markus Mayer
2016-10-31 19:44 ` Markus Mayer
2016-11-02 21:03 ` Will Deacon
2016-11-02 21:03 ` Will Deacon
2016-11-02 21:07 ` Markus Mayer
2016-11-02 21:07 ` Markus Mayer
2016-11-02 21:27 ` Will Deacon
2016-11-02 21:27 ` Will Deacon
2016-11-02 21:41 ` Markus Mayer
2016-11-02 21:41 ` Markus Mayer
2016-11-02 21:57 ` Florian Fainelli
2016-11-02 21:57 ` Florian Fainelli
2016-11-03 14:16 ` Will Deacon
2016-11-03 14:16 ` Will Deacon
2016-11-03 17:20 ` Florian Fainelli
2016-11-03 17:20 ` Florian Fainelli
2016-12-28 20:17 ` Florian Fainelli
2016-12-28 20:17 ` Florian Fainelli
2017-01-04 11:49 ` Will Deacon [this message]
2017-01-04 11:49 ` Will Deacon
2017-01-04 22:39 ` Florian Fainelli
2017-01-04 22:39 ` Florian Fainelli
2017-01-04 23:04 ` Markus Mayer
2017-01-04 23:04 ` Markus Mayer
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=20170104114920.GB18193@arm.com \
--to=will.deacon@arm.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.