linux-next: omap2plus_defconfig not building

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6&& CPU_V7

From: Catalin Marinas<[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar<[email protected]>

Signed-off-by Catalin Marinas<[email protected]>

Cc Leif Lindholm<[email protected]>

---
  arch/arm/mm/Kconfig |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/mm/Kconfig +1 -1

index 8493ed0..5195d61 100644
@@ -638,7 +638,7 @@ config ARM_THUMBEE
 
  config SWP_EMULATE
  	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7
+	depends on CPU_V7&&  !CPU_V6
  	select HAVE_PROC_CPU if PROC_FS
  	default y if SMP
  	help

Quoted 7 lines · Catalin Marinas

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

Quoted 2 lines

This patch should fix it:

Yes, it does. I've not yet boot tested on omap2; will try that out in a bit.

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

From: Catalin Marinas <[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Cc Leif Lindholm <[email protected]>

---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/mm/Kconfig +1 -1

index 8493ed0..5195d61 100644
@@ -638,7 +638,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7
+	depends on CPU_V7 && !CPU_V6
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help

Quoted 13 lines · Catalin Marinas

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

Quoted 8 lines

From: Catalin Marinas <[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Cc Leif Lindholm <[email protected]>

Hi Catalin, Leif,

I can't find this patch in linux-next. Hope we haven't missed it. Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets CONFIG_SWP_EMULATE enabled even without this patch - I can't figure out why.

Quoted 12 lines · Catalin Marinas

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

Quoted 8 lines

From: Catalin Marinas <[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Cc Leif Lindholm <[email protected]>

I can't find this patch in linux-next. Hope we haven't missed it. Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets CONFIG_SWP_EMULATE enabled even without this patch - I can't figure out why.

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

Quoted 4 lines · Catalin Marinas

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

It's probably not a good idea to override the compiler architecture, but just allow the assembler to accept the instruction. -Wa,-march=armv7-a should be good enough.

Quoted 6 lines · Russell King - ARM Linux

Quoted 4 lines · Catalin Marinas

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

Quoted 3 lines

It's probably not a good idea to override the compiler architecture, but just allow the assembler to accept the instruction. -Wa,-march=armv7-a should be good enough.

Yes, even better via AFLAGS.

Do you have a patch already or I should push one?

Quoted 7 lines · Catalin Marinas

Quoted 6 lines · Russell King - ARM Linux

Quoted 4 lines · Catalin Marinas

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

Quoted 5 lines

Quoted 3 lines

It's probably not a good idea to override the compiler architecture, but just allow the assembler to accept the instruction. -Wa,-march=armv7-a should be good enough.

Yes, even better via AFLAGS.

Not by AFLAGS unless you want to rewrite swp_emulate entirely in assembler! AFLAGS is used for .S -> .o. CFLAGS is used for .c -> .o.

Quoted 1 line

Do you have a patch already or I should push one?

I've already fixed it.

Quoted 22 lines · Anand Gadiyar

Quoted 12 lines · Catalin Marinas

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

Quoted 8 lines

From: Catalin Marinas <[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Cc Leif Lindholm <[email protected]>

Quoted 6 lines

I can't find this patch in linux-next. Hope we haven't missed it. Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets CONFIG_SWP_EMULATE enabled even without this patch - I can't figure out why.

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

If it's not in yet, I can submit a patch.

Here's what a 'make V=1' throws up.

ccache arm-none-linux-gnueabi-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d -nostdinc -isystem /db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=6 -march=armv6 -mtune=arm1136j-s -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Wa,-march=armv7-a -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)" -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)" -c
-o arch/arm/kernel/.tmp_swp_emulate.o arch/arm/kernel/swp_emulate.c
/tmp/ccLscgtf.s: Assembler messages:
/tmp/ccLscgtf.s:339: Error: selected processor does not support ARM mode ldrexb r7,[r6]' /tmp/ccLscgtf.s:340: Error: selected processor does not support ARM mode strexb r3,r2,[r6]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel/] Error 2

Please do:

make V=1 CFLAGS_KERNEL=-v arch/arm/kernel/swp_emulate.o

and send the output. This should show what command arguments are being passed to the assembler.

Quoted 6 lines · Russell King - ARM Linux

Please do:

make V=1 CFLAGS_KERNEL=-v arch/arm/kernel/swp_emulate.o

and send the output. This should show what command arguments are being passed to the assembler.

Here's the last line of output from the command above. I've attached the complete log if anyone's interested.

/db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/as -v -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -EL -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /tmp/a0393673/ccache/tmp.hash.ubomapldc13.24604.o /tmp/cc4MQyRN.s
GNU assembler version 2.19.51 (arm-none-linux-gnueabi) using BFD version (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709
/tmp/cc4MQyRN.s: Assembler messages:
/tmp/cc4MQyRN.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]'
/tmp/cc4MQyRN.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel/swp_emulate.o] Error 2

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

Hi Russell,

Quoted 10 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Quoted 1 line

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Please can you try this patch?

Quoted 14 lines · Will Deacon

Hi Russell,

Quoted 11 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

Quoted 5 lines

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

Quoted 19 lines · Russell King - ARM Linux

Quoted 18 lines · Will Deacon

Hi Russell,

Quoted 11 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Quoted 3 lines

Quoted 1 line

Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

An alternative would be to add the '.arch armv7-a' in the inline assembly in swp_emulate.c. But that's an ugly workaround and you can't revert to the previous .arch unless you add another '.arch armv6' at the end of the asm (with lots of #ifdef's).

Quoted 19 lines · Russell King - ARM Linux

Quoted 18 lines · Will Deacon

Hi Russell,

Quoted 11 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Quoted 3 lines

Quoted 1 line

Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

An alternative would be to add the '.arch armv7-a' in the inline assembly in swp_emulate.c. But that's an ugly workaround and you can't revert to the previous .arch unless you add another '.arch armv6' at the end of the asm (with lots of #ifdef's).

Quoted 24 lines · Catalin Marinas

Quoted 22 lines · Russell King - ARM Linux

Quoted 12 lines · Will Deacon

Hi Russell,

Quoted 10 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Quoted 7 lines

Quoted 1 line

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

Quoted 4 lines

An alternative would be to add the '.arch armv7-a' in the inline assembly in swp_emulate.c. But that's an ugly workaround and you can't revert to the previous .arch unless you add another '.arch armv6' at the end of the asm (with lots of #ifdef's).

Yup, so this won't work either. ?Also, as I understand it, I don't think you can rely upon the compiler ordering functions wrt. asm() statements outside of the function blocks, so I don't think this will work anyway.

We could separate out the non-ARMv7 specific code into a separate file (maybe called swp_emulate-init.c) and export proc_read_status and swp_hook into the global namespace. ?These would have to be renamed to avoid any possible clashes with other symbols.

We could just take the view that we don't allow SWP on ARMv7 at all, which would make it a pain for userspace people.

We could also re-enable SWP support on ARMv7 without the emulation code.

Luckily, this is the only place - at present - where we have C code built containing instructions (via asm() statements) for higher versions of the architecture.

Quoted 25 lines · Russell King - ARM Linux

Quoted 24 lines · Catalin Marinas

Quoted 22 lines · Russell King - ARM Linux

Quoted 12 lines · Will Deacon

Hi Russell,

Quoted 10 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Quoted 7 lines

Quoted 1 line

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

Quoted 8 lines

Quoted 4 lines

An alternative would be to add the '.arch armv7-a' in the inline assembly in swp_emulate.c. But that's an ugly workaround and you can't revert to the previous .arch unless you add another '.arch armv6' at the end of the asm (with lots of #ifdef's).

Yup, so this won't work either. ?Also, as I understand it, I don't think you can rely upon the compiler ordering functions wrt. asm() statements outside of the function blocks, so I don't think this will work anyway.

The compiler treats inline asms as solid lumps, so providing that the two .arch directives are inside the affected inline asm block, it should work.

What you presumably can't do reliably is something like

#include <...>
#include <...>

asm(".arch armv7-a");

...

{
asm( v7-dependent code )
}

Quoted 10 lines

We could separate out the non-ARMv7 specific code into a separate file (maybe called swp_emulate-init.c) and export proc_read_status and swp_hook into the global namespace. ?These would have to be renamed to avoid any possible clashes with other symbols.

We could just take the view that we don't allow SWP on ARMv7 at all, which would make it a pain for userspace people.

We could also re-enable SWP support on ARMv7 without the emulation code.

Quoted 3 lines

Luckily, this is the only place - at present - where we have C code built containing instructions (via asm() statements) for higher versions of the architecture.

For this case, I agree that separating the affected assembler out into a separate .S file is probably the cleanest and simplest solution... but I guess we should think about whether we're going to need to revisit this in the future.

Hi Russell,

Quoted 7 lines

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

Quoted 4 lines

So it looks like someone's changed the behaviour of the assembler so it's no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa option. This means that the compiler generates a .arch armv6 directive in the .s file and the assembler barfs.

Quoted 22 lines · Anand Gadiyar

Quoted 12 lines · Catalin Marinas

Quoted 5 lines · Anand Gadiyar

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file gets compiled when the omap2plus_defconfig is built - the omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:

ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

Quoted 8 lines

From: Catalin Marinas <[email protected]>

This option uses LDREXB/STREXB to emulate SWPB but these instructions are not supported on all the ARMv6 processors.

Reported-by Anand Gadiyar <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Cc Leif Lindholm <[email protected]>

Quoted 6 lines

I can't find this patch in linux-next. Hope we haven't missed it. Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets CONFIG_SWP_EMULATE enabled even without this patch - I can't figure out why.

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

If it's not in yet, I can submit a patch.

Looks like the long term solution is to move the _user_swpX_asm into a separate .S file and set the v7 instructions for it.

Quoted 7 lines · Catalin Marinas

Quoted 6 lines · Anand Gadiyar

I can't find this patch in linux-next. Hope we haven't missed it. Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets CONFIG_SWP_EMULATE enabled even without this patch - I can't figure out why.

Quoted 6 lines

Russell had a better idea for handling this, not sure whether it went into -next. It was basically adding -march=armv7-a to CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger an undef fault for SWP on ARMv6 anyway.

If it's not in yet, I can submit a patch.

It's also queued for 2.6.38, but there is an issue with the latest gcc stuffing a .armv7 directive (or whatever) at the beginning of its output, thereby overriding the -Wa,-march=armv7-a on the command line. I think someone's looking at fixing GCC.

This stuff _is_ in linux-next, and has been in linux-next for ages.

Quoted 7 lines · Russell King - ARM Linux

It's also queued for 2.6.38, but there is an issue with the latest gcc stuffing a .armv7 directive (or whatever) at the beginning of its output, thereby overriding the -Wa,-march=armv7-a on the command line. I think someone's looking at fixing GCC.

This stuff _is_ in linux-next, and has been in linux-next for ages.

Yes, but that's a different patch :) Sorry I should have provided a link for the one I'm talking about, it's the patch that changes the options for SWP_EMULATE to have "depends on CPU_V7 && !CPU_V6":

http://marc.info/?l=linux-arm-kernel&m=128748874510144&w=2

That's still needed until we have the assembly in a separate .S file, or have the GCC options changed.