| Message ID | 9641c58c03720104186a797a96e30a52ae9805e4.1553356359.git.stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] ARM: use arch_extension directive instead of arch argument | expand |
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 a 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. > > 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> > --- > 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 | 2 +- > arch/arm/mach-exynos/sleep.S | 2 +- > arch/arm/mach-highbank/Makefile | 3 --- > arch/arm/mach-highbank/smc.S | 2 +- > 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 | 1 + > arch/arm/mach-omap2/omap-smc.S | 2 +- > arch/arm/mach-omap2/sleep34xx.S | 1 + > arch/arm/mach-omap2/sleep43xx.S | 1 + > arch/arm/mach-omap2/sleep44xx.S | 1 + > arch/arm/mach-tango/Makefile | 3 --- > arch/arm/mach-tango/smc.S | 1 + > 17 files changed, 10 insertions(+), 30 deletions(-) [...] > diff --git a/arch/arm/mach-tango/Makefile b/arch/arm/mach-tango/Makefile > index da6c633d3cc0..97cd04508fa1 100644 > --- a/arch/arm/mach-tango/Makefile > +++ b/arch/arm/mach-tango/Makefile > @@ -1,7 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > -plus_sec := $(call as-instr,.arch_extension sec,+sec) > -AFLAGS_smc.o := -Wa,-march=armv7-a$(plus_sec) > - > obj-y += setup.o smc.o > obj-$(CONFIG_SMP) += platsmp.o > obj-$(CONFIG_SUSPEND) += pm.o > 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 For Tango: Acked-by: Mans Rullgard <mans@mansr.com>
On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <stefan@agner.ch> wrote: > > 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 a 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. > > 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> This sounds like a good idea. I think we have platform specific minimum toolchain versions elsewhere, but I don't see a problem with raising the minimum version for all the armv7ve platforms. I've added this patch to my randconfig test queue, but please send it to arm@kernel.org for inclusion when you have collected more Acks. Do you have a git tree with other patches required for the integrated assembler? I might try that out as well with my randconfig tree. At the moment I'm building with clang-8 and a small number of patches on top. Acked-by: Arnd Bergmann <arnd@arndb.de>
On 23.03.2019 21:06, Arnd Bergmann wrote: > On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <stefan@agner.ch> wrote: >> >> 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 a 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. >> >> 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> > > This sounds like a good idea. I think we have platform specific > minimum toolchain versions elsewhere, but I don't see a problem > with raising the minimum version for all the armv7ve platforms. > > I've added this patch to my randconfig test queue, but please > send it to arm@kernel.org for inclusion when you have > collected more Acks. Cool, will do! > > Do you have a git tree with other patches required for the > integrated assembler? I might try that out as well with > my randconfig tree. At the moment I'm building with > clang-8 and a small number of patches on top. I do have some more work in progress patches. I made some rough commits and pushed the tree here: https://github.com/ClangBuiltLinux/linux/commits/arm-fixes-hacks-to-make-llvm-integrated-as-work This tree compiles for me and a test boot with qemu seems to work. It seems that LLVM's integrated assembler is capable of assembling almost the whole kernel a lot can be worked around/fixed on kernel side. There are only about a handful of files where I still use the GNU assembler. Haven't looked closely at these cases yet. There is one issue which probably need a change in LLVM: https://github.com/ClangBuiltLinux/linux/issues/306 I proposed this fix: https://reviews.llvm.org/D59733 > > Acked-by: Arnd Bergmann <arnd@arndb.de> Thx. -- Stefan
On 23/03/2019 16:52, Stefan Agner wrote: > 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 a build > errors such as this: "leads to build errors [...]" (delete "a")
On Sat, 23 Mar 2019 at 16:52, Stefan Agner <stefan@agner.ch> wrote: > > 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 a 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. > > 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> > --- > 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 | 2 +- > arch/arm/mach-exynos/sleep.S | 2 +- for Exynos: Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
On Sun, Mar 24, 2019 at 3:06 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <stefan@agner.ch> wrote: > > > > 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 a 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. > > > > 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> > > This sounds like a good idea. I think we have platform specific > minimum toolchain versions elsewhere, but I don't see a problem > with raising the minimum version for all the armv7ve platforms. > > I've added this patch to my randconfig test queue, but please > send it to arm@kernel.org for inclusion when you have > collected more Acks. > > Do you have a git tree with other patches required for the > integrated assembler? I might try that out as well with > my randconfig tree. At the moment I'm building with > clang-8 and a small number of patches on top. > > Acked-by: Arnd Bergmann <arnd@arndb.de> I only now looked at the results and found a problem: In a mixed v6/v7 configuration, the arch_extension flag is not sufficient, and for armv6+sec, we get failures like /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S: Assembler messages: /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:343: Error: selected processor does not support `isb' in ARM mode /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:350: Error: selected processor does not support `dsb' in ARM mode /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:351: Error: selected processor does not support `dmb' in ARM mode clang: error: assembler command failed with exit code 1 (use -v to see invocation) /git/arm-soc/scripts/Makefile.build:369: recipe for target 'arch/arm/mach-omap2/sleep44xx.o' failed make[3]: *** [arch/arm/mach-omap2/sleep44xx.o] Error 1 ==> build/arm/0x64728DCE_defconfig/log <== /git/arm-soc/arch/arm/mach-omap2/omap-smc.S: Assembler messages: /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:31: Error: selected processor does not support `dsb' in ARM mode /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:53: Error: selected processor does not support `dsb' in ARM mode /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:54: Error: selected processor does not support `dmb' in ARM mode Arnd
On 31.03.2019 19:34, Arnd Bergmann wrote: > On Sun, Mar 24, 2019 at 3:06 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <stefan@agner.ch> wrote: >> > >> > 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 a 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. >> > >> > 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> >> >> This sounds like a good idea. I think we have platform specific >> minimum toolchain versions elsewhere, but I don't see a problem >> with raising the minimum version for all the armv7ve platforms. >> >> I've added this patch to my randconfig test queue, but please >> send it to arm@kernel.org for inclusion when you have >> collected more Acks. >> >> Do you have a git tree with other patches required for the >> integrated assembler? I might try that out as well with >> my randconfig tree. At the moment I'm building with >> clang-8 and a small number of patches on top. >> >> Acked-by: Arnd Bergmann <arnd@arndb.de> > > I only now looked at the results and found a problem: > In a mixed v6/v7 configuration, the arch_extension flag > is not sufficient, and for armv6+sec, we get failures like > > /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S: Assembler messages: > /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:343: Error: selected > processor does not support `isb' in ARM mode > /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:350: Error: selected > processor does not support `dsb' in ARM mode > /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:351: Error: selected > processor does not support `dmb' in ARM mode > clang: error: assembler command failed with exit code 1 (use -v to see > invocation) > /git/arm-soc/scripts/Makefile.build:369: recipe for target > 'arch/arm/mach-omap2/sleep44xx.o' failed > make[3]: *** [arch/arm/mach-omap2/sleep44xx.o] Error 1 > > ==> build/arm/0x64728DCE_defconfig/log <== > /git/arm-soc/arch/arm/mach-omap2/omap-smc.S: Assembler messages: > /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:31: Error: selected > processor does not support `dsb' in ARM mode > /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:53: Error: selected > processor does not support `dsb' in ARM mode > /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:54: Error: selected > processor does not support `dmb' in ARM mode Hm, I guess I can just use .arch armv7-a in those cases, as we use in other places. Thanks for testing! Will send a v2. -- Stefan
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile index 8fd23b263c60..b59c813b1af4 100644 --- a/arch/arm/mach-bcm/Makefile +++ b/arch/arm/mach-bcm/Makefile @@ -40,9 +40,6 @@ obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o # Support for secure monitor traps obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o -ifeq ($(call as-instr,.arch_extension sec,as_has_sec),as_has_sec) -CFLAGS_bcm_kona_smc.o += -Wa,-march=armv7-a+sec -DREQUIRES_SEC -endif # BCM2835 obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o 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-exynos/Makefile b/arch/arm/mach-exynos/Makefile index cd00c82a1add..44de9f36fd1b 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -14,9 +14,5 @@ obj-$(CONFIG_PM_SLEEP) += suspend.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o -plus_sec := $(call as-instr,.arch_extension sec,+sec) -AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec) -AFLAGS_sleep.o :=-Wa,-march=armv7-a$(plus_sec) - obj-$(CONFIG_EXYNOS5420_MCPM) += mcpm-exynos.o CFLAGS_mcpm-exynos.o += -march=armv7-a diff --git a/arch/arm/mach-exynos/exynos-smc.S b/arch/arm/mach-exynos/exynos-smc.S index d259532ba937..392f8ba351f4 100644 --- a/arch/arm/mach-exynos/exynos-smc.S +++ b/arch/arm/mach-exynos/exynos-smc.S @@ -10,7 +10,7 @@ /* * Function signature: void exynos_smc(u32 cmd, u32 arg1, u32 arg2, u32 arg3) */ - + .arch_extension sec ENTRY(exynos_smc) stmfd sp!, {r4-r11, lr} dsb diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S index 2783c3a0c06a..6e3207d486b4 100644 --- a/arch/arm/mach-exynos/sleep.S +++ b/arch/arm/mach-exynos/sleep.S @@ -44,7 +44,7 @@ ENTRY(exynos_cpu_resume) ENDPROC(exynos_cpu_resume) .align - + .arch_extension sec ENTRY(exynos_cpu_resume_ns) mrc p15, 0, r0, c0, c0, 0 ldr r1, =CPU_MASK diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile index 55840f414d3e..e7741b883d13 100644 --- a/arch/arm/mach-highbank/Makefile +++ b/arch/arm/mach-highbank/Makefile @@ -1,6 +1,3 @@ obj-y := highbank.o system.o smc.o -plus_sec := $(call as-instr,.arch_extension sec,+sec) -AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec) - obj-$(CONFIG_PM_SLEEP) += pm.o diff --git a/arch/arm/mach-highbank/smc.S b/arch/arm/mach-highbank/smc.S index 407d17baaaa9..c53d6e37bb30 100644 --- a/arch/arm/mach-highbank/smc.S +++ b/arch/arm/mach-highbank/smc.S @@ -16,7 +16,7 @@ * the monitor API number. * Function signature : void highbank_smc1(u32 fn, u32 arg) */ - + .arch_extension sec ENTRY(highbank_smc1) stmfd sp!, {r4-r11, lr} mov r12, r0 diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile index f8b0dccac8dc..739b38be5696 100644 --- a/arch/arm/mach-keystone/Makefile +++ b/arch/arm/mach-keystone/Makefile @@ -1,9 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 obj-y := keystone.o smc.o -plus_sec := $(call as-instr,.arch_extension sec,+sec) -AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec) - obj-$(CONFIG_SMP) += platsmp.o # PM domain driver for Keystone SOCs diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S index d15de8179fab..b105a465bc16 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-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 85d1b13c9215..f1d283995b31 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -41,11 +41,6 @@ obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o -plus_sec := $(call as-instr,.arch_extension sec,+sec) -AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) -AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec) -AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec) - # Functions loaded to SRAM obj-$(CONFIG_SOC_OMAP2420) += sram242x.o obj-$(CONFIG_SOC_OMAP2430) += sram243x.o @@ -95,9 +90,6 @@ obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) -AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec) -AFLAGS_sleep43xx.o :=-Wa,-march=armv7-a$(plus_sec) endif diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 4c6f14cf92a8..605b9fa9ba9b 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -58,6 +58,7 @@ ENDPROC(omap5_secondary_startup) * omap5_secondary_startup if the primary CPU was put into HYP mode by * the boot loader. */ + .arch_extension sec ENTRY(omap5_secondary_hyp_startup) wait_2: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S index 72506e6cf9e7..b71a92eaffc9 100644 --- a/arch/arm/mach-omap2/omap-smc.S +++ b/arch/arm/mach-omap2/omap-smc.S @@ -23,7 +23,7 @@ * link register "lr". * Function signature : void omap_smc1(u32 fn, u32 arg) */ - + .arch_extension sec ENTRY(omap_smc1) stmfd sp!, {r2-r12, lr} mov r12, r0 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 22daf4efed68..42a9bff8c53b 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -97,6 +97,7 @@ ENDPROC(enable_omap3630_toggle_l2_on_restore) * * r0 = physical address of the parameters */ + .arch_extension sec ENTRY(save_secure_ram_context) stmfd sp!, {r4 - r11, lr} @ save registers on stack mov r3, r0 @ physical address of parameters diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S index 5b9343b58fc7..19d78d8a6bc9 100644 --- a/arch/arm/mach-omap2/sleep43xx.S +++ b/arch/arm/mach-omap2/sleep43xx.S @@ -56,6 +56,7 @@ #define RTC_PMIC_EXT_WAKEUP_EN BIT(0) .arm + .arch_extension sec .align 3 ENTRY(am43xx_do_wfi) diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 0cae3b070208..55afed959a9a 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -23,6 +23,7 @@ #if defined(CONFIG_SMP) && defined(CONFIG_PM) + .arch_extension sec .macro DO_SMC dsb smc #0 diff --git a/arch/arm/mach-tango/Makefile b/arch/arm/mach-tango/Makefile index da6c633d3cc0..97cd04508fa1 100644 --- a/arch/arm/mach-tango/Makefile +++ b/arch/arm/mach-tango/Makefile @@ -1,7 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -plus_sec := $(call as-instr,.arch_extension sec,+sec) -AFLAGS_smc.o := -Wa,-march=armv7-a$(plus_sec) - obj-y += setup.o smc.o obj-$(CONFIG_SMP) += platsmp.o obj-$(CONFIG_SUSPEND) += pm.o 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
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 a 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. 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> --- 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 | 2 +- arch/arm/mach-exynos/sleep.S | 2 +- arch/arm/mach-highbank/Makefile | 3 --- arch/arm/mach-highbank/smc.S | 2 +- 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 | 1 + arch/arm/mach-omap2/omap-smc.S | 2 +- arch/arm/mach-omap2/sleep34xx.S | 1 + arch/arm/mach-omap2/sleep43xx.S | 1 + arch/arm/mach-omap2/sleep44xx.S | 1 + arch/arm/mach-tango/Makefile | 3 --- arch/arm/mach-tango/smc.S | 1 + 17 files changed, 10 insertions(+), 30 deletions(-)