linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Markus Mayer <markus.mayer@broadcom.com>,
	Will Deacon <will.deacon@arm.com>
Cc: 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, 2 Nov 2016 14:57:26 -0700	[thread overview]
Message-ID: <2d72cbbb-df03-267c-53b0-e3083a746175@gmail.com> (raw)
In-Reply-To: <CAGt4E5sxMcyizwAjwEZd6zepOAyr05WCgtstoRDfNjkNQtnJCA@mail.gmail.com>

On 11/02/2016 02:41 PM, Markus Mayer wrote:
> On 2 November 2016 at 14:27, Will Deacon <will.deacon@arm.com> wrote:
>> On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote:
>>> On 2 November 2016 at 14:03, Will Deacon <will.deacon@arm.com> wrote:
>>>> On Mon, Oct 31, 2016 at 12:44:14PM -0700, Markus Mayer wrote:
>>>>> From: Markus Mayer <mmayer@broadcom.com>
>>>>>
>>>>> The new errata check leads to a warning with some older versions of the
>>>>> linker that do know how to work around the errata, but still use the
>>>>> original name of the command line option: --fix-cortex-a53. The commit
>>>>> in question that changed the name of the option can be found at [1].
>>>>> It looks like only "gold" is affected by this rename. Traditional "ld"
>>>>> isn't. (There, the argument was always called --fix-cortex-a53-843419.)
>>>>>
>>>>> To allow older versions of gold to properly handle the erratum if they
>>>>> can, check whether ld supports the old name of this option in addition
>>>>> to checking the new one.
>>>>>
>>>>> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
>>>>>
>>>>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>>>>
>>>> If newer versions of gold accept the correct option name, why do we care?
>>>
>>> Because Documentation/Changes states that the minimum requirement for
>>> binutils is 2.12. Right now, that is not really true. And not
>>> everybody can always use the newest toolchain, for various reasons.
>>
>> Well the kernel still builds, right? Can binutils 2.12 even work around
>> 843419? For people who can't use a recent toolchain, then they don't get
>> erratum workaround and we warn them about it.
> 
> Correct. Linkers as old as 2.12 are not able to work around the
> erratum, and the warning is accurate. So, there's no problem there.
> 
> But there are newer versions that do know how to work around the
> erratum, but use the original name of the option. Right now, you could
> be using a linker that knows how to fix the erratum, but instead, the
> you get a warning, and the erratum is not fixed.
> 
> This one, for instance:
> 
> $ arm-linux-ld -v
> GNU ld (GNU Binutils) Linaro 2014.11-2 2.24.0.20141017
> 
> Without the proposed patch, this linker will produce a kernel without
> the workaround, but not because the linker can't do it, but because it
> isn't given the command line argument it understands.
> 
>>> 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...
-- 
Florian

  reply	other threads:[~2016-11-02 21:57 UTC|newest]

Thread overview: 12+ 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-11-02 21:03 ` Will Deacon
2016-11-02 21:07   ` Markus Mayer
2016-11-02 21:27     ` Will Deacon
2016-11-02 21:41       ` Markus Mayer
2016-11-02 21:57         ` Florian Fainelli [this message]
2016-11-03 14:16           ` Will Deacon
2016-11-03 17:20             ` Florian Fainelli
2016-12-28 20:17               ` Florian Fainelli
2017-01-04 11:49                 ` Will Deacon
2017-01-04 22:39                   ` Florian Fainelli
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=2d72cbbb-df03-267c-53b0-e3083a746175@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=code@mmayer.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.mayer@broadcom.com \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).