All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: "Måns Rullgård" <mans@mansr.com>
Cc: nicolas.pitre@linaro.org, andrew@lunn.ch, tony@atomide.com,
	robh@kernel.org, f.fainelli@gmail.com,
	gregory.clement@bootlin.com, linux@armlinux.org.uk,
	krzk@kernel.org, arm@kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	sebastian.hesselbarth@gmail.com, jason@lakedaemon.net,
	arnd@arndb.de, marc.w.gonzalez@free.fr, rjui@broadcom.com,
	ssantosh@kernel.org, linux-arm-kernel@lists.infradead.org,
	sbranden@broadcom.com, ard.biesheuvel@linaro.org,
	ndesaulniers@google.com, linux-kernel@vger.kernel.org,
	kgene@kernel.org, robin.murphy@arm.com
Subject: Re: [PATCH v2 1/3] ARM: use arch_extension directive instead of arch argument
Date: Tue, 09 Apr 2019 17:06:38 +0200	[thread overview]
Message-ID: <398fb21bc96007bac89dce25ed2eb79e@agner.ch> (raw)
In-Reply-To: <yw1xk1g3xt4o.fsf@mansr.com>

On 09.04.2019 14:25, Måns Rullgård wrote:
> Stefan Agner <stefan@agner.ch> writes:
> 
>> The LLVM Target parser currently does not allow to specify the security
>> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
>> to use Clang with LLVM's integrated assembler, this leads to build
>> errors such as this:
>>   clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>>
>> Use ".arch_extension sec" to enable the security extension in a more
>> portable fasion. Also make sure to use ".arch armv7-a" in case a v6/v7
>> multi-platform kernel is being built.
>>
>> Note that this is technically not exactly the same as the old code
>> checked for availabilty of the security extension by calling as-instr.
>> However, there are already other sites which use ".arch_extension sec"
>> unconditionally, hence de-facto we need an assembler capable of
>> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
>> arch extension "sec" is available since binutils 2.21 according to
>> its documentation [1].
>>
>> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
>> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> Acked-by: Mans Rullgard <mans@mansr.com>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> ---
>> Changes since v1:
>> - Explicitly specify assembler architecture as armv7-a to avoid
>>   build issues when bulding v6/v7 multi arch kernel.
>>
>>  arch/arm/mach-bcm/Makefile         | 3 ---
>>  arch/arm/mach-bcm/bcm_kona_smc.c   | 2 --
>>  arch/arm/mach-exynos/Makefile      | 4 ----
>>  arch/arm/mach-exynos/exynos-smc.S  | 3 ++-
>>  arch/arm/mach-exynos/sleep.S       | 3 ++-
>>  arch/arm/mach-highbank/Makefile    | 3 ---
>>  arch/arm/mach-highbank/smc.S       | 3 ++-
>>  arch/arm/mach-keystone/Makefile    | 3 ---
>>  arch/arm/mach-keystone/smc.S       | 1 +
>>  arch/arm/mach-omap2/Makefile       | 8 --------
>>  arch/arm/mach-omap2/omap-headsmp.S | 2 ++
>>  arch/arm/mach-omap2/omap-smc.S     | 3 ++-
>>  arch/arm/mach-omap2/sleep33xx.S    | 1 +
>>  arch/arm/mach-omap2/sleep34xx.S    | 2 ++
>>  arch/arm/mach-omap2/sleep43xx.S    | 2 ++
>>  arch/arm/mach-omap2/sleep44xx.S    | 2 ++
>>  arch/arm/mach-tango/Makefile       | 3 ---
>>  arch/arm/mach-tango/smc.S          | 1 +
>>  18 files changed, 19 insertions(+), 30 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
>> index a55a7ecf146a..541e850a736c 100644
>> --- a/arch/arm/mach-bcm/bcm_kona_smc.c
>> +++ b/arch/arm/mach-bcm/bcm_kona_smc.c
>> @@ -125,9 +125,7 @@ static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
>>  		__asmeq("%2", "r4")
>>  		__asmeq("%3", "r5")
>>  		__asmeq("%4", "r6")
>> -#ifdef REQUIRES_SEC
>>  		".arch_extension sec\n"
>> -#endif
>>  		"	smc    #0\n"
>>  		: "=r" (ip), "=r" (r0)
>>  		: "r" (r4), "r" (r5), "r" (r6)
> 
> [...]
> 
>> diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S
>> index d15de8179fab..ec03dc499270 100644
>> --- a/arch/arm/mach-keystone/smc.S
>> +++ b/arch/arm/mach-keystone/smc.S
>> @@ -21,6 +21,7 @@
>>   *
>>   * Return: Non zero value on failure
>>   */
>> +	.arch_extension sec
>>  ENTRY(keystone_cpu_smc)
>>  	stmfd   sp!, {r4-r11, lr}
>>  	smc	#0
> 
> [...]
> 
>> diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
>> index 361a8dc89804..cf2d21e5226c 100644
>> --- a/arch/arm/mach-tango/smc.S
>> +++ b/arch/arm/mach-tango/smc.S
>> @@ -1,6 +1,7 @@
>>  /* SPDX-License-Identifier: GPL-2.0 */
>>  #include <linux/linkage.h>
>>
>> +	.arch_extension sec
>>  ENTRY(tango_smc)
>>  	push	{lr}
>>  	mov	ip, r1
> 
> Is there some reason these three don't need the .arch directive?

They all do not use a memory barrier instruction (e.g. dmb) which caused
issues on the other files.

--
Stefan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Agner <stefan@agner.ch>
To: "Måns Rullgård" <mans@mansr.com>
Cc: arm@kernel.org, linux@armlinux.org.uk, arnd@arndb.de,
	ard.biesheuvel@linaro.org, robin.murphy@arm.com,
	nicolas.pitre@linaro.org, f.fainelli@gmail.com,
	rjui@broadcom.com, sbranden@broadcom.com,
	bcm-kernel-feedback-list@broadcom.com, kgene@kernel.org,
	krzk@kernel.org, robh@kernel.org, ssantosh@kernel.org,
	jason@lakedaemon.net, andrew@lunn.ch,
	gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com,
	tony@atomide.com, marc.w.gonzalez@free.fr,
	ndesaulniers@google.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] ARM: use arch_extension directive instead of arch argument
Date: Tue, 09 Apr 2019 17:06:38 +0200	[thread overview]
Message-ID: <398fb21bc96007bac89dce25ed2eb79e@agner.ch> (raw)
In-Reply-To: <yw1xk1g3xt4o.fsf@mansr.com>

On 09.04.2019 14:25, Måns Rullgård wrote:
> Stefan Agner <stefan@agner.ch> writes:
> 
>> The LLVM Target parser currently does not allow to specify the security
>> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
>> to use Clang with LLVM's integrated assembler, this leads to build
>> errors such as this:
>>   clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>>
>> Use ".arch_extension sec" to enable the security extension in a more
>> portable fasion. Also make sure to use ".arch armv7-a" in case a v6/v7
>> multi-platform kernel is being built.
>>
>> Note that this is technically not exactly the same as the old code
>> checked for availabilty of the security extension by calling as-instr.
>> However, there are already other sites which use ".arch_extension sec"
>> unconditionally, hence de-facto we need an assembler capable of
>> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
>> arch extension "sec" is available since binutils 2.21 according to
>> its documentation [1].
>>
>> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
>> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> Acked-by: Mans Rullgard <mans@mansr.com>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>> ---
>> Changes since v1:
>> - Explicitly specify assembler architecture as armv7-a to avoid
>>   build issues when bulding v6/v7 multi arch kernel.
>>
>>  arch/arm/mach-bcm/Makefile         | 3 ---
>>  arch/arm/mach-bcm/bcm_kona_smc.c   | 2 --
>>  arch/arm/mach-exynos/Makefile      | 4 ----
>>  arch/arm/mach-exynos/exynos-smc.S  | 3 ++-
>>  arch/arm/mach-exynos/sleep.S       | 3 ++-
>>  arch/arm/mach-highbank/Makefile    | 3 ---
>>  arch/arm/mach-highbank/smc.S       | 3 ++-
>>  arch/arm/mach-keystone/Makefile    | 3 ---
>>  arch/arm/mach-keystone/smc.S       | 1 +
>>  arch/arm/mach-omap2/Makefile       | 8 --------
>>  arch/arm/mach-omap2/omap-headsmp.S | 2 ++
>>  arch/arm/mach-omap2/omap-smc.S     | 3 ++-
>>  arch/arm/mach-omap2/sleep33xx.S    | 1 +
>>  arch/arm/mach-omap2/sleep34xx.S    | 2 ++
>>  arch/arm/mach-omap2/sleep43xx.S    | 2 ++
>>  arch/arm/mach-omap2/sleep44xx.S    | 2 ++
>>  arch/arm/mach-tango/Makefile       | 3 ---
>>  arch/arm/mach-tango/smc.S          | 1 +
>>  18 files changed, 19 insertions(+), 30 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
>> index a55a7ecf146a..541e850a736c 100644
>> --- a/arch/arm/mach-bcm/bcm_kona_smc.c
>> +++ b/arch/arm/mach-bcm/bcm_kona_smc.c
>> @@ -125,9 +125,7 @@ static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
>>  		__asmeq("%2", "r4")
>>  		__asmeq("%3", "r5")
>>  		__asmeq("%4", "r6")
>> -#ifdef REQUIRES_SEC
>>  		".arch_extension sec\n"
>> -#endif
>>  		"	smc    #0\n"
>>  		: "=r" (ip), "=r" (r0)
>>  		: "r" (r4), "r" (r5), "r" (r6)
> 
> [...]
> 
>> diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S
>> index d15de8179fab..ec03dc499270 100644
>> --- a/arch/arm/mach-keystone/smc.S
>> +++ b/arch/arm/mach-keystone/smc.S
>> @@ -21,6 +21,7 @@
>>   *
>>   * Return: Non zero value on failure
>>   */
>> +	.arch_extension sec
>>  ENTRY(keystone_cpu_smc)
>>  	stmfd   sp!, {r4-r11, lr}
>>  	smc	#0
> 
> [...]
> 
>> diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
>> index 361a8dc89804..cf2d21e5226c 100644
>> --- a/arch/arm/mach-tango/smc.S
>> +++ b/arch/arm/mach-tango/smc.S
>> @@ -1,6 +1,7 @@
>>  /* SPDX-License-Identifier: GPL-2.0 */
>>  #include <linux/linkage.h>
>>
>> +	.arch_extension sec
>>  ENTRY(tango_smc)
>>  	push	{lr}
>>  	mov	ip, r1
> 
> Is there some reason these three don't need the .arch directive?

They all do not use a memory barrier instruction (e.g. dmb) which caused
issues on the other files.

--
Stefan

  reply	other threads:[~2019-04-09 15:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 20:59 [PATCH v2 1/3] ARM: use arch_extension directive instead of arch argument Stefan Agner
2019-04-08 20:59 ` Stefan Agner
2019-04-08 20:59 ` [PATCH v2 2/3] ARM: mvebu: drop unnecessary label Stefan Agner
2019-04-08 20:59   ` Stefan Agner
2019-04-08 20:59 ` [PATCH v2 3/3] ARM: mvebu: prefix coprocessor operand with p Stefan Agner
2019-04-08 20:59   ` Stefan Agner
2019-04-09 12:25 ` [PATCH v2 1/3] ARM: use arch_extension directive instead of arch argument Måns Rullgård
2019-04-09 12:25   ` Måns Rullgård
2019-04-09 15:06   ` Stefan Agner [this message]
2019-04-09 15:06     ` Stefan Agner
2019-04-10  8:20   ` Stefan Agner
2019-04-10  8:20     ` Stefan Agner
2019-04-09 14:50 ` Tony Lindgren
2019-04-09 14:50   ` Tony Lindgren
2019-04-10  8:42   ` Stefan Agner
2019-04-10  8:42     ` Stefan Agner

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=398fb21bc96007bac89dce25ed2eb79e@agner.ch \
    --to=stefan@agner.ch \
    --cc=andrew@lunn.ch \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregory.clement@bootlin.com \
    --cc=jason@lakedaemon.net \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mans@mansr.com \
    --cc=marc.w.gonzalez@free.fr \
    --cc=ndesaulniers@google.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=rjui@broadcom.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sbranden@broadcom.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=ssantosh@kernel.org \
    --cc=tony@atomide.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 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.