Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751991AbcL1USW (ORCPT ); Wed, 28 Dec 2016 15:18:22 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:36616 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751059AbcL1USU (ORCPT ); Wed, 28 Dec 2016 15:18:20 -0500 Subject: Re: [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53 To: Will Deacon References: <20161031194414.61287-1-code@mmayer.net> <20161102210331.GJ22791@arm.com> <20161102212747.GL22791@arm.com> <2d72cbbb-df03-267c-53b0-e3083a746175@gmail.com> <20161103141559.GQ22791@arm.com> Cc: Markus Mayer , Markus Mayer , Catalin Marinas , Linux Kernel Mailing List , ARM Kernel Mailing List From: Florian Fainelli Message-ID: Date: Wed, 28 Dec 2016 12:17:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3051 Lines: 63 On 11/03/2016 10:20 AM, Florian Fainelli wrote: > On 11/03/2016 07:16 AM, Will Deacon wrote: >> On Wed, Nov 02, 2016 at 02:57:26PM -0700, Florian Fainelli wrote: >>> On 11/02/2016 02:41 PM, Markus Mayer wrote: >>>> On 2 November 2016 at 14:27, Will Deacon wrote: >>>>> On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote: >>>>>> 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 > >> >> 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