All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-17 19:20 ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:20 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

This patch series reworks the ARMv6/ARMv6K support options, code
selection, and bit operations such that it's possible to safely
build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
in one image.

Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K
if we have the K extensions.  CPU_32v6K directly controlled whether
we should include the ARMv6K instructions (clrex, load/store exclusive
byte, half-word, double).  As the bitops code uses the load/store
exclusive byte operations, unsetting CPU_32v6K results in these
falling back to their non-SMP local-irq-disabling variants.  These
are only safe in uniprocessor environments.

So, the first two patches convert the bitops to use the ARMv6 load/store
exclusive word operations - and ensuring correctness by ensuring that
the pointer passed in is word-aligned.

We then introduce a new CPU_V6K which indicates that we're including
an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
including an ARMv6 non-K CPU.

We can then use CPU_V6 to ensure that the non-v6K code paths which are
still SMP safe are selected.

Without this patch set, such a kernel will be unsafe when run on
SMP platforms as it omits necessary SMP code to ensure that bit
operations are safe.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-17 19:20 ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:20 UTC (permalink / raw)
  To: linux-arm-kernel

This patch series reworks the ARMv6/ARMv6K support options, code
selection, and bit operations such that it's possible to safely
build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
in one image.

Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K
if we have the K extensions.  CPU_32v6K directly controlled whether
we should include the ARMv6K instructions (clrex, load/store exclusive
byte, half-word, double).  As the bitops code uses the load/store
exclusive byte operations, unsetting CPU_32v6K results in these
falling back to their non-SMP local-irq-disabling variants.  These
are only safe in uniprocessor environments.

So, the first two patches convert the bitops to use the ARMv6 load/store
exclusive word operations - and ensuring correctness by ensuring that
the pointer passed in is word-aligned.

We then introduce a new CPU_V6K which indicates that we're including
an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
including an ARMv6 non-K CPU.

We can then use CPU_V6 to ensure that the non-v6K code paths which are
still SMP safe are selected.

Without this patch set, such a kernel will be unsafe when run on
SMP platforms as it omits necessary SMP code to ensure that bit
operations are safe.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:21   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:21 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Add additional instructions to our assembly bitops functions to ensure
that they only operate on word-aligned pointers.  This will be necessary
when we switch these operations to use the word-based exclusive
operations.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/lib/bitops.h |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index d422529..910d599 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,6 +1,8 @@
 
 #if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
 	.macro	bitop, instr
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	mov	r2, #1
 	and	r3, r0, #7		@ Get bit offset
 	add	r1, r1, r0, lsr #3	@ Get byte offset
@@ -14,6 +16,8 @@
 	.endm
 
 	.macro	testop, instr, store
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	and	r3, r0, #7		@ Get bit offset
 	mov	r2, #1
 	add	r1, r1, r0, lsr #3	@ Get byte offset
@@ -32,6 +36,8 @@
 	.endm
 #else
 	.macro	bitop, instr
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	and	r2, r0, #7
 	mov	r3, #1
 	mov	r3, r3, lsl r2
@@ -52,6 +58,8 @@
  * to avoid dirtying the data cache.
  */
 	.macro	testop, instr, store
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	add	r1, r1, r0, lsr #3
 	and	r3, r0, #7
 	mov	r0, #1
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-17 19:21   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

Add additional instructions to our assembly bitops functions to ensure
that they only operate on word-aligned pointers.  This will be necessary
when we switch these operations to use the word-based exclusive
operations.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/lib/bitops.h |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index d422529..910d599 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,6 +1,8 @@
 
 #if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
 	.macro	bitop, instr
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	mov	r2, #1
 	and	r3, r0, #7		@ Get bit offset
 	add	r1, r1, r0, lsr #3	@ Get byte offset
@@ -14,6 +16,8 @@
 	.endm
 
 	.macro	testop, instr, store
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	and	r3, r0, #7		@ Get bit offset
 	mov	r2, #1
 	add	r1, r1, r0, lsr #3	@ Get byte offset
@@ -32,6 +36,8 @@
 	.endm
 #else
 	.macro	bitop, instr
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	and	r2, r0, #7
 	mov	r3, #1
 	mov	r3, r3, lsl r2
@@ -52,6 +58,8 @@
  * to avoid dirtying the data cache.
  */
 	.macro	testop, instr, store
+	tst	r1, #3
+	strne	r1, [r1, -r1]		@ assert word-aligned
 	add	r1, r1, r0, lsr #3
 	and	r3, r0, #7
 	mov	r0, #1
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:21   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:21 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Switch the set/clear/change bitops to use the word-based exclusive
operations, which are only present in a wider range of ARM architectures
than the byte-based exclusive operations.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/bitops.h |   60 +++++++++++++++--------------------------
 arch/arm/kernel/armksyms.c    |   18 ++++--------
 arch/arm/lib/bitops.h         |   38 +++++++++++++------------
 arch/arm/lib/changebit.S      |   10 +-----
 arch/arm/lib/clearbit.S       |   11 +------
 arch/arm/lib/setbit.S         |   11 +------
 arch/arm/lib/testchangebit.S  |    9 ++----
 arch/arm/lib/testclearbit.S   |    9 ++----
 arch/arm/lib/testsetbit.S     |    9 ++----
 9 files changed, 63 insertions(+), 112 deletions(-)

diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 7b1bb2b..af54ed1 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -149,14 +149,18 @@ ____atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p)
  */
 
 /*
+ * Native endian assembly bitops.  nr = 0 -> word 0 bit 0.
+ */
+extern void _set_bit(int nr, volatile unsigned long * p);
+extern void _clear_bit(int nr, volatile unsigned long * p);
+extern void _change_bit(int nr, volatile unsigned long * p);
+extern int _test_and_set_bit(int nr, volatile unsigned long * p);
+extern int _test_and_clear_bit(int nr, volatile unsigned long * p);
+extern int _test_and_change_bit(int nr, volatile unsigned long * p);
+
+/*
  * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
  */
-extern void _set_bit_le(int nr, volatile unsigned long * p);
-extern void _clear_bit_le(int nr, volatile unsigned long * p);
-extern void _change_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_le(int nr, volatile unsigned long * p);
 extern int _find_first_zero_bit_le(const void * p, unsigned size);
 extern int _find_next_zero_bit_le(const void * p, int size, int offset);
 extern int _find_first_bit_le(const unsigned long *p, unsigned size);
@@ -165,12 +169,6 @@ extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
 /*
  * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
  */
-extern void _set_bit_be(int nr, volatile unsigned long * p);
-extern void _clear_bit_be(int nr, volatile unsigned long * p);
-extern void _change_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_be(int nr, volatile unsigned long * p);
 extern int _find_first_zero_bit_be(const void * p, unsigned size);
 extern int _find_next_zero_bit_be(const void * p, int size, int offset);
 extern int _find_first_bit_be(const unsigned long *p, unsigned size);
@@ -180,33 +178,26 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
 /*
  * The __* form of bitops are non-atomic and may be reordered.
  */
-#define	ATOMIC_BITOP_LE(name,nr,p)		\
-	(__builtin_constant_p(nr) ?		\
-	 ____atomic_##name(nr, p) :		\
-	 _##name##_le(nr,p))
-
-#define	ATOMIC_BITOP_BE(name,nr,p)		\
-	(__builtin_constant_p(nr) ?		\
-	 ____atomic_##name(nr, p) :		\
-	 _##name##_be(nr,p))
+#define ATOMIC_BITOP(name,nr,p)			\
+	(__builtin_constant_p(nr) ? ____atomic_##name(nr, p) : _##name(nr,p))
 #else
-#define ATOMIC_BITOP_LE(name,nr,p)	_##name##_le(nr,p)
-#define ATOMIC_BITOP_BE(name,nr,p)	_##name##_be(nr,p)
+#define ATOMIC_BITOP(name,nr,p)		_##name(nr,p)
 #endif
 
-#define NONATOMIC_BITOP(name,nr,p)		\
-	(____nonatomic_##name(nr, p))
+/*
+ * Native endian atomic definitions.
+ */
+#define set_bit(nr,p)			ATOMIC_BITOP(set_bit,nr,p)
+#define clear_bit(nr,p)			ATOMIC_BITOP(clear_bit,nr,p)
+#define change_bit(nr,p)		ATOMIC_BITOP(change_bit,nr,p)
+#define test_and_set_bit(nr,p)		ATOMIC_BITOP(test_and_set_bit,nr,p)
+#define test_and_clear_bit(nr,p)	ATOMIC_BITOP(test_and_clear_bit,nr,p)
+#define test_and_change_bit(nr,p)	ATOMIC_BITOP(test_and_change_bit,nr,p)
 
 #ifndef __ARMEB__
 /*
  * These are the little endian, atomic definitions.
  */
-#define set_bit(nr,p)			ATOMIC_BITOP_LE(set_bit,nr,p)
-#define clear_bit(nr,p)			ATOMIC_BITOP_LE(clear_bit,nr,p)
-#define change_bit(nr,p)		ATOMIC_BITOP_LE(change_bit,nr,p)
-#define test_and_set_bit(nr,p)		ATOMIC_BITOP_LE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_LE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p)	ATOMIC_BITOP_LE(test_and_change_bit,nr,p)
 #define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
 #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
 #define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
@@ -215,16 +206,9 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
 #define WORD_BITOFF_TO_LE(x)		((x))
 
 #else
-
 /*
  * These are the big endian, atomic definitions.
  */
-#define set_bit(nr,p)			ATOMIC_BITOP_BE(set_bit,nr,p)
-#define clear_bit(nr,p)			ATOMIC_BITOP_BE(clear_bit,nr,p)
-#define change_bit(nr,p)		ATOMIC_BITOP_BE(change_bit,nr,p)
-#define test_and_set_bit(nr,p)		ATOMIC_BITOP_BE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_BE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p)	ATOMIC_BITOP_BE(test_and_change_bit,nr,p)
 #define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
 #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
 #define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index e5e1e53..d5d4185 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -140,24 +140,18 @@ EXPORT_SYMBOL(__aeabi_ulcmp);
 #endif
 
 	/* bitops */
-EXPORT_SYMBOL(_set_bit_le);
-EXPORT_SYMBOL(_test_and_set_bit_le);
-EXPORT_SYMBOL(_clear_bit_le);
-EXPORT_SYMBOL(_test_and_clear_bit_le);
-EXPORT_SYMBOL(_change_bit_le);
-EXPORT_SYMBOL(_test_and_change_bit_le);
+EXPORT_SYMBOL(_set_bit);
+EXPORT_SYMBOL(_test_and_set_bit);
+EXPORT_SYMBOL(_clear_bit);
+EXPORT_SYMBOL(_test_and_clear_bit);
+EXPORT_SYMBOL(_change_bit);
+EXPORT_SYMBOL(_test_and_change_bit);
 EXPORT_SYMBOL(_find_first_zero_bit_le);
 EXPORT_SYMBOL(_find_next_zero_bit_le);
 EXPORT_SYMBOL(_find_first_bit_le);
 EXPORT_SYMBOL(_find_next_bit_le);
 
 #ifdef __ARMEB__
-EXPORT_SYMBOL(_set_bit_be);
-EXPORT_SYMBOL(_test_and_set_bit_be);
-EXPORT_SYMBOL(_clear_bit_be);
-EXPORT_SYMBOL(_test_and_clear_bit_be);
-EXPORT_SYMBOL(_change_bit_be);
-EXPORT_SYMBOL(_test_and_change_bit_be);
 EXPORT_SYMBOL(_find_first_zero_bit_be);
 EXPORT_SYMBOL(_find_next_zero_bit_be);
 EXPORT_SYMBOL(_find_first_bit_be);
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index 910d599..f8a2bd3 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,15 +1,15 @@
-
-#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
+#if __LINUX_ARM_ARCH__ >= 6
 	.macro	bitop, instr
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
 	mov	r2, #1
-	and	r3, r0, #7		@ Get bit offset
-	add	r1, r1, r0, lsr #3	@ Get byte offset
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
 	mov	r3, r2, lsl r3
-1:	ldrexb	r2, [r1]
+1:	ldrex	r2, [r1]
 	\instr	r2, r2, r3
-	strexb	r0, r2, [r1]
+	strex	r0, r2, [r1]
 	cmp	r0, #0
 	bne	1b
 	mov	pc, lr
@@ -18,15 +18,16 @@
 	.macro	testop, instr, store
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	and	r3, r0, #7		@ Get bit offset
 	mov	r2, #1
-	add	r1, r1, r0, lsr #3	@ Get byte offset
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
 	mov	r3, r2, lsl r3		@ create mask
 	smp_dmb
-1:	ldrexb	r2, [r1]
+1:	ldrex	r2, [r1]
 	ands	r0, r2, r3		@ save old value of bit
-	\instr	r2, r2, r3			@ toggle bit
-	strexb	ip, r2, [r1]
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
 	cmp	ip, #0
 	bne	1b
 	smp_dmb
@@ -38,13 +39,14 @@
 	.macro	bitop, instr
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	and	r2, r0, #7
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
 	mov	r3, #1
 	mov	r3, r3, lsl r2
 	save_and_disable_irqs ip
-	ldrb	r2, [r1, r0, lsr #3]
+	ldr	r2, [r1, r0, lsl #2]
 	\instr	r2, r2, r3
-	strb	r2, [r1, r0, lsr #3]
+	str	r2, [r1, r0, lsl #2]
 	restore_irqs ip
 	mov	pc, lr
 	.endm
@@ -60,11 +62,11 @@
 	.macro	testop, instr, store
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	add	r1, r1, r0, lsr #3
-	and	r3, r0, #7
-	mov	r0, #1
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
 	save_and_disable_irqs ip
-	ldrb	r2, [r1]
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
 	tst	r2, r0, lsl r3
 	\instr	r2, r2, r0, lsl r3
 	\store	r2, [r1]
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index 80f3115..68ed5b6 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -12,12 +12,6 @@
 #include "bitops.h"
                 .text
 
-/* Purpose  : Function to change a bit
- * Prototype: int change_bit(int bit, void *addr)
- */
-ENTRY(_change_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_change_bit_le)
+ENTRY(_change_bit)
 	bitop	eor
-ENDPROC(_change_bit_be)
-ENDPROC(_change_bit_le)
+ENDPROC(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index 1a63e43..4c04c3b 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -12,13 +12,6 @@
 #include "bitops.h"
                 .text
 
-/*
- * Purpose  : Function to clear a bit
- * Prototype: int clear_bit(int bit, void *addr)
- */
-ENTRY(_clear_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_clear_bit_le)
+ENTRY(_clear_bit)
 	bitop	bic
-ENDPROC(_clear_bit_be)
-ENDPROC(_clear_bit_le)
+ENDPROC(_clear_bit)
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 1dd7176..bbee5c6 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -12,13 +12,6 @@
 #include "bitops.h"
 		.text
 
-/*
- * Purpose  : Function to set a bit
- * Prototype: int set_bit(int bit, void *addr)
- */
-ENTRY(_set_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_set_bit_le)
+ENTRY(_set_bit)
 	bitop	orr
-ENDPROC(_set_bit_be)
-ENDPROC(_set_bit_le)
+ENDPROC(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 5c98dc5..15a4d43 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_change_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_change_bit_le)
-	testop	eor, strb
-ENDPROC(_test_and_change_bit_be)
-ENDPROC(_test_and_change_bit_le)
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 543d709..521b66b 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_clear_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_clear_bit_le)
-	testop	bicne, strneb
-ENDPROC(_test_and_clear_bit_be)
-ENDPROC(_test_and_clear_bit_le)
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 0b3f390..1c98cc2 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_set_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_set_bit_le)
-	testop	orreq, streqb
-ENDPROC(_test_and_set_bit_be)
-ENDPROC(_test_and_set_bit_le)
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-17 19:21   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

Switch the set/clear/change bitops to use the word-based exclusive
operations, which are only present in a wider range of ARM architectures
than the byte-based exclusive operations.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/bitops.h |   60 +++++++++++++++--------------------------
 arch/arm/kernel/armksyms.c    |   18 ++++--------
 arch/arm/lib/bitops.h         |   38 +++++++++++++------------
 arch/arm/lib/changebit.S      |   10 +-----
 arch/arm/lib/clearbit.S       |   11 +------
 arch/arm/lib/setbit.S         |   11 +------
 arch/arm/lib/testchangebit.S  |    9 ++----
 arch/arm/lib/testclearbit.S   |    9 ++----
 arch/arm/lib/testsetbit.S     |    9 ++----
 9 files changed, 63 insertions(+), 112 deletions(-)

diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 7b1bb2b..af54ed1 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -149,14 +149,18 @@ ____atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p)
  */
 
 /*
+ * Native endian assembly bitops.  nr = 0 -> word 0 bit 0.
+ */
+extern void _set_bit(int nr, volatile unsigned long * p);
+extern void _clear_bit(int nr, volatile unsigned long * p);
+extern void _change_bit(int nr, volatile unsigned long * p);
+extern int _test_and_set_bit(int nr, volatile unsigned long * p);
+extern int _test_and_clear_bit(int nr, volatile unsigned long * p);
+extern int _test_and_change_bit(int nr, volatile unsigned long * p);
+
+/*
  * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
  */
-extern void _set_bit_le(int nr, volatile unsigned long * p);
-extern void _clear_bit_le(int nr, volatile unsigned long * p);
-extern void _change_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_le(int nr, volatile unsigned long * p);
 extern int _find_first_zero_bit_le(const void * p, unsigned size);
 extern int _find_next_zero_bit_le(const void * p, int size, int offset);
 extern int _find_first_bit_le(const unsigned long *p, unsigned size);
@@ -165,12 +169,6 @@ extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
 /*
  * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
  */
-extern void _set_bit_be(int nr, volatile unsigned long * p);
-extern void _clear_bit_be(int nr, volatile unsigned long * p);
-extern void _change_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_be(int nr, volatile unsigned long * p);
 extern int _find_first_zero_bit_be(const void * p, unsigned size);
 extern int _find_next_zero_bit_be(const void * p, int size, int offset);
 extern int _find_first_bit_be(const unsigned long *p, unsigned size);
@@ -180,33 +178,26 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
 /*
  * The __* form of bitops are non-atomic and may be reordered.
  */
-#define	ATOMIC_BITOP_LE(name,nr,p)		\
-	(__builtin_constant_p(nr) ?		\
-	 ____atomic_##name(nr, p) :		\
-	 _##name##_le(nr,p))
-
-#define	ATOMIC_BITOP_BE(name,nr,p)		\
-	(__builtin_constant_p(nr) ?		\
-	 ____atomic_##name(nr, p) :		\
-	 _##name##_be(nr,p))
+#define ATOMIC_BITOP(name,nr,p)			\
+	(__builtin_constant_p(nr) ? ____atomic_##name(nr, p) : _##name(nr,p))
 #else
-#define ATOMIC_BITOP_LE(name,nr,p)	_##name##_le(nr,p)
-#define ATOMIC_BITOP_BE(name,nr,p)	_##name##_be(nr,p)
+#define ATOMIC_BITOP(name,nr,p)		_##name(nr,p)
 #endif
 
-#define NONATOMIC_BITOP(name,nr,p)		\
-	(____nonatomic_##name(nr, p))
+/*
+ * Native endian atomic definitions.
+ */
+#define set_bit(nr,p)			ATOMIC_BITOP(set_bit,nr,p)
+#define clear_bit(nr,p)			ATOMIC_BITOP(clear_bit,nr,p)
+#define change_bit(nr,p)		ATOMIC_BITOP(change_bit,nr,p)
+#define test_and_set_bit(nr,p)		ATOMIC_BITOP(test_and_set_bit,nr,p)
+#define test_and_clear_bit(nr,p)	ATOMIC_BITOP(test_and_clear_bit,nr,p)
+#define test_and_change_bit(nr,p)	ATOMIC_BITOP(test_and_change_bit,nr,p)
 
 #ifndef __ARMEB__
 /*
  * These are the little endian, atomic definitions.
  */
-#define set_bit(nr,p)			ATOMIC_BITOP_LE(set_bit,nr,p)
-#define clear_bit(nr,p)			ATOMIC_BITOP_LE(clear_bit,nr,p)
-#define change_bit(nr,p)		ATOMIC_BITOP_LE(change_bit,nr,p)
-#define test_and_set_bit(nr,p)		ATOMIC_BITOP_LE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_LE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p)	ATOMIC_BITOP_LE(test_and_change_bit,nr,p)
 #define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
 #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
 #define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
@@ -215,16 +206,9 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
 #define WORD_BITOFF_TO_LE(x)		((x))
 
 #else
-
 /*
  * These are the big endian, atomic definitions.
  */
-#define set_bit(nr,p)			ATOMIC_BITOP_BE(set_bit,nr,p)
-#define clear_bit(nr,p)			ATOMIC_BITOP_BE(clear_bit,nr,p)
-#define change_bit(nr,p)		ATOMIC_BITOP_BE(change_bit,nr,p)
-#define test_and_set_bit(nr,p)		ATOMIC_BITOP_BE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_BE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p)	ATOMIC_BITOP_BE(test_and_change_bit,nr,p)
 #define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
 #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
 #define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index e5e1e53..d5d4185 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -140,24 +140,18 @@ EXPORT_SYMBOL(__aeabi_ulcmp);
 #endif
 
 	/* bitops */
-EXPORT_SYMBOL(_set_bit_le);
-EXPORT_SYMBOL(_test_and_set_bit_le);
-EXPORT_SYMBOL(_clear_bit_le);
-EXPORT_SYMBOL(_test_and_clear_bit_le);
-EXPORT_SYMBOL(_change_bit_le);
-EXPORT_SYMBOL(_test_and_change_bit_le);
+EXPORT_SYMBOL(_set_bit);
+EXPORT_SYMBOL(_test_and_set_bit);
+EXPORT_SYMBOL(_clear_bit);
+EXPORT_SYMBOL(_test_and_clear_bit);
+EXPORT_SYMBOL(_change_bit);
+EXPORT_SYMBOL(_test_and_change_bit);
 EXPORT_SYMBOL(_find_first_zero_bit_le);
 EXPORT_SYMBOL(_find_next_zero_bit_le);
 EXPORT_SYMBOL(_find_first_bit_le);
 EXPORT_SYMBOL(_find_next_bit_le);
 
 #ifdef __ARMEB__
-EXPORT_SYMBOL(_set_bit_be);
-EXPORT_SYMBOL(_test_and_set_bit_be);
-EXPORT_SYMBOL(_clear_bit_be);
-EXPORT_SYMBOL(_test_and_clear_bit_be);
-EXPORT_SYMBOL(_change_bit_be);
-EXPORT_SYMBOL(_test_and_change_bit_be);
 EXPORT_SYMBOL(_find_first_zero_bit_be);
 EXPORT_SYMBOL(_find_next_zero_bit_be);
 EXPORT_SYMBOL(_find_first_bit_be);
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index 910d599..f8a2bd3 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,15 +1,15 @@
-
-#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
+#if __LINUX_ARM_ARCH__ >= 6
 	.macro	bitop, instr
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
 	mov	r2, #1
-	and	r3, r0, #7		@ Get bit offset
-	add	r1, r1, r0, lsr #3	@ Get byte offset
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
 	mov	r3, r2, lsl r3
-1:	ldrexb	r2, [r1]
+1:	ldrex	r2, [r1]
 	\instr	r2, r2, r3
-	strexb	r0, r2, [r1]
+	strex	r0, r2, [r1]
 	cmp	r0, #0
 	bne	1b
 	mov	pc, lr
@@ -18,15 +18,16 @@
 	.macro	testop, instr, store
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	and	r3, r0, #7		@ Get bit offset
 	mov	r2, #1
-	add	r1, r1, r0, lsr #3	@ Get byte offset
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
 	mov	r3, r2, lsl r3		@ create mask
 	smp_dmb
-1:	ldrexb	r2, [r1]
+1:	ldrex	r2, [r1]
 	ands	r0, r2, r3		@ save old value of bit
-	\instr	r2, r2, r3			@ toggle bit
-	strexb	ip, r2, [r1]
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
 	cmp	ip, #0
 	bne	1b
 	smp_dmb
@@ -38,13 +39,14 @@
 	.macro	bitop, instr
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	and	r2, r0, #7
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
 	mov	r3, #1
 	mov	r3, r3, lsl r2
 	save_and_disable_irqs ip
-	ldrb	r2, [r1, r0, lsr #3]
+	ldr	r2, [r1, r0, lsl #2]
 	\instr	r2, r2, r3
-	strb	r2, [r1, r0, lsr #3]
+	str	r2, [r1, r0, lsl #2]
 	restore_irqs ip
 	mov	pc, lr
 	.endm
@@ -60,11 +62,11 @@
 	.macro	testop, instr, store
 	tst	r1, #3
 	strne	r1, [r1, -r1]		@ assert word-aligned
-	add	r1, r1, r0, lsr #3
-	and	r3, r0, #7
-	mov	r0, #1
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
 	save_and_disable_irqs ip
-	ldrb	r2, [r1]
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
 	tst	r2, r0, lsl r3
 	\instr	r2, r2, r0, lsl r3
 	\store	r2, [r1]
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index 80f3115..68ed5b6 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -12,12 +12,6 @@
 #include "bitops.h"
                 .text
 
-/* Purpose  : Function to change a bit
- * Prototype: int change_bit(int bit, void *addr)
- */
-ENTRY(_change_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_change_bit_le)
+ENTRY(_change_bit)
 	bitop	eor
-ENDPROC(_change_bit_be)
-ENDPROC(_change_bit_le)
+ENDPROC(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index 1a63e43..4c04c3b 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -12,13 +12,6 @@
 #include "bitops.h"
                 .text
 
-/*
- * Purpose  : Function to clear a bit
- * Prototype: int clear_bit(int bit, void *addr)
- */
-ENTRY(_clear_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_clear_bit_le)
+ENTRY(_clear_bit)
 	bitop	bic
-ENDPROC(_clear_bit_be)
-ENDPROC(_clear_bit_le)
+ENDPROC(_clear_bit)
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 1dd7176..bbee5c6 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -12,13 +12,6 @@
 #include "bitops.h"
 		.text
 
-/*
- * Purpose  : Function to set a bit
- * Prototype: int set_bit(int bit, void *addr)
- */
-ENTRY(_set_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_set_bit_le)
+ENTRY(_set_bit)
 	bitop	orr
-ENDPROC(_set_bit_be)
-ENDPROC(_set_bit_le)
+ENDPROC(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 5c98dc5..15a4d43 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_change_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_change_bit_le)
-	testop	eor, strb
-ENDPROC(_test_and_change_bit_be)
-ENDPROC(_test_and_change_bit_le)
+ENTRY(_test_and_change_bit)
+	testop	eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 543d709..521b66b 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_clear_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_clear_bit_le)
-	testop	bicne, strneb
-ENDPROC(_test_and_clear_bit_be)
-ENDPROC(_test_and_clear_bit_le)
+ENTRY(_test_and_clear_bit)
+	testop	bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 0b3f390..1c98cc2 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -12,9 +12,6 @@
 #include "bitops.h"
                 .text
 
-ENTRY(_test_and_set_bit_be)
-		eor	r0, r0, #0x18		@ big endian byte ordering
-ENTRY(_test_and_set_bit_le)
-	testop	orreq, streqb
-ENDPROC(_test_and_set_bit_be)
-ENDPROC(_test_and_set_bit_le)
+ENTRY(_test_and_set_bit)
+	testop	orreq, streq
+ENDPROC(_test_and_set_bit)
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.

However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream.  Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/spinlock.h |   37 +++++++++++++++++++++++++------------
 1 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 17eb355..da1af52 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
 #error SMP not supported on pre-ARMv6 CPUs
 #endif
 
+/*
+ * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
+ * extensions, so when running on UP, we have to patch these instructions away.
+ */
+#define ALT_SMP(smp, up)					\
+	"9998:	" smp "\n"					\
+	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
+	"	.long	9998b\n"				\
+	"	" up "\n"					\
+	"	.popsection\n"
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEV		ALT_SMP("sev.w", "nop.w")
+#define WFE(cond)	ALT_SMP("wfe" cond ".w", "nop.w")
+#else
+#define SEV		ALT_SMP("sev", "nop")
+#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
+#endif
+
 static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
 	__asm__ __volatile__ (
 		"dsb\n"
-		"sev"
+		SEV
 	);
-#elif defined(CONFIG_CPU_32v6K)
+#else
 	__asm__ __volatile__ (
 		"mcr p15, 0, %0, c7, c10, 4\n"
-		"sev"
+		SEV
 		: : "r" (0)
 	);
 #endif
@@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfene\n"
-#endif
+	WFE("ne")
 "	strexeq	%0, %2, [%1]\n"
 "	teqeq	%0, #0\n"
 "	bne	1b"
@@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfene\n"
-#endif
+	WFE("ne")
 "	strexeq	%0, %2, [%1]\n"
 "	teq	%0, #0\n"
 "	bne	1b"
@@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
 "1:	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
 "	strexpl	%1, %0, [%2]\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfemi\n"
-#endif
+	WFE("mi")
 "	rsbpls	%0, %1, #0\n"
 "	bmi	1b"
 	: "=&r" (tmp), "=&r" (tmp2)
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel

SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.

However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream.  Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/spinlock.h |   37 +++++++++++++++++++++++++------------
 1 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 17eb355..da1af52 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
 #error SMP not supported on pre-ARMv6 CPUs
 #endif
 
+/*
+ * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
+ * extensions, so when running on UP, we have to patch these instructions away.
+ */
+#define ALT_SMP(smp, up)					\
+	"9998:	" smp "\n"					\
+	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
+	"	.long	9998b\n"				\
+	"	" up "\n"					\
+	"	.popsection\n"
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEV		ALT_SMP("sev.w", "nop.w")
+#define WFE(cond)	ALT_SMP("wfe" cond ".w", "nop.w")
+#else
+#define SEV		ALT_SMP("sev", "nop")
+#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
+#endif
+
 static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
 	__asm__ __volatile__ (
 		"dsb\n"
-		"sev"
+		SEV
 	);
-#elif defined(CONFIG_CPU_32v6K)
+#else
 	__asm__ __volatile__ (
 		"mcr p15, 0, %0, c7, c10, 4\n"
-		"sev"
+		SEV
 		: : "r" (0)
 	);
 #endif
@@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfene\n"
-#endif
+	WFE("ne")
 "	strexeq	%0, %2, [%1]\n"
 "	teqeq	%0, #0\n"
 "	bne	1b"
@@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfene\n"
-#endif
+	WFE("ne")
 "	strexeq	%0, %2, [%1]\n"
 "	teq	%0, #0\n"
 "	bne	1b"
@@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
 "1:	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
 "	strexpl	%1, %0, [%2]\n"
-#ifdef CONFIG_CPU_32v6K
-"	wfemi\n"
-#endif
+	WFE("mi")
 "	rsbpls	%0, %1, #0\n"
 "	bmi	1b"
 	: "=&r" (tmp), "=&r" (tmp2)
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Introduce a CPU_V6K configuration option for platforms to select if they
have a V6K CPU core.  This allows us to identify whether we need to
support ARMv6 CPUs without the V6K SMP extensions at build time.

Currently CPU_V6K is just an alias for CPU_V6, and all places which
reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).

Select CPU_V6K from platforms which are known to be V6K-only.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig                  |   10 ++++----
 arch/arm/Makefile                 |    1 +
 arch/arm/boot/compressed/head.S   |    2 +-
 arch/arm/boot/compressed/misc.c   |    2 +-
 arch/arm/include/asm/cacheflush.h |    5 ++-
 arch/arm/include/asm/proc-fns.h   |    2 +-
 arch/arm/kernel/debug.S           |    2 +-
 arch/arm/kernel/perf_event_v6.c   |    4 +-
 arch/arm/mm/Kconfig               |   47 +++++++++++++++++++++++-------------
 arch/arm/mm/Makefile              |    1 +
 arch/arm/mm/mmap.c                |    2 +-
 11 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..95ba92f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -24,7 +24,7 @@ config ARM
 	select HAVE_PERF_EVENTS
 	select PERF_USE_VMALLOC
 	select HAVE_REGS_AND_STACK_ACCESS_API
-	select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V7))
+	select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_GENERIC_HARDIRQS
 	select HAVE_SPARSE_IRQ
@@ -1048,7 +1048,7 @@ config XSCALE_PMU
 	default y
 
 config CPU_HAS_PMU
-	depends on (CPU_V6 || CPU_V7 || XSCALE_PMU) && \
+	depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU) && \
 		   (!ARCH_OMAP3 || OMAP3_EMU)
 	default y
 	bool
@@ -1064,7 +1064,7 @@ endif
 
 config ARM_ERRATA_411920
 	bool "ARM errata: Invalidation of the Instruction Cache operation can fail"
-	depends on CPU_V6
+	depends on CPU_V6 || CPU_V6K
 	help
 	  Invalidation of the Instruction Cache operation can
 	  fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
@@ -1361,7 +1361,7 @@ config HZ
 
 config THUMB2_KERNEL
 	bool "Compile the kernel in Thumb-2 mode (EXPERIMENTAL)"
-	depends on CPU_V7 && !CPU_V6 && EXPERIMENTAL
+	depends on CPU_V7 && !CPU_V6 && !CPU_V6K && EXPERIMENTAL
 	select AEABI
 	select ARM_ASM_UNIFIED
 	help
@@ -1852,7 +1852,7 @@ config FPE_FASTFPE
 
 config VFP
 	bool "VFP-format floating point maths"
-	depends on CPU_V6 || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
+	depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
 	help
 	  Say Y to include VFP support code in the kernel. This is needed
 	  if your hardware includes a VFP unit.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c22c1ad..9c43052 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
 tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
 tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
+tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
 
 ifeq ($(CONFIG_AEABI),y)
 CFLAGS_ABI	:=-mabi=aapcs-linux -mno-thumb-interwork
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 7193884..91f20f0 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -21,7 +21,7 @@
 
 #if defined(CONFIG_DEBUG_ICEDCC)
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 		.macro	loadsp, rb, tmp
 		.endm
 		.macro	writeb, ch, rb
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index e653a6d..4657e87 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -36,7 +36,7 @@ extern void error(char *x);
 
 #ifdef CONFIG_DEBUG_ICEDCC
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 
 static void icedcc_putc(int ch)
 {
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 3acd8fa..7d0614f 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -116,7 +116,7 @@
 # define MULTI_CACHE 1
 #endif
 
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 //# ifdef _CACHE
 #  define MULTI_CACHE 1
 //# else
@@ -316,7 +316,8 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
  * Optimized __flush_icache_all for the common cases. Note that UP ARMv7
  * will fall through to use __flush_icache_all_generic.
  */
-#if (defined(CONFIG_CPU_V7) && defined(CONFIG_CPU_V6)) ||		\
+#if (defined(CONFIG_CPU_V7) && \
+     (defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K))) || \
 	defined(CONFIG_SMP_ON_UP)
 #define __flush_icache_preferred	__cpuc_flush_icache_all
 #elif __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index 8fdae9b..296ca47 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -231,7 +231,7 @@
 # endif
 #endif
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 # ifdef CPU_NAME
 #  undef  MULTI_CPU
 #  define MULTI_CPU
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index a0f0752..d2d983b 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -25,7 +25,7 @@
 		.macro	addruart, rp, rv
 		.endm
 
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 
 		.macro	senduart, rd, rx
 		mcr	p14, 0, \rd, c0, c5, 0
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index c058bfc..6fc2d22 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -30,7 +30,7 @@
  * enable the interrupt.
  */
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 enum armv6_perf_types {
 	ARMV6_PERFCTR_ICACHE_MISS	    = 0x0,
 	ARMV6_PERFCTR_IBUF_STALL	    = 0x1,
@@ -669,4 +669,4 @@ static const struct arm_pmu *__init armv6mpcore_pmu_init(void)
 {
 	return NULL;
 }
-#endif	/* CONFIG_CPU_V6 */
+#endif	/* CONFIG_CPU_V6 || CONFIG_CPU_V6K */
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9d30c6f..559e933 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -402,16 +402,18 @@ config CPU_V6
 	select CPU_TLB_V6 if MMU
 
 # ARMv6k
-config CPU_32v6K
-	bool "Support ARM V6K processor extensions" if !SMP
-	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
-	help
-	  Say Y here if your ARMv6 processor supports the 'K' extension.
-	  This enables the kernel to use some instructions not present
-	  on previous processors, and as such a kernel build with this
-	  enabled will not boot on processors with do not support these
-	  instructions.
+config CPU_V6K
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	select CPU_32v6
+	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_ABRT_EV6
+	select CPU_PABRT_V6
+	select CPU_CACHE_V6
+	select CPU_CACHE_VIPT
+	select CPU_CP15_MMU
+	select CPU_HAS_ASID if MMU
+	select CPU_COPY_V6 if MMU
+	select CPU_TLB_V6 if MMU
 
 # ARMv7
 config CPU_V7
@@ -453,6 +455,17 @@ config CPU_32v6
 	bool
 	select TLS_REG_EMUL if !CPU_32v6K && !MMU
 
+config CPU_32v6K
+	bool "Support ARM V6K processor extensions" if !SMP
+	depends on CPU_V6 || CPU_V6K || CPU_V7
+	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	help
+	  Say Y here if your ARMv6 processor supports the 'K' extension.
+	  This enables the kernel to use some instructions not present
+	  on previous processors, and as such a kernel build with this
+	  enabled will not boot on processors with do not support these
+	  instructions.
+
 config CPU_32v7
 	bool
 
@@ -623,7 +636,7 @@ comment "Processor Features"
 
 config ARM_THUMB
 	bool "Support Thumb user binaries"
-	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V7 || CPU_FEROCEON
+	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V6K || CPU_V7 || CPU_FEROCEON
 	default y
 	help
 	  Say Y if you want to include kernel support for running user space
@@ -681,7 +694,7 @@ config CPU_BIG_ENDIAN
 config CPU_ENDIAN_BE8
 	bool
 	depends on CPU_BIG_ENDIAN
-	default CPU_V6 || CPU_V7
+	default CPU_V6 || CPU_V6K || CPU_V7
 	help
 	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
 
@@ -747,7 +760,7 @@ config CPU_CACHE_ROUND_ROBIN
 
 config CPU_BPREDICT_DISABLE
 	bool "Disable branch prediction"
-	depends on CPU_ARM1020 || CPU_V6 || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
+	depends on CPU_ARM1020 || CPU_V6 || CPU_V6K || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
 	help
 	  Say Y here to disable branch prediction.  If unsure, say N.
 
@@ -767,7 +780,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
 
 config DMA_CACHE_RWFO
 	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on CPU_V6 && SMP
+	depends on (CPU_V6 || CPU_V6K) && SMP
 	default y
 	help
 	  The Snoop Control Unit on ARM11MPCore does not detect the
@@ -823,7 +836,7 @@ config CACHE_L2X0
 config CACHE_PL310
 	bool
 	depends on CACHE_L2X0
-	default y if CPU_V7 && !CPU_V6
+	default y if CPU_V7 && !(CPU_V6 || CPU_V6K)
 	help
 	  This option enables optimisations for the PL310 cache
 	  controller.
@@ -851,10 +864,10 @@ config ARM_L1_CACHE_SHIFT
 	default 5
 
 config ARM_DMA_MEM_BUFFERABLE
-	bool "Use non-cacheable memory for DMA" if CPU_V6 && !CPU_V7
+	bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
 	depends on !(MACH_REALVIEW_PB1176 || REALVIEW_EB_ARM11MP || \
 		     MACH_REALVIEW_PB11MP)
-	default y if CPU_V6 || CPU_V7
+	default y if CPU_V6 || CPU_V6K || CPU_V7
 	help
 	  Historically, the kernel has used strongly ordered mappings to
 	  provide DMA coherent memory.  With the advent of ARMv7, mapping
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 00d74a0..bca7e61 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_CPU_XSC3)		+= proc-xsc3.o
 obj-$(CONFIG_CPU_MOHAWK)	+= proc-mohawk.o
 obj-$(CONFIG_CPU_FEROCEON)	+= proc-feroceon.o
 obj-$(CONFIG_CPU_V6)		+= proc-v6.o
+obj-$(CONFIG_CPU_V6K)		+= proc-v6.o
 obj-$(CONFIG_CPU_V7)		+= proc-v7.o
 
 AFLAGS_proc-v6.o	:=-Wa,-march=armv6
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index b0a9830..afe209e 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -31,7 +31,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 	struct mm_struct *mm = current->mm;
 	struct vm_area_struct *vma;
 	unsigned long start_addr;
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 	unsigned int cache_type;
 	int do_align = 0, aliasing = 0;
 
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel

Introduce a CPU_V6K configuration option for platforms to select if they
have a V6K CPU core.  This allows us to identify whether we need to
support ARMv6 CPUs without the V6K SMP extensions at build time.

Currently CPU_V6K is just an alias for CPU_V6, and all places which
reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).

Select CPU_V6K from platforms which are known to be V6K-only.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig                  |   10 ++++----
 arch/arm/Makefile                 |    1 +
 arch/arm/boot/compressed/head.S   |    2 +-
 arch/arm/boot/compressed/misc.c   |    2 +-
 arch/arm/include/asm/cacheflush.h |    5 ++-
 arch/arm/include/asm/proc-fns.h   |    2 +-
 arch/arm/kernel/debug.S           |    2 +-
 arch/arm/kernel/perf_event_v6.c   |    4 +-
 arch/arm/mm/Kconfig               |   47 +++++++++++++++++++++++-------------
 arch/arm/mm/Makefile              |    1 +
 arch/arm/mm/mmap.c                |    2 +-
 11 files changed, 47 insertions(+), 31 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..95ba92f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -24,7 +24,7 @@ config ARM
 	select HAVE_PERF_EVENTS
 	select PERF_USE_VMALLOC
 	select HAVE_REGS_AND_STACK_ACCESS_API
-	select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V7))
+	select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_GENERIC_HARDIRQS
 	select HAVE_SPARSE_IRQ
@@ -1048,7 +1048,7 @@ config XSCALE_PMU
 	default y
 
 config CPU_HAS_PMU
-	depends on (CPU_V6 || CPU_V7 || XSCALE_PMU) && \
+	depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU) && \
 		   (!ARCH_OMAP3 || OMAP3_EMU)
 	default y
 	bool
@@ -1064,7 +1064,7 @@ endif
 
 config ARM_ERRATA_411920
 	bool "ARM errata: Invalidation of the Instruction Cache operation can fail"
-	depends on CPU_V6
+	depends on CPU_V6 || CPU_V6K
 	help
 	  Invalidation of the Instruction Cache operation can
 	  fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
@@ -1361,7 +1361,7 @@ config HZ
 
 config THUMB2_KERNEL
 	bool "Compile the kernel in Thumb-2 mode (EXPERIMENTAL)"
-	depends on CPU_V7 && !CPU_V6 && EXPERIMENTAL
+	depends on CPU_V7 && !CPU_V6 && !CPU_V6K && EXPERIMENTAL
 	select AEABI
 	select ARM_ASM_UNIFIED
 	help
@@ -1852,7 +1852,7 @@ config FPE_FASTFPE
 
 config VFP
 	bool "VFP-format floating point maths"
-	depends on CPU_V6 || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
+	depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
 	help
 	  Say Y to include VFP support code in the kernel. This is needed
 	  if your hardware includes a VFP unit.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c22c1ad..9c43052 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
 tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
 tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
+tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
 
 ifeq ($(CONFIG_AEABI),y)
 CFLAGS_ABI	:=-mabi=aapcs-linux -mno-thumb-interwork
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 7193884..91f20f0 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -21,7 +21,7 @@
 
 #if defined(CONFIG_DEBUG_ICEDCC)
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 		.macro	loadsp, rb, tmp
 		.endm
 		.macro	writeb, ch, rb
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index e653a6d..4657e87 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -36,7 +36,7 @@ extern void error(char *x);
 
 #ifdef CONFIG_DEBUG_ICEDCC
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 
 static void icedcc_putc(int ch)
 {
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 3acd8fa..7d0614f 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -116,7 +116,7 @@
 # define MULTI_CACHE 1
 #endif
 
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 //# ifdef _CACHE
 #  define MULTI_CACHE 1
 //# else
@@ -316,7 +316,8 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
  * Optimized __flush_icache_all for the common cases. Note that UP ARMv7
  * will fall through to use __flush_icache_all_generic.
  */
-#if (defined(CONFIG_CPU_V7) && defined(CONFIG_CPU_V6)) ||		\
+#if (defined(CONFIG_CPU_V7) && \
+     (defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K))) || \
 	defined(CONFIG_SMP_ON_UP)
 #define __flush_icache_preferred	__cpuc_flush_icache_all
 #elif __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index 8fdae9b..296ca47 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -231,7 +231,7 @@
 # endif
 #endif
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 # ifdef CPU_NAME
 #  undef  MULTI_CPU
 #  define MULTI_CPU
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index a0f0752..d2d983b 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -25,7 +25,7 @@
 		.macro	addruart, rp, rv
 		.endm
 
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 
 		.macro	senduart, rd, rx
 		mcr	p14, 0, \rd, c0, c5, 0
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index c058bfc..6fc2d22 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -30,7 +30,7 @@
  * enable the interrupt.
  */
 
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 enum armv6_perf_types {
 	ARMV6_PERFCTR_ICACHE_MISS	    = 0x0,
 	ARMV6_PERFCTR_IBUF_STALL	    = 0x1,
@@ -669,4 +669,4 @@ static const struct arm_pmu *__init armv6mpcore_pmu_init(void)
 {
 	return NULL;
 }
-#endif	/* CONFIG_CPU_V6 */
+#endif	/* CONFIG_CPU_V6 || CONFIG_CPU_V6K */
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9d30c6f..559e933 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -402,16 +402,18 @@ config CPU_V6
 	select CPU_TLB_V6 if MMU
 
 # ARMv6k
-config CPU_32v6K
-	bool "Support ARM V6K processor extensions" if !SMP
-	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
-	help
-	  Say Y here if your ARMv6 processor supports the 'K' extension.
-	  This enables the kernel to use some instructions not present
-	  on previous processors, and as such a kernel build with this
-	  enabled will not boot on processors with do not support these
-	  instructions.
+config CPU_V6K
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	select CPU_32v6
+	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_ABRT_EV6
+	select CPU_PABRT_V6
+	select CPU_CACHE_V6
+	select CPU_CACHE_VIPT
+	select CPU_CP15_MMU
+	select CPU_HAS_ASID if MMU
+	select CPU_COPY_V6 if MMU
+	select CPU_TLB_V6 if MMU
 
 # ARMv7
 config CPU_V7
@@ -453,6 +455,17 @@ config CPU_32v6
 	bool
 	select TLS_REG_EMUL if !CPU_32v6K && !MMU
 
+config CPU_32v6K
+	bool "Support ARM V6K processor extensions" if !SMP
+	depends on CPU_V6 || CPU_V6K || CPU_V7
+	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	help
+	  Say Y here if your ARMv6 processor supports the 'K' extension.
+	  This enables the kernel to use some instructions not present
+	  on previous processors, and as such a kernel build with this
+	  enabled will not boot on processors with do not support these
+	  instructions.
+
 config CPU_32v7
 	bool
 
@@ -623,7 +636,7 @@ comment "Processor Features"
 
 config ARM_THUMB
 	bool "Support Thumb user binaries"
-	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V7 || CPU_FEROCEON
+	depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V6K || CPU_V7 || CPU_FEROCEON
 	default y
 	help
 	  Say Y if you want to include kernel support for running user space
@@ -681,7 +694,7 @@ config CPU_BIG_ENDIAN
 config CPU_ENDIAN_BE8
 	bool
 	depends on CPU_BIG_ENDIAN
-	default CPU_V6 || CPU_V7
+	default CPU_V6 || CPU_V6K || CPU_V7
 	help
 	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
 
@@ -747,7 +760,7 @@ config CPU_CACHE_ROUND_ROBIN
 
 config CPU_BPREDICT_DISABLE
 	bool "Disable branch prediction"
-	depends on CPU_ARM1020 || CPU_V6 || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
+	depends on CPU_ARM1020 || CPU_V6 || CPU_V6K || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
 	help
 	  Say Y here to disable branch prediction.  If unsure, say N.
 
@@ -767,7 +780,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
 
 config DMA_CACHE_RWFO
 	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on CPU_V6 && SMP
+	depends on (CPU_V6 || CPU_V6K) && SMP
 	default y
 	help
 	  The Snoop Control Unit on ARM11MPCore does not detect the
@@ -823,7 +836,7 @@ config CACHE_L2X0
 config CACHE_PL310
 	bool
 	depends on CACHE_L2X0
-	default y if CPU_V7 && !CPU_V6
+	default y if CPU_V7 && !(CPU_V6 || CPU_V6K)
 	help
 	  This option enables optimisations for the PL310 cache
 	  controller.
@@ -851,10 +864,10 @@ config ARM_L1_CACHE_SHIFT
 	default 5
 
 config ARM_DMA_MEM_BUFFERABLE
-	bool "Use non-cacheable memory for DMA" if CPU_V6 && !CPU_V7
+	bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
 	depends on !(MACH_REALVIEW_PB1176 || REALVIEW_EB_ARM11MP || \
 		     MACH_REALVIEW_PB11MP)
-	default y if CPU_V6 || CPU_V7
+	default y if CPU_V6 || CPU_V6K || CPU_V7
 	help
 	  Historically, the kernel has used strongly ordered mappings to
 	  provide DMA coherent memory.  With the advent of ARMv7, mapping
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 00d74a0..bca7e61 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_CPU_XSC3)		+= proc-xsc3.o
 obj-$(CONFIG_CPU_MOHAWK)	+= proc-mohawk.o
 obj-$(CONFIG_CPU_FEROCEON)	+= proc-feroceon.o
 obj-$(CONFIG_CPU_V6)		+= proc-v6.o
+obj-$(CONFIG_CPU_V6K)		+= proc-v6.o
 obj-$(CONFIG_CPU_V7)		+= proc-v7.o
 
 AFLAGS_proc-v6.o	:=-Wa,-march=armv6
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index b0a9830..afe209e 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -31,7 +31,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 	struct mm_struct *mm = current->mm;
 	struct vm_area_struct *vma;
 	unsigned long start_addr;
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
 	unsigned int cache_type;
 	int do_align = 0, aliasing = 0;
 
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 05/14] ARM: v6k: Realview EB 11MPCore and PB11MPCore use V6K architecture CPUs
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Make Realview EB ARM11MPCore and PB11MPCore select the new V6K CPU
option.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-realview/Kconfig |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index b4575ae..e219459 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -17,7 +17,7 @@ config REALVIEW_EB_A9MP
 config REALVIEW_EB_ARM11MP
 	bool "Support ARM11MPCore tile"
 	depends on MACH_REALVIEW_EB
-	select CPU_V6
+	select CPU_V6K
 	select ARCH_HAS_BARRIERS if SMP
 	help
 	  Enable support for the ARM11MPCore tile on the Realview platform.
@@ -33,7 +33,7 @@ config REALVIEW_EB_ARM11MP_REVB
 
 config MACH_REALVIEW_PB11MP
 	bool "Support RealView/PB11MPCore platform"
-	select CPU_V6
+	select CPU_V6K
 	select ARM_GIC
 	select HAVE_PATA_PLATFORM
 	select ARCH_HAS_BARRIERS if SMP
@@ -42,6 +42,7 @@ config MACH_REALVIEW_PB11MP
 	  PB11MPCore is a platform with an on-board ARM11MPCore and has
 	  support for PCI-E and Compact Flash.
 
+# ARMv6 CPU without K extensions, but does have the new exclusive ops
 config MACH_REALVIEW_PB1176
 	bool "Support RealView/PB1176 platform"
 	select CPU_V6
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 05/14] ARM: v6k: Realview EB 11MPCore and PB11MPCore use V6K architecture CPUs
@ 2011-01-17 19:22   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:22 UTC (permalink / raw)
  To: linux-arm-kernel

Make Realview EB ARM11MPCore and PB11MPCore select the new V6K CPU
option.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-realview/Kconfig |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index b4575ae..e219459 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -17,7 +17,7 @@ config REALVIEW_EB_A9MP
 config REALVIEW_EB_ARM11MP
 	bool "Support ARM11MPCore tile"
 	depends on MACH_REALVIEW_EB
-	select CPU_V6
+	select CPU_V6K
 	select ARCH_HAS_BARRIERS if SMP
 	help
 	  Enable support for the ARM11MPCore tile on the Realview platform.
@@ -33,7 +33,7 @@ config REALVIEW_EB_ARM11MP_REVB
 
 config MACH_REALVIEW_PB11MP
 	bool "Support RealView/PB11MPCore platform"
-	select CPU_V6
+	select CPU_V6K
 	select ARM_GIC
 	select HAVE_PATA_PLATFORM
 	select ARCH_HAS_BARRIERS if SMP
@@ -42,6 +42,7 @@ config MACH_REALVIEW_PB11MP
 	  PB11MPCore is a platform with an on-board ARM11MPCore and has
 	  support for PCI-E and Compact Flash.
 
+# ARMv6 CPU without K extensions, but does have the new exclusive ops
 config MACH_REALVIEW_PB1176
 	bool "Support RealView/PB1176 platform"
 	select CPU_V6
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Make Dove platforms select the new V6K CPU option.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-dove/Kconfig |    4 +++-
 arch/arm/mm/Kconfig        |    4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index a4ed390..822439a 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -5,12 +5,14 @@ menu "Marvell Dove Implementations"
 config MACH_DOVE_DB
 	bool "Marvell DB-MV88AP510 Development Board"
 	select I2C_BOARDINFO
+	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-MV88AP510 Development Board.
 
- config MACH_CM_A510
+config MACH_CM_A510
 	bool "CompuLab CM-A510 Board"
+	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  CompuLab CM-A510 Board.
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 559e933..22a3f4a 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -390,7 +390,7 @@ config CPU_PJ4
 
 # ARMv6
 config CPU_V6
-	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
 	select CPU_ABRT_EV6
 	select CPU_PABRT_V6
@@ -403,7 +403,7 @@ config CPU_V6
 
 # ARMv6k
 config CPU_V6K
-	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
 	select CPU_32v6K if !ARCH_OMAP2
 	select CPU_ABRT_EV6
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel

Make Dove platforms select the new V6K CPU option.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-dove/Kconfig |    4 +++-
 arch/arm/mm/Kconfig        |    4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index a4ed390..822439a 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -5,12 +5,14 @@ menu "Marvell Dove Implementations"
 config MACH_DOVE_DB
 	bool "Marvell DB-MV88AP510 Development Board"
 	select I2C_BOARDINFO
+	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-MV88AP510 Development Board.
 
- config MACH_CM_A510
+config MACH_CM_A510
 	bool "CompuLab CM-A510 Board"
+	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  CompuLab CM-A510 Board.
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 559e933..22a3f4a 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -390,7 +390,7 @@ config CPU_PJ4
 
 # ARMv6
 config CPU_V6
-	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
 	select CPU_ABRT_EV6
 	select CPU_PABRT_V6
@@ -403,7 +403,7 @@ config CPU_V6
 
 # ARMv6k
 config CPU_V6K
-	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
 	select CPU_32v6K if !ARCH_OMAP2
 	select CPU_ABRT_EV6
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
which don't have the V6K extensions implemented.  Always use the
dummy store-exclusive method to ensure that the exclusive monitors are
cleared.

If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
have the K extensions available on all CPUs we're building support for,
so we can use the new clear-exclusive instruction.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/entry-header.S |   14 +++++++-------
 arch/arm/mm/abort-ev6.S        |    6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index ae94649..051166c 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -76,13 +76,13 @@
 #ifndef CONFIG_THUMB2_KERNEL
 	.macro	svc_exit, rpsr
 	msr	spsr_cxsf, \rpsr
-#if defined(CONFIG_CPU_32v6K)
-	clrex					@ clear the exclusive monitor
-	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
 	ldr	r0, [sp]
 	strex	r1, r2, [sp]			@ clear the exclusive monitor
 	ldmib	sp, {r1 - pc}^			@ load r1 - pc, cpsr
+#elif defined(CONFIG_CPU_32v6K)
+	clrex					@ clear the exclusive monitor
+	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
 #else
 	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
 #endif
@@ -92,10 +92,10 @@
 	ldr	r1, [sp, #\offset + S_PSR]	@ get calling cpsr
 	ldr	lr, [sp, #\offset + S_PC]!	@ get pc
 	msr	spsr_cxsf, r1			@ save in spsr_svc
-#if defined(CONFIG_CPU_32v6K)
-	clrex					@ clear the exclusive monitor
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
 	strex	r1, r2, [sp]			@ clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+	clrex					@ clear the exclusive monitor
 #endif
 	.if	\fast
 	ldmdb	sp, {r1 - lr}^			@ get calling r1 - lr
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index f332df7..1478aa5 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -20,11 +20,11 @@
  */
 	.align	5
 ENTRY(v6_early_abort)
-#ifdef CONFIG_CPU_32v6K
-	clrex
-#else
+#ifdef CONFIG_CPU_V6
 	sub	r1, sp, #4			@ Get unused stack location
 	strex	r0, r1, [r1]			@ Clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+	clrex
 #endif
 	mrc	p15, 0, r1, c5, c0, 0		@ get FSR
 	mrc	p15, 0, r0, c6, c0, 0		@ get FAR
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel

If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
which don't have the V6K extensions implemented.  Always use the
dummy store-exclusive method to ensure that the exclusive monitors are
cleared.

If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
have the K extensions available on all CPUs we're building support for,
so we can use the new clear-exclusive instruction.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/entry-header.S |   14 +++++++-------
 arch/arm/mm/abort-ev6.S        |    6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index ae94649..051166c 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -76,13 +76,13 @@
 #ifndef CONFIG_THUMB2_KERNEL
 	.macro	svc_exit, rpsr
 	msr	spsr_cxsf, \rpsr
-#if defined(CONFIG_CPU_32v6K)
-	clrex					@ clear the exclusive monitor
-	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
 	ldr	r0, [sp]
 	strex	r1, r2, [sp]			@ clear the exclusive monitor
 	ldmib	sp, {r1 - pc}^			@ load r1 - pc, cpsr
+#elif defined(CONFIG_CPU_32v6K)
+	clrex					@ clear the exclusive monitor
+	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
 #else
 	ldmia	sp, {r0 - pc}^			@ load r0 - pc, cpsr
 #endif
@@ -92,10 +92,10 @@
 	ldr	r1, [sp, #\offset + S_PSR]	@ get calling cpsr
 	ldr	lr, [sp, #\offset + S_PC]!	@ get pc
 	msr	spsr_cxsf, r1			@ save in spsr_svc
-#if defined(CONFIG_CPU_32v6K)
-	clrex					@ clear the exclusive monitor
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
 	strex	r1, r2, [sp]			@ clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+	clrex					@ clear the exclusive monitor
 #endif
 	.if	\fast
 	ldmdb	sp, {r1 - lr}^			@ get calling r1 - lr
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index f332df7..1478aa5 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -20,11 +20,11 @@
  */
 	.align	5
 ENTRY(v6_early_abort)
-#ifdef CONFIG_CPU_32v6K
-	clrex
-#else
+#ifdef CONFIG_CPU_V6
 	sub	r1, sp, #4			@ Get unused stack location
 	strex	r0, r1, [r1]			@ Clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+	clrex
 #endif
 	mrc	p15, 0, r1, c5, c0, 0		@ get FSR
 	mrc	p15, 0, r0, c6, c0, 0		@ get FAR
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword
exclusive operations, which aren't implemented before V6K.  Use the
generic versions (or omit them) instead.

If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have
the K extnesions, so use these new instructions.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/system.h |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 97f6d60..9a87823 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -347,6 +347,7 @@ void cpu_idle_wait(void);
 #include <asm-generic/cmpxchg-local.h>
 
 #if __LINUX_ARM_ARCH__ < 6
+/* min ARCH < ARMv6 */
 
 #ifdef CONFIG_SMP
 #error "SMP is not supported on this platform"
@@ -365,7 +366,7 @@ void cpu_idle_wait(void);
 #include <asm-generic/cmpxchg.h>
 #endif
 
-#else	/* __LINUX_ARM_ARCH__ >= 6 */
+#else	/* min ARCH >= ARMv6 */
 
 extern void __bad_cmpxchg(volatile void *ptr, int size);
 
@@ -379,7 +380,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 	unsigned long oldval, res;
 
 	switch (size) {
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6	/* min ARCH >= ARMv6K */
 	case 1:
 		do {
 			asm volatile("@ __cmpxchg1\n"
@@ -404,7 +405,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 				: "memory", "cc");
 		} while (res);
 		break;
-#endif /* CONFIG_CPU_32v6K */
+#endif
 	case 4:
 		do {
 			asm volatile("@ __cmpxchg4\n"
@@ -450,12 +451,12 @@ static inline unsigned long __cmpxchg_local(volatile void *ptr,
 	unsigned long ret;
 
 	switch (size) {
-#ifndef CONFIG_CPU_32v6K
+#ifdef CONFIG_CPU_V6	/* min ARCH == ARMv6 */
 	case 1:
 	case 2:
 		ret = __cmpxchg_local_generic(ptr, old, new, size);
 		break;
-#endif	/* !CONFIG_CPU_32v6K */
+#endif
 	default:
 		ret = __cmpxchg(ptr, old, new, size);
 	}
@@ -469,7 +470,7 @@ static inline unsigned long __cmpxchg_local(volatile void *ptr,
 				       (unsigned long)(n),		\
 				       sizeof(*(ptr))))
 
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6	/* min ARCH >= ARMv6K */
 
 /*
  * Note : ARMv7-M (currently unsupported by Linux) does not support
@@ -524,11 +525,11 @@ static inline unsigned long long __cmpxchg64_mb(volatile void *ptr,
 					 (unsigned long long)(o),	\
 					 (unsigned long long)(n)))
 
-#else	/* !CONFIG_CPU_32v6K */
+#else /* min ARCH = ARMv6 */
 
 #define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
 
-#endif	/* CONFIG_CPU_32v6K */
+#endif
 
 #endif	/* __LINUX_ARM_ARCH__ >= 6 */
 
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
@ 2011-01-17 19:23   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:23 UTC (permalink / raw)
  To: linux-arm-kernel

If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword
exclusive operations, which aren't implemented before V6K.  Use the
generic versions (or omit them) instead.

If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have
the K extnesions, so use these new instructions.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/system.h |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 97f6d60..9a87823 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -347,6 +347,7 @@ void cpu_idle_wait(void);
 #include <asm-generic/cmpxchg-local.h>
 
 #if __LINUX_ARM_ARCH__ < 6
+/* min ARCH < ARMv6 */
 
 #ifdef CONFIG_SMP
 #error "SMP is not supported on this platform"
@@ -365,7 +366,7 @@ void cpu_idle_wait(void);
 #include <asm-generic/cmpxchg.h>
 #endif
 
-#else	/* __LINUX_ARM_ARCH__ >= 6 */
+#else	/* min ARCH >= ARMv6 */
 
 extern void __bad_cmpxchg(volatile void *ptr, int size);
 
@@ -379,7 +380,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 	unsigned long oldval, res;
 
 	switch (size) {
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6	/* min ARCH >= ARMv6K */
 	case 1:
 		do {
 			asm volatile("@ __cmpxchg1\n"
@@ -404,7 +405,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 				: "memory", "cc");
 		} while (res);
 		break;
-#endif /* CONFIG_CPU_32v6K */
+#endif
 	case 4:
 		do {
 			asm volatile("@ __cmpxchg4\n"
@@ -450,12 +451,12 @@ static inline unsigned long __cmpxchg_local(volatile void *ptr,
 	unsigned long ret;
 
 	switch (size) {
-#ifndef CONFIG_CPU_32v6K
+#ifdef CONFIG_CPU_V6	/* min ARCH == ARMv6 */
 	case 1:
 	case 2:
 		ret = __cmpxchg_local_generic(ptr, old, new, size);
 		break;
-#endif	/* !CONFIG_CPU_32v6K */
+#endif
 	default:
 		ret = __cmpxchg(ptr, old, new, size);
 	}
@@ -469,7 +470,7 @@ static inline unsigned long __cmpxchg_local(volatile void *ptr,
 				       (unsigned long)(n),		\
 				       sizeof(*(ptr))))
 
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6	/* min ARCH >= ARMv6K */
 
 /*
  * Note : ARMv7-M (currently unsupported by Linux) does not support
@@ -524,11 +525,11 @@ static inline unsigned long long __cmpxchg64_mb(volatile void *ptr,
 					 (unsigned long long)(o),	\
 					 (unsigned long long)(n)))
 
-#else	/* !CONFIG_CPU_32v6K */
+#else /* min ARCH = ARMv6 */
 
 #define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
 
-#endif	/* CONFIG_CPU_32v6K */
+#endif
 
 #endif	/* __LINUX_ARM_ARCH__ >= 6 */
 
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
instructions in the kernel's atomic implementations as these are not
supported.  Fall back to the generic spinlock code instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 95ba92f..283d7b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,7 @@ config ARM
 	select HAVE_MEMBLOCK
 	select RTC_LIB
 	select SYS_SUPPORTS_APM_EMULATION
-	select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
+	select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
 	select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
 	select HAVE_ARCH_KGDB
 	select HAVE_KPROBES if (!XIP_KERNEL && !THUMB2_KERNEL)
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel

If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
instructions in the kernel's atomic implementations as these are not
supported.  Fall back to the generic spinlock code instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 95ba92f..283d7b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,7 @@ config ARM
 	select HAVE_MEMBLOCK
 	select RTC_LIB
 	select SYS_SUPPORTS_APM_EMULATION
-	select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
+	select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
 	select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
 	select HAVE_ARCH_KGDB
 	select HAVE_KPROBES if (!XIP_KERNEL && !THUMB2_KERNEL)
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
Use the conditional code which copes with this variability.  Otherwise,
if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
supported CPUs, so use it unconditionally.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/tls.h |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index e71d6ff..60843eb 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -28,15 +28,14 @@
 #define tls_emu		1
 #define has_tls_reg		1
 #define set_tls		set_tls_none
-#elif __LINUX_ARM_ARCH__ >= 7 ||					\
-	(__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
-#define tls_emu		0
-#define has_tls_reg		1
-#define set_tls		set_tls_v6k
-#elif __LINUX_ARM_ARCH__ == 6
+#elif defined(CONFIG_CPU_V6)
 #define tls_emu		0
 #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
 #define set_tls		set_tls_v6
+#elif defined(CONFIG_CPU_32v6K)
+#define tls_emu		0
+#define has_tls_reg		1
+#define set_tls		set_tls_v6k
 #else
 #define tls_emu		0
 #define has_tls_reg		0
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel

If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
Use the conditional code which copes with this variability.  Otherwise,
if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
supported CPUs, so use it unconditionally.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/tls.h |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index e71d6ff..60843eb 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -28,15 +28,14 @@
 #define tls_emu		1
 #define has_tls_reg		1
 #define set_tls		set_tls_none
-#elif __LINUX_ARM_ARCH__ >= 7 ||					\
-	(__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
-#define tls_emu		0
-#define has_tls_reg		1
-#define set_tls		set_tls_v6k
-#elif __LINUX_ARM_ARCH__ == 6
+#elif defined(CONFIG_CPU_V6)
 #define tls_emu		0
 #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
 #define set_tls		set_tls_v6
+#elif defined(CONFIG_CPU_32v6K)
+#define tls_emu		0
+#define has_tls_reg		1
+#define set_tls		set_tls_v6k
 #else
 #define tls_emu		0
 #define has_tls_reg		0
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Rather than turning off CPU domain switching when the build architecture
includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
turn it on when it's required to support a CPU architecture.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 22a3f4a..29215f5 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -435,25 +435,30 @@ config CPU_32v3
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v4
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v4T
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v5
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v6
 	bool
 	select TLS_REG_EMUL if !CPU_32v6K && !MMU
+	select CPU_USE_DOMAINS if CPU_V6 && MMU
 
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
@@ -620,8 +625,6 @@ config CPU_CP15_MPU
 
 config CPU_USE_DOMAINS
 	bool
-	depends on MMU
-	default y if !CPU_32v6K
 	help
 	  This option enables or disables the use of domain switching
 	  via the set_fs() function.
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-17 19:24   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:24 UTC (permalink / raw)
  To: linux-arm-kernel

Rather than turning off CPU domain switching when the build architecture
includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
turn it on when it's required to support a CPU architecture.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 22a3f4a..29215f5 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -435,25 +435,30 @@ config CPU_32v3
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v4
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v4T
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v5
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
 	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
+	select CPU_USE_DOMAINS if MMU
 
 config CPU_32v6
 	bool
 	select TLS_REG_EMUL if !CPU_32v6K && !MMU
+	select CPU_USE_DOMAINS if CPU_V6 && MMU
 
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
@@ -620,8 +625,6 @@ config CPU_CP15_MPU
 
 config CPU_USE_DOMAINS
 	bool
-	depends on MMU
-	default y if !CPU_32v6K
 	help
 	  This option enables or disables the use of domain switching
 	  via the set_fs() function.
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

CPU_32v6K controls whether we use the ARMv6K extension instructions in
the kernel, and in some places whether we use SMP-safe code sequences
(eg, bitops.)

MX3 prevents the selection of this option to ensure that it is not
enabled for their CPU, which is ARMv6 only.  Now that we've split the
CPU_V6 option, V6K support won't be offered for MX3 anymore.

OMAP prevents the selection of this option in an attempt to produce a
kernel which runs on architectures from ARMv6 to ARMv7 MPCore.  We now
achieve this in a different way (see the previous patches).

As such, we no longer need to offer this as a configuration option to
the user.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |   14 +++-----------
 1 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 29215f5..ca1238b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_V6K
 	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_ABRT_EV6
 	select CPU_PABRT_V6
 	select CPU_CACHE_V6
@@ -418,7 +418,7 @@ config CPU_V6K
 # ARMv7
 config CPU_V7
 	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
 	select CPU_PABRT_V7
@@ -461,15 +461,7 @@ config CPU_32v6
 	select CPU_USE_DOMAINS if CPU_V6 && MMU
 
 config CPU_32v6K
-	bool "Support ARM V6K processor extensions" if !SMP
-	depends on CPU_V6 || CPU_V6K || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
-	help
-	  Say Y here if your ARMv6 processor supports the 'K' extension.
-	  This enables the kernel to use some instructions not present
-	  on previous processors, and as such a kernel build with this
-	  enabled will not boot on processors with do not support these
-	  instructions.
+	bool
 
 config CPU_32v7
 	bool
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel

CPU_32v6K controls whether we use the ARMv6K extension instructions in
the kernel, and in some places whether we use SMP-safe code sequences
(eg, bitops.)

MX3 prevents the selection of this option to ensure that it is not
enabled for their CPU, which is ARMv6 only.  Now that we've split the
CPU_V6 option, V6K support won't be offered for MX3 anymore.

OMAP prevents the selection of this option in an attempt to produce a
kernel which runs on architectures from ARMv6 to ARMv7 MPCore.  We now
achieve this in a different way (see the previous patches).

As such, we no longer need to offer this as a configuration option to
the user.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |   14 +++-----------
 1 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 29215f5..ca1238b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_V6K
 	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
 	select CPU_32v6
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_ABRT_EV6
 	select CPU_PABRT_V6
 	select CPU_CACHE_V6
@@ -418,7 +418,7 @@ config CPU_V6K
 # ARMv7
 config CPU_V7
 	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
 	select CPU_PABRT_V7
@@ -461,15 +461,7 @@ config CPU_32v6
 	select CPU_USE_DOMAINS if CPU_V6 && MMU
 
 config CPU_32v6K
-	bool "Support ARM V6K processor extensions" if !SMP
-	depends on CPU_V6 || CPU_V6K || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
-	help
-	  Say Y here if your ARMv6 processor supports the 'K' extension.
-	  This enables the kernel to use some instructions not present
-	  on previous processors, and as such a kernel build with this
-	  enabled will not boot on processors with do not support these
-	  instructions.
+	bool
 
 config CPU_32v7
 	bool
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything,
we don't need to disable swp emulation to work around the build problem
with OMAP.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index ca1238b..843bc8c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -652,7 +652,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7 && !CPU_V6
+	depends on CPU_V7
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel

Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything,
we don't need to disable swp emulation to work around the build problem
with OMAP.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index ca1238b..843bc8c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -652,7 +652,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7 && !CPU_V6
+	depends on CPU_V7
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

SMP extensions are only supported on ARMv6k or ARMv7 architectures, so
only offer the option if we're building for such an architecture.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 283d7b9..ba304a3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1250,6 +1250,7 @@ source "kernel/time/Kconfig"
 config SMP
 	bool "Symmetric Multi-Processing (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
+	depends on CPU_V6K || CPU_V7
 	depends on GENERIC_CLOCKEVENTS
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
-- 
1.6.2.5


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
@ 2011-01-17 19:25   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 19:25 UTC (permalink / raw)
  To: linux-arm-kernel

SMP extensions are only supported on ARMv6k or ARMv7 architectures, so
only offer the option if we're building for such an architecture.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 283d7b9..ba304a3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1250,6 +1250,7 @@ source "kernel/time/Kconfig"
 config SMP
 	bool "Symmetric Multi-Processing (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
+	depends on CPU_V6K || CPU_V7
 	depends on GENERIC_CLOCKEVENTS
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-17 19:24   ` Russell King - ARM Linux
@ 2011-01-17 22:03     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 22:03 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Rather than turning off CPU domain switching when the build architecture
> includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> turn it on when it's required to support a CPU architecture.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>


> ---
>  arch/arm/mm/Kconfig |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 22a3f4a..29215f5 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -435,25 +435,30 @@ config CPU_32v3
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v4
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v4T
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v5
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v6
>  	bool
>  	select TLS_REG_EMUL if !CPU_32v6K && !MMU
> +	select CPU_USE_DOMAINS if CPU_V6 && MMU
>  
>  config CPU_32v6K
>  	bool "Support ARM V6K processor extensions" if !SMP
> @@ -620,8 +625,6 @@ config CPU_CP15_MPU
>  
>  config CPU_USE_DOMAINS
>  	bool
> -	depends on MMU
> -	default y if !CPU_32v6K
>  	help
>  	  This option enables or disables the use of domain switching
>  	  via the set_fs() function.
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-17 22:03     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 22:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Rather than turning off CPU domain switching when the build architecture
> includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> turn it on when it's required to support a CPU architecture.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>


> ---
>  arch/arm/mm/Kconfig |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 22a3f4a..29215f5 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -435,25 +435,30 @@ config CPU_32v3
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v4
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v4T
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v5
>  	bool
>  	select TLS_REG_EMUL if SMP || !MMU
>  	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
> +	select CPU_USE_DOMAINS if MMU
>  
>  config CPU_32v6
>  	bool
>  	select TLS_REG_EMUL if !CPU_32v6K && !MMU
> +	select CPU_USE_DOMAINS if CPU_V6 && MMU
>  
>  config CPU_32v6K
>  	bool "Support ARM V6K processor extensions" if !SMP
> @@ -620,8 +625,6 @@ config CPU_CP15_MPU
>  
>  config CPU_USE_DOMAINS
>  	bool
> -	depends on MMU
> -	default y if !CPU_32v6K
>  	help
>  	  This option enables or disables the use of domain switching
>  	  via the set_fs() function.
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-17 22:21   ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 22:21 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:20]:
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.
> 
> Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K
> if we have the K extensions.  CPU_32v6K directly controlled whether
> we should include the ARMv6K instructions (clrex, load/store exclusive
> byte, half-word, double).  As the bitops code uses the load/store
> exclusive byte operations, unsetting CPU_32v6K results in these
> falling back to their non-SMP local-irq-disabling variants.  These
> are only safe in uniprocessor environments.
> 
> So, the first two patches convert the bitops to use the ARMv6 load/store
> exclusive word operations - and ensuring correctness by ensuring that
> the pointer passed in is word-aligned.
> 
> We then introduce a new CPU_V6K which indicates that we're including
> an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
> including an ARMv6 non-K CPU.
> 
> We can then use CPU_V6 to ensure that the non-v6K code paths which are
> still SMP safe are selected.
> 
> Without this patch set, such a kernel will be unsafe when run on
> SMP platforms as it omits necessary SMP code to ensure that bit
> operations are safe.

Amazing, based on a quick test this series boots just fine on non-v6K
omap2420 using omap2plus_defconfig :)

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-17 22:21   ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 22:21 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:20]:
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.
> 
> Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K
> if we have the K extensions.  CPU_32v6K directly controlled whether
> we should include the ARMv6K instructions (clrex, load/store exclusive
> byte, half-word, double).  As the bitops code uses the load/store
> exclusive byte operations, unsetting CPU_32v6K results in these
> falling back to their non-SMP local-irq-disabling variants.  These
> are only safe in uniprocessor environments.
> 
> So, the first two patches convert the bitops to use the ARMv6 load/store
> exclusive word operations - and ensuring correctness by ensuring that
> the pointer passed in is word-aligned.
> 
> We then introduce a new CPU_V6K which indicates that we're including
> an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
> including an ARMv6 non-K CPU.
> 
> We can then use CPU_V6 to ensure that the non-v6K code paths which are
> still SMP safe are selected.
> 
> Without this patch set, such a kernel will be unsafe when run on
> SMP platforms as it omits necessary SMP code to ensure that bit
> operations are safe.

Amazing, based on a quick test this series boots just fine on non-v6K
omap2420 using omap2plus_defconfig :)

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 19:24   ` Russell King - ARM Linux
@ 2011-01-17 22:23     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 22:23 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> Use the conditional code which copes with this variability.  Otherwise,
> if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> supported CPUs, so use it unconditionally.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Note: this is becoming a bit confusing and prone to mistake when we have:

	CONFIG_CPU_V6
	CONFIG_CPU_V6K
	CONFIG_CPU_32v6
	CONFIG_CPU_32v6K

I don't know what to suggest for a less similar naming scheme between 
the CPU design and the allowed instruction set though.


> ---
>  arch/arm/include/asm/tls.h |   11 +++++------
>  1 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
> index e71d6ff..60843eb 100644
> --- a/arch/arm/include/asm/tls.h
> +++ b/arch/arm/include/asm/tls.h
> @@ -28,15 +28,14 @@
>  #define tls_emu		1
>  #define has_tls_reg		1
>  #define set_tls		set_tls_none
> -#elif __LINUX_ARM_ARCH__ >= 7 ||					\
> -	(__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> -#define tls_emu		0
> -#define has_tls_reg		1
> -#define set_tls		set_tls_v6k
> -#elif __LINUX_ARM_ARCH__ == 6
> +#elif defined(CONFIG_CPU_V6)
>  #define tls_emu		0
>  #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
>  #define set_tls		set_tls_v6
> +#elif defined(CONFIG_CPU_32v6K)
> +#define tls_emu		0
> +#define has_tls_reg		1
> +#define set_tls		set_tls_v6k
>  #else
>  #define tls_emu		0
>  #define has_tls_reg		0
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-17 22:23     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 22:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> Use the conditional code which copes with this variability.  Otherwise,
> if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> supported CPUs, so use it unconditionally.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Note: this is becoming a bit confusing and prone to mistake when we have:

	CONFIG_CPU_V6
	CONFIG_CPU_V6K
	CONFIG_CPU_32v6
	CONFIG_CPU_32v6K

I don't know what to suggest for a less similar naming scheme between 
the CPU design and the allowed instruction set though.


> ---
>  arch/arm/include/asm/tls.h |   11 +++++------
>  1 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
> index e71d6ff..60843eb 100644
> --- a/arch/arm/include/asm/tls.h
> +++ b/arch/arm/include/asm/tls.h
> @@ -28,15 +28,14 @@
>  #define tls_emu		1
>  #define has_tls_reg		1
>  #define set_tls		set_tls_none
> -#elif __LINUX_ARM_ARCH__ >= 7 ||					\
> -	(__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> -#define tls_emu		0
> -#define has_tls_reg		1
> -#define set_tls		set_tls_v6k
> -#elif __LINUX_ARM_ARCH__ == 6
> +#elif defined(CONFIG_CPU_V6)
>  #define tls_emu		0
>  #define has_tls_reg		(elf_hwcap & HWCAP_TLS)
>  #define set_tls		set_tls_v6
> +#elif defined(CONFIG_CPU_32v6K)
> +#define tls_emu		0
> +#define has_tls_reg		1
> +#define set_tls		set_tls_v6k
>  #else
>  #define tls_emu		0
>  #define has_tls_reg		0
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 22:23     ` Nicolas Pitre
@ 2011-01-17 22:36       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 22:36 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: linux-arm-kernel, linux-omap

On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> > Use the conditional code which copes with this variability.  Otherwise,
> > if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> > supported CPUs, so use it unconditionally.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> 
> Note: this is becoming a bit confusing and prone to mistake when we have:

Agreed.

> 	CONFIG_CPU_V6
> 	CONFIG_CPU_V6K
> 	CONFIG_CPU_32v6
> 	CONFIG_CPU_32v6K
> 
> I don't know what to suggest for a less similar naming scheme between 
> the CPU design and the allowed instruction set though.

It's best to consider CONFIG_CPU_V6/CONFIG_CPU_V6K/CONFIG_CPU_V7 in the
same light as CONFIG_CPU_ARM926T etc.  It selects a specific CPU core
(or family of CPU cores) rather than an architecture - the fact that it
_may_ tie up with an architecture is incidental.

The CPU_32vX selects the major architecture version.  32vX<letter> selects
sub-options of the architecture.

It may be better at some point to get rid of the CPU_32v* and replace
them with CPU_ARCH_V* instead, which makes it clear that these ones
definitely refer to the architecture versions.

The last point while we're here is I don't think it helps to have the
conditionals spread between the Kconfig files and this file - I'd much
rather see them all in Kconfig so we can see exactly how we end up with
each option (TLS_EMUL, TLS_V6, TLS_V6K) in one place.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-17 22:36       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 22:36 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> > Use the conditional code which copes with this variability.  Otherwise,
> > if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> > supported CPUs, so use it unconditionally.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> 
> Note: this is becoming a bit confusing and prone to mistake when we have:

Agreed.

> 	CONFIG_CPU_V6
> 	CONFIG_CPU_V6K
> 	CONFIG_CPU_32v6
> 	CONFIG_CPU_32v6K
> 
> I don't know what to suggest for a less similar naming scheme between 
> the CPU design and the allowed instruction set though.

It's best to consider CONFIG_CPU_V6/CONFIG_CPU_V6K/CONFIG_CPU_V7 in the
same light as CONFIG_CPU_ARM926T etc.  It selects a specific CPU core
(or family of CPU cores) rather than an architecture - the fact that it
_may_ tie up with an architecture is incidental.

The CPU_32vX selects the major architecture version.  32vX<letter> selects
sub-options of the architecture.

It may be better at some point to get rid of the CPU_32v* and replace
them with CPU_ARCH_V* instead, which makes it clear that these ones
definitely refer to the architecture versions.

The last point while we're here is I don't think it helps to have the
conditionals spread between the Kconfig files and this file - I'd much
rather see them all in Kconfig so we can see exactly how we end up with
each option (TLS_EMUL, TLS_V6, TLS_V6K) in one place.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 22:36       ` Russell King - ARM Linux
@ 2011-01-17 22:52         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 22:52 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: linux-omap, linux-arm-kernel

On Mon, Jan 17, 2011 at 10:36:35PM +0000, Russell King - ARM Linux wrote:
> It may be better at some point to get rid of the CPU_32v* and replace
> them with CPU_ARCH_V* instead, which makes it clear that these ones
> definitely refer to the architecture versions.

Last point on this is that I think we want to sanitize PJ4.

If we think about CPU_V7 as being the selection of ARM CPUs which are V7
architectures, CPU_PJ4 should be a separate config option selecting all
the same symbols which CPU_V7 does - and that should also select proc-v7.S
for building.

I'm not sure it makes sense to have (eg) the V7 perf events available on
PJ4 or the ARM errata for their V7 cores?

Does PJ4 have VFPv3?  Is Neon available on PJ4?  What about the DCC
debug registers?

etc.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-17 22:52         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-17 22:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 17, 2011 at 10:36:35PM +0000, Russell King - ARM Linux wrote:
> It may be better at some point to get rid of the CPU_32v* and replace
> them with CPU_ARCH_V* instead, which makes it clear that these ones
> definitely refer to the architecture versions.

Last point on this is that I think we want to sanitize PJ4.

If we think about CPU_V7 as being the selection of ARM CPUs which are V7
architectures, CPU_PJ4 should be a separate config option selecting all
the same symbols which CPU_V7 does - and that should also select proc-v7.S
for building.

I'm not sure it makes sense to have (eg) the V7 perf events available on
PJ4 or the ARM errata for their V7 cores?

Does PJ4 have VFPv3?  Is Neon available on PJ4?  What about the DCC
debug registers?

etc.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-17 19:22   ` Russell King - ARM Linux
@ 2011-01-17 23:13     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:13 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:21]:
> SMP requires at least the ARMv6K extensions to be present, so if we're
> running on SMP, the WFE and SEV instructions must be available.
> 
> However, when we run on UP, the v6K extensions may not be available,
> and so we don't want WFE/SEV to be in the instruction stream.  Use the
> SMP alternatives infrastructure to replace these instructions with NOPs
> if we build for SMP but run on UP.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Boots on omap242x (ARMv6 without K) and omap3/4:

Tested-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/include/asm/spinlock.h |   37 +++++++++++++++++++++++++------------
>  1 files changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 17eb355..da1af52 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,17 +5,36 @@
>  #error SMP not supported on pre-ARMv6 CPUs
>  #endif
>  
> +/*
> + * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> + * extensions, so when running on UP, we have to patch these instructions away.
> + */
> +#define ALT_SMP(smp, up)					\
> +	"9998:	" smp "\n"					\
> +	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
> +	"	.long	9998b\n"				\
> +	"	" up "\n"					\
> +	"	.popsection\n"
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define SEV		ALT_SMP("sev.w", "nop.w")
> +#define WFE(cond)	ALT_SMP("wfe" cond ".w", "nop.w")
> +#else
> +#define SEV		ALT_SMP("sev", "nop")
> +#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
> +#endif
> +
>  static inline void dsb_sev(void)
>  {
>  #if __LINUX_ARM_ARCH__ >= 7
>  	__asm__ __volatile__ (
>  		"dsb\n"
> -		"sev"
> +		SEV
>  	);
> -#elif defined(CONFIG_CPU_32v6K)
> +#else
>  	__asm__ __volatile__ (
>  		"mcr p15, 0, %0, c7, c10, 4\n"
> -		"sev"
> +		SEV
>  		: : "r" (0)
>  	);
>  #endif
> @@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfene\n"
> -#endif
> +	WFE("ne")
>  "	strexeq	%0, %2, [%1]\n"
>  "	teqeq	%0, #0\n"
>  "	bne	1b"
> @@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfene\n"
> -#endif
> +	WFE("ne")
>  "	strexeq	%0, %2, [%1]\n"
>  "	teq	%0, #0\n"
>  "	bne	1b"
> @@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
>  "1:	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
>  "	strexpl	%1, %0, [%2]\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfemi\n"
> -#endif
> +	WFE("mi")
>  "	rsbpls	%0, %1, #0\n"
>  "	bmi	1b"
>  	: "=&r" (tmp), "=&r" (tmp2)
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-17 23:13     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:13 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:21]:
> SMP requires at least the ARMv6K extensions to be present, so if we're
> running on SMP, the WFE and SEV instructions must be available.
> 
> However, when we run on UP, the v6K extensions may not be available,
> and so we don't want WFE/SEV to be in the instruction stream.  Use the
> SMP alternatives infrastructure to replace these instructions with NOPs
> if we build for SMP but run on UP.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Boots on omap242x (ARMv6 without K) and omap3/4:

Tested-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/include/asm/spinlock.h |   37 +++++++++++++++++++++++++------------
>  1 files changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 17eb355..da1af52 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,17 +5,36 @@
>  #error SMP not supported on pre-ARMv6 CPUs
>  #endif
>  
> +/*
> + * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> + * extensions, so when running on UP, we have to patch these instructions away.
> + */
> +#define ALT_SMP(smp, up)					\
> +	"9998:	" smp "\n"					\
> +	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
> +	"	.long	9998b\n"				\
> +	"	" up "\n"					\
> +	"	.popsection\n"
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define SEV		ALT_SMP("sev.w", "nop.w")
> +#define WFE(cond)	ALT_SMP("wfe" cond ".w", "nop.w")
> +#else
> +#define SEV		ALT_SMP("sev", "nop")
> +#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
> +#endif
> +
>  static inline void dsb_sev(void)
>  {
>  #if __LINUX_ARM_ARCH__ >= 7
>  	__asm__ __volatile__ (
>  		"dsb\n"
> -		"sev"
> +		SEV
>  	);
> -#elif defined(CONFIG_CPU_32v6K)
> +#else
>  	__asm__ __volatile__ (
>  		"mcr p15, 0, %0, c7, c10, 4\n"
> -		"sev"
> +		SEV
>  		: : "r" (0)
>  	);
>  #endif
> @@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfene\n"
> -#endif
> +	WFE("ne")
>  "	strexeq	%0, %2, [%1]\n"
>  "	teqeq	%0, #0\n"
>  "	bne	1b"
> @@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfene\n"
> -#endif
> +	WFE("ne")
>  "	strexeq	%0, %2, [%1]\n"
>  "	teq	%0, #0\n"
>  "	bne	1b"
> @@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
>  "1:	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
>  "	strexpl	%1, %0, [%2]\n"
> -#ifdef CONFIG_CPU_32v6K
> -"	wfemi\n"
> -#endif
> +	WFE("mi")
>  "	rsbpls	%0, %1, #0\n"
>  "	bmi	1b"
>  	: "=&r" (tmp), "=&r" (tmp2)
> -- 
> 1.6.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-17 19:22   ` Russell King - ARM Linux
@ 2011-01-17 23:14     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:14 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:29]:
> Introduce a CPU_V6K configuration option for platforms to select if they
> have a V6K CPU core.  This allows us to identify whether we need to
> support ARMv6 CPUs without the V6K SMP extensions at build time.
> 
> Currently CPU_V6K is just an alias for CPU_V6, and all places which
> reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).
> 
> Select CPU_V6K from platforms which are known to be V6K-only.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
@ 2011-01-17 23:14     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:14 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:29]:
> Introduce a CPU_V6K configuration option for platforms to select if they
> have a V6K CPU core.  This allows us to identify whether we need to
> support ARMv6 CPUs without the V6K SMP extensions at build time.
> 
> Currently CPU_V6K is just an alias for CPU_V6, and all places which
> reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).
> 
> Select CPU_V6K from platforms which are known to be V6K-only.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
  2011-01-17 19:23   ` Russell King - ARM Linux
@ 2011-01-17 23:15     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:15 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:27]:
> If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
> which don't have the V6K extensions implemented.  Always use the
> dummy store-exclusive method to ensure that the exclusive monitors are
> cleared.
> 
> If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
> have the K extensions available on all CPUs we're building support for,
> so we can use the new clear-exclusive instruction.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
@ 2011-01-17 23:15     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:15 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:27]:
> If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
> which don't have the V6K extensions implemented.  Always use the
> dummy store-exclusive method to ensure that the exclusive monitors are
> cleared.
> 
> If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
> have the K extensions available on all CPUs we're building support for,
> so we can use the new clear-exclusive instruction.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
  2011-01-17 19:23   ` Russell King - ARM Linux
@ 2011-01-17 23:18     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:18 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword
> exclusive operations, which aren't implemented before V6K.  Use the
> generic versions (or omit them) instead.
> 
> If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have
> the K extnesions, so use these new instructions.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
@ 2011-01-17 23:18     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:18 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword
> exclusive operations, which aren't implemented before V6K.  Use the
> generic versions (or omit them) instead.
> 
> If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have
> the K extnesions, so use these new instructions.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
  2011-01-17 19:24   ` Russell King - ARM Linux
@ 2011-01-17 23:21     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:21 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
> instructions in the kernel's atomic implementations as these are not
> supported.  Fall back to the generic spinlock code instead.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
@ 2011-01-17 23:21     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:21 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
> instructions in the kernel's atomic implementations as these are not
> supported.  Fall back to the generic spinlock code instead.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 22:23     ` Nicolas Pitre
@ 2011-01-17 23:21       ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:21 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap

* Nicolas Pitre <nico@fluxnic.net> [110117 14:22]:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> > Use the conditional code which copes with this variability.  Otherwise,
> > if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> > supported CPUs, so use it unconditionally.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-17 23:21       ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:21 UTC (permalink / raw)
  To: linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [110117 14:22]:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> > Use the conditional code which copes with this variability.  Otherwise,
> > if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
> > supported CPUs, so use it unconditionally.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-17 22:03     ` Nicolas Pitre
@ 2011-01-17 23:23       ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:23 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap

* Nicolas Pitre <nico@fluxnic.net> [110117 14:02]:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > Rather than turning off CPU domain switching when the build architecture
> > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > turn it on when it's required to support a CPU architecture.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-17 23:23       ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:23 UTC (permalink / raw)
  To: linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [110117 14:02]:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
> 
> > Rather than turning off CPU domain switching when the build architecture
> > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > turn it on when it's required to support a CPU architecture.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
  2011-01-17 19:25   ` Russell King - ARM Linux
@ 2011-01-17 23:24     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:24 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:24]:
> CPU_32v6K controls whether we use the ARMv6K extension instructions in
> the kernel, and in some places whether we use SMP-safe code sequences
> (eg, bitops.)
> 
> MX3 prevents the selection of this option to ensure that it is not
> enabled for their CPU, which is ARMv6 only.  Now that we've split the
> CPU_V6 option, V6K support won't be offered for MX3 anymore.
> 
> OMAP prevents the selection of this option in an attempt to produce a
> kernel which runs on architectures from ARMv6 to ARMv7 MPCore.  We now
> achieve this in a different way (see the previous patches).
> 
> As such, we no longer need to offer this as a configuration option to
> the user.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
@ 2011-01-17 23:24     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:24 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:24]:
> CPU_32v6K controls whether we use the ARMv6K extension instructions in
> the kernel, and in some places whether we use SMP-safe code sequences
> (eg, bitops.)
> 
> MX3 prevents the selection of this option to ensure that it is not
> enabled for their CPU, which is ARMv6 only.  Now that we've split the
> CPU_V6 option, V6K support won't be offered for MX3 anymore.
> 
> OMAP prevents the selection of this option in an attempt to produce a
> kernel which runs on architectures from ARMv6 to ARMv7 MPCore.  We now
> achieve this in a different way (see the previous patches).
> 
> As such, we no longer need to offer this as a configuration option to
> the user.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
  2011-01-17 19:25   ` Russell King - ARM Linux
@ 2011-01-17 23:24     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:24 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:26]:
> Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything,
> we don't need to disable swp emulation to work around the build problem
> with OMAP.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Glad to see this issue sorted out.

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
@ 2011-01-17 23:24     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:24 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:26]:
> Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything,
> we don't need to disable swp emulation to work around the build problem
> with OMAP.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Glad to see this issue sorted out.

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
  2011-01-17 19:25   ` Russell King - ARM Linux
@ 2011-01-17 23:25     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:25 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:25]:
> SMP extensions are only supported on ARMv6k or ARMv7 architectures, so
> only offer the option if we're building for such an architecture.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
@ 2011-01-17 23:25     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-17 23:25 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:25]:
> SMP extensions are only supported on ARMv6k or ARMv7 architectures, so
> only offer the option if we're building for such an architecture.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
  2011-01-17 19:23   ` Russell King - ARM Linux
@ 2011-01-17 23:39     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 23:39 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Make Dove platforms select the new V6K CPU option.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Tested-by: Nicolas Pitre <nicolas.pitre@linaro.org>

I'd suggest doing the following instead of attaching the selection to 
each individual board target , as the whole Dove architecture is V6K:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba304a3..d3f5674 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -457,6 +457,7 @@ config ARCH_IXP4XX
 
 config ARCH_DOVE
 	bool "Marvell Dove"
+	select CPU_V6K
 	select PCI
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 822439a..dd937c5 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -5,14 +5,12 @@ menu "Marvell Dove Implementations"
 config MACH_DOVE_DB
 	bool "Marvell DB-MV88AP510 Development Board"
 	select I2C_BOARDINFO
-	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-MV88AP510 Development Board.
 
 config MACH_CM_A510
 	bool "CompuLab CM-A510 Board"
-	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  CompuLab CM-A510 Board.




> ---
>  arch/arm/mach-dove/Kconfig |    4 +++-
>  arch/arm/mm/Kconfig        |    4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
> index a4ed390..822439a 100644
> --- a/arch/arm/mach-dove/Kconfig
> +++ b/arch/arm/mach-dove/Kconfig
> @@ -5,12 +5,14 @@ menu "Marvell Dove Implementations"
>  config MACH_DOVE_DB
>  	bool "Marvell DB-MV88AP510 Development Board"
>  	select I2C_BOARDINFO
> +	select CPU_V6K
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell DB-MV88AP510 Development Board.
>  
> - config MACH_CM_A510
> +config MACH_CM_A510
>  	bool "CompuLab CM-A510 Board"
> +	select CPU_V6K
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  CompuLab CM-A510 Board.
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 559e933..22a3f4a 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -390,7 +390,7 @@ config CPU_PJ4
>  
>  # ARMv6
>  config CPU_V6
> -	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
> +	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
>  	select CPU_32v6
>  	select CPU_ABRT_EV6
>  	select CPU_PABRT_V6
> @@ -403,7 +403,7 @@ config CPU_V6
>  
>  # ARMv6k
>  config CPU_V6K
> -	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
> +	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
>  	select CPU_32v6
>  	select CPU_32v6K if !ARCH_OMAP2
>  	select CPU_ABRT_EV6
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
@ 2011-01-17 23:39     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-17 23:39 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Make Dove platforms select the new V6K CPU option.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Tested-by: Nicolas Pitre <nicolas.pitre@linaro.org>

I'd suggest doing the following instead of attaching the selection to 
each individual board target , as the whole Dove architecture is V6K:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba304a3..d3f5674 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -457,6 +457,7 @@ config ARCH_IXP4XX
 
 config ARCH_DOVE
 	bool "Marvell Dove"
+	select CPU_V6K
 	select PCI
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 822439a..dd937c5 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -5,14 +5,12 @@ menu "Marvell Dove Implementations"
 config MACH_DOVE_DB
 	bool "Marvell DB-MV88AP510 Development Board"
 	select I2C_BOARDINFO
-	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-MV88AP510 Development Board.
 
 config MACH_CM_A510
 	bool "CompuLab CM-A510 Board"
-	select CPU_V6K
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  CompuLab CM-A510 Board.




> ---
>  arch/arm/mach-dove/Kconfig |    4 +++-
>  arch/arm/mm/Kconfig        |    4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
> index a4ed390..822439a 100644
> --- a/arch/arm/mach-dove/Kconfig
> +++ b/arch/arm/mach-dove/Kconfig
> @@ -5,12 +5,14 @@ menu "Marvell Dove Implementations"
>  config MACH_DOVE_DB
>  	bool "Marvell DB-MV88AP510 Development Board"
>  	select I2C_BOARDINFO
> +	select CPU_V6K
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell DB-MV88AP510 Development Board.
>  
> - config MACH_CM_A510
> +config MACH_CM_A510
>  	bool "CompuLab CM-A510 Board"
> +	select CPU_V6K
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  CompuLab CM-A510 Board.
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 559e933..22a3f4a 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -390,7 +390,7 @@ config CPU_PJ4
>  
>  # ARMv6
>  config CPU_V6
> -	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
> +	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
>  	select CPU_32v6
>  	select CPU_ABRT_EV6
>  	select CPU_PABRT_V6
> @@ -403,7 +403,7 @@ config CPU_V6
>  
>  # ARMv6k
>  config CPU_V6K
> -	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
> +	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
>  	select CPU_32v6
>  	select CPU_32v6K if !ARCH_OMAP2
>  	select CPU_ABRT_EV6
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 22:36       ` Russell King - ARM Linux
@ 2011-01-18  4:25         ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  4:25 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote:
> > Note: this is becoming a bit confusing and prone to mistake when we have:
> 
> Agreed.
> 
> > 	CONFIG_CPU_V6
> > 	CONFIG_CPU_V6K
> > 	CONFIG_CPU_32v6
> > 	CONFIG_CPU_32v6K
> 
> It may be better at some point to get rid of the CPU_32v* and replace
> them with CPU_ARCH_V* instead, which makes it clear that these ones
> definitely refer to the architecture versions.

Agreed.

> The last point while we're here is I don't think it helps to have the
> conditionals spread between the Kconfig files and this file - I'd much
> rather see them all in Kconfig so we can see exactly how we end up with
> each option (TLS_EMUL, TLS_V6, TLS_V6K) in one place.

Yep, although I'd suggest a naming based on the implementation and not 
on the CPU level it happens to be used on.  Something like TLS_EMUL, 
TLS_HW_REG, TLS_HIVECT, where (TLS_HW_REG && TLS_HIVECT) would 
correspond to the current 'if defined(CONFIG_CPU_V6)' case.  That would 
allow for an eventual combination of CONFIG_CPU_32v5 and 
CONFIG_CPU_32v6 (that would be Kirkwood + Dove).


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-18  4:25         ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  4:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote:
> > Note: this is becoming a bit confusing and prone to mistake when we have:
> 
> Agreed.
> 
> > 	CONFIG_CPU_V6
> > 	CONFIG_CPU_V6K
> > 	CONFIG_CPU_32v6
> > 	CONFIG_CPU_32v6K
> 
> It may be better at some point to get rid of the CPU_32v* and replace
> them with CPU_ARCH_V* instead, which makes it clear that these ones
> definitely refer to the architecture versions.

Agreed.

> The last point while we're here is I don't think it helps to have the
> conditionals spread between the Kconfig files and this file - I'd much
> rather see them all in Kconfig so we can see exactly how we end up with
> each option (TLS_EMUL, TLS_V6, TLS_V6K) in one place.

Yep, although I'd suggest a naming based on the implementation and not 
on the CPU level it happens to be used on.  Something like TLS_EMUL, 
TLS_HW_REG, TLS_HIVECT, where (TLS_HW_REG && TLS_HIVECT) would 
correspond to the current 'if defined(CONFIG_CPU_V6)' case.  That would 
allow for an eventual combination of CONFIG_CPU_32v5 and 
CONFIG_CPU_32v6 (that would be Kirkwood + Dove).


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
  2011-01-17 22:52         ` Russell King - ARM Linux
@ 2011-01-18  4:27           ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  4:27 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-omap, linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 10:36:35PM +0000, Russell King - ARM Linux wrote:
> > It may be better at some point to get rid of the CPU_32v* and replace
> > them with CPU_ARCH_V* instead, which makes it clear that these ones
> > definitely refer to the architecture versions.
> 
> Last point on this is that I think we want to sanitize PJ4.
> 
> If we think about CPU_V7 as being the selection of ARM CPUs which are V7
> architectures, CPU_PJ4 should be a separate config option selecting all
> the same symbols which CPU_V7 does - and that should also select proc-v7.S
> for building.
> 
> I'm not sure it makes sense to have (eg) the V7 perf events available on
> PJ4 or the ARM errata for their V7 cores?
> 
> Does PJ4 have VFPv3?  Is Neon available on PJ4?  What about the DCC
> debug registers?

Agreed.  Actually this is also the same issue with Dove.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
@ 2011-01-18  4:27           ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  4:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 10:36:35PM +0000, Russell King - ARM Linux wrote:
> > It may be better at some point to get rid of the CPU_32v* and replace
> > them with CPU_ARCH_V* instead, which makes it clear that these ones
> > definitely refer to the architecture versions.
> 
> Last point on this is that I think we want to sanitize PJ4.
> 
> If we think about CPU_V7 as being the selection of ARM CPUs which are V7
> architectures, CPU_PJ4 should be a separate config option selecting all
> the same symbols which CPU_V7 does - and that should also select proc-v7.S
> for building.
> 
> I'm not sure it makes sense to have (eg) the V7 perf events available on
> PJ4 or the ARM errata for their V7 cores?
> 
> Does PJ4 have VFPv3?  Is Neon available on PJ4?  What about the DCC
> debug registers?

Agreed.  Actually this is also the same issue with Dove.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-17 19:21   ` Russell King - ARM Linux
@ 2011-01-18  5:42     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  5:42 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Reviewed-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Also heavily tested on an ext3 fs read-write, using a LE host.

> ---
>  arch/arm/include/asm/bitops.h |   60 +++++++++++++++--------------------------
>  arch/arm/kernel/armksyms.c    |   18 ++++--------
>  arch/arm/lib/bitops.h         |   38 +++++++++++++------------
>  arch/arm/lib/changebit.S      |   10 +-----
>  arch/arm/lib/clearbit.S       |   11 +------
>  arch/arm/lib/setbit.S         |   11 +------
>  arch/arm/lib/testchangebit.S  |    9 ++----
>  arch/arm/lib/testclearbit.S   |    9 ++----
>  arch/arm/lib/testsetbit.S     |    9 ++----
>  9 files changed, 63 insertions(+), 112 deletions(-)
> 
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index 7b1bb2b..af54ed1 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -149,14 +149,18 @@ ____atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p)
>   */
>  
>  /*
> + * Native endian assembly bitops.  nr = 0 -> word 0 bit 0.
> + */
> +extern void _set_bit(int nr, volatile unsigned long * p);
> +extern void _clear_bit(int nr, volatile unsigned long * p);
> +extern void _change_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_set_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_clear_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_change_bit(int nr, volatile unsigned long * p);
> +
> +/*
>   * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
>   */
> -extern void _set_bit_le(int nr, volatile unsigned long * p);
> -extern void _clear_bit_le(int nr, volatile unsigned long * p);
> -extern void _change_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_set_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_change_bit_le(int nr, volatile unsigned long * p);
>  extern int _find_first_zero_bit_le(const void * p, unsigned size);
>  extern int _find_next_zero_bit_le(const void * p, int size, int offset);
>  extern int _find_first_bit_le(const unsigned long *p, unsigned size);
> @@ -165,12 +169,6 @@ extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
>  /*
>   * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
>   */
> -extern void _set_bit_be(int nr, volatile unsigned long * p);
> -extern void _clear_bit_be(int nr, volatile unsigned long * p);
> -extern void _change_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_set_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_change_bit_be(int nr, volatile unsigned long * p);
>  extern int _find_first_zero_bit_be(const void * p, unsigned size);
>  extern int _find_next_zero_bit_be(const void * p, int size, int offset);
>  extern int _find_first_bit_be(const unsigned long *p, unsigned size);
> @@ -180,33 +178,26 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
>  /*
>   * The __* form of bitops are non-atomic and may be reordered.
>   */
> -#define	ATOMIC_BITOP_LE(name,nr,p)		\
> -	(__builtin_constant_p(nr) ?		\
> -	 ____atomic_##name(nr, p) :		\
> -	 _##name##_le(nr,p))
> -
> -#define	ATOMIC_BITOP_BE(name,nr,p)		\
> -	(__builtin_constant_p(nr) ?		\
> -	 ____atomic_##name(nr, p) :		\
> -	 _##name##_be(nr,p))
> +#define ATOMIC_BITOP(name,nr,p)			\
> +	(__builtin_constant_p(nr) ? ____atomic_##name(nr, p) : _##name(nr,p))
>  #else
> -#define ATOMIC_BITOP_LE(name,nr,p)	_##name##_le(nr,p)
> -#define ATOMIC_BITOP_BE(name,nr,p)	_##name##_be(nr,p)
> +#define ATOMIC_BITOP(name,nr,p)		_##name(nr,p)
>  #endif
>  
> -#define NONATOMIC_BITOP(name,nr,p)		\
> -	(____nonatomic_##name(nr, p))
> +/*
> + * Native endian atomic definitions.
> + */
> +#define set_bit(nr,p)			ATOMIC_BITOP(set_bit,nr,p)
> +#define clear_bit(nr,p)			ATOMIC_BITOP(clear_bit,nr,p)
> +#define change_bit(nr,p)		ATOMIC_BITOP(change_bit,nr,p)
> +#define test_and_set_bit(nr,p)		ATOMIC_BITOP(test_and_set_bit,nr,p)
> +#define test_and_clear_bit(nr,p)	ATOMIC_BITOP(test_and_clear_bit,nr,p)
> +#define test_and_change_bit(nr,p)	ATOMIC_BITOP(test_and_change_bit,nr,p)
>  
>  #ifndef __ARMEB__
>  /*
>   * These are the little endian, atomic definitions.
>   */
> -#define set_bit(nr,p)			ATOMIC_BITOP_LE(set_bit,nr,p)
> -#define clear_bit(nr,p)			ATOMIC_BITOP_LE(clear_bit,nr,p)
> -#define change_bit(nr,p)		ATOMIC_BITOP_LE(change_bit,nr,p)
> -#define test_and_set_bit(nr,p)		ATOMIC_BITOP_LE(test_and_set_bit,nr,p)
> -#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_LE(test_and_clear_bit,nr,p)
> -#define test_and_change_bit(nr,p)	ATOMIC_BITOP_LE(test_and_change_bit,nr,p)
>  #define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
>  #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
>  #define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
> @@ -215,16 +206,9 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
>  #define WORD_BITOFF_TO_LE(x)		((x))
>  
>  #else
> -
>  /*
>   * These are the big endian, atomic definitions.
>   */
> -#define set_bit(nr,p)			ATOMIC_BITOP_BE(set_bit,nr,p)
> -#define clear_bit(nr,p)			ATOMIC_BITOP_BE(clear_bit,nr,p)
> -#define change_bit(nr,p)		ATOMIC_BITOP_BE(change_bit,nr,p)
> -#define test_and_set_bit(nr,p)		ATOMIC_BITOP_BE(test_and_set_bit,nr,p)
> -#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_BE(test_and_clear_bit,nr,p)
> -#define test_and_change_bit(nr,p)	ATOMIC_BITOP_BE(test_and_change_bit,nr,p)
>  #define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
>  #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
>  #define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
> diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
> index e5e1e53..d5d4185 100644
> --- a/arch/arm/kernel/armksyms.c
> +++ b/arch/arm/kernel/armksyms.c
> @@ -140,24 +140,18 @@ EXPORT_SYMBOL(__aeabi_ulcmp);
>  #endif
>  
>  	/* bitops */
> -EXPORT_SYMBOL(_set_bit_le);
> -EXPORT_SYMBOL(_test_and_set_bit_le);
> -EXPORT_SYMBOL(_clear_bit_le);
> -EXPORT_SYMBOL(_test_and_clear_bit_le);
> -EXPORT_SYMBOL(_change_bit_le);
> -EXPORT_SYMBOL(_test_and_change_bit_le);
> +EXPORT_SYMBOL(_set_bit);
> +EXPORT_SYMBOL(_test_and_set_bit);
> +EXPORT_SYMBOL(_clear_bit);
> +EXPORT_SYMBOL(_test_and_clear_bit);
> +EXPORT_SYMBOL(_change_bit);
> +EXPORT_SYMBOL(_test_and_change_bit);
>  EXPORT_SYMBOL(_find_first_zero_bit_le);
>  EXPORT_SYMBOL(_find_next_zero_bit_le);
>  EXPORT_SYMBOL(_find_first_bit_le);
>  EXPORT_SYMBOL(_find_next_bit_le);
>  
>  #ifdef __ARMEB__
> -EXPORT_SYMBOL(_set_bit_be);
> -EXPORT_SYMBOL(_test_and_set_bit_be);
> -EXPORT_SYMBOL(_clear_bit_be);
> -EXPORT_SYMBOL(_test_and_clear_bit_be);
> -EXPORT_SYMBOL(_change_bit_be);
> -EXPORT_SYMBOL(_test_and_change_bit_be);
>  EXPORT_SYMBOL(_find_first_zero_bit_be);
>  EXPORT_SYMBOL(_find_next_zero_bit_be);
>  EXPORT_SYMBOL(_find_first_bit_be);
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index 910d599..f8a2bd3 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,15 +1,15 @@
> -
> -#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
> +#if __LINUX_ARM_ARCH__ >= 6
>  	.macro	bitop, instr
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
>  	mov	r2, #1
> -	and	r3, r0, #7		@ Get bit offset
> -	add	r1, r1, r0, lsr #3	@ Get byte offset
> +	and	r3, r0, #31		@ Get bit offset
> +	mov	r0, r0, lsr #5
> +	add	r1, r1, r0, lsl #2	@ Get word offset
>  	mov	r3, r2, lsl r3
> -1:	ldrexb	r2, [r1]
> +1:	ldrex	r2, [r1]
>  	\instr	r2, r2, r3
> -	strexb	r0, r2, [r1]
> +	strex	r0, r2, [r1]
>  	cmp	r0, #0
>  	bne	1b
>  	mov	pc, lr
> @@ -18,15 +18,16 @@
>  	.macro	testop, instr, store
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	and	r3, r0, #7		@ Get bit offset
>  	mov	r2, #1
> -	add	r1, r1, r0, lsr #3	@ Get byte offset
> +	and	r3, r0, #31		@ Get bit offset
> +	mov	r0, r0, lsr #5
> +	add	r1, r1, r0, lsl #2	@ Get word offset
>  	mov	r3, r2, lsl r3		@ create mask
>  	smp_dmb
> -1:	ldrexb	r2, [r1]
> +1:	ldrex	r2, [r1]
>  	ands	r0, r2, r3		@ save old value of bit
> -	\instr	r2, r2, r3			@ toggle bit
> -	strexb	ip, r2, [r1]
> +	\instr	r2, r2, r3		@ toggle bit
> +	strex	ip, r2, [r1]
>  	cmp	ip, #0
>  	bne	1b
>  	smp_dmb
> @@ -38,13 +39,14 @@
>  	.macro	bitop, instr
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	and	r2, r0, #7
> +	and	r2, r0, #31
> +	mov	r0, r0, lsr #5
>  	mov	r3, #1
>  	mov	r3, r3, lsl r2
>  	save_and_disable_irqs ip
> -	ldrb	r2, [r1, r0, lsr #3]
> +	ldr	r2, [r1, r0, lsl #2]
>  	\instr	r2, r2, r3
> -	strb	r2, [r1, r0, lsr #3]
> +	str	r2, [r1, r0, lsl #2]
>  	restore_irqs ip
>  	mov	pc, lr
>  	.endm
> @@ -60,11 +62,11 @@
>  	.macro	testop, instr, store
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	add	r1, r1, r0, lsr #3
> -	and	r3, r0, #7
> -	mov	r0, #1
> +	and	r3, r0, #31
> +	mov	r0, r0, lsr #5
>  	save_and_disable_irqs ip
> -	ldrb	r2, [r1]
> +	ldr	r2, [r1, r0, lsl #2]!
> +	mov	r0, #1
>  	tst	r2, r0, lsl r3
>  	\instr	r2, r2, r0, lsl r3
>  	\store	r2, [r1]
> diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
> index 80f3115..68ed5b6 100644
> --- a/arch/arm/lib/changebit.S
> +++ b/arch/arm/lib/changebit.S
> @@ -12,12 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -/* Purpose  : Function to change a bit
> - * Prototype: int change_bit(int bit, void *addr)
> - */
> -ENTRY(_change_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_change_bit_le)
> +ENTRY(_change_bit)
>  	bitop	eor
> -ENDPROC(_change_bit_be)
> -ENDPROC(_change_bit_le)
> +ENDPROC(_change_bit)
> diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
> index 1a63e43..4c04c3b 100644
> --- a/arch/arm/lib/clearbit.S
> +++ b/arch/arm/lib/clearbit.S
> @@ -12,13 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -/*
> - * Purpose  : Function to clear a bit
> - * Prototype: int clear_bit(int bit, void *addr)
> - */
> -ENTRY(_clear_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_clear_bit_le)
> +ENTRY(_clear_bit)
>  	bitop	bic
> -ENDPROC(_clear_bit_be)
> -ENDPROC(_clear_bit_le)
> +ENDPROC(_clear_bit)
> diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
> index 1dd7176..bbee5c6 100644
> --- a/arch/arm/lib/setbit.S
> +++ b/arch/arm/lib/setbit.S
> @@ -12,13 +12,6 @@
>  #include "bitops.h"
>  		.text
>  
> -/*
> - * Purpose  : Function to set a bit
> - * Prototype: int set_bit(int bit, void *addr)
> - */
> -ENTRY(_set_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_set_bit_le)
> +ENTRY(_set_bit)
>  	bitop	orr
> -ENDPROC(_set_bit_be)
> -ENDPROC(_set_bit_le)
> +ENDPROC(_set_bit)
> diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
> index 5c98dc5..15a4d43 100644
> --- a/arch/arm/lib/testchangebit.S
> +++ b/arch/arm/lib/testchangebit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_change_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_change_bit_le)
> -	testop	eor, strb
> -ENDPROC(_test_and_change_bit_be)
> -ENDPROC(_test_and_change_bit_le)
> +ENTRY(_test_and_change_bit)
> +	testop	eor, str
> +ENDPROC(_test_and_change_bit)
> diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
> index 543d709..521b66b 100644
> --- a/arch/arm/lib/testclearbit.S
> +++ b/arch/arm/lib/testclearbit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_clear_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_clear_bit_le)
> -	testop	bicne, strneb
> -ENDPROC(_test_and_clear_bit_be)
> -ENDPROC(_test_and_clear_bit_le)
> +ENTRY(_test_and_clear_bit)
> +	testop	bicne, strne
> +ENDPROC(_test_and_clear_bit)
> diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
> index 0b3f390..1c98cc2 100644
> --- a/arch/arm/lib/testsetbit.S
> +++ b/arch/arm/lib/testsetbit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_set_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_set_bit_le)
> -	testop	orreq, streqb
> -ENDPROC(_test_and_set_bit_be)
> -ENDPROC(_test_and_set_bit_le)
> +ENTRY(_test_and_set_bit)
> +	testop	orreq, streq
> +ENDPROC(_test_and_set_bit)
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-18  5:42     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  5:42 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Reviewed-by: Nicolas Pitre <nicolas.pitre@linaro.org>

Also heavily tested on an ext3 fs read-write, using a LE host.

> ---
>  arch/arm/include/asm/bitops.h |   60 +++++++++++++++--------------------------
>  arch/arm/kernel/armksyms.c    |   18 ++++--------
>  arch/arm/lib/bitops.h         |   38 +++++++++++++------------
>  arch/arm/lib/changebit.S      |   10 +-----
>  arch/arm/lib/clearbit.S       |   11 +------
>  arch/arm/lib/setbit.S         |   11 +------
>  arch/arm/lib/testchangebit.S  |    9 ++----
>  arch/arm/lib/testclearbit.S   |    9 ++----
>  arch/arm/lib/testsetbit.S     |    9 ++----
>  9 files changed, 63 insertions(+), 112 deletions(-)
> 
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index 7b1bb2b..af54ed1 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -149,14 +149,18 @@ ____atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p)
>   */
>  
>  /*
> + * Native endian assembly bitops.  nr = 0 -> word 0 bit 0.
> + */
> +extern void _set_bit(int nr, volatile unsigned long * p);
> +extern void _clear_bit(int nr, volatile unsigned long * p);
> +extern void _change_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_set_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_clear_bit(int nr, volatile unsigned long * p);
> +extern int _test_and_change_bit(int nr, volatile unsigned long * p);
> +
> +/*
>   * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
>   */
> -extern void _set_bit_le(int nr, volatile unsigned long * p);
> -extern void _clear_bit_le(int nr, volatile unsigned long * p);
> -extern void _change_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_set_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p);
> -extern int _test_and_change_bit_le(int nr, volatile unsigned long * p);
>  extern int _find_first_zero_bit_le(const void * p, unsigned size);
>  extern int _find_next_zero_bit_le(const void * p, int size, int offset);
>  extern int _find_first_bit_le(const unsigned long *p, unsigned size);
> @@ -165,12 +169,6 @@ extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
>  /*
>   * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
>   */
> -extern void _set_bit_be(int nr, volatile unsigned long * p);
> -extern void _clear_bit_be(int nr, volatile unsigned long * p);
> -extern void _change_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_set_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p);
> -extern int _test_and_change_bit_be(int nr, volatile unsigned long * p);
>  extern int _find_first_zero_bit_be(const void * p, unsigned size);
>  extern int _find_next_zero_bit_be(const void * p, int size, int offset);
>  extern int _find_first_bit_be(const unsigned long *p, unsigned size);
> @@ -180,33 +178,26 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
>  /*
>   * The __* form of bitops are non-atomic and may be reordered.
>   */
> -#define	ATOMIC_BITOP_LE(name,nr,p)		\
> -	(__builtin_constant_p(nr) ?		\
> -	 ____atomic_##name(nr, p) :		\
> -	 _##name##_le(nr,p))
> -
> -#define	ATOMIC_BITOP_BE(name,nr,p)		\
> -	(__builtin_constant_p(nr) ?		\
> -	 ____atomic_##name(nr, p) :		\
> -	 _##name##_be(nr,p))
> +#define ATOMIC_BITOP(name,nr,p)			\
> +	(__builtin_constant_p(nr) ? ____atomic_##name(nr, p) : _##name(nr,p))
>  #else
> -#define ATOMIC_BITOP_LE(name,nr,p)	_##name##_le(nr,p)
> -#define ATOMIC_BITOP_BE(name,nr,p)	_##name##_be(nr,p)
> +#define ATOMIC_BITOP(name,nr,p)		_##name(nr,p)
>  #endif
>  
> -#define NONATOMIC_BITOP(name,nr,p)		\
> -	(____nonatomic_##name(nr, p))
> +/*
> + * Native endian atomic definitions.
> + */
> +#define set_bit(nr,p)			ATOMIC_BITOP(set_bit,nr,p)
> +#define clear_bit(nr,p)			ATOMIC_BITOP(clear_bit,nr,p)
> +#define change_bit(nr,p)		ATOMIC_BITOP(change_bit,nr,p)
> +#define test_and_set_bit(nr,p)		ATOMIC_BITOP(test_and_set_bit,nr,p)
> +#define test_and_clear_bit(nr,p)	ATOMIC_BITOP(test_and_clear_bit,nr,p)
> +#define test_and_change_bit(nr,p)	ATOMIC_BITOP(test_and_change_bit,nr,p)
>  
>  #ifndef __ARMEB__
>  /*
>   * These are the little endian, atomic definitions.
>   */
> -#define set_bit(nr,p)			ATOMIC_BITOP_LE(set_bit,nr,p)
> -#define clear_bit(nr,p)			ATOMIC_BITOP_LE(clear_bit,nr,p)
> -#define change_bit(nr,p)		ATOMIC_BITOP_LE(change_bit,nr,p)
> -#define test_and_set_bit(nr,p)		ATOMIC_BITOP_LE(test_and_set_bit,nr,p)
> -#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_LE(test_and_clear_bit,nr,p)
> -#define test_and_change_bit(nr,p)	ATOMIC_BITOP_LE(test_and_change_bit,nr,p)
>  #define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
>  #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
>  #define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
> @@ -215,16 +206,9 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
>  #define WORD_BITOFF_TO_LE(x)		((x))
>  
>  #else
> -
>  /*
>   * These are the big endian, atomic definitions.
>   */
> -#define set_bit(nr,p)			ATOMIC_BITOP_BE(set_bit,nr,p)
> -#define clear_bit(nr,p)			ATOMIC_BITOP_BE(clear_bit,nr,p)
> -#define change_bit(nr,p)		ATOMIC_BITOP_BE(change_bit,nr,p)
> -#define test_and_set_bit(nr,p)		ATOMIC_BITOP_BE(test_and_set_bit,nr,p)
> -#define test_and_clear_bit(nr,p)	ATOMIC_BITOP_BE(test_and_clear_bit,nr,p)
> -#define test_and_change_bit(nr,p)	ATOMIC_BITOP_BE(test_and_change_bit,nr,p)
>  #define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
>  #define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
>  #define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
> diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
> index e5e1e53..d5d4185 100644
> --- a/arch/arm/kernel/armksyms.c
> +++ b/arch/arm/kernel/armksyms.c
> @@ -140,24 +140,18 @@ EXPORT_SYMBOL(__aeabi_ulcmp);
>  #endif
>  
>  	/* bitops */
> -EXPORT_SYMBOL(_set_bit_le);
> -EXPORT_SYMBOL(_test_and_set_bit_le);
> -EXPORT_SYMBOL(_clear_bit_le);
> -EXPORT_SYMBOL(_test_and_clear_bit_le);
> -EXPORT_SYMBOL(_change_bit_le);
> -EXPORT_SYMBOL(_test_and_change_bit_le);
> +EXPORT_SYMBOL(_set_bit);
> +EXPORT_SYMBOL(_test_and_set_bit);
> +EXPORT_SYMBOL(_clear_bit);
> +EXPORT_SYMBOL(_test_and_clear_bit);
> +EXPORT_SYMBOL(_change_bit);
> +EXPORT_SYMBOL(_test_and_change_bit);
>  EXPORT_SYMBOL(_find_first_zero_bit_le);
>  EXPORT_SYMBOL(_find_next_zero_bit_le);
>  EXPORT_SYMBOL(_find_first_bit_le);
>  EXPORT_SYMBOL(_find_next_bit_le);
>  
>  #ifdef __ARMEB__
> -EXPORT_SYMBOL(_set_bit_be);
> -EXPORT_SYMBOL(_test_and_set_bit_be);
> -EXPORT_SYMBOL(_clear_bit_be);
> -EXPORT_SYMBOL(_test_and_clear_bit_be);
> -EXPORT_SYMBOL(_change_bit_be);
> -EXPORT_SYMBOL(_test_and_change_bit_be);
>  EXPORT_SYMBOL(_find_first_zero_bit_be);
>  EXPORT_SYMBOL(_find_next_zero_bit_be);
>  EXPORT_SYMBOL(_find_first_bit_be);
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index 910d599..f8a2bd3 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,15 +1,15 @@
> -
> -#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
> +#if __LINUX_ARM_ARCH__ >= 6
>  	.macro	bitop, instr
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
>  	mov	r2, #1
> -	and	r3, r0, #7		@ Get bit offset
> -	add	r1, r1, r0, lsr #3	@ Get byte offset
> +	and	r3, r0, #31		@ Get bit offset
> +	mov	r0, r0, lsr #5
> +	add	r1, r1, r0, lsl #2	@ Get word offset
>  	mov	r3, r2, lsl r3
> -1:	ldrexb	r2, [r1]
> +1:	ldrex	r2, [r1]
>  	\instr	r2, r2, r3
> -	strexb	r0, r2, [r1]
> +	strex	r0, r2, [r1]
>  	cmp	r0, #0
>  	bne	1b
>  	mov	pc, lr
> @@ -18,15 +18,16 @@
>  	.macro	testop, instr, store
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	and	r3, r0, #7		@ Get bit offset
>  	mov	r2, #1
> -	add	r1, r1, r0, lsr #3	@ Get byte offset
> +	and	r3, r0, #31		@ Get bit offset
> +	mov	r0, r0, lsr #5
> +	add	r1, r1, r0, lsl #2	@ Get word offset
>  	mov	r3, r2, lsl r3		@ create mask
>  	smp_dmb
> -1:	ldrexb	r2, [r1]
> +1:	ldrex	r2, [r1]
>  	ands	r0, r2, r3		@ save old value of bit
> -	\instr	r2, r2, r3			@ toggle bit
> -	strexb	ip, r2, [r1]
> +	\instr	r2, r2, r3		@ toggle bit
> +	strex	ip, r2, [r1]
>  	cmp	ip, #0
>  	bne	1b
>  	smp_dmb
> @@ -38,13 +39,14 @@
>  	.macro	bitop, instr
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	and	r2, r0, #7
> +	and	r2, r0, #31
> +	mov	r0, r0, lsr #5
>  	mov	r3, #1
>  	mov	r3, r3, lsl r2
>  	save_and_disable_irqs ip
> -	ldrb	r2, [r1, r0, lsr #3]
> +	ldr	r2, [r1, r0, lsl #2]
>  	\instr	r2, r2, r3
> -	strb	r2, [r1, r0, lsr #3]
> +	str	r2, [r1, r0, lsl #2]
>  	restore_irqs ip
>  	mov	pc, lr
>  	.endm
> @@ -60,11 +62,11 @@
>  	.macro	testop, instr, store
>  	tst	r1, #3
>  	strne	r1, [r1, -r1]		@ assert word-aligned
> -	add	r1, r1, r0, lsr #3
> -	and	r3, r0, #7
> -	mov	r0, #1
> +	and	r3, r0, #31
> +	mov	r0, r0, lsr #5
>  	save_and_disable_irqs ip
> -	ldrb	r2, [r1]
> +	ldr	r2, [r1, r0, lsl #2]!
> +	mov	r0, #1
>  	tst	r2, r0, lsl r3
>  	\instr	r2, r2, r0, lsl r3
>  	\store	r2, [r1]
> diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
> index 80f3115..68ed5b6 100644
> --- a/arch/arm/lib/changebit.S
> +++ b/arch/arm/lib/changebit.S
> @@ -12,12 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -/* Purpose  : Function to change a bit
> - * Prototype: int change_bit(int bit, void *addr)
> - */
> -ENTRY(_change_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_change_bit_le)
> +ENTRY(_change_bit)
>  	bitop	eor
> -ENDPROC(_change_bit_be)
> -ENDPROC(_change_bit_le)
> +ENDPROC(_change_bit)
> diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
> index 1a63e43..4c04c3b 100644
> --- a/arch/arm/lib/clearbit.S
> +++ b/arch/arm/lib/clearbit.S
> @@ -12,13 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -/*
> - * Purpose  : Function to clear a bit
> - * Prototype: int clear_bit(int bit, void *addr)
> - */
> -ENTRY(_clear_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_clear_bit_le)
> +ENTRY(_clear_bit)
>  	bitop	bic
> -ENDPROC(_clear_bit_be)
> -ENDPROC(_clear_bit_le)
> +ENDPROC(_clear_bit)
> diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
> index 1dd7176..bbee5c6 100644
> --- a/arch/arm/lib/setbit.S
> +++ b/arch/arm/lib/setbit.S
> @@ -12,13 +12,6 @@
>  #include "bitops.h"
>  		.text
>  
> -/*
> - * Purpose  : Function to set a bit
> - * Prototype: int set_bit(int bit, void *addr)
> - */
> -ENTRY(_set_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_set_bit_le)
> +ENTRY(_set_bit)
>  	bitop	orr
> -ENDPROC(_set_bit_be)
> -ENDPROC(_set_bit_le)
> +ENDPROC(_set_bit)
> diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
> index 5c98dc5..15a4d43 100644
> --- a/arch/arm/lib/testchangebit.S
> +++ b/arch/arm/lib/testchangebit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_change_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_change_bit_le)
> -	testop	eor, strb
> -ENDPROC(_test_and_change_bit_be)
> -ENDPROC(_test_and_change_bit_le)
> +ENTRY(_test_and_change_bit)
> +	testop	eor, str
> +ENDPROC(_test_and_change_bit)
> diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
> index 543d709..521b66b 100644
> --- a/arch/arm/lib/testclearbit.S
> +++ b/arch/arm/lib/testclearbit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_clear_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_clear_bit_le)
> -	testop	bicne, strneb
> -ENDPROC(_test_and_clear_bit_be)
> -ENDPROC(_test_and_clear_bit_le)
> +ENTRY(_test_and_clear_bit)
> +	testop	bicne, strne
> +ENDPROC(_test_and_clear_bit)
> diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
> index 0b3f390..1c98cc2 100644
> --- a/arch/arm/lib/testsetbit.S
> +++ b/arch/arm/lib/testsetbit.S
> @@ -12,9 +12,6 @@
>  #include "bitops.h"
>                  .text
>  
> -ENTRY(_test_and_set_bit_be)
> -		eor	r0, r0, #0x18		@ big endian byte ordering
> -ENTRY(_test_and_set_bit_le)
> -	testop	orreq, streqb
> -ENDPROC(_test_and_set_bit_be)
> -ENDPROC(_test_and_set_bit_le)
> +ENTRY(_test_and_set_bit)
> +	testop	orreq, streq
> +ENDPROC(_test_and_set_bit)
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-17 19:21   ` Russell King - ARM Linux
@ 2011-01-18  6:00     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  6:00 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Add additional instructions to our assembly bitops functions to ensure
> that they only operate on word-aligned pointers.  This will be necessary
> when we switch these operations to use the word-based exclusive
> operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This breaks the Thumb2 kernel build:

  AS      arch/arm/lib/changebit.o
arch/arm/lib/changebit.S: Assembler messages:
arch/arm/lib/changebit.S:16: Error: Thumb does not support negative register indexing -- `strne r1,[r1,-r1]'

I also wonder what happens with a misaligned ldrex/strex... Does the 
alignment trap get invoked?  If so, the assertion could be put there 
instead if that's not done already, removing this overhead from bitops 
calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
as usual since the ldr/str are not special, but the previous code 
allowed for misaligned pointer so result would be no worse than before 
in that case.  Testing appears to indicate those misaligned bitops are 
rather nonexistent so far.

> ---
>  arch/arm/lib/bitops.h |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index d422529..910d599 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,6 +1,8 @@
>  
>  #if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
>  	.macro	bitop, instr
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	mov	r2, #1
>  	and	r3, r0, #7		@ Get bit offset
>  	add	r1, r1, r0, lsr #3	@ Get byte offset
> @@ -14,6 +16,8 @@
>  	.endm
>  
>  	.macro	testop, instr, store
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	and	r3, r0, #7		@ Get bit offset
>  	mov	r2, #1
>  	add	r1, r1, r0, lsr #3	@ Get byte offset
> @@ -32,6 +36,8 @@
>  	.endm
>  #else
>  	.macro	bitop, instr
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	and	r2, r0, #7
>  	mov	r3, #1
>  	mov	r3, r3, lsl r2
> @@ -52,6 +58,8 @@
>   * to avoid dirtying the data cache.
>   */
>  	.macro	testop, instr, store
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	add	r1, r1, r0, lsr #3
>  	and	r3, r0, #7
>  	mov	r0, #1
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-18  6:00     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18  6:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:

> Add additional instructions to our assembly bitops functions to ensure
> that they only operate on word-aligned pointers.  This will be necessary
> when we switch these operations to use the word-based exclusive
> operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This breaks the Thumb2 kernel build:

  AS      arch/arm/lib/changebit.o
arch/arm/lib/changebit.S: Assembler messages:
arch/arm/lib/changebit.S:16: Error: Thumb does not support negative register indexing -- `strne r1,[r1,-r1]'

I also wonder what happens with a misaligned ldrex/strex... Does the 
alignment trap get invoked?  If so, the assertion could be put there 
instead if that's not done already, removing this overhead from bitops 
calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
as usual since the ldr/str are not special, but the previous code 
allowed for misaligned pointer so result would be no worse than before 
in that case.  Testing appears to indicate those misaligned bitops are 
rather nonexistent so far.

> ---
>  arch/arm/lib/bitops.h |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index d422529..910d599 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,6 +1,8 @@
>  
>  #if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
>  	.macro	bitop, instr
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	mov	r2, #1
>  	and	r3, r0, #7		@ Get bit offset
>  	add	r1, r1, r0, lsr #3	@ Get byte offset
> @@ -14,6 +16,8 @@
>  	.endm
>  
>  	.macro	testop, instr, store
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	and	r3, r0, #7		@ Get bit offset
>  	mov	r2, #1
>  	add	r1, r1, r0, lsr #3	@ Get byte offset
> @@ -32,6 +36,8 @@
>  	.endm
>  #else
>  	.macro	bitop, instr
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	and	r2, r0, #7
>  	mov	r3, #1
>  	mov	r3, r3, lsl r2
> @@ -52,6 +58,8 @@
>   * to avoid dirtying the data cache.
>   */
>  	.macro	testop, instr, store
> +	tst	r1, #3
> +	strne	r1, [r1, -r1]		@ assert word-aligned
>  	add	r1, r1, r0, lsr #3
>  	and	r3, r0, #7
>  	mov	r0, #1
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
  2011-01-17 19:24   ` Russell King - ARM Linux
  (?)
  (?)
@ 2011-01-18 10:24   ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-18 10:24 UTC (permalink / raw)
  To: 'Russell King - ARM Linux', linux-arm-kernel, linux-omap

> If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
> instructions in the kernel's atomic implementations as these are not
> supported.  Fall back to the generic spinlock code instead.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 95ba92f..283d7b9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,7 +7,7 @@ config ARM
>  	select HAVE_MEMBLOCK
>  	select RTC_LIB
>  	select SYS_SUPPORTS_APM_EMULATION
> -	select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
> +	select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
>  	select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
>  	select HAVE_ARCH_KGDB
>  	select HAVE_KPROBES if (!XIP_KERNEL && !THUMB2_KERNEL)

Acked-by: Will Deacon <will.deacon@arm.com>

Thanks,

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
  2011-01-17 19:24   ` Russell King - ARM Linux
                     ` (2 preceding siblings ...)
  (?)
@ 2011-01-18 10:24   ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-18 10:24 UTC (permalink / raw)
  To: linux-arm-kernel

> If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
> instructions in the kernel's atomic implementations as these are not
> supported.  Fall back to the generic spinlock code instead.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 95ba92f..283d7b9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,7 +7,7 @@ config ARM
>  	select HAVE_MEMBLOCK
>  	select RTC_LIB
>  	select SYS_SUPPORTS_APM_EMULATION
> -	select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI)
> +	select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
>  	select HAVE_OPROFILE if (HAVE_PERF_EVENTS)
>  	select HAVE_ARCH_KGDB
>  	select HAVE_KPROBES if (!XIP_KERNEL && !THUMB2_KERNEL)

Acked-by: Will Deacon <will.deacon@arm.com>

Thanks,

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-17 19:22   ` Russell King - ARM Linux
  (?)
  (?)
@ 2011-01-18 10:36   ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-18 10:36 UTC (permalink / raw)
  To: 'Russell King - ARM Linux', linux-arm-kernel, linux-omap

Hi Russell,

> Introduce a CPU_V6K configuration option for platforms to select if they
> have a V6K CPU core.  This allows us to identify whether we need to
> support ARMv6 CPUs without the V6K SMP extensions at build time.
> 
> Currently CPU_V6K is just an alias for CPU_V6, and all places which
> reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).
> 
> Select CPU_V6K from platforms which are known to be V6K-only.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

[...]

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c22c1ad..9c43052 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
>  tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-
> mcpu=xscale
>  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
>  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> +tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)

Can we change the tune target to 1176 for v6k?
 
>  config DMA_CACHE_RWFO
>  	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on CPU_V6 && SMP
> +	depends on (CPU_V6 || CPU_V6K) && SMP
>  	default y
>  	help
>  	  The Snoop Control Unit on ARM11MPCore does not detect the

Can we lose the CPU_V6 check here? RWFO is only required for 11MPCore
so I think we just need to check CPU_V6K && SMP.

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-17 19:22   ` Russell King - ARM Linux
                     ` (2 preceding siblings ...)
  (?)
@ 2011-01-18 10:36   ` Will Deacon
  2011-01-18 11:09       ` Russell King - ARM Linux
  -1 siblings, 1 reply; 254+ messages in thread
From: Will Deacon @ 2011-01-18 10:36 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Russell,

> Introduce a CPU_V6K configuration option for platforms to select if they
> have a V6K CPU core.  This allows us to identify whether we need to
> support ARMv6 CPUs without the V6K SMP extensions at build time.
> 
> Currently CPU_V6K is just an alias for CPU_V6, and all places which
> reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).
> 
> Select CPU_V6K from platforms which are known to be V6K-only.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

[...]

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c22c1ad..9c43052 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
>  tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-
> mcpu=xscale
>  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
>  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> +tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)

Can we change the tune target to 1176 for v6k?
 
>  config DMA_CACHE_RWFO
>  	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on CPU_V6 && SMP
> +	depends on (CPU_V6 || CPU_V6K) && SMP
>  	default y
>  	help
>  	  The Snoop Control Unit on ARM11MPCore does not detect the

Can we lose the CPU_V6 check here? RWFO is only required for 11MPCore
so I think we just need to check CPU_V6K && SMP.

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-18 10:36   ` Will Deacon
@ 2011-01-18 11:09       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 11:09 UTC (permalink / raw)
  To: Will Deacon; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 18, 2011 at 10:36:08AM -0000, Will Deacon wrote:
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c22c1ad..9c43052 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
> >  tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-
> > mcpu=xscale
> >  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> >  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> > +tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> 
> Can we change the tune target to 1176 for v6k?

At first glance, GCC doesn't seem to do anything different for 1136 vs
1176:

ARM_CORE("arm1136j-s",    arm1136js,    6J,                              FL_LDSCHED, 9e)
ARM_CORE("arm1176jz-s",   arm1176jzs,   6ZK,                             FL_LDSCHED, 9e)
ARM_CORE("mpcore",        mpcore,       6K,                              FL_LDSCHED | FL_VFPV2, 9e)

The 6J/6K are used to set the __ARM_ARCH_xx__ definition.  Everything else
between 1136 and 1176 is the same.  In fact, looking at the .md files,
switching to 1176 may make things worse:

arm1020e.md: (and (eq_attr "tune" "arm1020e,arm1022e")
arm1020e.md:  (const (if_then_else (and (eq_attr "tune" "arm1020e,arm1022e")
arm1026ejs.md: (and (eq_attr "tune" "arm1026ejs")
arm1136jfs.md: (and (eq_attr "tune" "arm1136js,arm1136jfs")
arm926ejs.md: (and (eq_attr "tune" "arm926ejs")
arm-cores.def:   If you update this table, you must update the "tune" attribute
in
arm.h:  {"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}" }, \
arm.md:          (eq_attr "tune" "arm926ejs,arm1020e,arm1026ejs,arm1136js,arm1136jfs,cortexa8")
arm.md:        (eq_attr "tune" "!arm1020e,arm1022e,cortexa8"))
arm-tune.md:(define_attr "tune"
cortex-a8.md:  (and (eq_attr "tune" "cortexa8")
cortex-a8-neon.md:  (and (eq_attr "tune" "cortexa8")

Nothing seems to tune for arm1176, but it looks like quite a bit of work
has been put into providing gcc with a pipeline description for arm1136.

The above is from gcc 4.3.5 sources.

> >  config DMA_CACHE_RWFO
> >  	bool "Enable read/write for ownership DMA cache maintenance"
> > -	depends on CPU_V6 && SMP
> > +	depends on (CPU_V6 || CPU_V6K) && SMP
> >  	default y
> >  	help
> >  	  The Snoop Control Unit on ARM11MPCore does not detect the
> 
> Can we lose the CPU_V6 check here? RWFO is only required for 11MPCore
> so I think we just need to check CPU_V6K && SMP.

I'd rather not in this patch - this patch adds CPU_V6K as an alias for
CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
We could remove it in a later patch though.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
@ 2011-01-18 11:09       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 11:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 10:36:08AM -0000, Will Deacon wrote:
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c22c1ad..9c43052 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE)	:=$(call cc-option,-mtune=xscale,-mtune=strongarm110)
> >  tune-$(CONFIG_CPU_XSC3)		:=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-
> > mcpu=xscale
> >  tune-$(CONFIG_CPU_FEROCEON)	:=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> >  tune-$(CONFIG_CPU_V6)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> > +tune-$(CONFIG_CPU_V6K)		:=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
> 
> Can we change the tune target to 1176 for v6k?

At first glance, GCC doesn't seem to do anything different for 1136 vs
1176:

ARM_CORE("arm1136j-s",    arm1136js,    6J,                              FL_LDSCHED, 9e)
ARM_CORE("arm1176jz-s",   arm1176jzs,   6ZK,                             FL_LDSCHED, 9e)
ARM_CORE("mpcore",        mpcore,       6K,                              FL_LDSCHED | FL_VFPV2, 9e)

The 6J/6K are used to set the __ARM_ARCH_xx__ definition.  Everything else
between 1136 and 1176 is the same.  In fact, looking at the .md files,
switching to 1176 may make things worse:

arm1020e.md: (and (eq_attr "tune" "arm1020e,arm1022e")
arm1020e.md:  (const (if_then_else (and (eq_attr "tune" "arm1020e,arm1022e")
arm1026ejs.md: (and (eq_attr "tune" "arm1026ejs")
arm1136jfs.md: (and (eq_attr "tune" "arm1136js,arm1136jfs")
arm926ejs.md: (and (eq_attr "tune" "arm926ejs")
arm-cores.def:   If you update this table, you must update the "tune" attribute
in
arm.h:  {"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}" }, \
arm.md:          (eq_attr "tune" "arm926ejs,arm1020e,arm1026ejs,arm1136js,arm1136jfs,cortexa8")
arm.md:        (eq_attr "tune" "!arm1020e,arm1022e,cortexa8"))
arm-tune.md:(define_attr "tune"
cortex-a8.md:  (and (eq_attr "tune" "cortexa8")
cortex-a8-neon.md:  (and (eq_attr "tune" "cortexa8")

Nothing seems to tune for arm1176, but it looks like quite a bit of work
has been put into providing gcc with a pipeline description for arm1136.

The above is from gcc 4.3.5 sources.

> >  config DMA_CACHE_RWFO
> >  	bool "Enable read/write for ownership DMA cache maintenance"
> > -	depends on CPU_V6 && SMP
> > +	depends on (CPU_V6 || CPU_V6K) && SMP
> >  	default y
> >  	help
> >  	  The Snoop Control Unit on ARM11MPCore does not detect the
> 
> Can we lose the CPU_V6 check here? RWFO is only required for 11MPCore
> so I think we just need to check CPU_V6K && SMP.

I'd rather not in this patch - this patch adds CPU_V6K as an alias for
CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
We could remove it in a later patch though.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-18 11:09       ` Russell King - ARM Linux
@ 2011-01-18 13:35         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 13:35 UTC (permalink / raw)
  To: Will Deacon; +Cc: linux-omap, linux-arm-kernel

On Tue, Jan 18, 2011 at 11:09:22AM +0000, Russell King - ARM Linux wrote:
> I'd rather not in this patch - this patch adds CPU_V6K as an alias for
> CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
> We could remove it in a later patch though.

Here's a follow-up patch to do that.  There's a few other things which
could do with updating now that we have CPU_Vx* straightened out.  I've
also recently noticed that the v6 and v7 cache stuff doesn't use the
direct-call optimization (see commented out bits in cacheflush.h).

That was because my original V6 support used the block cache operations,
which had to be run-time tested for presence, and so modified the
global cpu_cache methods directly.  As the block cache stuff was dropped,
we should re-enable this optimization.

That said, I'd rather not add too much to this series as I think it needs
to go into mainline ASAP - and probably stable as well, even though it's
on the large side - once properly and fully tested.

8<----
Subject: [PATCH] ARM: v6k: DMA_CACHE_RWFO isn't appropriate for non-v6k CPUs

Limit DMA_CACHE_RWFO to only v6k SMP CPUs - V6 CPUs aren't SMP capable,
so the read/write for ownership work-around doesn't apply to them.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 843bc8c..808b832 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -775,7 +775,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
 
 config DMA_CACHE_RWFO
 	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on (CPU_V6 || CPU_V6K) && SMP
+	depends on CPU_V6K && SMP
 	default y
 	help
 	  The Snoop Control Unit on ARM11MPCore does not detect the
-- 
1.6.2.5



^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
@ 2011-01-18 13:35         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 13:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 11:09:22AM +0000, Russell King - ARM Linux wrote:
> I'd rather not in this patch - this patch adds CPU_V6K as an alias for
> CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
> We could remove it in a later patch though.

Here's a follow-up patch to do that.  There's a few other things which
could do with updating now that we have CPU_Vx* straightened out.  I've
also recently noticed that the v6 and v7 cache stuff doesn't use the
direct-call optimization (see commented out bits in cacheflush.h).

That was because my original V6 support used the block cache operations,
which had to be run-time tested for presence, and so modified the
global cpu_cache methods directly.  As the block cache stuff was dropped,
we should re-enable this optimization.

That said, I'd rather not add too much to this series as I think it needs
to go into mainline ASAP - and probably stable as well, even though it's
on the large side - once properly and fully tested.

8<----
Subject: [PATCH] ARM: v6k: DMA_CACHE_RWFO isn't appropriate for non-v6k CPUs

Limit DMA_CACHE_RWFO to only v6k SMP CPUs - V6 CPUs aren't SMP capable,
so the read/write for ownership work-around doesn't apply to them.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 843bc8c..808b832 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -775,7 +775,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
 
 config DMA_CACHE_RWFO
 	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on (CPU_V6 || CPU_V6K) && SMP
+	depends on CPU_V6K && SMP
 	default y
 	help
 	  The Snoop Control Unit on ARM11MPCore does not detect the
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-18  6:00     ` Nicolas Pitre
@ 2011-01-18 14:30       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 14:30 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> I also wonder what happens with a misaligned ldrex/strex... Does the 
> alignment trap get invoked?  If so, the assertion could be put there 
> instead if that's not done already, removing this overhead from bitops 
> calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
> as usual since the ldr/str are not special, but the previous code 
> allowed for misaligned pointer so result would be no worse than before 
> in that case.  Testing appears to indicate those misaligned bitops are 
> rather nonexistent so far.

Well, whether LDREX/STREX always fault for misalignment is well open to
debate.  The ARM ARM for ARMv7 seems to imply they will always fault for
misaligned accesses.  For ARMv6, the situation is less clear - the way
the manual is arranged, it suggests that they will if SCTLR.U is set.
When it's clear, the ARM ARM doesn't specify what the outcome is.

I also don't know how our unaligned fixup will behave with an unaligned
LDREX/STREX without checking the bit patterns.

So... I think that's too many unknowns to rely on it, especially when
filesystem data is at stake.

Maybe changing it to:

	ands	ip, r1, #3
	strneb	r1, [ip]

instead?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-18 14:30       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 14:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> I also wonder what happens with a misaligned ldrex/strex... Does the 
> alignment trap get invoked?  If so, the assertion could be put there 
> instead if that's not done already, removing this overhead from bitops 
> calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
> as usual since the ldr/str are not special, but the previous code 
> allowed for misaligned pointer so result would be no worse than before 
> in that case.  Testing appears to indicate those misaligned bitops are 
> rather nonexistent so far.

Well, whether LDREX/STREX always fault for misalignment is well open to
debate.  The ARM ARM for ARMv7 seems to imply they will always fault for
misaligned accesses.  For ARMv6, the situation is less clear - the way
the manual is arranged, it suggests that they will if SCTLR.U is set.
When it's clear, the ARM ARM doesn't specify what the outcome is.

I also don't know how our unaligned fixup will behave with an unaligned
LDREX/STREX without checking the bit patterns.

So... I think that's too many unknowns to rely on it, especially when
filesystem data is at stake.

Maybe changing it to:

	ands	ip, r1, #3
	strneb	r1, [ip]

instead?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-01-18 14:30   ` Kirill A. Shutemov
  -1 siblings, 0 replies; 254+ messages in thread
From: Kirill A. Shutemov @ 2011-01-18 14:30 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.

Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-18 14:30   ` Kirill A. Shutemov
  0 siblings, 0 replies; 254+ messages in thread
From: Kirill A. Shutemov @ 2011-01-18 14:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.

Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-18 14:30   ` Kirill A. Shutemov
@ 2011-01-18 14:40     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 14:40 UTC (permalink / raw)
  To: Kirill A. Shutemov; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > This patch series reworks the ARMv6/ARMv6K support options, code
> > selection, and bit operations such that it's possible to safely
> > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > in one image.
> 
> Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?

Err what?  There's no CPU_ARCH_ARMv6K.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-18 14:40     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 14:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > This patch series reworks the ARMv6/ARMv6K support options, code
> > selection, and bit operations such that it's possible to safely
> > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > in one image.
> 
> Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?

Err what?  There's no CPU_ARCH_ARMv6K.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-18 14:40     ` Russell King - ARM Linux
@ 2011-01-18 14:44       ` Kirill A. Shutemov
  -1 siblings, 0 replies; 254+ messages in thread
From: Kirill A. Shutemov @ 2011-01-18 14:44 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > > This patch series reworks the ARMv6/ARMv6K support options, code
> > > selection, and bit operations such that it's possible to safely
> > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > > in one image.
> > 
> > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?
> 
> Err what?  There's no CPU_ARCH_ARMv6K.

I some cases we need runtime check for K extention (see exceptions_init())
Is there any facility for it?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-18 14:44       ` Kirill A. Shutemov
  0 siblings, 0 replies; 254+ messages in thread
From: Kirill A. Shutemov @ 2011-01-18 14:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > > This patch series reworks the ARMv6/ARMv6K support options, code
> > > selection, and bit operations such that it's possible to safely
> > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > > in one image.
> > 
> > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?
> 
> Err what?  There's no CPU_ARCH_ARMv6K.

I some cases we need runtime check for K extention (see exceptions_init())
Is there any facility for it?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-18 14:44       ` Kirill A. Shutemov
@ 2011-01-18 15:01         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 15:01 UTC (permalink / raw)
  To: Kirill A. Shutemov; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > > > This patch series reworks the ARMv6/ARMv6K support options, code
> > > > selection, and bit operations such that it's possible to safely
> > > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > > > in one image.
> > > 
> > > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?
> > 
> > Err what?  There's no CPU_ARCH_ARMv6K.
> 
> I some cases we need runtime check for K extention (see exceptions_init())
> Is there any facility for it?

From what I can tell there's no hard and fast way to say at runtime
"this CPU has K extensions" as it appears possible from the ARM ARM to
have a CPU which is ARMv6K (eg, the CPU in Dove) which does not support
SMP.  Whether that identifies itself as ARMv6 in the architecture field
of the main ID register, or uses the new CPUID scheme is not clear.
If it identifies itself as ARMv6, then there's no CPUID registers to
detect what it supports.

If it's the new CPUID scheme, while we can tell that a CPU has CLREX
support, that doesn't necessary mean that it has the access fault stuff.
That just means that a greater range of exclusive operations are
supported.

Also:

| An implementation that provides hardware management of the access flag:
| • does not generate Access Flag faults when the access flag is enabled
| ...

So, if we don't enable the access flag support, then we shouldn't see
them (we don't enable them.)

What's more:

| Memory Model Feature Register 2 (ID_MMFR2)
| HW access flag, bits [31:28]
| Indicates support for a Hardware access flag, as part of the VMSAv7 implementation.
| Permitted values are:
| 0b0000 Not supported.
| 0b0001 Support for VMSAv7 access flag, updated in hardware.

That doesn't suggest that it's valid to assume that this will be '1' on
ARMv6K - and istr there's some subtle differences between the various
CPUID registers for different architectures as well - to make the CPUID
scheme just that little more complicated to use, so these bits may not
even be defined that way for ARMv6K.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-01-18 15:01         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-18 15:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > > > This patch series reworks the ARMv6/ARMv6K support options, code
> > > > selection, and bit operations such that it's possible to safely
> > > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> > > > in one image.
> > > 
> > > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks?
> > 
> > Err what?  There's no CPU_ARCH_ARMv6K.
> 
> I some cases we need runtime check for K extention (see exceptions_init())
> Is there any facility for it?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-18  6:00     ` Nicolas Pitre
@ 2011-01-18 15:11       ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-18 15:11 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On 18 January 2011 06:00, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
>
>> Add additional instructions to our assembly bitops functions to ensure
>> that they only operate on word-aligned pointers.  This will be necessary
>> when we switch these operations to use the word-based exclusive
>> operations.
>>
>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> This breaks the Thumb2 kernel build:
>
>  AS      arch/arm/lib/changebit.o
> arch/arm/lib/changebit.S: Assembler messages:
> arch/arm/lib/changebit.S:16: Error: Thumb does not support negative register indexing -- `strne r1,[r1,-r1]'
>
> I also wonder what happens with a misaligned ldrex/strex... Does the
> alignment trap get invoked?

According to the ARM ARM, unaligned ldrex/strex should generate an
alignment fault on ARMv6 (with SCTLR.U bit set) and ARMv7.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-18 15:11       ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-18 15:11 UTC (permalink / raw)
  To: linux-arm-kernel

On 18 January 2011 06:00, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
>
>> Add additional instructions to our assembly bitops functions to ensure
>> that they only operate on word-aligned pointers. ?This will be necessary
>> when we switch these operations to use the word-based exclusive
>> operations.
>>
>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> This breaks the Thumb2 kernel build:
>
> ?AS ? ? ?arch/arm/lib/changebit.o
> arch/arm/lib/changebit.S: Assembler messages:
> arch/arm/lib/changebit.S:16: Error: Thumb does not support negative register indexing -- `strne r1,[r1,-r1]'
>
> I also wonder what happens with a misaligned ldrex/strex... Does the
> alignment trap get invoked?

According to the ARM ARM, unaligned ldrex/strex should generate an
alignment fault on ARMv6 (with SCTLR.U bit set) and ARMv7.

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-18 13:35         ` Russell King - ARM Linux
  (?)
@ 2011-01-18 15:22         ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-18 15:22 UTC (permalink / raw)
  To: 'Russell King - ARM Linux'; +Cc: linux-omap, linux-arm-kernel

> On Tue, Jan 18, 2011 at 11:09:22AM +0000, Russell King - ARM Linux wrote:
> > I'd rather not in this patch - this patch adds CPU_V6K as an alias for
> > CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
> > We could remove it in a later patch though.
> 
> Here's a follow-up patch to do that.  There's a few other things which
> could do with updating now that we have CPU_Vx* straightened out.  I've
> also recently noticed that the v6 and v7 cache stuff doesn't use the
> direct-call optimization (see commented out bits in cacheflush.h).
> 
> That was because my original V6 support used the block cache operations,
> which had to be run-time tested for presence, and so modified the
> global cpu_cache methods directly.  As the block cache stuff was dropped,
> we should re-enable this optimization.
> 
> That said, I'd rather not add too much to this series as I think it needs
> to go into mainline ASAP - and probably stable as well, even though it's
> on the large side - once properly and fully tested.

Understood. Pruning the Kconfig is an optimisation and can be done once
the initial bulk is merged.
 
> Subject: [PATCH] ARM: v6k: DMA_CACHE_RWFO isn't appropriate for non-v6k CPUs
> 
> Limit DMA_CACHE_RWFO to only v6k SMP CPUs - V6 CPUs aren't SMP capable,
> so the read/write for ownership work-around doesn't apply to them.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/mm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 843bc8c..808b832 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -775,7 +775,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
> 
>  config DMA_CACHE_RWFO
>  	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on (CPU_V6 || CPU_V6K) && SMP
> +	depends on CPU_V6K && SMP
>  	default y
>  	help
>  	  The Snoop Control Unit on ARM11MPCore does not detect the

Looks good to me:

Acked-by: Will Deacon <will.deacon@arm.com>

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 04/14] ARM: v6k: introduce CPU_V6K option
  2011-01-18 13:35         ` Russell King - ARM Linux
  (?)
  (?)
@ 2011-01-18 15:22         ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-18 15:22 UTC (permalink / raw)
  To: linux-arm-kernel

> On Tue, Jan 18, 2011 at 11:09:22AM +0000, Russell King - ARM Linux wrote:
> > I'd rather not in this patch - this patch adds CPU_V6K as an alias for
> > CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
> > We could remove it in a later patch though.
> 
> Here's a follow-up patch to do that.  There's a few other things which
> could do with updating now that we have CPU_Vx* straightened out.  I've
> also recently noticed that the v6 and v7 cache stuff doesn't use the
> direct-call optimization (see commented out bits in cacheflush.h).
> 
> That was because my original V6 support used the block cache operations,
> which had to be run-time tested for presence, and so modified the
> global cpu_cache methods directly.  As the block cache stuff was dropped,
> we should re-enable this optimization.
> 
> That said, I'd rather not add too much to this series as I think it needs
> to go into mainline ASAP - and probably stable as well, even though it's
> on the large side - once properly and fully tested.

Understood. Pruning the Kconfig is an optimisation and can be done once
the initial bulk is merged.
 
> Subject: [PATCH] ARM: v6k: DMA_CACHE_RWFO isn't appropriate for non-v6k CPUs
> 
> Limit DMA_CACHE_RWFO to only v6k SMP CPUs - V6 CPUs aren't SMP capable,
> so the read/write for ownership work-around doesn't apply to them.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/mm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 843bc8c..808b832 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -775,7 +775,7 @@ config NEEDS_SYSCALL_FOR_CMPXCHG
> 
>  config DMA_CACHE_RWFO
>  	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on (CPU_V6 || CPU_V6K) && SMP
> +	depends on CPU_V6K && SMP
>  	default y
>  	help
>  	  The Snoop Control Unit on ARM11MPCore does not detect the

Looks good to me:

Acked-by: Will Deacon <will.deacon@arm.com>

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-18 14:30       ` Russell King - ARM Linux
@ 2011-01-18 18:20         ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18 18:20 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Tue, 18 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> > I also wonder what happens with a misaligned ldrex/strex... Does the 
> > alignment trap get invoked?  If so, the assertion could be put there 
> > instead if that's not done already, removing this overhead from bitops 
> > calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
> > as usual since the ldr/str are not special, but the previous code 
> > allowed for misaligned pointer so result would be no worse than before 
> > in that case.  Testing appears to indicate those misaligned bitops are 
> > rather nonexistent so far.
> 
> Well, whether LDREX/STREX always fault for misalignment is well open to
> debate.  The ARM ARM for ARMv7 seems to imply they will always fault for
> misaligned accesses.  For ARMv6, the situation is less clear - the way
> the manual is arranged, it suggests that they will if SCTLR.U is set.
> When it's clear, the ARM ARM doesn't specify what the outcome is.

Probably we should make sure they always fault on both ARMv6 and ARMv7 
regardless of this particular issue.

> I also don't know how our unaligned fixup will behave with an unaligned
> LDREX/STREX without checking the bit patterns.

Making ldrex/strex always fault means that we also need to make the 
alignment fixup code produce a SIGBUS, or panic the kernel if in atomic 
context.

> So... I think that's too many unknowns to rely on it, especially when
> filesystem data is at stake.
> 
> Maybe changing it to:
> 
> 	ands	ip, r1, #3
> 	strneb	r1, [ip]
> 
> instead?

Sure.  That would solve the T2 issue.  Eventually we could revisit the 
need for this assertion here once the above is done.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-18 18:20         ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-18 18:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 18 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> > I also wonder what happens with a misaligned ldrex/strex... Does the 
> > alignment trap get invoked?  If so, the assertion could be put there 
> > instead if that's not done already, removing this overhead from bitops 
> > calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
> > as usual since the ldr/str are not special, but the previous code 
> > allowed for misaligned pointer so result would be no worse than before 
> > in that case.  Testing appears to indicate those misaligned bitops are 
> > rather nonexistent so far.
> 
> Well, whether LDREX/STREX always fault for misalignment is well open to
> debate.  The ARM ARM for ARMv7 seems to imply they will always fault for
> misaligned accesses.  For ARMv6, the situation is less clear - the way
> the manual is arranged, it suggests that they will if SCTLR.U is set.
> When it's clear, the ARM ARM doesn't specify what the outcome is.

Probably we should make sure they always fault on both ARMv6 and ARMv7 
regardless of this particular issue.

> I also don't know how our unaligned fixup will behave with an unaligned
> LDREX/STREX without checking the bit patterns.

Making ldrex/strex always fault means that we also need to make the 
alignment fixup code produce a SIGBUS, or panic the kernel if in atomic 
context.

> So... I think that's too many unknowns to rely on it, especially when
> filesystem data is at stake.
> 
> Maybe changing it to:
> 
> 	ands	ip, r1, #3
> 	strneb	r1, [ip]
> 
> instead?

Sure.  That would solve the T2 issue.  Eventually we could revisit the 
need for this assertion here once the above is done.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-17 19:21   ` Russell King - ARM Linux
@ 2011-01-23  0:16     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-23  0:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap

On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

As only one person replied to this patch with test information, I'm
not happy to push this into -rc, and hence that prevents it going into
-stable too.  That means omap2plus_defconfig .38 mainline kernels
(including -stable) will remain potentially dangerous when run on
SMP capable hardware.

Therefore, I see no alternative at the moment but to purposely cause
builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
data corruption.

Please get your tested-by's to me for at least the first three patches
of this series ASAP.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-23  0:16     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-23  0:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

As only one person replied to this patch with test information, I'm
not happy to push this into -rc, and hence that prevents it going into
-stable too.  That means omap2plus_defconfig .38 mainline kernels
(including -stable) will remain potentially dangerous when run on
SMP capable hardware.

Therefore, I see no alternative at the moment but to purposely cause
builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
data corruption.

Please get your tested-by's to me for at least the first three patches
of this series ASAP.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-23  0:16     ` Russell King - ARM Linux
@ 2011-01-23  4:44       ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-23  4:44 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Sun, 23 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > Switch the set/clear/change bitops to use the word-based exclusive
> > operations, which are only present in a wider range of ARM architectures
> > than the byte-based exclusive operations.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> As only one person replied to this patch with test information, I'm
> not happy to push this into -rc, and hence that prevents it going into
> -stable too.  

At least another person did post results:

http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com

> That means omap2plus_defconfig .38 mainline kernels
> (including -stable) will remain potentially dangerous when run on
> SMP capable hardware.

I must admit that this series looks a bit large for stable IMHO.  I 
think that the fix for stable should limit itself only to prevent SMP 
from being selected if anything else than CPU_32v6K is selected.

This looks perfectly reasonable for 2.6.38-rc to me though.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-23  4:44       ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-23  4:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Sun, 23 Jan 2011, Russell King - ARM Linux wrote:

> On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > Switch the set/clear/change bitops to use the word-based exclusive
> > operations, which are only present in a wider range of ARM architectures
> > than the byte-based exclusive operations.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> As only one person replied to this patch with test information, I'm
> not happy to push this into -rc, and hence that prevents it going into
> -stable too.  

At least another person did post results:

http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com

> That means omap2plus_defconfig .38 mainline kernels
> (including -stable) will remain potentially dangerous when run on
> SMP capable hardware.

I must admit that this series looks a bit large for stable IMHO.  I 
think that the fix for stable should limit itself only to prevent SMP 
from being selected if anything else than CPU_32v6K is selected.

This looks perfectly reasonable for 2.6.38-rc to me though.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-23  4:44       ` Nicolas Pitre
@ 2011-01-23  9:35         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-23  9:35 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: linux-arm-kernel, linux-omap

On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> At least another person did post results:
> 
> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com

Slightly different patch - there were three revisions.  I can't attach
a tested-by given to a different patch to this one.

> > That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> 
> I must admit that this series looks a bit large for stable IMHO.  I 
> think that the fix for stable should limit itself only to prevent SMP 
> from being selected if anything else than CPU_32v6K is selected.

The first three are the bare minimum required for -stable.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-23  9:35         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-23  9:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> At least another person did post results:
> 
> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com

Slightly different patch - there were three revisions.  I can't attach
a tested-by given to a different patch to this one.

> > That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> 
> I must admit that this series looks a bit large for stable IMHO.  I 
> think that the fix for stable should limit itself only to prevent SMP 
> from being selected if anything else than CPU_32v6K is selected.

The first three are the bare minimum required for -stable.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-23  9:35         ` Russell King - ARM Linux
@ 2011-01-24  8:38           ` Poddar, Sourav
  -1 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24  8:38 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> At least another person did post results:
>>
>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
>
> Slightly different patch - there were three revisions.  I can't attach
> a tested-by given to a different patch to this one.
>
>> > That means omap2plus_defconfig .38 mainline kernels
>> > (including -stable) will remain potentially dangerous when run on
>> > SMP capable hardware.
>>
>> I must admit that this series looks a bit large for stable IMHO.  I
>> think that the fix for stable should limit itself only to prevent SMP
>> from being selected if anything else than CPU_32v6K is selected.
>
> The first three are the bare minimum required for -stable.
>

Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
the following boards :


1. Omap2420 SDP

2. Omap2430 SDP

3. Omap3430 SDP

4. Omap4 Blaze

Tested by : Sourav Poddar <sourav.poddar@ti.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24  8:38           ` Poddar, Sourav
  0 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24  8:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> At least another person did post results:
>>
>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
>
> Slightly different patch - there were three revisions. ?I can't attach
> a tested-by given to a different patch to this one.
>
>> > That means omap2plus_defconfig .38 mainline kernels
>> > (including -stable) will remain potentially dangerous when run on
>> > SMP capable hardware.
>>
>> I must admit that this series looks a bit large for stable IMHO. ?I
>> think that the fix for stable should limit itself only to prevent SMP
>> from being selected if anything else than CPU_32v6K is selected.
>
> The first three are the bare minimum required for -stable.
>

Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
the following boards :


1. Omap2420 SDP

2. Omap2430 SDP

3. Omap3430 SDP

4. Omap4 Blaze

Tested by : Sourav Poddar <sourav.poddar@ti.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24  8:38           ` Poddar, Sourav
@ 2011-01-24  8:57             ` Poddar, Sourav
  -1 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24  8:57 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>>> At least another person did post results:
>>>
>>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
>>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
>>
>> Slightly different patch - there were three revisions.  I can't attach
>> a tested-by given to a different patch to this one.
>>
>>> > That means omap2plus_defconfig .38 mainline kernels
>>> > (including -stable) will remain potentially dangerous when run on
>>> > SMP capable hardware.
>>>
>>> I must admit that this series looks a bit large for stable IMHO.  I
>>> think that the fix for stable should limit itself only to prevent SMP
>>> from being selected if anything else than CPU_32v6K is selected.
>>
>> The first three are the bare minimum required for -stable.
>>
>

 Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
 the following boards :


  1. Omap2420 SDP

  2. Omap2430 SDP

  3. Omap3430 SDP

  4. Omap4 Blaze

  Tested-by: Sourav Poddar <sourav.poddar@ti.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24  8:57             ` Poddar, Sourav
  0 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24  8:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>>> At least another person did post results:
>>>
>>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
>>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
>>
>> Slightly different patch - there were three revisions. ?I can't attach
>> a tested-by given to a different patch to this one.
>>
>>> > That means omap2plus_defconfig .38 mainline kernels
>>> > (including -stable) will remain potentially dangerous when run on
>>> > SMP capable hardware.
>>>
>>> I must admit that this series looks a bit large for stable IMHO. ?I
>>> think that the fix for stable should limit itself only to prevent SMP
>>> from being selected if anything else than CPU_32v6K is selected.
>>
>> The first three are the bare minimum required for -stable.
>>
>

 Boot tested the 14 patch series ?with CONFIG_SWP_EMULATE enabled, on
 the following boards :


  1. Omap2420 SDP

  2. Omap2430 SDP

  3. Omap3430 SDP

  4. Omap4 Blaze

  Tested-by: Sourav Poddar <sourav.poddar@ti.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24  8:57             ` Poddar, Sourav
@ 2011-01-24 10:28               ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 10:28 UTC (permalink / raw)
  To: Poddar, Sourav; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> >>> At least another person did post results:
> >>>
> >>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
> >>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
> >>
> >> Slightly different patch - there were three revisions.  I can't attach
> >> a tested-by given to a different patch to this one.
> >>
> >>> > That means omap2plus_defconfig .38 mainline kernels
> >>> > (including -stable) will remain potentially dangerous when run on
> >>> > SMP capable hardware.
> >>>
> >>> I must admit that this series looks a bit large for stable IMHO.  I
> >>> think that the fix for stable should limit itself only to prevent SMP
> >>> from being selected if anything else than CPU_32v6K is selected.
> >>
> >> The first three are the bare minimum required for -stable.
> >>
> >
> 
>  Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
>  the following boards :
> 
> 
>   1. Omap2420 SDP
> 
>   2. Omap2430 SDP
> 
>   3. Omap3430 SDP
> 
>   4. Omap4 Blaze
> 
>   Tested-by: Sourav Poddar <sourav.poddar@ti.com>

Thanks.  It's also important to ascertain which filesystems were tested -
could you let me know please?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24 10:28               ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 10:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> >>> At least another person did post results:
> >>>
> >>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
> >>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
> >>
> >> Slightly different patch - there were three revisions. ?I can't attach
> >> a tested-by given to a different patch to this one.
> >>
> >>> > That means omap2plus_defconfig .38 mainline kernels
> >>> > (including -stable) will remain potentially dangerous when run on
> >>> > SMP capable hardware.
> >>>
> >>> I must admit that this series looks a bit large for stable IMHO. ?I
> >>> think that the fix for stable should limit itself only to prevent SMP
> >>> from being selected if anything else than CPU_32v6K is selected.
> >>
> >> The first three are the bare minimum required for -stable.
> >>
> >
> 
>  Boot tested the 14 patch series ?with CONFIG_SWP_EMULATE enabled, on
>  the following boards :
> 
> 
>   1. Omap2420 SDP
> 
>   2. Omap2430 SDP
> 
>   3. Omap3430 SDP
> 
>   4. Omap4 Blaze
> 
>   Tested-by: Sourav Poddar <sourav.poddar@ti.com>

Thanks.  It's also important to ascertain which filesystems were tested -
could you let me know please?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24 10:28               ` Russell King - ARM Linux
@ 2011-01-24 13:47                 ` Poddar, Sourav
  -1 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24 13:47 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
>> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
>> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> >>> At least another person did post results:
>> >>>
>> >>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
>> >>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
>> >>
>> >> Slightly different patch - there were three revisions.  I can't attach
>> >> a tested-by given to a different patch to this one.
>> >>
>> >>> > That means omap2plus_defconfig .38 mainline kernels
>> >>> > (including -stable) will remain potentially dangerous when run on
>> >>> > SMP capable hardware.
>> >>>
>> >>> I must admit that this series looks a bit large for stable IMHO.  I
>> >>> think that the fix for stable should limit itself only to prevent SMP
>> >>> from being selected if anything else than CPU_32v6K is selected.
>> >>
>> >> The first three are the bare minimum required for -stable.
>> >>
>> >
>>
>>  Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
>>  the following boards :
>>
>>
>>   1. Omap2420 SDP
>>
>>   2. Omap2430 SDP
>>
>>   3. Omap3430 SDP
>>
>>   4. Omap4 Blaze
>>
>>   Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>
> Thanks.  It's also important to ascertain which filesystems were tested -
> could you let me know please?
>

It is a custom filesystem on BusyBox v1.17.2.
Please let me know if you need some other
information.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24 13:47                 ` Poddar, Sourav
  0 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24 13:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
>> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
>> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> >>> At least another person did post results:
>> >>>
>> >>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
>> >>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
>> >>
>> >> Slightly different patch - there were three revisions. ?I can't attach
>> >> a tested-by given to a different patch to this one.
>> >>
>> >>> > That means omap2plus_defconfig .38 mainline kernels
>> >>> > (including -stable) will remain potentially dangerous when run on
>> >>> > SMP capable hardware.
>> >>>
>> >>> I must admit that this series looks a bit large for stable IMHO. ?I
>> >>> think that the fix for stable should limit itself only to prevent SMP
>> >>> from being selected if anything else than CPU_32v6K is selected.
>> >>
>> >> The first three are the bare minimum required for -stable.
>> >>
>> >
>>
>> ?Boot tested the 14 patch series ?with CONFIG_SWP_EMULATE enabled, on
>> ?the following boards :
>>
>>
>> ? 1. Omap2420 SDP
>>
>> ? 2. Omap2430 SDP
>>
>> ? 3. Omap3430 SDP
>>
>> ? 4. Omap4 Blaze
>>
>> ? Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>
> Thanks. ?It's also important to ascertain which filesystems were tested -
> could you let me know please?
>

It is a custom filesystem on BusyBox v1.17.2.
Please let me know if you need some other
information.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24 13:47                 ` Poddar, Sourav
@ 2011-01-24 14:11                   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 14:11 UTC (permalink / raw)
  To: Poddar, Sourav; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> >> > <linux@arm.linux.org.uk> wrote:
> >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> >> >>> At least another person did post results:
> >> >>>
> >> >>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
> >> >>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
> >> >>
> >> >> Slightly different patch - there were three revisions.  I can't attach
> >> >> a tested-by given to a different patch to this one.
> >> >>
> >> >>> > That means omap2plus_defconfig .38 mainline kernels
> >> >>> > (including -stable) will remain potentially dangerous when run on
> >> >>> > SMP capable hardware.
> >> >>>
> >> >>> I must admit that this series looks a bit large for stable IMHO.  I
> >> >>> think that the fix for stable should limit itself only to prevent SMP
> >> >>> from being selected if anything else than CPU_32v6K is selected.
> >> >>
> >> >> The first three are the bare minimum required for -stable.
> >> >>
> >> >
> >>
> >>  Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
> >>  the following boards :
> >>
> >>
> >>   1. Omap2420 SDP
> >>
> >>   2. Omap2430 SDP
> >>
> >>   3. Omap3430 SDP
> >>
> >>   4. Omap4 Blaze
> >>
> >>   Tested-by: Sourav Poddar <sourav.poddar@ti.com>
> >
> > Thanks.  It's also important to ascertain which filesystems were tested -
> > could you let me know please?
> >
> 
> It is a custom filesystem on BusyBox v1.17.2.

So you wrote code under fs/ for this filesystem?

> Please let me know if you need some other
> information.

I'm trying to find out what _type_ of filesystem.  ext2, ext3, nfs, cramfs,
etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24 14:11                   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 14:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
> >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> >> > <linux@arm.linux.org.uk> wrote:
> >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> >> >>> At least another person did post results:
> >> >>>
> >> >>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
> >> >>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
> >> >>
> >> >> Slightly different patch - there were three revisions. ?I can't attach
> >> >> a tested-by given to a different patch to this one.
> >> >>
> >> >>> > That means omap2plus_defconfig .38 mainline kernels
> >> >>> > (including -stable) will remain potentially dangerous when run on
> >> >>> > SMP capable hardware.
> >> >>>
> >> >>> I must admit that this series looks a bit large for stable IMHO. ?I
> >> >>> think that the fix for stable should limit itself only to prevent SMP
> >> >>> from being selected if anything else than CPU_32v6K is selected.
> >> >>
> >> >> The first three are the bare minimum required for -stable.
> >> >>
> >> >
> >>
> >> ?Boot tested the 14 patch series ?with CONFIG_SWP_EMULATE enabled, on
> >> ?the following boards :
> >>
> >>
> >> ? 1. Omap2420 SDP
> >>
> >> ? 2. Omap2430 SDP
> >>
> >> ? 3. Omap3430 SDP
> >>
> >> ? 4. Omap4 Blaze
> >>
> >> ? Tested-by: Sourav Poddar <sourav.poddar@ti.com>
> >
> > Thanks. ?It's also important to ascertain which filesystems were tested -
> > could you let me know please?
> >
> 
> It is a custom filesystem on BusyBox v1.17.2.

So you wrote code under fs/ for this filesystem?

> Please let me know if you need some other
> information.

I'm trying to find out what _type_ of filesystem.  ext2, ext3, nfs, cramfs,
etc.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24 14:11                   ` Russell King - ARM Linux
@ 2011-01-24 14:54                     ` Poddar, Sourav
  -1 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24 14:54 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 7:41 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote:
>> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
>> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
>> >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
>> >> > <linux@arm.linux.org.uk> wrote:
>> >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> >> >>> At least another person did post results:
>> >> >>>
>> >> >>> http://mid.gmane.org/20110117094602.GA2622@pulham.picochip.com
>> >> >>> http://mid.gmane.org/20110117110308.GC2622@pulham.picochip.com
>> >> >>
>> >> >> Slightly different patch - there were three revisions.  I can't attach
>> >> >> a tested-by given to a different patch to this one.
>> >> >>
>> >> >>> > That means omap2plus_defconfig .38 mainline kernels
>> >> >>> > (including -stable) will remain potentially dangerous when run on
>> >> >>> > SMP capable hardware.
>> >> >>>
>> >> >>> I must admit that this series looks a bit large for stable IMHO.  I
>> >> >>> think that the fix for stable should limit itself only to prevent SMP
>> >> >>> from being selected if anything else than CPU_32v6K is selected.
>> >> >>
>> >> >> The first three are the bare minimum required for -stable.
>> >> >>
>> >> >
>> >>
>> >>  Boot tested the 14 patch series  with CONFIG_SWP_EMULATE enabled, on
>> >>  the following boards :
>> >>
>> >>
>> >>   1. Omap2420 SDP
>> >>
>> >>   2. Omap2430 SDP
>> >>
>> >>   3. Omap3430 SDP
>> >>
>> >>   4. Omap4 Blaze
>> >>
>> >>   Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>> >
>> > Thanks.  It's also important to ascertain which filesystems were tested -
>> > could you let me know please?
>> >
>>
>> It is a custom filesystem on BusyBox v1.17.2.
>
> So you wrote code under fs/ for this filesystem?

No.

>> Please let me know if you need some other
>> information.
>
> I'm trying to find out what _type_ of filesystem.  ext2, ext3, nfs, cramfs,
> etc.
>

nfs filesystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24 14:54                     ` Poddar, Sourav
  0 siblings, 0 replies; 254+ messages in thread
From: Poddar, Sourav @ 2011-01-24 14:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 7:41 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote:
>> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
>> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav <sourav.poddar@ti.com> wrote:
>> >> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
>> >> > <linux@arm.linux.org.uk> wrote:
>> >> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
>> >> >>> At least another person did post results:
>> >> >>>
>> >> >>> http://mid.gmane.org/20110117094602.GA2622 at pulham.picochip.com
>> >> >>> http://mid.gmane.org/20110117110308.GC2622 at pulham.picochip.com
>> >> >>
>> >> >> Slightly different patch - there were three revisions. ?I can't attach
>> >> >> a tested-by given to a different patch to this one.
>> >> >>
>> >> >>> > That means omap2plus_defconfig .38 mainline kernels
>> >> >>> > (including -stable) will remain potentially dangerous when run on
>> >> >>> > SMP capable hardware.
>> >> >>>
>> >> >>> I must admit that this series looks a bit large for stable IMHO. ?I
>> >> >>> think that the fix for stable should limit itself only to prevent SMP
>> >> >>> from being selected if anything else than CPU_32v6K is selected.
>> >> >>
>> >> >> The first three are the bare minimum required for -stable.
>> >> >>
>> >> >
>> >>
>> >> ?Boot tested the 14 patch series ?with CONFIG_SWP_EMULATE enabled, on
>> >> ?the following boards :
>> >>
>> >>
>> >> ? 1. Omap2420 SDP
>> >>
>> >> ? 2. Omap2430 SDP
>> >>
>> >> ? 3. Omap3430 SDP
>> >>
>> >> ? 4. Omap4 Blaze
>> >>
>> >> ? Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>> >
>> > Thanks. ?It's also important to ascertain which filesystems were tested -
>> > could you let me know please?
>> >
>>
>> It is a custom filesystem on BusyBox v1.17.2.
>
> So you wrote code under fs/ for this filesystem?

No.

>> Please let me know if you need some other
>> information.
>
> I'm trying to find out what _type_ of filesystem. ?ext2, ext3, nfs, cramfs,
> etc.
>

nfs filesystem.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-24 14:54                     ` Poddar, Sourav
@ 2011-01-24 15:00                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 15:00 UTC (permalink / raw)
  To: Poddar, Sourav; +Cc: Nicolas Pitre, linux-arm-kernel, linux-omap

On Mon, Jan 24, 2011 at 08:24:41PM +0530, Poddar, Sourav wrote:
> nfs filesystem.

Thanks.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-24 15:00                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-24 15:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 24, 2011 at 08:24:41PM +0530, Poddar, Sourav wrote:
> nfs filesystem.

Thanks.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-23  0:16     ` Russell King - ARM Linux
  (?)
  (?)
@ 2011-01-25 13:57     ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-25 13:57 UTC (permalink / raw)
  To: 'Russell King - ARM Linux', linux-arm-kernel, linux-omap

Hi Russell,

Hopefully this isn't too late to be useful.

> On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > Switch the set/clear/change bitops to use the word-based exclusive
> > operations, which are only present in a wider range of ARM architectures
> > than the byte-based exclusive operations.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> As only one person replied to this patch with test information, I'm
> not happy to push this into -rc, and hence that prevents it going into
> -stable too.  That means omap2plus_defconfig .38 mainline kernels
> (including -stable) will remain potentially dangerous when run on
> SMP capable hardware.
> 
> Therefore, I see no alternative at the moment but to purposely cause
> builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> data corruption.
> 
> Please get your tested-by's to me for at least the first three patches
> of this series ASAP.

I've tested this on the Versatile Express (ca9x4, little endian) with a USB
hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
file containing random data whilst the system was fairly loaded. File checksums
all passed and the kernel didn't do anything untowards.

Tested-by: Will Deacon <will.deacon@arm.com>

I appreciate this is the same test configuration as the one Nicolas did,
but it at least replicates his findings.

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-23  0:16     ` Russell King - ARM Linux
                       ` (2 preceding siblings ...)
  (?)
@ 2011-01-25 13:57     ` Will Deacon
  2011-01-25 14:11         ` Russell King - ARM Linux
  -1 siblings, 1 reply; 254+ messages in thread
From: Will Deacon @ 2011-01-25 13:57 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Russell,

Hopefully this isn't too late to be useful.

> On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > Switch the set/clear/change bitops to use the word-based exclusive
> > operations, which are only present in a wider range of ARM architectures
> > than the byte-based exclusive operations.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> As only one person replied to this patch with test information, I'm
> not happy to push this into -rc, and hence that prevents it going into
> -stable too.  That means omap2plus_defconfig .38 mainline kernels
> (including -stable) will remain potentially dangerous when run on
> SMP capable hardware.
> 
> Therefore, I see no alternative at the moment but to purposely cause
> builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> data corruption.
> 
> Please get your tested-by's to me for at least the first three patches
> of this series ASAP.

I've tested this on the Versatile Express (ca9x4, little endian) with a USB
hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
file containing random data whilst the system was fairly loaded. File checksums
all passed and the kernel didn't do anything untowards.

Tested-by: Will Deacon <will.deacon@arm.com>

I appreciate this is the same test configuration as the one Nicolas did,
but it at least replicates his findings.

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-25 13:57     ` Will Deacon
@ 2011-01-25 14:11         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 14:11 UTC (permalink / raw)
  To: Will Deacon; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 25, 2011 at 01:57:26PM -0000, Will Deacon wrote:
> Hi Russell,
> 
> Hopefully this isn't too late to be useful.
> 
> > On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > > Switch the set/clear/change bitops to use the word-based exclusive
> > > operations, which are only present in a wider range of ARM architectures
> > > than the byte-based exclusive operations.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > As only one person replied to this patch with test information, I'm
> > not happy to push this into -rc, and hence that prevents it going into
> > -stable too.  That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> > 
> > Therefore, I see no alternative at the moment but to purposely cause
> > builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> > data corruption.
> > 
> > Please get your tested-by's to me for at least the first three patches
> > of this series ASAP.
> 
> I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> file containing random data whilst the system was fairly loaded. File checksums
> all passed and the kernel didn't do anything untowards.
> 
> Tested-by: Will Deacon <will.deacon@arm.com>
> 
> I appreciate this is the same test configuration as the one Nicolas did,
> but it at least replicates his findings.

Was this for just the first three or the complete set?

Thanks.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-25 14:11         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 14:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 25, 2011 at 01:57:26PM -0000, Will Deacon wrote:
> Hi Russell,
> 
> Hopefully this isn't too late to be useful.
> 
> > On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > > Switch the set/clear/change bitops to use the word-based exclusive
> > > operations, which are only present in a wider range of ARM architectures
> > > than the byte-based exclusive operations.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > As only one person replied to this patch with test information, I'm
> > not happy to push this into -rc, and hence that prevents it going into
> > -stable too.  That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> > 
> > Therefore, I see no alternative at the moment but to purposely cause
> > builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> > data corruption.
> > 
> > Please get your tested-by's to me for at least the first three patches
> > of this series ASAP.
> 
> I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> file containing random data whilst the system was fairly loaded. File checksums
> all passed and the kernel didn't do anything untowards.
> 
> Tested-by: Will Deacon <will.deacon@arm.com>
> 
> I appreciate this is the same test configuration as the one Nicolas did,
> but it at least replicates his findings.

Was this for just the first three or the complete set?

Thanks.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-25 14:11         ` Russell King - ARM Linux
  (?)
  (?)
@ 2011-01-25 14:19         ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-25 14:19 UTC (permalink / raw)
  To: 'Russell King - ARM Linux'; +Cc: linux-omap, linux-arm-kernel

> > I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> > hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> > file containing random data whilst the system was fairly loaded. File checksums
> > all passed and the kernel didn't do anything untowards.
> >
> > Tested-by: Will Deacon <will.deacon@arm.com>
> >
> > I appreciate this is the same test configuration as the one Nicolas did,
> > but it at least replicates his findings.
> 
> Was this for just the first three or the complete set?

This was for your -devel branch as of last night (head 75c4aa97).
If I try to extract patches from the mailing list, Exchange destroys
them :(

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-25 14:11         ` Russell King - ARM Linux
  (?)
@ 2011-01-25 14:19         ` Will Deacon
  -1 siblings, 0 replies; 254+ messages in thread
From: Will Deacon @ 2011-01-25 14:19 UTC (permalink / raw)
  To: linux-arm-kernel

> > I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> > hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> > file containing random data whilst the system was fairly loaded. File checksums
> > all passed and the kernel didn't do anything untowards.
> >
> > Tested-by: Will Deacon <will.deacon@arm.com>
> >
> > I appreciate this is the same test configuration as the one Nicolas did,
> > but it at least replicates his findings.
> 
> Was this for just the first three or the complete set?

This was for your -devel branch as of last night (head 75c4aa97).
If I try to extract patches from the mailing list, Exchange destroys
them :(

Will

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-17 19:22   ` Russell King - ARM Linux
@ 2011-01-25 16:43     ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-25 16:43 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

Hi there,

On Mon, Jan 17, 2011 at 7:22 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> SMP requires at least the ARMv6K extensions to be present, so if we're
> running on SMP, the WFE and SEV instructions must be available.
>
> However, when we run on UP, the v6K extensions may not be available,
> and so we don't want WFE/SEV to be in the instruction stream.  Use the
> SMP alternatives infrastructure to replace these instructions with NOPs
> if we build for SMP but run on UP.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/include/asm/spinlock.h |   37 +++++++++++++++++++++++++------------
>  1 files changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 17eb355..da1af52 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,17 +5,36 @@
>  #error SMP not supported on pre-ARMv6 CPUs
>  #endif
>
> +/*
> + * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> + * extensions, so when running on UP, we have to patch these instructions away.
> + */
> +#define ALT_SMP(smp, up)                                       \
> +       "9998:  " smp "\n"                                      \
> +       "       .pushsection \".alt.smp.init\", \"a\"\n"        \
> +       "       .long   9998b\n"                                \
> +       "       " up "\n"                                       \
> +       "       .popsection\n"
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define SEV            ALT_SMP("sev.w", "nop.w")
> +#define WFE(cond)      ALT_SMP("wfe" cond ".w", "nop.w")
> +#else
> +#define SEV            ALT_SMP("sev", "nop")
> +#define WFE(cond)      ALT_SMP("wfe" cond, "nop")
> +#endif
> +
>  static inline void dsb_sev(void)
>  {
>  #if __LINUX_ARM_ARCH__ >= 7
>        __asm__ __volatile__ (
>                "dsb\n"
> -               "sev"
> +               SEV
>        );
> -#elif defined(CONFIG_CPU_32v6K)
> +#else
>        __asm__ __volatile__ (
>                "mcr p15, 0, %0, c7, c10, 4\n"
> -               "sev"
> +               SEV
>                : : "r" (0)
>        );
>  #endif
> @@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>        __asm__ __volatile__(
>  "1:    ldrex   %0, [%1]\n"
>  "      teq     %0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"      wfene\n"
> -#endif
> +       WFE("ne")
>  "      strexeq %0, %2, [%1]\n"
>  "      teqeq   %0, #0\n"
>  "      bne     1b"
> @@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>        __asm__ __volatile__(
>  "1:    ldrex   %0, [%1]\n"
>  "      teq     %0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -"      wfene\n"
> -#endif
> +       WFE("ne")
>  "      strexeq %0, %2, [%1]\n"
>  "      teq     %0, #0\n"
>  "      bne     1b"
> @@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
>  "1:    ldrex   %0, [%2]\n"
>  "      adds    %0, %0, #1\n"
>  "      strexpl %1, %0, [%2]\n"
> -#ifdef CONFIG_CPU_32v6K
> -"      wfemi\n"
> -#endif
> +       WFE("mi")
>  "      rsbpls  %0, %1, #0\n"
>  "      bmi     1b"
>        : "=&r" (tmp), "=&r" (tmp2)
> --
> 1.6.2.5

A couple of questions on this:

1) I notice these spinlock functions are generally marked inline.

Is that likely to happen in modules?  If so, there would be a need to
do SMP_ON_UP fixups at module load time -- I don't think that's
currently implemented.

2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
vmlinux link errors like this:

  LD      .tmp_vmlinux1
`.exit.text' referenced in section `.alt.smp.init' of
drivers/built-in.o: defined in discarded section `.exit.text' of
drivers/built-in.o
make: *** [.tmp_vmlinux1] Error 1

I don't know whether this is caused by the patch directly or as a
side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
git bisect indentified this above patch as the first one with the
error in that case.

I don't understand the section discarding logic too well, so I'm not
sure how to fix it for now...

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-25 16:43     ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-25 16:43 UTC (permalink / raw)
  To: linux-arm-kernel

Hi there,

On Mon, Jan 17, 2011 at 7:22 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> SMP requires at least the ARMv6K extensions to be present, so if we're
> running on SMP, the WFE and SEV instructions must be available.
>
> However, when we run on UP, the v6K extensions may not be available,
> and so we don't want WFE/SEV to be in the instruction stream. ?Use the
> SMP alternatives infrastructure to replace these instructions with NOPs
> if we build for SMP but run on UP.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> ?arch/arm/include/asm/spinlock.h | ? 37 +++++++++++++++++++++++++------------
> ?1 files changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 17eb355..da1af52 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,17 +5,36 @@
> ?#error SMP not supported on pre-ARMv6 CPUs
> ?#endif
>
> +/*
> + * sev and wfe are ARMv6K extensions. ?Uniprocessor ARMv6 may not have the K
> + * extensions, so when running on UP, we have to patch these instructions away.
> + */
> +#define ALT_SMP(smp, up) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? "9998: ?" smp "\n" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? " ? ? ? .pushsection \".alt.smp.init\", \"a\"\n" ? ? ? ?\
> + ? ? ? " ? ? ? .long ? 9998b\n" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? " ? ? ? " up "\n" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? " ? ? ? .popsection\n"
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define SEV ? ? ? ? ? ?ALT_SMP("sev.w", "nop.w")
> +#define WFE(cond) ? ? ?ALT_SMP("wfe" cond ".w", "nop.w")
> +#else
> +#define SEV ? ? ? ? ? ?ALT_SMP("sev", "nop")
> +#define WFE(cond) ? ? ?ALT_SMP("wfe" cond, "nop")
> +#endif
> +
> ?static inline void dsb_sev(void)
> ?{
> ?#if __LINUX_ARM_ARCH__ >= 7
> ? ? ? ?__asm__ __volatile__ (
> ? ? ? ? ? ? ? ?"dsb\n"
> - ? ? ? ? ? ? ? "sev"
> + ? ? ? ? ? ? ? SEV
> ? ? ? ?);
> -#elif defined(CONFIG_CPU_32v6K)
> +#else
> ? ? ? ?__asm__ __volatile__ (
> ? ? ? ? ? ? ? ?"mcr p15, 0, %0, c7, c10, 4\n"
> - ? ? ? ? ? ? ? "sev"
> + ? ? ? ? ? ? ? SEV
> ? ? ? ? ? ? ? ?: : "r" (0)
> ? ? ? ?);
> ?#endif
> @@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> ? ? ? ?__asm__ __volatile__(
> ?"1: ? ?ldrex ? %0, [%1]\n"
> ?" ? ? ?teq ? ? %0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -" ? ? ?wfene\n"
> -#endif
> + ? ? ? WFE("ne")
> ?" ? ? ?strexeq %0, %2, [%1]\n"
> ?" ? ? ?teqeq ? %0, #0\n"
> ?" ? ? ?bne ? ? 1b"
> @@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
> ? ? ? ?__asm__ __volatile__(
> ?"1: ? ?ldrex ? %0, [%1]\n"
> ?" ? ? ?teq ? ? %0, #0\n"
> -#ifdef CONFIG_CPU_32v6K
> -" ? ? ?wfene\n"
> -#endif
> + ? ? ? WFE("ne")
> ?" ? ? ?strexeq %0, %2, [%1]\n"
> ?" ? ? ?teq ? ? %0, #0\n"
> ?" ? ? ?bne ? ? 1b"
> @@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
> ?"1: ? ?ldrex ? %0, [%2]\n"
> ?" ? ? ?adds ? ?%0, %0, #1\n"
> ?" ? ? ?strexpl %1, %0, [%2]\n"
> -#ifdef CONFIG_CPU_32v6K
> -" ? ? ?wfemi\n"
> -#endif
> + ? ? ? WFE("mi")
> ?" ? ? ?rsbpls ?%0, %1, #0\n"
> ?" ? ? ?bmi ? ? 1b"
> ? ? ? ?: "=&r" (tmp), "=&r" (tmp2)
> --
> 1.6.2.5

A couple of questions on this:

1) I notice these spinlock functions are generally marked inline.

Is that likely to happen in modules?  If so, there would be a need to
do SMP_ON_UP fixups at module load time -- I don't think that's
currently implemented.

2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
vmlinux link errors like this:

  LD      .tmp_vmlinux1
`.exit.text' referenced in section `.alt.smp.init' of
drivers/built-in.o: defined in discarded section `.exit.text' of
drivers/built-in.o
make: *** [.tmp_vmlinux1] Error 1

I don't know whether this is caused by the patch directly or as a
side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
git bisect indentified this above patch as the first one with the
error in that case.

I don't understand the section discarding logic too well, so I'm not
sure how to fix it for now...

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-25 16:43     ` Dave Martin
@ 2011-01-25 16:59       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 16:59 UTC (permalink / raw)
  To: Dave Martin; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> A couple of questions on this:
> 
> 1) I notice these spinlock functions are generally marked inline.
> 
> Is that likely to happen in modules?  If so, there would be a need to
> do SMP_ON_UP fixups at module load time -- I don't think that's
> currently implemented.

No one should be using the arch_* spinlocks directly.  The spinlocks
are implemented in out of line code in kernel/spinlock.c

> 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
> vmlinux link errors like this:
> 
>   LD      .tmp_vmlinux1
> `.exit.text' referenced in section `.alt.smp.init' of
> drivers/built-in.o: defined in discarded section `.exit.text' of
> drivers/built-in.o
> make: *** [.tmp_vmlinux1] Error 1
> 
> I don't know whether this is caused by the patch directly or as a
> side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
> git bisect indentified this above patch as the first one with the
> error in that case.
> 
> I don't understand the section discarding logic too well, so I'm not
> sure how to fix it for now...

Hmm.  I don't see how that could happen, unless some driver is going
behind the spinlock APIs, or using our dsb_sev() directly.

I think you need to first track down what's responsible for inserting
architecture spinlock code into drivers.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-25 16:59       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 16:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> A couple of questions on this:
> 
> 1) I notice these spinlock functions are generally marked inline.
> 
> Is that likely to happen in modules?  If so, there would be a need to
> do SMP_ON_UP fixups at module load time -- I don't think that's
> currently implemented.

No one should be using the arch_* spinlocks directly.  The spinlocks
are implemented in out of line code in kernel/spinlock.c

> 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
> vmlinux link errors like this:
> 
>   LD      .tmp_vmlinux1
> `.exit.text' referenced in section `.alt.smp.init' of
> drivers/built-in.o: defined in discarded section `.exit.text' of
> drivers/built-in.o
> make: *** [.tmp_vmlinux1] Error 1
> 
> I don't know whether this is caused by the patch directly or as a
> side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
> git bisect indentified this above patch as the first one with the
> error in that case.
> 
> I don't understand the section discarding logic too well, so I'm not
> sure how to fix it for now...

Hmm.  I don't see how that could happen, unless some driver is going
behind the spinlock APIs, or using our dsb_sev() directly.

I think you need to first track down what's responsible for inserting
architecture spinlock code into drivers.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-25 16:59       ` Russell King - ARM Linux
@ 2011-01-25 17:33         ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-25 17:33 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
>> A couple of questions on this:
>>
>> 1) I notice these spinlock functions are generally marked inline.
>>
>> Is that likely to happen in modules?  If so, there would be a need to
>> do SMP_ON_UP fixups at module load time -- I don't think that's
>> currently implemented.
>
> No one should be using the arch_* spinlocks directly.  The spinlocks
> are implemented in out of line code in kernel/spinlock.c

OK--- do think this is something we need a sanity-check for, or does
this fall into to a category of bad driver implementation which will
get thrown out during peer review?

>
>> 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
>> vmlinux link errors like this:
>>
>>   LD      .tmp_vmlinux1
>> `.exit.text' referenced in section `.alt.smp.init' of
>> drivers/built-in.o: defined in discarded section `.exit.text' of
>> drivers/built-in.o
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> I don't know whether this is caused by the patch directly or as a
>> side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
>> git bisect indentified this above patch as the first one with the
>> error in that case.
>>
>> I don't understand the section discarding logic too well, so I'm not
>> sure how to fix it for now...
>
> Hmm.  I don't see how that could happen, unless some driver is going
> behind the spinlock APIs, or using our dsb_sev() directly.
>
> I think you need to first track down what's responsible for inserting
> architecture spinlock code into drivers.
>

OK, I'll try and do a bit more digging.  I think I have a better idea
of what to look for now, anyhow.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-25 17:33         ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-25 17:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
>> A couple of questions on this:
>>
>> 1) I notice these spinlock functions are generally marked inline.
>>
>> Is that likely to happen in modules? ?If so, there would be a need to
>> do SMP_ON_UP fixups at module load time -- I don't think that's
>> currently implemented.
>
> No one should be using the arch_* spinlocks directly. ?The spinlocks
> are implemented in out of line code in kernel/spinlock.c

OK--- do think this is something we need a sanity-check for, or does
this fall into to a category of bad driver implementation which will
get thrown out during peer review?

>
>> 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
>> vmlinux link errors like this:
>>
>> ? LD ? ? ?.tmp_vmlinux1
>> `.exit.text' referenced in section `.alt.smp.init' of
>> drivers/built-in.o: defined in discarded section `.exit.text' of
>> drivers/built-in.o
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> I don't know whether this is caused by the patch directly or as a
>> side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
>> git bisect indentified this above patch as the first one with the
>> error in that case.
>>
>> I don't understand the section discarding logic too well, so I'm not
>> sure how to fix it for now...
>
> Hmm. ?I don't see how that could happen, unless some driver is going
> behind the spinlock APIs, or using our dsb_sev() directly.
>
> I think you need to first track down what's responsible for inserting
> architecture spinlock code into drivers.
>

OK, I'll try and do a bit more digging.  I think I have a better idea
of what to look for now, anyhow.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-25 17:33         ` Dave Martin
@ 2011-01-25 17:46           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 17:46 UTC (permalink / raw)
  To: Dave Martin; +Cc: linux-arm-kernel, linux-omap

On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
> On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> >> A couple of questions on this:
> >>
> >> 1) I notice these spinlock functions are generally marked inline.
> >>
> >> Is that likely to happen in modules?  If so, there would be a need to
> >> do SMP_ON_UP fixups at module load time -- I don't think that's
> >> currently implemented.
> >
> > No one should be using the arch_* spinlocks directly.  The spinlocks
> > are implemented in out of line code in kernel/spinlock.c
> 
> OK--- do think this is something we need a sanity-check for, or does
> this fall into to a category of bad driver implementation which will
> get thrown out during peer review?

Hmm, actually it looks like you can end up with configurations where the
spinlocks are inlined.

That means we'll have to get rid of the link-time discarding of the
.exit sections, and discard them along with the .init sections.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-25 17:46           ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-25 17:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
> On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> >> A couple of questions on this:
> >>
> >> 1) I notice these spinlock functions are generally marked inline.
> >>
> >> Is that likely to happen in modules? ?If so, there would be a need to
> >> do SMP_ON_UP fixups at module load time -- I don't think that's
> >> currently implemented.
> >
> > No one should be using the arch_* spinlocks directly. ?The spinlocks
> > are implemented in out of line code in kernel/spinlock.c
> 
> OK--- do think this is something we need a sanity-check for, or does
> this fall into to a category of bad driver implementation which will
> get thrown out during peer review?

Hmm, actually it looks like you can end up with configurations where the
spinlocks are inlined.

That means we'll have to get rid of the link-time discarding of the
.exit sections, and discard them along with the .init sections.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
  2011-01-17 19:21   ` Russell King - ARM Linux
@ 2011-01-25 19:50     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-25 19:50 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:20]:
> Add additional instructions to our assembly bitops functions to ensure
> that they only operate on word-aligned pointers.  This will be necessary
> when we switch these operations to use the word-based exclusive
> operations.

If it's still not too late, we've had this in the testing branch
in the linux-omap tree for about a week now. So far no problems,
for me file systems tested have been ext3 and nfs.

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
@ 2011-01-25 19:50     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-25 19:50 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:20]:
> Add additional instructions to our assembly bitops functions to ensure
> that they only operate on word-aligned pointers.  This will be necessary
> when we switch these operations to use the word-based exclusive
> operations.

If it's still not too late, we've had this in the testing branch
in the linux-omap tree for about a week now. So far no problems,
for me file systems tested have been ext3 and nfs.

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
  2011-01-17 19:21   ` Russell King - ARM Linux
@ 2011-01-25 19:51     ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-25 19:51 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.

This too been in use for about a week now with ext3 and nfs:

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-25 19:51     ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-25 19:51 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110117 11:23]:
> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.

This too been in use for about a week now with ext3 and nfs:

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-25 17:46           ` Russell King - ARM Linux
@ 2011-01-25 21:21             ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-25 21:21 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Dave Martin, linux-omap, linux-arm-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1209 bytes --]

On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
> > On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> > >> A couple of questions on this:
> > >>
> > >> 1) I notice these spinlock functions are generally marked inline.
> > >>
> > >> Is that likely to happen in modules?  If so, there would be a need to
> > >> do SMP_ON_UP fixups at module load time -- I don't think that's
> > >> currently implemented.
> > >
> > > No one should be using the arch_* spinlocks directly.  The spinlocks
> > > are implemented in out of line code in kernel/spinlock.c
> > 
> > OK--- do think this is something we need a sanity-check for, or does
> > this fall into to a category of bad driver implementation which will
> > get thrown out during peer review?
> 
> Hmm, actually it looks like you can end up with configurations where the
> spinlocks are inlined.
> 
> That means we'll have to get rid of the link-time discarding of the
> .exit sections, and discard them along with the .init sections.

... but only when CONFIG_SMP_ON_UP=y.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-25 21:21             ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-25 21:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
> > On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
> > >> A couple of questions on this:
> > >>
> > >> 1) I notice these spinlock functions are generally marked inline.
> > >>
> > >> Is that likely to happen in modules? ?If so, there would be a need to
> > >> do SMP_ON_UP fixups at module load time -- I don't think that's
> > >> currently implemented.
> > >
> > > No one should be using the arch_* spinlocks directly. ?The spinlocks
> > > are implemented in out of line code in kernel/spinlock.c
> > 
> > OK--- do think this is something we need a sanity-check for, or does
> > this fall into to a category of bad driver implementation which will
> > get thrown out during peer review?
> 
> Hmm, actually it looks like you can end up with configurations where the
> spinlocks are inlined.
> 
> That means we'll have to get rid of the link-time discarding of the
> .exit sections, and discard them along with the .init sections.

... but only when CONFIG_SMP_ON_UP=y.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
       [not found]     ` <000601cbbc97$cc6955d0$653c0170$%deacon@arm.com>
@ 2011-01-25 21:38         ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-25 21:38 UTC (permalink / raw)
  To: Will Deacon
  Cc: 'Russell King - ARM Linux', linux-arm-kernel, linux-omap

On Tue, 25 Jan 2011, Will Deacon wrote:

> Hi Russell,
> 
> Hopefully this isn't too late to be useful.
> 
> > On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > > Switch the set/clear/change bitops to use the word-based exclusive
> > > operations, which are only present in a wider range of ARM architectures
> > > than the byte-based exclusive operations.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > As only one person replied to this patch with test information, I'm
> > not happy to push this into -rc, and hence that prevents it going into
> > -stable too.  That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> > 
> > Therefore, I see no alternative at the moment but to purposely cause
> > builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> > data corruption.
> > 
> > Please get your tested-by's to me for at least the first three patches
> > of this series ASAP.
> 
> I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> file containing random data whilst the system was fairly loaded. File checksums
> all passed and the kernel didn't do anything untowards.
> 
> Tested-by: Will Deacon <will.deacon@arm.com>
> 
> I appreciate this is the same test configuration as the one Nicolas did,
> but it at least replicates his findings.

Well, I did run parallel instances of the git test suite on a Dove board 
using the sata_mv driver.  Therefore this is still a significant
difference in configuration which is good.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
@ 2011-01-25 21:38         ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-25 21:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 25 Jan 2011, Will Deacon wrote:

> Hi Russell,
> 
> Hopefully this isn't too late to be useful.
> 
> > On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > > Switch the set/clear/change bitops to use the word-based exclusive
> > > operations, which are only present in a wider range of ARM architectures
> > > than the byte-based exclusive operations.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > As only one person replied to this patch with test information, I'm
> > not happy to push this into -rc, and hence that prevents it going into
> > -stable too.  That means omap2plus_defconfig .38 mainline kernels
> > (including -stable) will remain potentially dangerous when run on
> > SMP capable hardware.
> > 
> > Therefore, I see no alternative at the moment but to purposely cause
> > builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from
> > data corruption.
> > 
> > Please get your tested-by's to me for at least the first three patches
> > of this series ASAP.
> 
> I've tested this on the Versatile Express (ca9x4, little endian) with a USB
> hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB
> file containing random data whilst the system was fairly loaded. File checksums
> all passed and the kernel didn't do anything untowards.
> 
> Tested-by: Will Deacon <will.deacon@arm.com>
> 
> I appreciate this is the same test configuration as the one Nicolas did,
> but it at least replicates his findings.

Well, I did run parallel instances of the git test suite on a Dove board 
using the sata_mv driver.  Therefore this is still a significant
difference in configuration which is good.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-25 21:21             ` Nicolas Pitre
@ 2011-01-26 11:11               ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-26 11:11 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Tue, Jan 25, 2011 at 9:21 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
>> > On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> > > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
>> > >> A couple of questions on this:
>> > >>
>> > >> 1) I notice these spinlock functions are generally marked inline.
>> > >>
>> > >> Is that likely to happen in modules?  If so, there would be a need to
>> > >> do SMP_ON_UP fixups at module load time -- I don't think that's
>> > >> currently implemented.
>> > >
>> > > No one should be using the arch_* spinlocks directly.  The spinlocks
>> > > are implemented in out of line code in kernel/spinlock.c
>> >
>> > OK--- do think this is something we need a sanity-check for, or does
>> > this fall into to a category of bad driver implementation which will
>> > get thrown out during peer review?
>>
>> Hmm, actually it looks like you can end up with configurations where the
>> spinlocks are inlined.
>>
>> That means we'll have to get rid of the link-time discarding of the
>> .exit sections, and discard them along with the .init sections.
>
> ... but only when CONFIG_SMP_ON_UP=y.
>
>
> Nicolas

Do we need to consider any other discarded sections?  In vmlinux.lds, I have:

 /* Default discards */
 /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
*(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
*(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }


Alternatively, I wonder .alt.smp.init could make weak references
instead of normal references: then if the referenced section is
discarded, the reference will revert to 0 and the fixup code can
ignore it (at the expense of wasting a bit of space in the fixup table
... but it's no worse than the current situation).  From
experimentation, it seems this doesn't work if the referenced symbol
is defined in the same file, since the linker resolves the reference
before discarding sections, but maybe there's a way around it...

This does rely on generating a globally unique symbol name for every
fixup ... we can come close using KBUILD_MODNAME, __LINE__ and/or the
assembler macro widget \@.  But I think that KBUILD_MODNAME doesn't
take the file path into account so may not really be globally unique.

If we put every fixup in its own _section_ we might be able to
collapse those out of the list at link time too.  However, that seems
hard to achieve, since in order to do the correct link-time filtering
we would need the fixup's section name to be based on the referenced
section's name ... due to preprocessor limitations I don't think we
can do that automatically (and manual maintenance would be a bad
plan).

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 11:11               ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-26 11:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 25, 2011 at 9:21 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
>> > On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> > > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
>> > >> A couple of questions on this:
>> > >>
>> > >> 1) I notice these spinlock functions are generally marked inline.
>> > >>
>> > >> Is that likely to happen in modules? ?If so, there would be a need to
>> > >> do SMP_ON_UP fixups at module load time -- I don't think that's
>> > >> currently implemented.
>> > >
>> > > No one should be using the arch_* spinlocks directly. ?The spinlocks
>> > > are implemented in out of line code in kernel/spinlock.c
>> >
>> > OK--- do think this is something we need a sanity-check for, or does
>> > this fall into to a category of bad driver implementation which will
>> > get thrown out during peer review?
>>
>> Hmm, actually it looks like you can end up with configurations where the
>> spinlocks are inlined.
>>
>> That means we'll have to get rid of the link-time discarding of the
>> .exit sections, and discard them along with the .init sections.
>
> ... but only when CONFIG_SMP_ON_UP=y.
>
>
> Nicolas

Do we need to consider any other discarded sections?  In vmlinux.lds, I have:

 /* Default discards */
 /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
*(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
*(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }


Alternatively, I wonder .alt.smp.init could make weak references
instead of normal references: then if the referenced section is
discarded, the reference will revert to 0 and the fixup code can
ignore it (at the expense of wasting a bit of space in the fixup table
... but it's no worse than the current situation).  From
experimentation, it seems this doesn't work if the referenced symbol
is defined in the same file, since the linker resolves the reference
before discarding sections, but maybe there's a way around it...

This does rely on generating a globally unique symbol name for every
fixup ... we can come close using KBUILD_MODNAME, __LINE__ and/or the
assembler macro widget \@.  But I think that KBUILD_MODNAME doesn't
take the file path into account so may not really be globally unique.

If we put every fixup in its own _section_ we might be able to
collapse those out of the list at link time too.  However, that seems
hard to achieve, since in order to do the correct link-time filtering
we would need the fixup's section name to be based on the referenced
section's name ... due to preprocessor limitations I don't think we
can do that automatically (and manual maintenance would be a bad
plan).

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 11:11               ` Dave Martin
@ 2011-01-26 12:44                 ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-26 12:44 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 11:11:31AM +0000, Dave Martin wrote:
> Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> 
>  /* Default discards */
>  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }

We need to keep all the text exit stuff, and that could well want
data exit stuff, so I think we need ot keep most of that.  Maybe not
the .discard* stuff though.

> If we put every fixup in its own _section_ we might be able to
> collapse those out of the list at link time too.  However, that seems
> hard to achieve, since in order to do the correct link-time filtering
> we would need the fixup's section name to be based on the referenced
> section's name ... due to preprocessor limitations I don't think we
> can do that automatically (and manual maintenance would be a bad
> plan).

I suspect if it was sanely possible to do, then x86 would already be
doing it as they've had this problem for a lot longer than we have.
It might be worth talking to toolchain people to see if it can be made
to work somehow - but we really don't want to get rid of all discarded
section warnings.

IOW, if we have a text segment which is included in the image and it
references discarded .exit text, we really do want it to fail at link
time.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 12:44                 ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-26 12:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 11:11:31AM +0000, Dave Martin wrote:
> Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> 
>  /* Default discards */
>  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }

We need to keep all the text exit stuff, and that could well want
data exit stuff, so I think we need ot keep most of that.  Maybe not
the .discard* stuff though.

> If we put every fixup in its own _section_ we might be able to
> collapse those out of the list at link time too.  However, that seems
> hard to achieve, since in order to do the correct link-time filtering
> we would need the fixup's section name to be based on the referenced
> section's name ... due to preprocessor limitations I don't think we
> can do that automatically (and manual maintenance would be a bad
> plan).

I suspect if it was sanely possible to do, then x86 would already be
doing it as they've had this problem for a lot longer than we have.
It might be worth talking to toolchain people to see if it can be made
to work somehow - but we really don't want to get rid of all discarded
section warnings.

IOW, if we have a text segment which is included in the image and it
references discarded .exit text, we really do want it to fail at link
time.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 11:11               ` Dave Martin
@ 2011-01-26 15:42                 ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 15:42 UTC (permalink / raw)
  To: Dave Martin; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Wed, 26 Jan 2011, Dave Martin wrote:

> On Tue, Jan 25, 2011 at 9:21 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> >
> >> Hmm, actually it looks like you can end up with configurations where the
> >> spinlocks are inlined.
> >>
> >> That means we'll have to get rid of the link-time discarding of the
> >> .exit sections, and discard them along with the .init sections.
> >
> > ... but only when CONFIG_SMP_ON_UP=y.
> 
> Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> 
>  /* Default discards */
>  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }
> 
> 
> Alternatively, I wonder .alt.smp.init could make weak references
> instead of normal references: then if the referenced section is
> discarded, the reference will revert to 0 and the fixup code can
> ignore it (at the expense of wasting a bit of space in the fixup table
> ... but it's no worse than the current situation).  From
> experimentation, it seems this doesn't work if the referenced symbol
> is defined in the same file, since the linker resolves the reference
> before discarding sections, but maybe there's a way around it...

That's strange.  How can the linker resolve the reference if the 
referenced symbol is not in the same section as the reference source?  
What happens when the final link completes?


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 15:42                 ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 15:42 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 26 Jan 2011, Dave Martin wrote:

> On Tue, Jan 25, 2011 at 9:21 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> >
> >> Hmm, actually it looks like you can end up with configurations where the
> >> spinlocks are inlined.
> >>
> >> That means we'll have to get rid of the link-time discarding of the
> >> .exit sections, and discard them along with the .init sections.
> >
> > ... but only when CONFIG_SMP_ON_UP=y.
> 
> Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> 
>  /* Default discards */
>  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }
> 
> 
> Alternatively, I wonder .alt.smp.init could make weak references
> instead of normal references: then if the referenced section is
> discarded, the reference will revert to 0 and the fixup code can
> ignore it (at the expense of wasting a bit of space in the fixup table
> ... but it's no worse than the current situation).  From
> experimentation, it seems this doesn't work if the referenced symbol
> is defined in the same file, since the linker resolves the reference
> before discarding sections, but maybe there's a way around it...

That's strange.  How can the linker resolve the reference if the 
referenced symbol is not in the same section as the reference source?  
What happens when the final link completes?


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 15:42                 ` Nicolas Pitre
@ 2011-01-26 15:52                   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-26 15:52 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Dave Martin, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 10:42:41AM -0500, Nicolas Pitre wrote:
> On Wed, 26 Jan 2011, Dave Martin wrote:
> > Alternatively, I wonder .alt.smp.init could make weak references
> > instead of normal references: then if the referenced section is
> > discarded, the reference will revert to 0 and the fixup code can
> > ignore it (at the expense of wasting a bit of space in the fixup table
> > ... but it's no worse than the current situation).  From
> > experimentation, it seems this doesn't work if the referenced symbol
> > is defined in the same file, since the linker resolves the reference
> > before discarding sections, but maybe there's a way around it...
> 
> That's strange.  How can the linker resolve the reference if the 
> referenced symbol is not in the same section as the reference source?  
> What happens when the final link completes?

$ cat t.s
	.section ".exit.text", "ax", %progbits
	mov	r0, r0
a:	mov	r0, r0

	.pushsection ".alt.smp.fixup", "a"
	.weak	a
	.long	a
	mov	r0, r1
	.popsection
$ arm-linux-as -o t.o t.s
$ arm-linux-nm t.o
00000004 W a
$ arm-linux-objdump -Dr t.o

Disassembly of section .exit.text:

00000000 <a-0x4>:
   0:	e1a00000 	nop			(mov r0,r0)

00000004 <a>:
   4:	e1a00000 	.word	0xe1a00000

Disassembly of section .alt.smp.fixup:

00000000 <.alt.smp.fixup>:
   0:	00000000 	.word	0x00000000
			0: R_ARM_ABS32	a
   4:	e1a00001 	mov	r0, r1

which when linked with:

SECTIONS
{
        .alt.smp.init : { *(.alt.smp.init) }

        /DISCARD/ : { *(.exit.text) }
}

$ arm-linux-ld -T t.lds -r -o t.oo t.o
`a' referenced in section `.alt.smp.fixup' of t.o: defined in discarded section `.exit.text' of t.o

So I don't think weak symbols work like we want them to.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 15:52                   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-26 15:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 10:42:41AM -0500, Nicolas Pitre wrote:
> On Wed, 26 Jan 2011, Dave Martin wrote:
> > Alternatively, I wonder .alt.smp.init could make weak references
> > instead of normal references: then if the referenced section is
> > discarded, the reference will revert to 0 and the fixup code can
> > ignore it (at the expense of wasting a bit of space in the fixup table
> > ... but it's no worse than the current situation).  From
> > experimentation, it seems this doesn't work if the referenced symbol
> > is defined in the same file, since the linker resolves the reference
> > before discarding sections, but maybe there's a way around it...
> 
> That's strange.  How can the linker resolve the reference if the 
> referenced symbol is not in the same section as the reference source?  
> What happens when the final link completes?

$ cat t.s
	.section ".exit.text", "ax", %progbits
	mov	r0, r0
a:	mov	r0, r0

	.pushsection ".alt.smp.fixup", "a"
	.weak	a
	.long	a
	mov	r0, r1
	.popsection
$ arm-linux-as -o t.o t.s
$ arm-linux-nm t.o
00000004 W a
$ arm-linux-objdump -Dr t.o

Disassembly of section .exit.text:

00000000 <a-0x4>:
   0:	e1a00000 	nop			(mov r0,r0)

00000004 <a>:
   4:	e1a00000 	.word	0xe1a00000

Disassembly of section .alt.smp.fixup:

00000000 <.alt.smp.fixup>:
   0:	00000000 	.word	0x00000000
			0: R_ARM_ABS32	a
   4:	e1a00001 	mov	r0, r1

which when linked with:

SECTIONS
{
        .alt.smp.init : { *(.alt.smp.init) }

        /DISCARD/ : { *(.exit.text) }
}

$ arm-linux-ld -T t.lds -r -o t.oo t.o
`a' referenced in section `.alt.smp.fixup' of t.o: defined in discarded section `.exit.text' of t.o

So I don't think weak symbols work like we want them to.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 15:52                   ` Russell King - ARM Linux
@ 2011-01-26 16:59                     ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-26 16:59 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 26, 2011 at 10:42:41AM -0500, Nicolas Pitre wrote:
>> On Wed, 26 Jan 2011, Dave Martin wrote:
>> > Alternatively, I wonder .alt.smp.init could make weak references
>> > instead of normal references: then if the referenced section is
>> > discarded, the reference will revert to 0 and the fixup code can
>> > ignore it (at the expense of wasting a bit of space in the fixup table
>> > ... but it's no worse than the current situation).  From
>> > experimentation, it seems this doesn't work if the referenced symbol
>> > is defined in the same file, since the linker resolves the reference
>> > before discarding sections, but maybe there's a way around it...
>>
>> That's strange.  How can the linker resolve the reference if the
>> referenced symbol is not in the same section as the reference source?
>> What happens when the final link completes?
>
> $ cat t.s
>        .section ".exit.text", "ax", %progbits
>        mov     r0, r0
> a:      mov     r0, r0
>
>        .pushsection ".alt.smp.fixup", "a"
>        .weak   a
>        .long   a
>        mov     r0, r1
>        .popsection
> $ arm-linux-as -o t.o t.s
> $ arm-linux-nm t.o
> 00000004 W a
> $ arm-linux-objdump -Dr t.o
>
> Disassembly of section .exit.text:
>
> 00000000 <a-0x4>:
>   0:   e1a00000        nop                     (mov r0,r0)
>
> 00000004 <a>:
>   4:   e1a00000        .word   0xe1a00000
>
> Disassembly of section .alt.smp.fixup:
>
> 00000000 <.alt.smp.fixup>:
>   0:   00000000        .word   0x00000000
>                        0: R_ARM_ABS32  a
>   4:   e1a00001        mov     r0, r1
>
> which when linked with:
>
> SECTIONS
> {
>        .alt.smp.init : { *(.alt.smp.init) }
>
>        /DISCARD/ : { *(.exit.text) }
> }
>
> $ arm-linux-ld -T t.lds -r -o t.oo t.o
> `a' referenced in section `.alt.smp.fixup' of t.o: defined in discarded section `.exit.text' of t.o
>
> So I don't think weak symbols work like we want them to.
>

That was the conclusion I came to also ... the linker seems to resolve
references in each object before discarding sections, so the weak
reference has already become concrete and section discard breaks it.

---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 16:59                     ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-26 16:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 26, 2011 at 10:42:41AM -0500, Nicolas Pitre wrote:
>> On Wed, 26 Jan 2011, Dave Martin wrote:
>> > Alternatively, I wonder .alt.smp.init could make weak references
>> > instead of normal references: then if the referenced section is
>> > discarded, the reference will revert to 0 and the fixup code can
>> > ignore it (at the expense of wasting a bit of space in the fixup table
>> > ... but it's no worse than the current situation). ?From
>> > experimentation, it seems this doesn't work if the referenced symbol
>> > is defined in the same file, since the linker resolves the reference
>> > before discarding sections, but maybe there's a way around it...
>>
>> That's strange. ?How can the linker resolve the reference if the
>> referenced symbol is not in the same section as the reference source?
>> What happens when the final link completes?
>
> $ cat t.s
> ? ? ? ?.section ".exit.text", "ax", %progbits
> ? ? ? ?mov ? ? r0, r0
> a: ? ? ?mov ? ? r0, r0
>
> ? ? ? ?.pushsection ".alt.smp.fixup", "a"
> ? ? ? ?.weak ? a
> ? ? ? ?.long ? a
> ? ? ? ?mov ? ? r0, r1
> ? ? ? ?.popsection
> $ arm-linux-as -o t.o t.s
> $ arm-linux-nm t.o
> 00000004 W a
> $ arm-linux-objdump -Dr t.o
>
> Disassembly of section .exit.text:
>
> 00000000 <a-0x4>:
> ? 0: ? e1a00000 ? ? ? ?nop ? ? ? ? ? ? ? ? ? ? (mov r0,r0)
>
> 00000004 <a>:
> ? 4: ? e1a00000 ? ? ? ?.word ? 0xe1a00000
>
> Disassembly of section .alt.smp.fixup:
>
> 00000000 <.alt.smp.fixup>:
> ? 0: ? 00000000 ? ? ? ?.word ? 0x00000000
> ? ? ? ? ? ? ? ? ? ? ? ?0: R_ARM_ABS32 ?a
> ? 4: ? e1a00001 ? ? ? ?mov ? ? r0, r1
>
> which when linked with:
>
> SECTIONS
> {
> ? ? ? ?.alt.smp.init : { *(.alt.smp.init) }
>
> ? ? ? ?/DISCARD/ : { *(.exit.text) }
> }
>
> $ arm-linux-ld -T t.lds -r -o t.oo t.o
> `a' referenced in section `.alt.smp.fixup' of t.o: defined in discarded section `.exit.text' of t.o
>
> So I don't think weak symbols work like we want them to.
>

That was the conclusion I came to also ... the linker seems to resolve
references in each object before discarding sections, so the weak
reference has already become concrete and section discard breaks it.

---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-01-26 12:44                 ` Russell King - ARM Linux
@ 2011-01-26 17:25                   ` Dave P. Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave P. Martin @ 2011-01-26 17:25 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Dave Martin, Nicolas Pitre, linux-omap, linux-arm-kernel

SMP_ON_UP fixups lead to vmlinux link errors if those sections are
discarded at link-time.  In particular this may happen for built-in
__exit stuff.

This patch modifies the vmlinux linker script to reduce the amount
of discarded sections, and tries to make sure that __exit sections
are kept in.

This is a hack and probably wrong!  Further discussion is needed.  

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---

On Wed, Jan 26, 2011 at 12:44:52PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 11:11:31AM +0000, Dave Martin wrote:
> > Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> > 
> >  /* Default discards */
> >  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> > *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> > *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }
> 
> We need to keep all the text exit stuff, and that could well want
> data exit stuff, so I think we need ot keep most of that.  Maybe not
> the .discard* stuff though.
> 
> > If we put every fixup in its own _section_ we might be able to
> > collapse those out of the list at link time too.  However, that seems
> > hard to achieve, since in order to do the correct link-time filtering
> > we would need the fixup's section name to be based on the referenced
> > section's name ... due to preprocessor limitations I don't think we
> > can do that automatically (and manual maintenance would be a bad
> > plan).
> 
> I suspect if it was sanely possible to do, then x86 would already be
> doing it as they've had this problem for a lot longer than we have.
> It might be worth talking to toolchain people to see if it can be made
> to work somehow - but we really don't want to get rid of all discarded
> section warnings.
> 
> IOW, if we have a text segment which is included in the image and it
> references discarded .exit text, we really do want it to fail at link
> time.

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..473e30e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -85,6 +85,7 @@ SECTIONS
 	 * unwind exit sections must be discarded before the rest of the
 	 * unwind sections get included.
 	 */
+#ifndef CONFIG_SMP_ON_UP
 	/DISCARD/ : {
 		*(.ARM.exidx.exit.text)
 		*(.ARM.extab.exit.text)
@@ -99,6 +100,7 @@ SECTIONS
 		*(__ex_table)
 #endif
 	}
+#endif
 
 	.text : {			/* Real text segment		*/
 		_text = .;		/* Text and read-only data	*/
@@ -107,6 +109,12 @@ SECTIONS
 			__exception_text_end = .;
 			IRQENTRY_TEXT
 			TEXT_TEXT
+#ifdef CONFIG_SMP_ON_UP
+			*(.exit.text)
+			CPU_KEEP(exit.text)
+			DEV_KEEP(exit.text)
+			MEM_KEEP(exit.text)
+#endif
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
@@ -116,6 +124,11 @@ SECTIONS
 			*(.gnu.warning)
 			*(.rodata)
 			*(.rodata.*)
+#ifdef CONFIG_SMP_ON_UP
+			CPU_KEEP(exit.rodata)
+			DEV_KEEP(exit.rodata)
+			MEM_KEEP(exit.rodata)
+#endif
 			*(.glue_7)
 			*(.glue_7t)
 		. = ALIGN(4);
@@ -188,6 +201,11 @@ SECTIONS
 		 * and the usual data section
 		 */
 		DATA_DATA
+#ifdef CONFIG_SMP_ON_UP
+		DEV_KEEP(exit.data)
+		CPU_KEEP(exit.data)
+		MEM_KEEP(exit.data)
+#endif
 		CONSTRUCTORS
 
 		_edata = .;
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-01-26 17:25                   ` Dave P. Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave P. Martin @ 2011-01-26 17:25 UTC (permalink / raw)
  To: linux-arm-kernel

SMP_ON_UP fixups lead to vmlinux link errors if those sections are
discarded at link-time.  In particular this may happen for built-in
__exit stuff.

This patch modifies the vmlinux linker script to reduce the amount
of discarded sections, and tries to make sure that __exit sections
are kept in.

This is a hack and probably wrong!  Further discussion is needed.  

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---

On Wed, Jan 26, 2011 at 12:44:52PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 11:11:31AM +0000, Dave Martin wrote:
> > Do we need to consider any other discarded sections?  In vmlinux.lds, I have:
> > 
> >  /* Default discards */
> >  /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> > *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
> > *(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }
> 
> We need to keep all the text exit stuff, and that could well want
> data exit stuff, so I think we need ot keep most of that.  Maybe not
> the .discard* stuff though.
> 
> > If we put every fixup in its own _section_ we might be able to
> > collapse those out of the list at link time too.  However, that seems
> > hard to achieve, since in order to do the correct link-time filtering
> > we would need the fixup's section name to be based on the referenced
> > section's name ... due to preprocessor limitations I don't think we
> > can do that automatically (and manual maintenance would be a bad
> > plan).
> 
> I suspect if it was sanely possible to do, then x86 would already be
> doing it as they've had this problem for a lot longer than we have.
> It might be worth talking to toolchain people to see if it can be made
> to work somehow - but we really don't want to get rid of all discarded
> section warnings.
> 
> IOW, if we have a text segment which is included in the image and it
> references discarded .exit text, we really do want it to fail at link
> time.

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..473e30e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -85,6 +85,7 @@ SECTIONS
 	 * unwind exit sections must be discarded before the rest of the
 	 * unwind sections get included.
 	 */
+#ifndef CONFIG_SMP_ON_UP
 	/DISCARD/ : {
 		*(.ARM.exidx.exit.text)
 		*(.ARM.extab.exit.text)
@@ -99,6 +100,7 @@ SECTIONS
 		*(__ex_table)
 #endif
 	}
+#endif
 
 	.text : {			/* Real text segment		*/
 		_text = .;		/* Text and read-only data	*/
@@ -107,6 +109,12 @@ SECTIONS
 			__exception_text_end = .;
 			IRQENTRY_TEXT
 			TEXT_TEXT
+#ifdef CONFIG_SMP_ON_UP
+			*(.exit.text)
+			CPU_KEEP(exit.text)
+			DEV_KEEP(exit.text)
+			MEM_KEEP(exit.text)
+#endif
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
@@ -116,6 +124,11 @@ SECTIONS
 			*(.gnu.warning)
 			*(.rodata)
 			*(.rodata.*)
+#ifdef CONFIG_SMP_ON_UP
+			CPU_KEEP(exit.rodata)
+			DEV_KEEP(exit.rodata)
+			MEM_KEEP(exit.rodata)
+#endif
 			*(.glue_7)
 			*(.glue_7t)
 		. = ALIGN(4);
@@ -188,6 +201,11 @@ SECTIONS
 		 * and the usual data section
 		 */
 		DATA_DATA
+#ifdef CONFIG_SMP_ON_UP
+		DEV_KEEP(exit.data)
+		CPU_KEEP(exit.data)
+		MEM_KEEP(exit.data)
+#endif
 		CONSTRUCTORS
 
 		_edata = .;
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 16:59                     ` Dave Martin
@ 2011-01-26 21:06                       ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 21:06 UTC (permalink / raw)
  To: Dave Martin; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Wed, 26 Jan 2011, Dave Martin wrote:

> On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > So I don't think weak symbols work like we want them to.
> >
> 
> That was the conclusion I came to also ... the linker seems to resolve
> references in each object before discarding sections, so the weak
> reference has already become concrete and section discard breaks it.

Well, I must add to the chorus.

And it seems to be impossible to obtain the name of the currently active 
section from gas either, which would have made the conditional omission 
of the fixup possible, or similar.

Bummer.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-26 21:06                       ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 21:06 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 26 Jan 2011, Dave Martin wrote:

> On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > So I don't think weak symbols work like we want them to.
> >
> 
> That was the conclusion I came to also ... the linker seems to resolve
> references in each object before discarding sections, so the weak
> reference has already become concrete and section discard breaks it.

Well, I must add to the chorus.

And it seems to be impossible to obtain the name of the currently active 
section from gas either, which would have made the conditional omission 
of the fixup possible, or similar.

Bummer.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-01-26 17:25                   ` Dave P. Martin
@ 2011-01-26 21:31                     ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 21:31 UTC (permalink / raw)
  To: Dave P. Martin; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Wed, 26 Jan 2011, Dave P. Martin wrote:

> SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> discarded at link-time.  In particular this may happen for built-in
> __exit stuff.
> 
> This patch modifies the vmlinux linker script to reduce the amount
> of discarded sections, and tries to make sure that __exit sections
> are kept in.
> 
> This is a hack and probably wrong!  Further discussion is needed.  
> 
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

Since discarded sections are by definition not used, we should at least 
put them into the .init section so to discard them at run time.  And 
only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
example).


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-01-26 21:31                     ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-01-26 21:31 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 26 Jan 2011, Dave P. Martin wrote:

> SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> discarded at link-time.  In particular this may happen for built-in
> __exit stuff.
> 
> This patch modifies the vmlinux linker script to reduce the amount
> of discarded sections, and tries to make sure that __exit sections
> are kept in.
> 
> This is a hack and probably wrong!  Further discussion is needed.  
> 
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

Since discarded sections are by definition not used, we should at least 
put them into the .init section so to discard them at run time.  And 
only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
example).


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
  2011-01-26 21:06                       ` Nicolas Pitre
@ 2011-01-27 11:44                         ` Dave P. Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave P. Martin @ 2011-01-27 11:44 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Dave Martin, Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 04:06:40PM -0500, Nicolas Pitre wrote:
> On Wed, 26 Jan 2011, Dave Martin wrote:
> 
> > On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > So I don't think weak symbols work like we want them to.
> > >
> > 
> > That was the conclusion I came to also ... the linker seems to resolve
> > references in each object before discarding sections, so the weak
> > reference has already become concrete and section discard breaks it.
> 
> Well, I must add to the chorus.
> 
> And it seems to be impossible to obtain the name of the currently active 
> section from gas either, which would have made the conditional omission 
> of the fixup possible, or similar.
> 
> Bummer.
> 
> 
> Nicolas

I've achieved this sort of thing in the past by wrapping the assmbler.
It's not pretty though, and it's unlikely anyone would be interested
in merging such a thing...

The example below is really a hack and won't work well in the the
presence of macros or conditional assembler.  However, since gcc output
contains none of either except in inline asm, you can get away with
a surprising amount.

If it needed to be robust this could mostly be implemented in 
assembler macros, but the need to hook things like .section, combined
with gas's refusal to redefine existing directives, means that you
would have a run a script over the input first, to translate .section
and friends into something you can hook.

And implementing anything non-trivial with assembler macros, while
almost always possible (unlike crippled cpp) gets very painful and
confusing...

Cheers
---Dave

$ chmod +x gasfilter filt-as
$ PATH=$PWD:$PATH
$ arm-linux-gnueabi-gcc -wrapper $PWD/filt-as -c tst.s
$ arm-linux-gnueabi-objdump -dsh tst.o

tst.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000004  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000038  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000038  2**0
                  ALLOC
  3 .text.fixup   00000004  00000000  00000000  00000038  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  4 .text.init    00000008  00000000  00000000  0000003c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .text.init.fixup 00000004  00000000  00000000  00000044  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  6 .ARM.attributes 00000021  00000000  00000000  00000048  2**0
                  CONTENTS, READONLY
Contents of section .text:
 0000 00f020e3                             .. .            
Contents of section .text.fixup:
 0000 00000000                             ....            
Contents of section .text.init:
 0000 00f020e3 00f020e3                    .. ... .        
Contents of section .text.init.fixup:
 0000 04000000                             ....            
Contents of section .ARM.attributes:
 0000 41200000 00616561 62690001 16000000  A ...aeabi......
 0010 05372d41 00060a07 41080109 020a042c  .7-A....A......,
 0020 01                                   .               

Disassembly of section .text:

00000000 <main>:
   0:	e320f000 	nop	{0}

Disassembly of section .text.fixup:

00000000 <.text.fixup>:
   0:	00000000 	.word	0x00000000

Disassembly of section .text.init:

00000000 <init>:
   0:	e320f000 	nop	{0}

00000004 <__fixup_3>:
   4:	e320f000 	nop	{0}

Disassembly of section .text.init.fixup:

00000000 <.text.init.fixup>:
   0:	00000004 	.word	0x00000004

diff -Nur filt-as filt-as
--- filt-as	1970-01-01 01:00:00.000000000 +0100
+++ filt-as	2011-01-27 11:30:11.858552002 +0000
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+case "$1" in
+	as|*/as|*-as) ;;
+	*) exec "$@"
+esac
+
+real_as=$1
+shift
+
+out=a.out
+in=-
+
+while [ $# != 0 ]; do
+	case "$1" in
+		-o)
+			out=$2
+			shift
+			;;
+		*.s)
+			in=$1
+			;;
+		*)
+			args=$args\ $1
+	esac
+	shift
+done
+
+gasfilter <"$in" \
+| "$real_as" $args -o "$out"
diff -Nur gasfilter gasfilter
--- gasfilter	1970-01-01 01:00:00.000000000 +0100
+++ gasfilter	2011-01-27 11:10:01.478552002 +0000
@@ -0,0 +1,68 @@
+#!/usr/bin/perl
+
+use strict;
+
+my $xpushsection_defined;
+
+my @section_stack = ( undef );
+
+sub setsection ($$) {
+	my ($name, $line) = @_;
+
+	print ".purgem __xpushsection\n" if $xpushsection_defined;
+
+	print
+".macro __xpushsection name:req, flags
+	.pushsection \"$name.\\name\", \"\\flags\"
+.endm
+";
+
+	$section_stack[$#section_stack] = $name;
+
+	$xpushsection_defined = 1;
+
+	print $line
+}
+
+sub popsection ($)
+{
+	pop @section_stack;
+	setsection $section_stack[$#section_stack], $_[0];
+}
+
+sub pushsection ($$)
+{
+	my ($name, $line) = @_;
+
+	push @section_stack, $name;
+	setsection $name, $line;
+}
+
+sub xpushsection ($$) {
+	my ($name, $rest) = @_;
+
+	print "__xpushsection \"$name\"$rest\n"
+}
+
+sub process_line {
+	$_ = $_[0] if defined $_[0];
+
+	if (/^\s*(\.(text|data|bss))(\s|$)/) {
+		setsection $1, $_
+	} elsif (/^\s*\.section\s+([\$._0-9A-Za-z]+).*/) {
+		setsection $1, $_
+	} elsif (/^\s*\.pushsection\s+([\$._0-9A-Za-z]+).*/) {
+		pushsection $1, $_
+	} elsif (/^\s*\.popsection(\s|$)/) {
+		popsection $_
+	} elsif (/^\s*\.xpushsection\s+([\$._0-9A-Za-z]+)(.*)/) {
+		xpushsection $1, $2
+	} elsif (/^\s*\.xpopsection(\s|$)/) {
+		print ".popsection\n"
+	} else {
+		print
+	}
+}	
+
+process_line ".text\n";
+process_line while <>;
diff -Nur tst.s tst.s
--- tst.s	1970-01-01 01:00:00.000000000 +0100
+++ tst.s	2011-01-27 11:07:39.338552001 +0000
@@ -0,0 +1,23 @@
+.macro fixup
+	_fixup \@
+.endm
+
+.macro _fixup num
+__fixup_\num :
+	.xpushsection fixup, "a"
+	.long __fixup_\num
+	.xpopsection
+.endm
+
+.globl main
+main:
+	fixup
+	nop
+
+.section .text.init, "ax"
+.globl init
+init:	nop
+
+	fixup
+	nop
+

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
@ 2011-01-27 11:44                         ` Dave P. Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave P. Martin @ 2011-01-27 11:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 04:06:40PM -0500, Nicolas Pitre wrote:
> On Wed, 26 Jan 2011, Dave Martin wrote:
> 
> > On Wed, Jan 26, 2011 at 3:52 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > So I don't think weak symbols work like we want them to.
> > >
> > 
> > That was the conclusion I came to also ... the linker seems to resolve
> > references in each object before discarding sections, so the weak
> > reference has already become concrete and section discard breaks it.
> 
> Well, I must add to the chorus.
> 
> And it seems to be impossible to obtain the name of the currently active 
> section from gas either, which would have made the conditional omission 
> of the fixup possible, or similar.
> 
> Bummer.
> 
> 
> Nicolas

I've achieved this sort of thing in the past by wrapping the assmbler.
It's not pretty though, and it's unlikely anyone would be interested
in merging such a thing...

The example below is really a hack and won't work well in the the
presence of macros or conditional assembler.  However, since gcc output
contains none of either except in inline asm, you can get away with
a surprising amount.

If it needed to be robust this could mostly be implemented in 
assembler macros, but the need to hook things like .section, combined
with gas's refusal to redefine existing directives, means that you
would have a run a script over the input first, to translate .section
and friends into something you can hook.

And implementing anything non-trivial with assembler macros, while
almost always possible (unlike crippled cpp) gets very painful and
confusing...

Cheers
---Dave

$ chmod +x gasfilter filt-as
$ PATH=$PWD:$PATH
$ arm-linux-gnueabi-gcc -wrapper $PWD/filt-as -c tst.s
$ arm-linux-gnueabi-objdump -dsh tst.o

tst.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000004  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000038  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000038  2**0
                  ALLOC
  3 .text.fixup   00000004  00000000  00000000  00000038  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  4 .text.init    00000008  00000000  00000000  0000003c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .text.init.fixup 00000004  00000000  00000000  00000044  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  6 .ARM.attributes 00000021  00000000  00000000  00000048  2**0
                  CONTENTS, READONLY
Contents of section .text:
 0000 00f020e3                             .. .            
Contents of section .text.fixup:
 0000 00000000                             ....            
Contents of section .text.init:
 0000 00f020e3 00f020e3                    .. ... .        
Contents of section .text.init.fixup:
 0000 04000000                             ....            
Contents of section .ARM.attributes:
 0000 41200000 00616561 62690001 16000000  A ...aeabi......
 0010 05372d41 00060a07 41080109 020a042c  .7-A....A......,
 0020 01                                   .               

Disassembly of section .text:

00000000 <main>:
   0:	e320f000 	nop	{0}

Disassembly of section .text.fixup:

00000000 <.text.fixup>:
   0:	00000000 	.word	0x00000000

Disassembly of section .text.init:

00000000 <init>:
   0:	e320f000 	nop	{0}

00000004 <__fixup_3>:
   4:	e320f000 	nop	{0}

Disassembly of section .text.init.fixup:

00000000 <.text.init.fixup>:
   0:	00000004 	.word	0x00000004

diff -Nur filt-as filt-as
--- filt-as	1970-01-01 01:00:00.000000000 +0100
+++ filt-as	2011-01-27 11:30:11.858552002 +0000
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+case "$1" in
+	as|*/as|*-as) ;;
+	*) exec "$@"
+esac
+
+real_as=$1
+shift
+
+out=a.out
+in=-
+
+while [ $# != 0 ]; do
+	case "$1" in
+		-o)
+			out=$2
+			shift
+			;;
+		*.s)
+			in=$1
+			;;
+		*)
+			args=$args\ $1
+	esac
+	shift
+done
+
+gasfilter <"$in" \
+| "$real_as" $args -o "$out"
diff -Nur gasfilter gasfilter
--- gasfilter	1970-01-01 01:00:00.000000000 +0100
+++ gasfilter	2011-01-27 11:10:01.478552002 +0000
@@ -0,0 +1,68 @@
+#!/usr/bin/perl
+
+use strict;
+
+my $xpushsection_defined;
+
+my @section_stack = ( undef );
+
+sub setsection ($$) {
+	my ($name, $line) = @_;
+
+	print ".purgem __xpushsection\n" if $xpushsection_defined;
+
+	print
+".macro __xpushsection name:req, flags
+	.pushsection \"$name.\\name\", \"\\flags\"
+.endm
+";
+
+	$section_stack[$#section_stack] = $name;
+
+	$xpushsection_defined = 1;
+
+	print $line
+}
+
+sub popsection ($)
+{
+	pop @section_stack;
+	setsection $section_stack[$#section_stack], $_[0];
+}
+
+sub pushsection ($$)
+{
+	my ($name, $line) = @_;
+
+	push @section_stack, $name;
+	setsection $name, $line;
+}
+
+sub xpushsection ($$) {
+	my ($name, $rest) = @_;
+
+	print "__xpushsection \"$name\"$rest\n"
+}
+
+sub process_line {
+	$_ = $_[0] if defined $_[0];
+
+	if (/^\s*(\.(text|data|bss))(\s|$)/) {
+		setsection $1, $_
+	} elsif (/^\s*\.section\s+([\$._0-9A-Za-z]+).*/) {
+		setsection $1, $_
+	} elsif (/^\s*\.pushsection\s+([\$._0-9A-Za-z]+).*/) {
+		pushsection $1, $_
+	} elsif (/^\s*\.popsection(\s|$)/) {
+		popsection $_
+	} elsif (/^\s*\.xpushsection\s+([\$._0-9A-Za-z]+)(.*)/) {
+		xpushsection $1, $2
+	} elsif (/^\s*\.xpopsection(\s|$)/) {
+		print ".popsection\n"
+	} else {
+		print
+	}
+}	
+
+process_line ".text\n";
+process_line while <>;
diff -Nur tst.s tst.s
--- tst.s	1970-01-01 01:00:00.000000000 +0100
+++ tst.s	2011-01-27 11:07:39.338552001 +0000
@@ -0,0 +1,23 @@
+.macro fixup
+	_fixup \@
+.endm
+
+.macro _fixup num
+__fixup_\num :
+	.xpushsection fixup, "a"
+	.long __fixup_\num
+	.xpopsection
+.endm
+
+.globl main
+main:
+	fixup
+	nop
+
+.section .text.init, "ax"
+.globl init
+init:	nop
+
+	fixup
+	nop
+

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH v2] ARM: Avoid discarding sections that might have SMP_ON_UP fixups SMP_ON_UP fixups
  2011-01-26 21:31                     ` Nicolas Pitre
@ 2011-01-27 14:37                       ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-27 14:37 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 04:31:37PM -0500, Nicolas Pitre wrote:
> Since discarded sections are by definition not used, we should at least 
> put them into the .init section so to discard them at run time.  And 
> only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
> example).
> 
> 
> Nicolas

I'll check up on whether we need to care about writable data.
For now I've just attempted to move stuff to .init.

Cheers
---Dave



v2: Also move the .exit stuff to the .init area where it can
be discarded on boot.  The result builds, but I haven't tested it
yet.

v1:

SMP_ON_UP fixups lead to vmlinux link errors if those sections are
discarded at link-time.  In particular this may happen for built-in
__exit stuff.

This patch modifies the vmlinux linker script to reduce the amount
of discarded sections, and tries to make sure that __exit sections
are kept in.

This is a hack and probably wrong!

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/kernel/vmlinux.lds.S |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..5774b95 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -43,6 +43,17 @@ SECTIONS
 		_sinittext = .;
 			HEAD_TEXT
 			INIT_TEXT
+#ifdef CONFIG_SMP_ON_UP
+			*(.exit.text)
+			CPU_KEEP(exit.text)
+			DEV_KEEP(exit.text)
+			MEM_KEEP(exit.text)
+#endif
+#ifdef CONFIG_SMP_ON_UP
+			CPU_KEEP(exit.rodata)
+			DEV_KEEP(exit.rodata)
+			MEM_KEEP(exit.rodata)
+#endif
 		_einittext = .;
 		ARM_CPU_DISCARD(PROC_INFO)
 		__arch_info_begin = .;
@@ -72,6 +83,11 @@ SECTIONS
 		__init_begin = _stext;
 		INIT_DATA
 #endif
+#ifdef CONFIG_SMP_ON_UP
+		DEV_KEEP(exit.data)
+		CPU_KEEP(exit.data)
+		MEM_KEEP(exit.data)
+#endif
 	}
 
 	PERCPU(PAGE_SIZE)
@@ -85,6 +101,7 @@ SECTIONS
 	 * unwind exit sections must be discarded before the rest of the
 	 * unwind sections get included.
 	 */
+#ifndef CONFIG_SMP_ON_UP
 	/DISCARD/ : {
 		*(.ARM.exidx.exit.text)
 		*(.ARM.extab.exit.text)
@@ -99,6 +116,7 @@ SECTIONS
 		*(__ex_table)
 #endif
 	}
+#endif
 
 	.text : {			/* Real text segment		*/
 		_text = .;		/* Text and read-only data	*/
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH v2] ARM: Avoid discarding sections that might have SMP_ON_UP fixups SMP_ON_UP fixups
@ 2011-01-27 14:37                       ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-01-27 14:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 04:31:37PM -0500, Nicolas Pitre wrote:
> Since discarded sections are by definition not used, we should at least 
> put them into the .init section so to discard them at run time.  And 
> only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
> example).
> 
> 
> Nicolas

I'll check up on whether we need to care about writable data.
For now I've just attempted to move stuff to .init.

Cheers
---Dave



v2: Also move the .exit stuff to the .init area where it can
be discarded on boot.  The result builds, but I haven't tested it
yet.

v1:

SMP_ON_UP fixups lead to vmlinux link errors if those sections are
discarded at link-time.  In particular this may happen for built-in
__exit stuff.

This patch modifies the vmlinux linker script to reduce the amount
of discarded sections, and tries to make sure that __exit sections
are kept in.

This is a hack and probably wrong!

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/kernel/vmlinux.lds.S |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..5774b95 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -43,6 +43,17 @@ SECTIONS
 		_sinittext = .;
 			HEAD_TEXT
 			INIT_TEXT
+#ifdef CONFIG_SMP_ON_UP
+			*(.exit.text)
+			CPU_KEEP(exit.text)
+			DEV_KEEP(exit.text)
+			MEM_KEEP(exit.text)
+#endif
+#ifdef CONFIG_SMP_ON_UP
+			CPU_KEEP(exit.rodata)
+			DEV_KEEP(exit.rodata)
+			MEM_KEEP(exit.rodata)
+#endif
 		_einittext = .;
 		ARM_CPU_DISCARD(PROC_INFO)
 		__arch_info_begin = .;
@@ -72,6 +83,11 @@ SECTIONS
 		__init_begin = _stext;
 		INIT_DATA
 #endif
+#ifdef CONFIG_SMP_ON_UP
+		DEV_KEEP(exit.data)
+		CPU_KEEP(exit.data)
+		MEM_KEEP(exit.data)
+#endif
 	}
 
 	PERCPU(PAGE_SIZE)
@@ -85,6 +101,7 @@ SECTIONS
 	 * unwind exit sections must be discarded before the rest of the
 	 * unwind sections get included.
 	 */
+#ifndef CONFIG_SMP_ON_UP
 	/DISCARD/ : {
 		*(.ARM.exidx.exit.text)
 		*(.ARM.extab.exit.text)
@@ -99,6 +116,7 @@ SECTIONS
 		*(__ex_table)
 #endif
 	}
+#endif
 
 	.text : {			/* Real text segment		*/
 		_text = .;		/* Text and read-only data	*/
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH v2] ARM: Avoid discarding sections that might have SMP_ON_UP fixups SMP_ON_UP fixups
  2011-01-27 14:37                       ` Dave Martin
@ 2011-01-27 16:46                         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-27 16:46 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Jan 27, 2011 at 02:37:09PM +0000, Dave Martin wrote:
> On Wed, Jan 26, 2011 at 04:31:37PM -0500, Nicolas Pitre wrote:
> > Since discarded sections are by definition not used, we should at least 
> > put them into the .init section so to discard them at run time.  And 
> > only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
> > example).
> > 
> > 
> > Nicolas
> 
> I'll check up on whether we need to care about writable data.
> For now I've just attempted to move stuff to .init.

You can keep the discarding of the unwind data for exit sections as
the exit sections don't depend on the unwind data.

It's all to do with sections being referenced from other sections.  If
a section being kept references a section being discarded, then the
linker will error out.  You need to keep any section that is being
referenced - but you don't need to keep sections which only reference
those being kept.

I'd also prefer to see a 'KEEP_EXIT' macro as I think we can discard
these sections in more cases than just SMP_ON_UP.  I think it's:

SMP_ON_UP && !DEBUG_SPINLOCK

which requires it.  So if you have spinlock debugging enabled you can
discard the exit sections.  See include/linux/spinlock.h.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH v2] ARM: Avoid discarding sections that might have SMP_ON_UP fixups SMP_ON_UP fixups
@ 2011-01-27 16:46                         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-27 16:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jan 27, 2011 at 02:37:09PM +0000, Dave Martin wrote:
> On Wed, Jan 26, 2011 at 04:31:37PM -0500, Nicolas Pitre wrote:
> > Since discarded sections are by definition not used, we should at least 
> > put them into the .init section so to discard them at run time.  And 
> > only the EXIT_TEXT and EXIT_DATA would need to be kept (see x86 for 
> > example).
> > 
> > 
> > Nicolas
> 
> I'll check up on whether we need to care about writable data.
> For now I've just attempted to move stuff to .init.

You can keep the discarding of the unwind data for exit sections as
the exit sections don't depend on the unwind data.

It's all to do with sections being referenced from other sections.  If
a section being kept references a section being discarded, then the
linker will error out.  You need to keep any section that is being
referenced - but you don't need to keep sections which only reference
those being kept.

I'd also prefer to see a 'KEEP_EXIT' macro as I think we can discard
these sections in more cases than just SMP_ON_UP.  I think it's:

SMP_ON_UP && !DEBUG_SPINLOCK

which requires it.  So if you have spinlock debugging enabled you can
discard the exit sections.  See include/linux/spinlock.h.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-17 19:24   ` Russell King - ARM Linux
@ 2011-01-27 18:14     ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-27 18:14 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On 17 January 2011 19:24, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Rather than turning off CPU domain switching when the build architecture
> includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> turn it on when it's required to support a CPU architecture.

(sorry, I'm well behind list messages, didn't reply earlier)

Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
built in the same kernel? The side effect is that user read-only
addresses are writable by the kernel and SWP emulation no longer
works.

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-27 18:14     ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-27 18:14 UTC (permalink / raw)
  To: linux-arm-kernel

On 17 January 2011 19:24, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Rather than turning off CPU domain switching when the build architecture
> includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> turn it on when it's required to support a CPU architecture.

(sorry, I'm well behind list messages, didn't reply earlier)

Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
built in the same kernel? The side effect is that user read-only
addresses are writable by the kernel and SWP emulation no longer
works.

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-27 18:14     ` Catalin Marinas
@ 2011-01-27 18:59       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-27 18:59 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-arm-kernel, linux-omap

On Thu, Jan 27, 2011 at 06:14:56PM +0000, Catalin Marinas wrote:
> On 17 January 2011 19:24, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Rather than turning off CPU domain switching when the build architecture
> > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > turn it on when it's required to support a CPU architecture.
> 
> (sorry, I'm well behind list messages, didn't reply earlier)
> 
> Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
> built in the same kernel? The side effect is that user read-only
> addresses are writable by the kernel and SWP emulation no longer
> works.

It means that a kernel with ARMv6 through to ARMv7 will have CPU
domains enabled.  So maybe we want:

config CPU_32v6
	select CPU_USE_DOMAINS if !CPU_V6K && MMU

instead?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-27 18:59       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-27 18:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jan 27, 2011 at 06:14:56PM +0000, Catalin Marinas wrote:
> On 17 January 2011 19:24, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Rather than turning off CPU domain switching when the build architecture
> > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > turn it on when it's required to support a CPU architecture.
> 
> (sorry, I'm well behind list messages, didn't reply earlier)
> 
> Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
> built in the same kernel? The side effect is that user read-only
> addresses are writable by the kernel and SWP emulation no longer
> works.

It means that a kernel with ARMv6 through to ARMv7 will have CPU
domains enabled.  So maybe we want:

config CPU_32v6
	select CPU_USE_DOMAINS if !CPU_V6K && MMU

instead?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-27 18:59       ` Russell King - ARM Linux
@ 2011-01-28  9:46         ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28  9:46 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

On Thu, 2011-01-27 at 18:59 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 06:14:56PM +0000, Catalin Marinas wrote:
> > On 17 January 2011 19:24, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > Rather than turning off CPU domain switching when the build architecture
> > > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > > turn it on when it's required to support a CPU architecture.
> >
> > (sorry, I'm well behind list messages, didn't reply earlier)
> >
> > Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
> > built in the same kernel? The side effect is that user read-only
> > addresses are writable by the kernel and SWP emulation no longer
> > works.
> 
> It means that a kernel with ARMv6 through to ARMv7 will have CPU
> domains enabled.  So maybe we want:
> 
> config CPU_32v6
>         select CPU_USE_DOMAINS if !CPU_V6K && MMU
> 
> instead?

Does this mean that we could still configure a kernel to run on CPU_V6
with domains disabled? The vectors page becomes read-only and setting
the TLS would fail.

My point is that we may want SWP_EMULATE disabled (or depending on !
CPU_USE_DOMAINS). With domains enabled every read-only user page is
writeable by the kernel. This has the side-effect that SWP emulation
using LDREX/STREX breaks COW.

We could change early_trap_init() to always use the vectors_page rather
than the high mapping and determine at run-time (patch the code) whether
set_pte_ext sets R/W kernel permissions for RO user pages.

-- 
Catalin



^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28  9:46         ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28  9:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, 2011-01-27 at 18:59 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 06:14:56PM +0000, Catalin Marinas wrote:
> > On 17 January 2011 19:24, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > Rather than turning off CPU domain switching when the build architecture
> > > includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
> > > turn it on when it's required to support a CPU architecture.
> >
> > (sorry, I'm well behind list messages, didn't reply earlier)
> >
> > Does it mean that we get domains enabled even for ARMv7 when ARMv6 is
> > built in the same kernel? The side effect is that user read-only
> > addresses are writable by the kernel and SWP emulation no longer
> > works.
> 
> It means that a kernel with ARMv6 through to ARMv7 will have CPU
> domains enabled.  So maybe we want:
> 
> config CPU_32v6
>         select CPU_USE_DOMAINS if !CPU_V6K && MMU
> 
> instead?

Does this mean that we could still configure a kernel to run on CPU_V6
with domains disabled? The vectors page becomes read-only and setting
the TLS would fail.

My point is that we may want SWP_EMULATE disabled (or depending on !
CPU_USE_DOMAINS). With domains enabled every read-only user page is
writeable by the kernel. This has the side-effect that SWP emulation
using LDREX/STREX breaks COW.

We could change early_trap_init() to always use the vectors_page rather
than the high mapping and determine at run-time (patch the code) whether
set_pte_ext sets R/W kernel permissions for RO user pages.

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28  9:46         ` Catalin Marinas
@ 2011-01-28  9:59           ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28  9:59 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-omap, linux-arm-kernel

On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> Does this mean that we could still configure a kernel to run on CPU_V6
> with domains disabled? The vectors page becomes read-only and setting
> the TLS would fail.

Yes it will, so that's not acceptable either.

> My point is that we may want SWP_EMULATE disabled (or depending on !
> CPU_USE_DOMAINS). With domains enabled every read-only user page is
> writeable by the kernel. This has the side-effect that SWP emulation
> using LDREX/STREX breaks COW.

Yes, and maybe we should instead just enable the SWP instruction by default
on ARMv7, and if SWP emulation is built, disable it at that point.

> We could change early_trap_init() to always use the vectors_page rather
> than the high mapping and determine at run-time (patch the code) whether
> set_pte_ext sets R/W kernel permissions for RO user pages.

With aliasing caches that becomes much more difficult.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28  9:59           ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28  9:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> Does this mean that we could still configure a kernel to run on CPU_V6
> with domains disabled? The vectors page becomes read-only and setting
> the TLS would fail.

Yes it will, so that's not acceptable either.

> My point is that we may want SWP_EMULATE disabled (or depending on !
> CPU_USE_DOMAINS). With domains enabled every read-only user page is
> writeable by the kernel. This has the side-effect that SWP emulation
> using LDREX/STREX breaks COW.

Yes, and maybe we should instead just enable the SWP instruction by default
on ARMv7, and if SWP emulation is built, disable it at that point.

> We could change early_trap_init() to always use the vectors_page rather
> than the high mapping and determine at run-time (patch the code) whether
> set_pte_ext sets R/W kernel permissions for RO user pages.

With aliasing caches that becomes much more difficult.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28  9:59           ` Russell King - ARM Linux
@ 2011-01-28 10:46             ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 10:46 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-omap, linux-arm-kernel

On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > My point is that we may want SWP_EMULATE disabled (or depending on !
> > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > writeable by the kernel. This has the side-effect that SWP emulation
> > using LDREX/STREX breaks COW.
> 
> Yes, and maybe we should instead just enable the SWP instruction by default
> on ARMv7, and if SWP emulation is built, disable it at that point.

We can't disable the SWP instruction as long as domains are enabled (COW
not working for in-kernel STREX).

On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
independent of the domains setting and have early_trap_init() use
vectors_page() if cpu_architecture() >= 7 (this would actually catch
ARM11MPCore as well because of the way we interpret CPUID).

-- 
Catalin



^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 10:46             ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 10:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > My point is that we may want SWP_EMULATE disabled (or depending on !
> > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > writeable by the kernel. This has the side-effect that SWP emulation
> > using LDREX/STREX breaks COW.
> 
> Yes, and maybe we should instead just enable the SWP instruction by default
> on ARMv7, and if SWP emulation is built, disable it at that point.

We can't disable the SWP instruction as long as domains are enabled (COW
not working for in-kernel STREX).

On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
independent of the domains setting and have early_trap_init() use
vectors_page() if cpu_architecture() >= 7 (this would actually catch
ARM11MPCore as well because of the way we interpret CPUID).

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 10:46             ` Catalin Marinas
@ 2011-01-28 11:06               ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 11:06 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-omap, linux-arm-kernel

On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > writeable by the kernel. This has the side-effect that SWP emulation
> > > using LDREX/STREX breaks COW.
> > 
> > Yes, and maybe we should instead just enable the SWP instruction by default
> > on ARMv7, and if SWP emulation is built, disable it at that point.
> 
> We can't disable the SWP instruction as long as domains are enabled (COW
> not working for in-kernel STREX).
> 
> On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> independent of the domains setting and have early_trap_init() use
> vectors_page() if cpu_architecture() >= 7 (this would actually catch
> ARM11MPCore as well because of the way we interpret CPUID).

What about a kernel covering ARMv6 too?  Writing to an aliased mapping
of the vectors page (as required for TLS emulation) will require
additional cache maintainence on every context switch.

1. SWP emulation requires domain support turned off
2. We can't turn domains off without creating a vectors page alias
3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
   without additional cache maintainence.

I don't think overloading the context switch with yet more conditionals
based on yet more TLS combinations is a practical solution.

So, ARMv6 TLS emulation, and SWP emulation are incompatible with each
other.

So either we don't have the SWP instruction at all on ARMv6+, or we have
it enabled in hardware, or we don't and use the emulation where possible.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 11:06               ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 11:06 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > writeable by the kernel. This has the side-effect that SWP emulation
> > > using LDREX/STREX breaks COW.
> > 
> > Yes, and maybe we should instead just enable the SWP instruction by default
> > on ARMv7, and if SWP emulation is built, disable it at that point.
> 
> We can't disable the SWP instruction as long as domains are enabled (COW
> not working for in-kernel STREX).
> 
> On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> independent of the domains setting and have early_trap_init() use
> vectors_page() if cpu_architecture() >= 7 (this would actually catch
> ARM11MPCore as well because of the way we interpret CPUID).

What about a kernel covering ARMv6 too?  Writing to an aliased mapping
of the vectors page (as required for TLS emulation) will require
additional cache maintainence on every context switch.

1. SWP emulation requires domain support turned off
2. We can't turn domains off without creating a vectors page alias
3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
   without additional cache maintainence.

I don't think overloading the context switch with yet more conditionals
based on yet more TLS combinations is a practical solution.

So, ARMv6 TLS emulation, and SWP emulation are incompatible with each
other.

So either we don't have the SWP instruction at all on ARMv6+, or we have
it enabled in hardware, or we don't and use the emulation where possible.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 11:06               ` Russell King - ARM Linux
@ 2011-01-28 12:25                 ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 12:25 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-omap, linux-arm-kernel

On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > using LDREX/STREX breaks COW.
> > >
> > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > on ARMv7, and if SWP emulation is built, disable it at that point.
> >
> > We can't disable the SWP instruction as long as domains are enabled (COW
> > not working for in-kernel STREX).
> >
> > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > independent of the domains setting and have early_trap_init() use
> > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > ARM11MPCore as well because of the way we interpret CPUID).
> 
> What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> of the vectors page (as required for TLS emulation) will require
> additional cache maintainence on every context switch.

With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
v6 is compiled in? If that's the case, we may have a problem - I talked
to the toolchain guys and it looks like code optimised for ARMv7 reads
the TLS register directly without going through the kuser helper. So you
may have people taking an Ubuntu filesystem (v7 only) and a pre-built
OMAP image with TLS emulation even on Cortex-A8 and things won't work as
expected.

On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
and use the TLS register. The only other place where this matters on
ARMv7 is early_trap_init() but it's easily fixable on this architecture.

> 1. SWP emulation requires domain support turned off

Not necessarily - it requires RO user pages to be kernel RO (though this
feature came with the domains removal patch).

> 2. We can't turn domains off without creating a vectors page alias

Correct.

> 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
>    without additional cache maintainence.

Correct.

> I don't think overloading the context switch with yet more conditionals
> based on yet more TLS combinations is a practical solution.

Yet another run-time code patching for the TLS, though it gets a bit
complex. But we may need to solve it for the v7 filesystem case I
mentioned above.

> So, ARMv6 TLS emulation, and SWP emulation are incompatible with each
> other.

Yes.

> So either we don't have the SWP instruction at all on ARMv6+, or we have
> it enabled in hardware, or we don't and use the emulation where possible.

If we can't sort out TLS register setting on v6+v7 kernels (I think we
should), then we must have the SWP instruction enabled (no emulation).
Which gets us back to the SWP_EMULATE depend on (CPU_V7 && !CPU_V6).

-- 
Catalin



^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 12:25                 ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 12:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > using LDREX/STREX breaks COW.
> > >
> > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > on ARMv7, and if SWP emulation is built, disable it at that point.
> >
> > We can't disable the SWP instruction as long as domains are enabled (COW
> > not working for in-kernel STREX).
> >
> > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > independent of the domains setting and have early_trap_init() use
> > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > ARM11MPCore as well because of the way we interpret CPUID).
> 
> What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> of the vectors page (as required for TLS emulation) will require
> additional cache maintainence on every context switch.

With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
v6 is compiled in? If that's the case, we may have a problem - I talked
to the toolchain guys and it looks like code optimised for ARMv7 reads
the TLS register directly without going through the kuser helper. So you
may have people taking an Ubuntu filesystem (v7 only) and a pre-built
OMAP image with TLS emulation even on Cortex-A8 and things won't work as
expected.

On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
and use the TLS register. The only other place where this matters on
ARMv7 is early_trap_init() but it's easily fixable on this architecture.

> 1. SWP emulation requires domain support turned off

Not necessarily - it requires RO user pages to be kernel RO (though this
feature came with the domains removal patch).

> 2. We can't turn domains off without creating a vectors page alias

Correct.

> 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
>    without additional cache maintainence.

Correct.

> I don't think overloading the context switch with yet more conditionals
> based on yet more TLS combinations is a practical solution.

Yet another run-time code patching for the TLS, though it gets a bit
complex. But we may need to solve it for the v7 filesystem case I
mentioned above.

> So, ARMv6 TLS emulation, and SWP emulation are incompatible with each
> other.

Yes.

> So either we don't have the SWP instruction at all on ARMv6+, or we have
> it enabled in hardware, or we don't and use the emulation where possible.

If we can't sort out TLS register setting on v6+v7 kernels (I think we
should), then we must have the SWP instruction enabled (no emulation).
Which gets us back to the SWP_EMULATE depend on (CPU_V7 && !CPU_V6).

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 12:25                 ` Catalin Marinas
@ 2011-01-28 13:05                   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:05 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-omap, linux-arm-kernel

On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > > using LDREX/STREX breaks COW.
> > > >
> > > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > > on ARMv7, and if SWP emulation is built, disable it at that point.
> > >
> > > We can't disable the SWP instruction as long as domains are enabled (COW
> > > not working for in-kernel STREX).
> > >
> > > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > > independent of the domains setting and have early_trap_init() use
> > > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > > ARM11MPCore as well because of the way we interpret CPUID).
> > 
> > What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> > of the vectors page (as required for TLS emulation) will require
> > additional cache maintainence on every context switch.
> 
> With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> v6 is compiled in? If that's the case, we may have a problem - I talked
> to the toolchain guys and it looks like code optimised for ARMv7 reads
> the TLS register directly without going through the kuser helper.

That's not a problem, because you wouldn't run ARMv7 optimized userspace
on an ARMv6 CPU.  That's not what this whole exercise is about.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 13:05                   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:05 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > > using LDREX/STREX breaks COW.
> > > >
> > > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > > on ARMv7, and if SWP emulation is built, disable it at that point.
> > >
> > > We can't disable the SWP instruction as long as domains are enabled (COW
> > > not working for in-kernel STREX).
> > >
> > > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > > independent of the domains setting and have early_trap_init() use
> > > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > > ARM11MPCore as well because of the way we interpret CPUID).
> > 
> > What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> > of the vectors page (as required for TLS emulation) will require
> > additional cache maintainence on every context switch.
> 
> With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> v6 is compiled in? If that's the case, we may have a problem - I talked
> to the toolchain guys and it looks like code optimised for ARMv7 reads
> the TLS register directly without going through the kuser helper.

That's not a problem, because you wouldn't run ARMv7 optimized userspace
on an ARMv6 CPU.  That's not what this whole exercise is about.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 13:05                   ` Russell King - ARM Linux
@ 2011-01-28 13:10                     ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 13:10 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-omap, linux-arm-kernel

On Fri, 2011-01-28 at 13:05 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > v6 is compiled in? If that's the case, we may have a problem - I talked
> > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > the TLS register directly without going through the kuser helper.
> 
> That's not a problem, because you wouldn't run ARMv7 optimized userspace
> on an ARMv6 CPU.  That's not what this whole exercise is about.

But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel
image compiled for v6+v7.

-- 
Catalin



^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 13:10                     ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 13:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2011-01-28 at 13:05 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > v6 is compiled in? If that's the case, we may have a problem - I talked
> > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > the TLS register directly without going through the kuser helper.
> 
> That's not a problem, because you wouldn't run ARMv7 optimized userspace
> on an ARMv6 CPU.  That's not what this whole exercise is about.

But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel
image compiled for v6+v7.

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 12:25                 ` Catalin Marinas
@ 2011-01-28 13:21                   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:21 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-omap, linux-arm-kernel

On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > > using LDREX/STREX breaks COW.
> > > >
> > > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > > on ARMv7, and if SWP emulation is built, disable it at that point.
> > >
> > > We can't disable the SWP instruction as long as domains are enabled (COW
> > > not working for in-kernel STREX).
> > >
> > > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > > independent of the domains setting and have early_trap_init() use
> > > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > > ARM11MPCore as well because of the way we interpret CPUID).
> > 
> > What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> > of the vectors page (as required for TLS emulation) will require
> > additional cache maintainence on every context switch.
> 
> With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> v6 is compiled in? If that's the case, we may have a problem - I talked
> to the toolchain guys and it looks like code optimised for ARMv7 reads
> the TLS register directly without going through the kuser helper. So you
> may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> expected.

You're really making a mountain out of TLS.

If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
we will use the TLS register if that's available on the hardware.  If it
isn't, we will write the TLS value directly to virtual 0xffff0ffc.

So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
TLS register, and your v7 optimized binaries which access the TLS register
directly will work.  Same for v6k.

For v6, you won't be able to run v7 optimized binaries on that hardware
anyway, because it doesn't have the TLS register, and as such the
instructions which access it will fault.  That's true whether you have
a v6 only kernel or a v6+v6k+v7 kernel.

What we're discussing has nothing at all to do with getting v7 binaries
running on v6 hardware.  That's just not going to happen.

> On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
> page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
> and use the TLS register. The only other place where this matters on
> ARMv7 is early_trap_init() but it's easily fixable on this architecture.

That's pointless.  There's no "could map the vectors page" - set_pte_ext()
doesn't know what's the vectors page and what isn't.  It's about how
set_pte_ext() maps pages which are marked with just L_PTE_USER.

All L_PTE_USER pages get mapped as user read-only.  Whether they get mapped
SVC read-only or SVC read-write depends on whether we support domains.
Without domains, they're mapped SVC read-write, and we need to use the
ldrt/strt instructions.  With domains, they're mapped SVC read-only, and we
no longer need the ldrt/strt instructions.

> > 1. SWP emulation requires domain support turned off
> 
> Not necessarily - it requires RO user pages to be kernel RO (though this
> feature came with the domains removal patch).

Yes it does because without domains, we need user pages to be kernel
read-only, which also makes the vectors page kernel read-only.

> > 2. We can't turn domains off without creating a vectors page alias
> 
> Correct.
> 
> > 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
> >    without additional cache maintainence.
> 
> Correct.
> 
> > I don't think overloading the context switch with yet more conditionals
> > based on yet more TLS combinations is a practical solution.
> 
> Yet another run-time code patching for the TLS, though it gets a bit
> complex.

It _already_ is complex.  We don't need any more complexity there.  Have
a look in asm/tls.h to see that there's already four different cases we
have to consider.

> But we may need to solve it for the v7 filesystem case I mentioned above.

No we don't.  We're already selecting the code appropriately from four
different cases for the supported processor types.  We don't need "maybe
the vectors page is read-only" introducing another two cases with complex
cache flushing and location of the vectors page, and we certainly don't
need this complication at runtime.

> If we can't sort out TLS register setting on v6+v7 kernels (I think we
> should), then we must have the SWP instruction enabled (no emulation).
> Which gets us back to the SWP_EMULATE depend on (CPU_V7 && !CPU_V6).

That I think is the right solution.  It sorts out the issues without
additional overhead.

The only use which SWP_EMULATE gets us then is detecting userspace
programs which use the SWP instruction - and that can only happen on
a V7-only or v6k+v7 targetted kernel.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 13:21                   ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +0000, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Jan 28, 2011 at 09:46:06AM +0000, Catalin Marinas wrote:
> > > > > My point is that we may want SWP_EMULATE disabled (or depending on !
> > > > > CPU_USE_DOMAINS). With domains enabled every read-only user page is
> > > > > writeable by the kernel. This has the side-effect that SWP emulation
> > > > > using LDREX/STREX breaks COW.
> > > >
> > > > Yes, and maybe we should instead just enable the SWP instruction by default
> > > > on ARMv7, and if SWP emulation is built, disable it at that point.
> > >
> > > We can't disable the SWP instruction as long as domains are enabled (COW
> > > not working for in-kernel STREX).
> > >
> > > On ARMv7 we could always force R/O kernel/user pages in set_pte_ext
> > > independent of the domains setting and have early_trap_init() use
> > > vectors_page() if cpu_architecture() >= 7 (this would actually catch
> > > ARM11MPCore as well because of the way we interpret CPUID).
> > 
> > What about a kernel covering ARMv6 too?  Writing to an aliased mapping
> > of the vectors page (as required for TLS emulation) will require
> > additional cache maintainence on every context switch.
> 
> With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> v6 is compiled in? If that's the case, we may have a problem - I talked
> to the toolchain guys and it looks like code optimised for ARMv7 reads
> the TLS register directly without going through the kuser helper. So you
> may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> expected.

You're really making a mountain out of TLS.

If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
we will use the TLS register if that's available on the hardware.  If it
isn't, we will write the TLS value directly to virtual 0xffff0ffc.

So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
TLS register, and your v7 optimized binaries which access the TLS register
directly will work.  Same for v6k.

For v6, you won't be able to run v7 optimized binaries on that hardware
anyway, because it doesn't have the TLS register, and as such the
instructions which access it will fault.  That's true whether you have
a v6 only kernel or a v6+v6k+v7 kernel.

What we're discussing has nothing at all to do with getting v7 binaries
running on v6 hardware.  That's just not going to happen.

> On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
> page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
> and use the TLS register. The only other place where this matters on
> ARMv7 is early_trap_init() but it's easily fixable on this architecture.

That's pointless.  There's no "could map the vectors page" - set_pte_ext()
doesn't know what's the vectors page and what isn't.  It's about how
set_pte_ext() maps pages which are marked with just L_PTE_USER.

All L_PTE_USER pages get mapped as user read-only.  Whether they get mapped
SVC read-only or SVC read-write depends on whether we support domains.
Without domains, they're mapped SVC read-write, and we need to use the
ldrt/strt instructions.  With domains, they're mapped SVC read-only, and we
no longer need the ldrt/strt instructions.

> > 1. SWP emulation requires domain support turned off
> 
> Not necessarily - it requires RO user pages to be kernel RO (though this
> feature came with the domains removal patch).

Yes it does because without domains, we need user pages to be kernel
read-only, which also makes the vectors page kernel read-only.

> > 2. We can't turn domains off without creating a vectors page alias
> 
> Correct.
> 
> > 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches
> >    without additional cache maintainence.
> 
> Correct.
> 
> > I don't think overloading the context switch with yet more conditionals
> > based on yet more TLS combinations is a practical solution.
> 
> Yet another run-time code patching for the TLS, though it gets a bit
> complex.

It _already_ is complex.  We don't need any more complexity there.  Have
a look in asm/tls.h to see that there's already four different cases we
have to consider.

> But we may need to solve it for the v7 filesystem case I mentioned above.

No we don't.  We're already selecting the code appropriately from four
different cases for the supported processor types.  We don't need "maybe
the vectors page is read-only" introducing another two cases with complex
cache flushing and location of the vectors page, and we certainly don't
need this complication at runtime.

> If we can't sort out TLS register setting on v6+v7 kernels (I think we
> should), then we must have the SWP instruction enabled (no emulation).
> Which gets us back to the SWP_EMULATE depend on (CPU_V7 && !CPU_V6).

That I think is the right solution.  It sorts out the issues without
additional overhead.

The only use which SWP_EMULATE gets us then is detecting userspace
programs which use the SWP instruction - and that can only happen on
a V7-only or v6k+v7 targetted kernel.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 13:10                     ` Catalin Marinas
@ 2011-01-28 13:22                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:22 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-omap, linux-arm-kernel

On Fri, Jan 28, 2011 at 01:10:56PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 13:05 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > > v6 is compiled in? If that's the case, we may have a problem - I talked
> > > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > > the TLS register directly without going through the kuser helper.
> > 
> > That's not a problem, because you wouldn't run ARMv7 optimized userspace
> > on an ARMv6 CPU.  That's not what this whole exercise is about.
> 
> But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel
> image compiled for v6+v7.

Yes.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 13:22                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-01-28 13:22 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 28, 2011 at 01:10:56PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 13:05 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > > v6 is compiled in? If that's the case, we may have a problem - I talked
> > > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > > the TLS register directly without going through the kuser helper.
> > 
> > That's not a problem, because you wouldn't run ARMv7 optimized userspace
> > on an ARMv6 CPU.  That's not what this whole exercise is about.
> 
> But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel
> image compiled for v6+v7.

Yes.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 13:21                   ` Russell King - ARM Linux
@ 2011-01-28 15:11                     ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 15:11 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-omap, linux-arm-kernel

On Fri, 2011-01-28 at 13:21 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > v6 is compiled in? If that's the case, we may have a problem - I talked
> > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > the TLS register directly without going through the kuser helper. So you
> > may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> > OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> > expected.
> 
> You're really making a mountain out of TLS.

Not really, just asking for clarification as I haven't checked all your
patches recently.

> If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
> we will use the TLS register if that's available on the hardware.  If it
> isn't, we will write the TLS value directly to virtual 0xffff0ffc.
> 
> So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
> TLS register, and your v7 optimized binaries which access the TLS register
> directly will work.  Same for v6k.

Great.

> What we're discussing has nothing at all to do with getting v7 binaries
> running on v6 hardware.  That's just not going to happen.

I wasn't suggesting this. That's not easily possible.

> > On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
> > page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
> > and use the TLS register. The only other place where this matters on
> > ARMv7 is early_trap_init() but it's easily fixable on this architecture.
> 
> That's pointless.  There's no "could map the vectors page" - set_pte_ext()
> doesn't know what's the vectors page and what isn't.  It's about how
> set_pte_ext() maps pages which are marked with just L_PTE_USER.

What I meant is that we leave cpu_v6_set_pte_ext as it is (with R/W
kernel access for RO user pages) and always mark such pages kernel RO in
cpu_v7_set_pte_ext. See patch at the end of this email.

> > > 1. SWP emulation requires domain support turned off
> >
> > Not necessarily - it requires RO user pages to be kernel RO (though this
> > feature came with the domains removal patch).
> 
> Yes it does because without domains, we need user pages to be kernel
> read-only, which also makes the vectors page kernel read-only.

But even with domains we can make user pages kernel RO for ARMv7 only.

> The only use which SWP_EMULATE gets us then is detecting userspace
> programs which use the SWP instruction - and that can only happen on
> a V7-only or v6k+v7 targetted kernel.

In some MP hardware configurations, SWP may not ensure atomicity across
all the CPUs. Exclusives would ensure this behaviour.

The patch below allows domains to be enabled on ARMv7 and also use SWP
emulation (tested on VE + A9 with domains enabled):


diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
 
 void __init early_trap_init(void)
 {
-#if defined(CONFIG_CPU_USE_DOMAINS)
-	unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
-	unsigned long vectors = (unsigned long)vectors_page;
-#endif
+	unsigned long vectors;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
 	extern char __kuser_helper_start[], __kuser_helper_end[];
 	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
 
 	/*
+	 * On ARMv7, user RO pages are mapped as kernel RO.
+	 */
+	if (cpu_architecture() >= 7)
+		vectors = (unsigned long)vectors_page;
+	else
+		vectors = CONFIG_VECTORS_BASE;
+
+	/*
 	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
 	 * into the vector page, mapped at 0xffff0000, and ensure these
 	 * are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
 
 	tst	r1, #L_PTE_USER
 	orrne	r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
-	@ allow kernel read/write access to read-only user pages
-	tstne	r3, #PTE_EXT_APX
-	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
 
 	tst	r1, #L_PTE_XN
 	orrne	r3, r3, #PTE_EXT_XN



-- 
Catalin



^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 15:11                     ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-01-28 15:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2011-01-28 at 13:21 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > v6 is compiled in? If that's the case, we may have a problem - I talked
> > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > the TLS register directly without going through the kuser helper. So you
> > may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> > OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> > expected.
> 
> You're really making a mountain out of TLS.

Not really, just asking for clarification as I haven't checked all your
patches recently.

> If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
> we will use the TLS register if that's available on the hardware.  If it
> isn't, we will write the TLS value directly to virtual 0xffff0ffc.
> 
> So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
> TLS register, and your v7 optimized binaries which access the TLS register
> directly will work.  Same for v6k.

Great.

> What we're discussing has nothing at all to do with getting v7 binaries
> running on v6 hardware.  That's just not going to happen.

I wasn't suggesting this. That's not easily possible.

> > On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
> > page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
> > and use the TLS register. The only other place where this matters on
> > ARMv7 is early_trap_init() but it's easily fixable on this architecture.
> 
> That's pointless.  There's no "could map the vectors page" - set_pte_ext()
> doesn't know what's the vectors page and what isn't.  It's about how
> set_pte_ext() maps pages which are marked with just L_PTE_USER.

What I meant is that we leave cpu_v6_set_pte_ext as it is (with R/W
kernel access for RO user pages) and always mark such pages kernel RO in
cpu_v7_set_pte_ext. See patch at the end of this email.

> > > 1. SWP emulation requires domain support turned off
> >
> > Not necessarily - it requires RO user pages to be kernel RO (though this
> > feature came with the domains removal patch).
> 
> Yes it does because without domains, we need user pages to be kernel
> read-only, which also makes the vectors page kernel read-only.

But even with domains we can make user pages kernel RO for ARMv7 only.

> The only use which SWP_EMULATE gets us then is detecting userspace
> programs which use the SWP instruction - and that can only happen on
> a V7-only or v6k+v7 targetted kernel.

In some MP hardware configurations, SWP may not ensure atomicity across
all the CPUs. Exclusives would ensure this behaviour.

The patch below allows domains to be enabled on ARMv7 and also use SWP
emulation (tested on VE + A9 with domains enabled):


diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
 
 void __init early_trap_init(void)
 {
-#if defined(CONFIG_CPU_USE_DOMAINS)
-	unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
-	unsigned long vectors = (unsigned long)vectors_page;
-#endif
+	unsigned long vectors;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
 	extern char __kuser_helper_start[], __kuser_helper_end[];
 	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
 
 	/*
+	 * On ARMv7, user RO pages are mapped as kernel RO.
+	 */
+	if (cpu_architecture() >= 7)
+		vectors = (unsigned long)vectors_page;
+	else
+		vectors = CONFIG_VECTORS_BASE;
+
+	/*
 	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
 	 * into the vector page, mapped at 0xffff0000, and ensure these
 	 * are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
 
 	tst	r1, #L_PTE_USER
 	orrne	r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
-	@ allow kernel read/write access to read-only user pages
-	tstne	r3, #PTE_EXT_APX
-	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
 
 	tst	r1, #L_PTE_XN
 	orrne	r3, r3, #PTE_EXT_XN



-- 
Catalin

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
  2011-01-28 15:11                     ` Catalin Marinas
@ 2011-01-28 16:49                       ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-28 16:49 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

* Catalin Marinas <catalin.marinas@arm.com> [110128 07:11]:
> On Fri, 2011-01-28 at 13:21 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > > v6 is compiled in? If that's the case, we may have a problem - I talked
> > > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > > the TLS register directly without going through the kuser helper. So you
> > > may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> > > OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> > > expected.
> > 
> > You're really making a mountain out of TLS.
> 
> Not really, just asking for clarification as I haven't checked all your
> patches recently.
> 
> > If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
> > we will use the TLS register if that's available on the hardware.  If it
> > isn't, we will write the TLS value directly to virtual 0xffff0ffc.
> > 
> > So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
> > TLS register, and your v7 optimized binaries which access the TLS register
> > directly will work.  Same for v6k.
> 
> Great.

Yes AFAIK we sorted out the TLS issue already a while back for v6+v6k+v7.

Regards,

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K
@ 2011-01-28 16:49                       ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-01-28 16:49 UTC (permalink / raw)
  To: linux-arm-kernel

* Catalin Marinas <catalin.marinas@arm.com> [110128 07:11]:
> On Fri, 2011-01-28 at 13:21 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 12:25:18PM +0000, Catalin Marinas wrote:
> > > With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
> > > v6 is compiled in? If that's the case, we may have a problem - I talked
> > > to the toolchain guys and it looks like code optimised for ARMv7 reads
> > > the TLS register directly without going through the kuser helper. So you
> > > may have people taking an Ubuntu filesystem (v7 only) and a pre-built
> > > OMAP image with TLS emulation even on Cortex-A8 and things won't work as
> > > expected.
> > 
> > You're really making a mountain out of TLS.
> 
> Not really, just asking for clarification as I haven't checked all your
> patches recently.
> 
> > If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
> > we will use the TLS register if that's available on the hardware.  If it
> > isn't, we will write the TLS value directly to virtual 0xffff0ffc.
> > 
> > So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
> > TLS register, and your v7 optimized binaries which access the TLS register
> > directly will work.  Same for v6k.
> 
> Great.

Yes AFAIK we sorted out the TLS issue already a while back for v6+v6k+v7.

Regards,

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-01-17 19:20 ` Russell King - ARM Linux
@ 2011-02-08 16:36   ` Santosh Shilimkar
  -1 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 16:36 UTC (permalink / raw)
  To: Russell King - ARM Linux, linux-arm-kernel, linux-omap

Russell,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Tuesday, January 18, 2011 12:51 AM
> To: linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.
>
> Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting
> CPU_32v6K
> if we have the K extensions.  CPU_32v6K directly controlled whether
> we should include the ARMv6K instructions (clrex, load/store
> exclusive
> byte, half-word, double).  As the bitops code uses the load/store
> exclusive byte operations, unsetting CPU_32v6K results in these
> falling back to their non-SMP local-irq-disabling variants.  These
> are only safe in uniprocessor environments.
>
> So, the first two patches convert the bitops to use the ARMv6
> load/store
> exclusive word operations - and ensuring correctness by ensuring
> that
> the pointer passed in is word-aligned.
>
> We then introduce a new CPU_V6K which indicates that we're including
> an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
> including an ARMv6 non-K CPU.
>
> We can then use CPU_V6 to ensure that the non-v6K code paths which
> are
> still SMP safe are selected.
>
> Without this patch set, such a kernel will be unsafe when run on
> SMP platforms as it omits necessary SMP code to ensure that bit
> operations are safe.
> --

Have tested this series on OMAP4430 and OMAP3430.
Don't know if it helps to push some of these patches to be part
of rc cycles. At least the SMP specific fixes should get merged
otherwise, builds like omap2plus_defconfig won't be running
right configuration on SMP machine.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-08 16:36   ` Santosh Shilimkar
  0 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 16:36 UTC (permalink / raw)
  To: linux-arm-kernel

Russell,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Tuesday, January 18, 2011 12:51 AM
> To: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
> Subject: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> This patch series reworks the ARMv6/ARMv6K support options, code
> selection, and bit operations such that it's possible to safely
> build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
> in one image.
>
> Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting
> CPU_32v6K
> if we have the K extensions.  CPU_32v6K directly controlled whether
> we should include the ARMv6K instructions (clrex, load/store
> exclusive
> byte, half-word, double).  As the bitops code uses the load/store
> exclusive byte operations, unsetting CPU_32v6K results in these
> falling back to their non-SMP local-irq-disabling variants.  These
> are only safe in uniprocessor environments.
>
> So, the first two patches convert the bitops to use the ARMv6
> load/store
> exclusive word operations - and ensuring correctness by ensuring
> that
> the pointer passed in is word-aligned.
>
> We then introduce a new CPU_V6K which indicates that we're including
> an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're
> including an ARMv6 non-K CPU.
>
> We can then use CPU_V6 to ensure that the non-v6K code paths which
> are
> still SMP safe are selected.
>
> Without this patch set, such a kernel will be unsafe when run on
> SMP platforms as it omits necessary SMP code to ensure that bit
> operations are safe.
> --

Have tested this series on OMAP4430 and OMAP3430.
Don't know if it helps to push some of these patches to be part
of rc cycles. At least the SMP specific fixes should get merged
otherwise, builds like omap2plus_defconfig won't be running
right configuration on SMP machine.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-08 16:36   ` Santosh Shilimkar
@ 2011-02-08 16:47     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-08 16:47 UTC (permalink / raw)
  To: Santosh Shilimkar; +Cc: linux-arm-kernel, linux-omap

On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
> Have tested this series on OMAP4430 and OMAP3430.
> Don't know if it helps to push some of these patches to be part
> of rc cycles. At least the SMP specific fixes should get merged
> otherwise, builds like omap2plus_defconfig won't be running
> right configuration on SMP machine.

It's _too_ _late_ in the rc cycle for a fix of this size.  As I've said
(several times) it was only possible for rc1.  That boat has been missed
as we're now on rc4.  We could see 2.6.38 in as little as two weeks time.

 27 files changed, 183 insertions(+), 197 deletions(-)

is too big.

There's still the outstanding question over:

  ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K

which remains unsettled.

I think it's probably going to be better to _purposely_ break the OMAP
build when it covers v6 and v7 CPUs in these kernels as I don't think it's
sanely fixable given where we are.  Again, that's something I _did_ point
out at the time.

I really can't help it if there is a lack of co-operation from people to
get necessary fixes properly tested in a timely manner.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-08 16:47     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-08 16:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
> Have tested this series on OMAP4430 and OMAP3430.
> Don't know if it helps to push some of these patches to be part
> of rc cycles. At least the SMP specific fixes should get merged
> otherwise, builds like omap2plus_defconfig won't be running
> right configuration on SMP machine.

It's _too_ _late_ in the rc cycle for a fix of this size.  As I've said
(several times) it was only possible for rc1.  That boat has been missed
as we're now on rc4.  We could see 2.6.38 in as little as two weeks time.

 27 files changed, 183 insertions(+), 197 deletions(-)

is too big.

There's still the outstanding question over:

  ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K

which remains unsettled.

I think it's probably going to be better to _purposely_ break the OMAP
build when it covers v6 and v7 CPUs in these kernels as I don't think it's
sanely fixable given where we are.  Again, that's something I _did_ point
out@the time.

I really can't help it if there is a lack of co-operation from people to
get necessary fixes properly tested in a timely manner.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-08 16:47     ` Russell King - ARM Linux
@ 2011-02-08 16:58       ` Santosh Shilimkar
  -1 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 16:58 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: linux-arm-kernel, linux-omap

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Tuesday, February 08, 2011 10:18 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
> > Have tested this series on OMAP4430 and OMAP3430.
> > Don't know if it helps to push some of these patches to be part
> > of rc cycles. At least the SMP specific fixes should get merged
> > otherwise, builds like omap2plus_defconfig won't be running
> > right configuration on SMP machine.
>
> It's _too_ _late_ in the rc cycle for a fix of this size.  As I've
> said
> (several times) it was only possible for rc1.  That boat has been
> missed
> as we're now on rc4.  We could see 2.6.38 in as little as two weeks
> time.
>
>  27 files changed, 183 insertions(+), 197 deletions(-)
>
> is too big.
>
Ok. Sorry about delay in testing out these patches.

> There's still the outstanding question over:
>
>   ARM: v6k: use CPU domain feature if we include support for arch <
> ARMv6K
>
> which remains unsettled.
>
> I think it's probably going to be better to _purposely_ break the
> OMAP
> build when it covers v6 and v7 CPUs in these kernels as I don't
> think it's
> sanely fixable given where we are.  Again, that's something I _did_
> point out at the time.
>
Any alternative possible other than breaking the omap2plus build?
It's quite useful to have one build which covers majority of the
omap machines.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-08 16:58       ` Santosh Shilimkar
  0 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 16:58 UTC (permalink / raw)
  To: linux-arm-kernel

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, February 08, 2011 10:18 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
> > Have tested this series on OMAP4430 and OMAP3430.
> > Don't know if it helps to push some of these patches to be part
> > of rc cycles. At least the SMP specific fixes should get merged
> > otherwise, builds like omap2plus_defconfig won't be running
> > right configuration on SMP machine.
>
> It's _too_ _late_ in the rc cycle for a fix of this size.  As I've
> said
> (several times) it was only possible for rc1.  That boat has been
> missed
> as we're now on rc4.  We could see 2.6.38 in as little as two weeks
> time.
>
>  27 files changed, 183 insertions(+), 197 deletions(-)
>
> is too big.
>
Ok. Sorry about delay in testing out these patches.

> There's still the outstanding question over:
>
>   ARM: v6k: use CPU domain feature if we include support for arch <
> ARMv6K
>
> which remains unsettled.
>
> I think it's probably going to be better to _purposely_ break the
> OMAP
> build when it covers v6 and v7 CPUs in these kernels as I don't
> think it's
> sanely fixable given where we are.  Again, that's something I _did_
> point out at the time.
>
Any alternative possible other than breaking the omap2plus build?
It's quite useful to have one build which covers majority of the
omap machines.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-08 16:58       ` Santosh Shilimkar
@ 2011-02-08 20:43         ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-08 20:43 UTC (permalink / raw)
  To: Santosh Shilimkar; +Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

On Tue, 8 Feb 2011, Santosh Shilimkar wrote:

> > I think it's probably going to be better to _purposely_ break the 
> > OMAP build when it covers v6 and v7 CPUs in these kernels as I don't 
> > think it's sanely fixable given where we are.

Agreed.  At least making SMP unavailable when both v6 and v7 are 
configured should be small and good enough for 2.6.38-rc5.

> Any alternative possible other than breaking the omap2plus build?
> It's quite useful to have one build which covers majority of the
> omap machines.

Just merge this patch series in your testing tree, or create two configs 
(two builds) instead of only (a broken) one.

Or use linux-next for testing which would be even more beneficial.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-08 20:43         ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-08 20:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 8 Feb 2011, Santosh Shilimkar wrote:

> > I think it's probably going to be better to _purposely_ break the 
> > OMAP build when it covers v6 and v7 CPUs in these kernels as I don't 
> > think it's sanely fixable given where we are.

Agreed.  At least making SMP unavailable when both v6 and v7 are 
configured should be small and good enough for 2.6.38-rc5.

> Any alternative possible other than breaking the omap2plus build?
> It's quite useful to have one build which covers majority of the
> omap machines.

Just merge this patch series in your testing tree, or create two configs 
(two builds) instead of only (a broken) one.

Or use linux-next for testing which would be even more beneficial.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-08 20:43         ` Nicolas Pitre
@ 2011-02-09  0:35           ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09  0:35 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Santosh Shilimkar, Russell King - ARM Linux, linux-omap,
	linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> 
> > > I think it's probably going to be better to _purposely_ break the 
> > > OMAP build when it covers v6 and v7 CPUs in these kernels as I don't 
> > > think it's sanely fixable given where we are.
> 
> Agreed.  At least making SMP unavailable when both v6 and v7 are 
> configured should be small and good enough for 2.6.38-rc5.

That's probably the best solution as then we can still do boot
testing on all omap2plus_defconfig boards.

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09  0:35           ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09  0:35 UTC (permalink / raw)
  To: linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> 
> > > I think it's probably going to be better to _purposely_ break the 
> > > OMAP build when it covers v6 and v7 CPUs in these kernels as I don't 
> > > think it's sanely fixable given where we are.
> 
> Agreed.  At least making SMP unavailable when both v6 and v7 are 
> configured should be small and good enough for 2.6.38-rc5.

That's probably the best solution as then we can still do boot
testing on all omap2plus_defconfig boards.

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09  0:35           ` Tony Lindgren
@ 2011-02-09  6:04             ` Santosh Shilimkar
  -1 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09  6:04 UTC (permalink / raw)
  To: Tony Lindgren, Nicolas Pitre
  Cc: Russell King - ARM Linux, linux-omap, linux-arm-kernel

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Wednesday, February 09, 2011 6:06 AM
> To: Nicolas Pitre
> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> >
> > > > I think it's probably going to be better to _purposely_ break
> the
> > > > OMAP build when it covers v6 and v7 CPUs in these kernels as I
> don't
> > > > think it's sanely fixable given where we are.
> >
> > Agreed.  At least making SMP unavailable when both v6 and v7 are
> > configured should be small and good enough for 2.6.38-rc5.
>
> That's probably the best solution as then we can still do boot
> testing on all omap2plus_defconfig boards.
>
Just to be clear, are we saying disable SMP from omap2plus build.
If the v6, v7 is not fixable then, we also need a SMP
config for OMAP. Just boot test with SMP disable config for
OMAP4 is not enough.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09  6:04             ` Santosh Shilimkar
  0 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09  6:04 UTC (permalink / raw)
  To: linux-arm-kernel

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Wednesday, February 09, 2011 6:06 AM
> To: Nicolas Pitre
> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> >
> > > > I think it's probably going to be better to _purposely_ break
> the
> > > > OMAP build when it covers v6 and v7 CPUs in these kernels as I
> don't
> > > > think it's sanely fixable given where we are.
> >
> > Agreed.  At least making SMP unavailable when both v6 and v7 are
> > configured should be small and good enough for 2.6.38-rc5.
>
> That's probably the best solution as then we can still do boot
> testing on all omap2plus_defconfig boards.
>
Just to be clear, are we saying disable SMP from omap2plus build.
If the v6, v7 is not fixable then, we also need a SMP
config for OMAP. Just boot test with SMP disable config for
OMAP4 is not enough.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09  6:04             ` Santosh Shilimkar
@ 2011-02-09  9:48               ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-09  9:48 UTC (permalink / raw)
  To: Santosh Shilimkar
  Cc: Tony Lindgren, Nicolas Pitre, linux-omap,
	Russell King - ARM Linux, linux-arm-kernel

On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Tony Lindgren
>> Sent: Wednesday, February 09, 2011 6:06 AM
>> To: Nicolas Pitre
>> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
>> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
>> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>>
>> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
>> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
>> >
>> > > > I think it's probably going to be better to _purposely_ break
>> the
>> > > > OMAP build when it covers v6 and v7 CPUs in these kernels as I
>> don't
>> > > > think it's sanely fixable given where we are.
>> >
>> > Agreed.  At least making SMP unavailable when both v6 and v7 are
>> > configured should be small and good enough for 2.6.38-rc5.
>>
>> That's probably the best solution as then we can still do boot
>> testing on all omap2plus_defconfig boards.
>>
> Just to be clear, are we saying disable SMP from omap2plus build.
> If the v6, v7 is not fixable then, we also need a SMP
> config for OMAP. Just boot test with SMP disable config for
> OMAP4 is not enough.

You could also have a "v7+" unified kernel -- i.e., supporting OMAP3+4+SMP.
This is what we currently do in Linaro, since we're focusing on v7 and above.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09  9:48               ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-09  9:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
>> owner at vger.kernel.org] On Behalf Of Tony Lindgren
>> Sent: Wednesday, February 09, 2011 6:06 AM
>> To: Nicolas Pitre
>> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>>
>> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
>> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
>> >
>> > > > I think it's probably going to be better to _purposely_ break
>> the
>> > > > OMAP build when it covers v6 and v7 CPUs in these kernels as I
>> don't
>> > > > think it's sanely fixable given where we are.
>> >
>> > Agreed. ?At least making SMP unavailable when both v6 and v7 are
>> > configured should be small and good enough for 2.6.38-rc5.
>>
>> That's probably the best solution as then we can still do boot
>> testing on all omap2plus_defconfig boards.
>>
> Just to be clear, are we saying disable SMP from omap2plus build.
> If the v6, v7 is not fixable then, we also need a SMP
> config for OMAP. Just boot test with SMP disable config for
> OMAP4 is not enough.

You could also have a "v7+" unified kernel -- i.e., supporting OMAP3+4+SMP.
This is what we currently do in Linaro, since we're focusing on v7 and above.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09  9:48               ` Dave Martin
@ 2011-02-09 10:00                 ` Santosh Shilimkar
  -1 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09 10:00 UTC (permalink / raw)
  To: Dave Martin, Tony Lindgren
  Cc: Nicolas Pitre, linux-omap, Russell King - ARM Linux, linux-arm-kernel

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Wednesday, February 09, 2011 3:18 PM
> To: Santosh Shilimkar
> Cc: Tony Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org;
> Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> >> Sent: Wednesday, February 09, 2011 6:06 AM
> >> To: Nicolas Pitre
> >> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
> >> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> >> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
> >>
> >> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> >> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> >> >
> >> > > > I think it's probably going to be better to _purposely_
> break
> >> the
> >> > > > OMAP build when it covers v6 and v7 CPUs in these kernels
> as I
> >> don't
> >> > > > think it's sanely fixable given where we are.
> >> >
> >> > Agreed.  At least making SMP unavailable when both v6 and v7
> are
> >> > configured should be small and good enough for 2.6.38-rc5.
> >>
> >> That's probably the best solution as then we can still do boot
> >> testing on all omap2plus_defconfig boards.
> >>
> > Just to be clear, are we saying disable SMP from omap2plus build.
> > If the v6, v7 is not fixable then, we also need a SMP
> > config for OMAP. Just boot test with SMP disable config for
> > OMAP4 is not enough.
>
> You could also have a "v7+" unified kernel -- i.e., supporting
> OMAP3+4+SMP.
> This is what we currently do in Linaro, since we're focusing on v7
> and above.
>
This sounds good way forward considering future OMAP architectures
as well.

But I let Tony comment on this idea.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 10:00                 ` Santosh Shilimkar
  0 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09 10:00 UTC (permalink / raw)
  To: linux-arm-kernel

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Wednesday, February 09, 2011 3:18 PM
> To: Santosh Shilimkar
> Cc: Tony Lindgren; Nicolas Pitre; linux-omap at vger.kernel.org;
> Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> >> owner at vger.kernel.org] On Behalf Of Tony Lindgren
> >> Sent: Wednesday, February 09, 2011 6:06 AM
> >> To: Nicolas Pitre
> >> Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
> >> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
> >>
> >> * Nicolas Pitre <nico@fluxnic.net> [110208 12:41]:
> >> > On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> >> >
> >> > > > I think it's probably going to be better to _purposely_
> break
> >> the
> >> > > > OMAP build when it covers v6 and v7 CPUs in these kernels
> as I
> >> don't
> >> > > > think it's sanely fixable given where we are.
> >> >
> >> > Agreed. ?At least making SMP unavailable when both v6 and v7
> are
> >> > configured should be small and good enough for 2.6.38-rc5.
> >>
> >> That's probably the best solution as then we can still do boot
> >> testing on all omap2plus_defconfig boards.
> >>
> > Just to be clear, are we saying disable SMP from omap2plus build.
> > If the v6, v7 is not fixable then, we also need a SMP
> > config for OMAP. Just boot test with SMP disable config for
> > OMAP4 is not enough.
>
> You could also have a "v7+" unified kernel -- i.e., supporting
> OMAP3+4+SMP.
> This is what we currently do in Linaro, since we're focusing on v7
> and above.
>
This sounds good way forward considering future OMAP architectures
as well.

But I let Tony comment on this idea.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-08 16:47     ` Russell King - ARM Linux
@ 2011-02-09 10:01       ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-02-09 10:01 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Santosh Shilimkar, linux-omap, linux-arm-kernel

On 8 February 2011 16:47, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
>> Have tested this series on OMAP4430 and OMAP3430.
>> Don't know if it helps to push some of these patches to be part
>> of rc cycles. At least the SMP specific fixes should get merged
>> otherwise, builds like omap2plus_defconfig won't be running
>> right configuration on SMP machine.
>
> It's _too_ _late_ in the rc cycle for a fix of this size.  As I've said
> (several times) it was only possible for rc1.  That boat has been missed
> as we're now on rc4.  We could see 2.6.38 in as little as two weeks time.
>
>  27 files changed, 183 insertions(+), 197 deletions(-)
>
> is too big.
>
> There's still the outstanding question over:
>
>  ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K

Could we make the domains usage a run-time feature based on the
architecture version? For ARMv7, we need to have the vectors page
read-only anyway if the SWP emulation is enabled (and I posted a
simple patch in a reply to your email).

The issue I see is that ARM11MPCore is reported as v7 though we still
use domains on this processor (we could always remove the domains if
TLS register is available or use some more precise architecture
version identification).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 10:01       ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-02-09 10:01 UTC (permalink / raw)
  To: linux-arm-kernel

On 8 February 2011 16:47, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
>> Have tested this series on OMAP4430 and OMAP3430.
>> Don't know if it helps to push some of these patches to be part
>> of rc cycles. At least the SMP specific fixes should get merged
>> otherwise, builds like omap2plus_defconfig won't be running
>> right configuration on SMP machine.
>
> It's _too_ _late_ in the rc cycle for a fix of this size. ?As I've said
> (several times) it was only possible for rc1. ?That boat has been missed
> as we're now on rc4. ?We could see 2.6.38 in as little as two weeks time.
>
> ?27 files changed, 183 insertions(+), 197 deletions(-)
>
> is too big.
>
> There's still the outstanding question over:
>
> ?ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K

Could we make the domains usage a run-time feature based on the
architecture version? For ARMv7, we need to have the vectors page
read-only anyway if the SWP emulation is enabled (and I posted a
simple patch in a reply to your email).

The issue I see is that ARM11MPCore is reported as v7 though we still
use domains on this processor (we could always remove the domains if
TLS register is available or use some more precise architecture
version identification).

-- 
Catalin

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-01-26 17:25                   ` Dave P. Martin
@ 2011-02-09 14:22                     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 14:22 UTC (permalink / raw)
  To: Dave P. Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
> SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> discarded at link-time.  In particular this may happen for built-in
> __exit stuff.
> 
> This patch modifies the vmlinux linker script to reduce the amount
> of discarded sections, and tries to make sure that __exit sections
> are kept in.
> 
> This is a hack and probably wrong!  Further discussion is needed.  

Can you send the configuration which you see this problem with?
I've tried to build a kernel which inlines the spinlocks, but I find
that's not possible, so I'm doubting whether any fix is required for
mainline.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-09 14:22                     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 14:22 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
> SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> discarded at link-time.  In particular this may happen for built-in
> __exit stuff.
> 
> This patch modifies the vmlinux linker script to reduce the amount
> of discarded sections, and tries to make sure that __exit sections
> are kept in.
> 
> This is a hack and probably wrong!  Further discussion is needed.  

Can you send the configuration which you see this problem with?
I've tried to build a kernel which inlines the spinlocks, but I find
that's not possible, so I'm doubting whether any fix is required for
mainline.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 10:00                 ` Santosh Shilimkar
@ 2011-02-09 16:24                   ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09 16:24 UTC (permalink / raw)
  To: Santosh Shilimkar
  Cc: Dave Martin, Nicolas Pitre, linux-omap, Russell King - ARM Linux,
	linux-arm-kernel

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > From: Dave Martin [mailto:dave.martin@linaro.org]
> >
> > You could also have a "v7+" unified kernel -- i.e., supporting
> > OMAP3+4+SMP.
> > This is what we currently do in Linaro, since we're focusing on v7
> > and above.
> >
> This sounds good way forward considering future OMAP architectures
> as well.
> 
> But I let Tony comment on this idea.

AFAIK these issues will be hopefully sorted out by the time the
next merge window opens. For the -rc cycle, disabling SMP in
config if ARMv6 is selected should do the trick.

Regards,

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 16:24                   ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09 16:24 UTC (permalink / raw)
  To: linux-arm-kernel

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > From: Dave Martin [mailto:dave.martin at linaro.org]
> >
> > You could also have a "v7+" unified kernel -- i.e., supporting
> > OMAP3+4+SMP.
> > This is what we currently do in Linaro, since we're focusing on v7
> > and above.
> >
> This sounds good way forward considering future OMAP architectures
> as well.
> 
> But I let Tony comment on this idea.

AFAIK these issues will be hopefully sorted out by the time the
next merge window opens. For the -rc cycle, disabling SMP in
config if ARMv6 is selected should do the trick.

Regards,

Tony

^ permalink raw reply	[flat|nested] 254+ messages in thread

* RE: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 16:24                   ` Tony Lindgren
@ 2011-02-09 16:27                     ` Santosh Shilimkar
  -1 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09 16:27 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Dave Martin, Nicolas Pitre, linux-omap, Russell King - ARM Linux,
	linux-arm-kernel

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, February 09, 2011 9:54 PM
> To: Santosh Shilimkar
> Cc: Dave Martin; Nicolas Pitre; linux-omap@vger.kernel.org; Russell
> King - ARM Linux; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > >
> > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > OMAP3+4+SMP.
> > > This is what we currently do in Linaro, since we're focusing on
> v7
> > > and above.
> > >
> > This sounds good way forward considering future OMAP architectures
> > as well.
> >
> > But I let Tony comment on this idea.
>
> AFAIK these issues will be hopefully sorted out by the time the
> next merge window opens. For the -rc cycle, disabling SMP in
> config if ARMv6 is selected should do the trick.
>
Ok.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 16:27                     ` Santosh Shilimkar
  0 siblings, 0 replies; 254+ messages in thread
From: Santosh Shilimkar @ 2011-02-09 16:27 UTC (permalink / raw)
  To: linux-arm-kernel

> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Wednesday, February 09, 2011 9:54 PM
> To: Santosh Shilimkar
> Cc: Dave Martin; Nicolas Pitre; linux-omap at vger.kernel.org; Russell
> King - ARM Linux; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > >
> > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > OMAP3+4+SMP.
> > > This is what we currently do in Linaro, since we're focusing on
> v7
> > > and above.
> > >
> > This sounds good way forward considering future OMAP architectures
> > as well.
> >
> > But I let Tony comment on this idea.
>
> AFAIK these issues will be hopefully sorted out by the time the
> next merge window opens. For the -rc cycle, disabling SMP in
> config if ARMv6 is selected should do the trick.
>
Ok.

Regards,
Santosh

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 16:24                   ` Tony Lindgren
@ 2011-02-09 16:32                     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 16:32 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Santosh Shilimkar, Dave Martin, Nicolas Pitre, linux-omap,
	linux-arm-kernel

On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > >
> > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > OMAP3+4+SMP.
> > > This is what we currently do in Linaro, since we're focusing on v7
> > > and above.
> > >
> > This sounds good way forward considering future OMAP architectures
> > as well.
> > 
> > But I let Tony comment on this idea.
> 
> AFAIK these issues will be hopefully sorted out by the time the
> next merge window opens. For the -rc cycle, disabling SMP in
> config if ARMv6 is selected should do the trick.

That's not soo easy - as we don't know in the Kconfig whether we include
ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
inflated the v6v7 patchset.

Maybe the best thing to do is:

config CPU_32v6K
        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
resulting undefined instruction traps if they try to run the kernel on
V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
to this.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 16:32                     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 16:32 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > >
> > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > OMAP3+4+SMP.
> > > This is what we currently do in Linaro, since we're focusing on v7
> > > and above.
> > >
> > This sounds good way forward considering future OMAP architectures
> > as well.
> > 
> > But I let Tony comment on this idea.
> 
> AFAIK these issues will be hopefully sorted out by the time the
> next merge window opens. For the -rc cycle, disabling SMP in
> config if ARMv6 is selected should do the trick.

That's not soo easy - as we don't know in the Kconfig whether we include
ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
inflated the v6v7 patchset.

Maybe the best thing to do is:

config CPU_32v6K
        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
resulting undefined instruction traps if they try to run the kernel on
V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
to this.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 16:32                     ` Russell King - ARM Linux
@ 2011-02-09 16:44                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 16:44 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Santosh Shilimkar, Dave Martin, Nicolas Pitre, linux-omap,
	linux-arm-kernel

On Wed, Feb 09, 2011 at 04:32:04PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > > >
> > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > OMAP3+4+SMP.
> > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > and above.
> > > >
> > > This sounds good way forward considering future OMAP architectures
> > > as well.
> > > 
> > > But I let Tony comment on this idea.
> > 
> > AFAIK these issues will be hopefully sorted out by the time the
> > next merge window opens. For the -rc cycle, disabling SMP in
> > config if ARMv6 is selected should do the trick.
> 
> That's not soo easy - as we don't know in the Kconfig whether we include
> ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> inflated the v6v7 patchset.
> 
> Maybe the best thing to do is:
> 
> config CPU_32v6K
>         bool "Support ARM V6K processor extensions" if !SMP
>         depends on CPU_V6 || CPU_V7
>         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> 
> drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> resulting undefined instruction traps if they try to run the kernel on
> V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> to this.

Right, this is what I propose.  Merging this will cause conflicts with
the v6v7 patchset.

8<-----
Subject: [PATCH] ARM: Avoid building unsafe kernels on OMAP2 and MX3

OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which
when they include support for SMP kernels means that the resulting
kernel is unsafe on SMP and can result in corrupted filesystems as we
end up using unsafe bitops.

Re-enable the use of V6K instructions on such kernels, and let such
kernels running on V6 CPUs eat undefined instruction faults which will
be much safer than filesystem corruption.  Next merge window we can fix
this properly (as it requires a much bigger set of changes.)

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9d30c6f..c9d2d56 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
@@ -416,7 +416,7 @@ config CPU_32v6K
 # ARMv7
 config CPU_V7
 	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
 	select CPU_PABRT_V7
-- 
1.6.2.5



^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 16:44                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-09 16:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Feb 09, 2011 at 04:32:04PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > > >
> > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > OMAP3+4+SMP.
> > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > and above.
> > > >
> > > This sounds good way forward considering future OMAP architectures
> > > as well.
> > > 
> > > But I let Tony comment on this idea.
> > 
> > AFAIK these issues will be hopefully sorted out by the time the
> > next merge window opens. For the -rc cycle, disabling SMP in
> > config if ARMv6 is selected should do the trick.
> 
> That's not soo easy - as we don't know in the Kconfig whether we include
> ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> inflated the v6v7 patchset.
> 
> Maybe the best thing to do is:
> 
> config CPU_32v6K
>         bool "Support ARM V6K processor extensions" if !SMP
>         depends on CPU_V6 || CPU_V7
>         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> 
> drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> resulting undefined instruction traps if they try to run the kernel on
> V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> to this.

Right, this is what I propose.  Merging this will cause conflicts with
the v6v7 patchset.

8<-----
Subject: [PATCH] ARM: Avoid building unsafe kernels on OMAP2 and MX3

OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which
when they include support for SMP kernels means that the resulting
kernel is unsafe on SMP and can result in corrupted filesystems as we
end up using unsafe bitops.

Re-enable the use of V6K instructions on such kernels, and let such
kernels running on V6 CPUs eat undefined instruction faults which will
be much safer than filesystem corruption.  Next merge window we can fix
this properly (as it requires a much bigger set of changes.)

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9d30c6f..c9d2d56 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
@@ -416,7 +416,7 @@ config CPU_32v6K
 # ARMv7
 config CPU_V7
 	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
-	select CPU_32v6K if !ARCH_OMAP2
+	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
 	select CPU_PABRT_V7
-- 
1.6.2.5

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 16:32                     ` Russell King - ARM Linux
@ 2011-02-09 16:45                       ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-09 16:45 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Tony Lindgren, Santosh Shilimkar, Dave Martin, linux-omap,
	linux-arm-kernel

On Wed, 9 Feb 2011, Russell King - ARM Linux wrote:

> On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > > >
> > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > OMAP3+4+SMP.
> > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > and above.
> > > >
> > > This sounds good way forward considering future OMAP architectures
> > > as well.
> > > 
> > > But I let Tony comment on this idea.
> > 
> > AFAIK these issues will be hopefully sorted out by the time the
> > next merge window opens. For the -rc cycle, disabling SMP in
> > config if ARMv6 is selected should do the trick.
> 
> That's not soo easy - as we don't know in the Kconfig whether we include
> ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> inflated the v6v7 patchset.
> 
> Maybe the best thing to do is:
> 
> config CPU_32v6K
>         bool "Support ARM V6K processor extensions" if !SMP
>         depends on CPU_V6 || CPU_V7
>         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> 
> drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> resulting undefined instruction traps if they try to run the kernel on
> V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> to this.

This should be good enough.  We're looking for a temporary stopgate 
solution to prevent people from corrupting their data, and the real fix 
will be available in the next kernel.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 16:45                       ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-09 16:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 9 Feb 2011, Russell King - ARM Linux wrote:

> On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > > >
> > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > OMAP3+4+SMP.
> > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > and above.
> > > >
> > > This sounds good way forward considering future OMAP architectures
> > > as well.
> > > 
> > > But I let Tony comment on this idea.
> > 
> > AFAIK these issues will be hopefully sorted out by the time the
> > next merge window opens. For the -rc cycle, disabling SMP in
> > config if ARMv6 is selected should do the trick.
> 
> That's not soo easy - as we don't know in the Kconfig whether we include
> ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> inflated the v6v7 patchset.
> 
> Maybe the best thing to do is:
> 
> config CPU_32v6K
>         bool "Support ARM V6K processor extensions" if !SMP
>         depends on CPU_V6 || CPU_V7
>         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> 
> drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> resulting undefined instruction traps if they try to run the kernel on
> V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> to this.

This should be good enough.  We're looking for a temporary stopgate 
solution to prevent people from corrupting their data, and the real fix 
will be available in the next kernel.


Nicolas

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 16:45                       ` Nicolas Pitre
@ 2011-02-09 17:48                         ` Tony Lindgren
  -1 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09 17:48 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Santosh Shilimkar, Dave Martin,
	linux-omap, linux-arm-kernel

* Nicolas Pitre <nicolas.pitre@linaro.org> [110209 08:44]:
> On Wed, 9 Feb 2011, Russell King - ARM Linux wrote:
> 
> > On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > > > >
> > > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > > OMAP3+4+SMP.
> > > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > > and above.
> > > > >
> > > > This sounds good way forward considering future OMAP architectures
> > > > as well.
> > > > 
> > > > But I let Tony comment on this idea.
> > > 
> > > AFAIK these issues will be hopefully sorted out by the time the
> > > next merge window opens. For the -rc cycle, disabling SMP in
> > > config if ARMv6 is selected should do the trick.
> > 
> > That's not soo easy - as we don't know in the Kconfig whether we include
> > ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> > inflated the v6v7 patchset.
> > 
> > Maybe the best thing to do is:
> > 
> > config CPU_32v6K
> >         bool "Support ARM V6K processor extensions" if !SMP
> >         depends on CPU_V6 || CPU_V7
> >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > 
> > drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> > resulting undefined instruction traps if they try to run the kernel on
> > V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> > to this.
> 
> This should be good enough.  We're looking for a temporary stopgate 
> solution to prevent people from corrupting their data, and the real fix 
> will be available in the next kernel.

OK. This patch will be needed anyways for the real fixes. And no temporary
apply-undo type patching needed. The only drawback is that omap2420 and
2430 won't boot with omap2plus_defconfig, but that will be only for a
few weeks.

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-09 17:48                         ` Tony Lindgren
  0 siblings, 0 replies; 254+ messages in thread
From: Tony Lindgren @ 2011-02-09 17:48 UTC (permalink / raw)
  To: linux-arm-kernel

* Nicolas Pitre <nicolas.pitre@linaro.org> [110209 08:44]:
> On Wed, 9 Feb 2011, Russell King - ARM Linux wrote:
> 
> > On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110209 01:59]:
> > > > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > > > >
> > > > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > > > OMAP3+4+SMP.
> > > > > This is what we currently do in Linaro, since we're focusing on v7
> > > > > and above.
> > > > >
> > > > This sounds good way forward considering future OMAP architectures
> > > > as well.
> > > > 
> > > > But I let Tony comment on this idea.
> > > 
> > > AFAIK these issues will be hopefully sorted out by the time the
> > > next merge window opens. For the -rc cycle, disabling SMP in
> > > config if ARMv6 is selected should do the trick.
> > 
> > That's not soo easy - as we don't know in the Kconfig whether we include
> > ARMv6 rather than ARMv6K.  It's exactly the same problem I ran into which
> > inflated the v6v7 patchset.
> > 
> > Maybe the best thing to do is:
> > 
> > config CPU_32v6K
> >         bool "Support ARM V6K processor extensions" if !SMP
> >         depends on CPU_V6 || CPU_V7
> >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > 
> > drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the
> > resulting undefined instruction traps if they try to run the kernel on
> > V6 non-K hardware.  Not ideal, but I don't see any other 'simple' solution
> > to this.
> 
> This should be good enough.  We're looking for a temporary stopgate 
> solution to prevent people from corrupting their data, and the real fix 
> will be available in the next kernel.

OK. This patch will be needed anyways for the real fixes. And no temporary
apply-undo type patching needed. The only drawback is that omap2420 and
2430 won't boot with omap2plus_defconfig, but that will be only for a
few weeks.

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-09 14:22                     ` Russell King - ARM Linux
@ 2011-02-10 12:56                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 12:56 UTC (permalink / raw)
  To: Dave P. Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> > discarded at link-time.  In particular this may happen for built-in
> > __exit stuff.
> > 
> > This patch modifies the vmlinux linker script to reduce the amount
> > of discarded sections, and tries to make sure that __exit sections
> > are kept in.
> > 
> > This is a hack and probably wrong!  Further discussion is needed.  
> 
> Can you send the configuration which you see this problem with?
> I've tried to build a kernel which inlines the spinlocks, but I find
> that's not possible, so I'm doubting whether any fix is required for
> mainline.

Any news on this, or can it not be reproduced?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 12:56                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 12:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> > discarded at link-time.  In particular this may happen for built-in
> > __exit stuff.
> > 
> > This patch modifies the vmlinux linker script to reduce the amount
> > of discarded sections, and tries to make sure that __exit sections
> > are kept in.
> > 
> > This is a hack and probably wrong!  Further discussion is needed.  
> 
> Can you send the configuration which you see this problem with?
> I've tried to build a kernel which inlines the spinlocks, but I find
> that's not possible, so I'm doubting whether any fix is required for
> mainline.

Any news on this, or can it not be reproduced?

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-09 10:01       ` Catalin Marinas
@ 2011-02-10 13:04         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 13:04 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: Santosh Shilimkar, linux-omap, linux-arm-kernel

On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> Could we make the domains usage a run-time feature based on the
> architecture version? For ARMv7, we need to have the vectors page
> read-only anyway if the SWP emulation is enabled (and I posted a
> simple patch in a reply to your email).
> 
> The issue I see is that ARM11MPCore is reported as v7 though we still
> use domains on this processor (we could always remove the domains if
> TLS register is available or use some more precise architecture
> version identification).

We could also do the below, which I think is more logical - SWP emulation
requires that CPU domains aren't enabled, so let's make that explicit
in the Kconfig.

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

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c9d2d56..7ea482b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -644,7 +644,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7 && !CPU_V6
+	depends on !CPU_USE_DOMAINS && CPU_V7 && !CPU_V6
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help


^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-10 13:04         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 13:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> Could we make the domains usage a run-time feature based on the
> architecture version? For ARMv7, we need to have the vectors page
> read-only anyway if the SWP emulation is enabled (and I posted a
> simple patch in a reply to your email).
> 
> The issue I see is that ARM11MPCore is reported as v7 though we still
> use domains on this processor (we could always remove the domains if
> TLS register is available or use some more precise architecture
> version identification).

We could also do the below, which I think is more logical - SWP emulation
requires that CPU domains aren't enabled, so let's make that explicit
in the Kconfig.

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

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c9d2d56..7ea482b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -644,7 +644,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7 && !CPU_V6
+	depends on !CPU_USE_DOMAINS && CPU_V7 && !CPU_V6
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-10 13:04         ` Russell King - ARM Linux
@ 2011-02-10 13:12           ` Catalin Marinas
  -1 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-02-10 13:12 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Santosh Shilimkar, linux-omap, linux-arm-kernel

On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > Could we make the domains usage a run-time feature based on the
> > architecture version? For ARMv7, we need to have the vectors page
> > read-only anyway if the SWP emulation is enabled (and I posted a
> > simple patch in a reply to your email).
> >
> > The issue I see is that ARM11MPCore is reported as v7 though we still
> > use domains on this processor (we could always remove the domains if
> > TLS register is available or use some more precise architecture
> > version identification).
> 
> We could also do the below, which I think is more logical - SWP emulation
> requires that CPU domains aren't enabled, so let's make that explicit
> in the Kconfig.

This may work but it is to restrictive IMHO. SWP emulation only requires
that RO user pages are also RO for the kernel. And there is a simple fix
for this:


diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
 
 void __init early_trap_init(void)
 {
-#if defined(CONFIG_CPU_USE_DOMAINS)
-	unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
-	unsigned long vectors = (unsigned long)vectors_page;
-#endif
+	unsigned long vectors;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
 	extern char __kuser_helper_start[], __kuser_helper_end[];
 	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
 
 	/*
+	 * On ARMv7, user RO pages are mapped as kernel RO.
+	 */
+	if (cpu_architecture() >= 7)
+		vectors = (unsigned long)vectors_page;
+	else
+		vectors = CONFIG_VECTORS_BASE;
+
+	/*
 	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
 	 * into the vector page, mapped at 0xffff0000, and ensure these
 	 * are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
 
 	tst	r1, #L_PTE_USER
 	orrne	r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
-	@ allow kernel read/write access to read-only user pages
-	tstne	r3, #PTE_EXT_APX
-	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
 
 	tst	r1, #L_PTE_XN
 	orrne	r3, r3, #PTE_EXT_XN


-- 
Catalin



^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-10 13:12           ` Catalin Marinas
  0 siblings, 0 replies; 254+ messages in thread
From: Catalin Marinas @ 2011-02-10 13:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > Could we make the domains usage a run-time feature based on the
> > architecture version? For ARMv7, we need to have the vectors page
> > read-only anyway if the SWP emulation is enabled (and I posted a
> > simple patch in a reply to your email).
> >
> > The issue I see is that ARM11MPCore is reported as v7 though we still
> > use domains on this processor (we could always remove the domains if
> > TLS register is available or use some more precise architecture
> > version identification).
> 
> We could also do the below, which I think is more logical - SWP emulation
> requires that CPU domains aren't enabled, so let's make that explicit
> in the Kconfig.

This may work but it is to restrictive IMHO. SWP emulation only requires
that RO user pages are also RO for the kernel. And there is a simple fix
for this:


diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
 
 void __init early_trap_init(void)
 {
-#if defined(CONFIG_CPU_USE_DOMAINS)
-	unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
-	unsigned long vectors = (unsigned long)vectors_page;
-#endif
+	unsigned long vectors;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
 	extern char __kuser_helper_start[], __kuser_helper_end[];
 	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
 
 	/*
+	 * On ARMv7, user RO pages are mapped as kernel RO.
+	 */
+	if (cpu_architecture() >= 7)
+		vectors = (unsigned long)vectors_page;
+	else
+		vectors = CONFIG_VECTORS_BASE;
+
+	/*
 	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
 	 * into the vector page, mapped at 0xffff0000, and ensure these
 	 * are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
 
 	tst	r1, #L_PTE_USER
 	orrne	r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
-	@ allow kernel read/write access to read-only user pages
-	tstne	r3, #PTE_EXT_APX
-	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
 
 	tst	r1, #L_PTE_XN
 	orrne	r3, r3, #PTE_EXT_XN


-- 
Catalin

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-10 13:12           ` Catalin Marinas
@ 2011-02-10 13:16             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 13:16 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: Santosh Shilimkar, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 01:12:35PM +0000, Catalin Marinas wrote:
> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> > 
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
> 
> This may work but it is to restrictive IMHO.

At this point I really don't care - mainly because of the lack of support
from the community for sorting out these problems and testing solutions
to them.

It's the simplest solution for the corner we find ourselves in with all
this crap, and avoids any possibility of any side effects caused by having
different behaviours from the same kernel.

I've merged it into my tree and I'm intending to push it upstream.  We can
then readdress it later once we have the real v6v7 crap fixed.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-10 13:16             ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 01:12:35PM +0000, Catalin Marinas wrote:
> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> > 
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
> 
> This may work but it is to restrictive IMHO.

At this point I really don't care - mainly because of the lack of support
from the community for sorting out these problems and testing solutions
to them.

It's the simplest solution for the corner we find ourselves in with all
this crap, and avoids any possibility of any side effects caused by having
different behaviours from the same kernel.

I've merged it into my tree and I'm intending to push it upstream.  We can
then readdress it later once we have the real v6v7 crap fixed.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 12:56                       ` Russell King - ARM Linux
@ 2011-02-10 14:11                         ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 14:11 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>> > discarded at link-time.  In particular this may happen for built-in
>> > __exit stuff.
>> >
>> > This patch modifies the vmlinux linker script to reduce the amount
>> > of discarded sections, and tries to make sure that __exit sections
>> > are kept in.
>> >
>> > This is a hack and probably wrong!  Further discussion is needed.
>>
>> Can you send the configuration which you see this problem with?
>> I've tried to build a kernel which inlines the spinlocks, but I find
>> that's not possible, so I'm doubting whether any fix is required for
>> mainline.
>
> Any news on this, or can it not be reproduced?
>

Hi, apologies-- didn't see my mail for a bit.

I get the problem with this tree and config (which builds with
SMP_ON_UP and THUMB2_KERNEL for omap3/4):

Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
dirty/arm/omap-thumb2+merged
Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

I haven't identified the precise combination of options which causes
the problem, and I don't really understand what the clean solution
would be -- it's on my list of stuff to look at, but not at the top.

Other people not enabling THUMB2_KERNEL have also had the problem
(though I guess that shouldn't make a difference anyway).

I suggested a patch on the binutils mailing list to add a way for
putting fixups in separate, sensibly-named sections which would allow
for a proper fix to this class of problem, but I haven't had any
significant feedback on that ... anyway, that would not be available
on most people's toolchains for a while even if it got accepted --
see:
http://cygwin.com/ml/binutils/2011-02/msg00004.html

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 14:11                         ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 14:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>> > discarded at link-time. ?In particular this may happen for built-in
>> > __exit stuff.
>> >
>> > This patch modifies the vmlinux linker script to reduce the amount
>> > of discarded sections, and tries to make sure that __exit sections
>> > are kept in.
>> >
>> > This is a hack and probably wrong! ?Further discussion is needed.
>>
>> Can you send the configuration which you see this problem with?
>> I've tried to build a kernel which inlines the spinlocks, but I find
>> that's not possible, so I'm doubting whether any fix is required for
>> mainline.
>
> Any news on this, or can it not be reproduced?
>

Hi, apologies-- didn't see my mail for a bit.

I get the problem with this tree and config (which builds with
SMP_ON_UP and THUMB2_KERNEL for omap3/4):

Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
dirty/arm/omap-thumb2+merged
Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

I haven't identified the precise combination of options which causes
the problem, and I don't really understand what the clean solution
would be -- it's on my list of stuff to look at, but not at the top.

Other people not enabling THUMB2_KERNEL have also had the problem
(though I guess that shouldn't make a difference anyway).

I suggested a patch on the binutils mailing list to add a way for
putting fixups in separate, sensibly-named sections which would allow
for a proper fix to this class of problem, but I haven't had any
significant feedback on that ... anyway, that would not be available
on most people's toolchains for a while even if it got accepted --
see:
http://cygwin.com/ml/binutils/2011-02/msg00004.html

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 14:11                         ` Dave Martin
@ 2011-02-10 14:13                           ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 14:13 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>>> > discarded at link-time.  In particular this may happen for built-in
>>> > __exit stuff.
>>> >
>>> > This patch modifies the vmlinux linker script to reduce the amount
>>> > of discarded sections, and tries to make sure that __exit sections
>>> > are kept in.
>>> >
>>> > This is a hack and probably wrong!  Further discussion is needed.
>>>
>>> Can you send the configuration which you see this problem with?
>>> I've tried to build a kernel which inlines the spinlocks, but I find
>>> that's not possible, so I'm doubting whether any fix is required for
>>> mainline.
>>
>> Any news on this, or can it not be reproduced?
>>
>
> Hi, apologies-- didn't see my mail for a bit.
>
> I get the problem with this tree and config (which builds with
> SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>
> Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> dirty/arm/omap-thumb2+merged
> Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

Note that this tree contains some extra patches (though I believe
nothing is there which should cause the problem), and does not contain
everything from rmk/devel -- so it's possible this has been fixed in
the meantime or no longer occurs for some other reason...

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 14:13                           ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 14:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>>> > discarded at link-time. ?In particular this may happen for built-in
>>> > __exit stuff.
>>> >
>>> > This patch modifies the vmlinux linker script to reduce the amount
>>> > of discarded sections, and tries to make sure that __exit sections
>>> > are kept in.
>>> >
>>> > This is a hack and probably wrong! ?Further discussion is needed.
>>>
>>> Can you send the configuration which you see this problem with?
>>> I've tried to build a kernel which inlines the spinlocks, but I find
>>> that's not possible, so I'm doubting whether any fix is required for
>>> mainline.
>>
>> Any news on this, or can it not be reproduced?
>>
>
> Hi, apologies-- didn't see my mail for a bit.
>
> I get the problem with this tree and config (which builds with
> SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>
> Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> dirty/arm/omap-thumb2+merged
> Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

Note that this tree contains some extra patches (though I believe
nothing is there which should cause the problem), and does not contain
everything from rmk/devel -- so it's possible this has been fixed in
the meantime or no longer occurs for some other reason...

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 14:13                           ` Dave Martin
@ 2011-02-10 14:46                             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 14:46 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> > Hi, apologies-- didn't see my mail for a bit.
> >
> > I get the problem with this tree and config (which builds with
> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
> >
> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> > dirty/arm/omap-thumb2+merged
> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

Thanks for the config.

> Note that this tree contains some extra patches (though I believe
> nothing is there which should cause the problem), and does not contain
> everything from rmk/devel -- so it's possible this has been fixed in
> the meantime or no longer occurs for some other reason...

No need - I now have some modules which contain SMP alternatives, so we
do need to fix the module loader for this, and keep the SMP alternatives
replacement code around.  It's not worth eliminating the code as if we
include an informative printk() to say why we're refusing to load the
module, the string would be larger than the code it eliminates.  So, I
think we need to merge the patch below to avoid run-time problems.

Of course, this conflicts rather badly with the p2v stuff...

 arch/arm/kernel/head.S   |   38 ++++++++++++++++++++++++++------------
 arch/arm/kernel/module.c |   22 +++++++++++++++++++++-
 2 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index c0225da..f06ff9f 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -391,6 +391,7 @@ ENDPROC(__turn_mmu_on)
 
 
 #ifdef CONFIG_SMP_ON_UP
+	__INIT
 __fixup_smp:
 	and	r3, r9, #0x000f0000	@ architecture version
 	teq	r3, #0x000f0000		@ CPU ID supported?
@@ -415,18 +416,7 @@ __fixup_smp_on_up:
 	sub	r3, r0, r3
 	add	r4, r4, r3
 	add	r5, r5, r3
-2:	cmp	r4, r5
-	movhs	pc, lr
-	ldmia	r4!, {r0, r6}
- ARM(	str	r6, [r0, r3]	)
- THUMB(	add	r0, r0, r3	)
-#ifdef __ARMEB__
- THUMB(	mov	r6, r6, ror #16	)	@ Convert word order for big-endian.
-#endif
- THUMB(	strh	r6, [r0], #2	)	@ For Thumb-2, store as two halfwords
- THUMB(	mov	r6, r6, lsr #16	)	@ to be robust against misaligned r3.
- THUMB(	strh	r6, [r0]	)
-	b	2b
+	b	__do_fixup_smp_on_up
 ENDPROC(__fixup_smp)
 
 	.align
@@ -440,7 +430,31 @@ smp_on_up:
 	ALT_SMP(.long	1)
 	ALT_UP(.long	0)
 	.popsection
+#endif
 
+	.text
+__do_fixup_smp_on_up:
+	cmp	r4, r5
+	movhs	pc, lr
+	ldmia	r4!, {r0, r6}
+ ARM(	str	r6, [r0, r3]	)
+ THUMB(	add	r0, r0, r3	)
+#ifdef __ARMEB__
+ THUMB(	mov	r6, r6, ror #16	)	@ Convert word order for big-endian.
 #endif
+ THUMB(	strh	r6, [r0], #2	)	@ For Thumb-2, store as two halfwords
+ THUMB(	mov	r6, r6, lsr #16	)	@ to be robust against misaligned r3.
+ THUMB(	strh	r6, [r0]	)
+	b	__do_fixup_smp_on_up
+ENDPROC(__do_fixup_smp_on_up)
+
+ENTRY(fixup_smp)
+	stmfd	sp!, {r4 - r6, lr}
+	mov	r4, r0
+	add	r5, r0, r1
+	mov	r3, #0
+	bl	__do_fixup_smp_on_up
+	ldmfd	sp!, {r4 - r6, pc}
+ENDPROC(fixup_smp)
 
 #include "head-common.S"
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 2cfe816..6d4105e 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -22,6 +22,7 @@
 
 #include <asm/pgtable.h>
 #include <asm/sections.h>
+#include <asm/smp_plat.h>
 #include <asm/unwind.h>
 
 #ifdef CONFIG_XIP_KERNEL
@@ -268,12 +269,28 @@ struct mod_unwind_map {
 	const Elf_Shdr *txt_sec;
 };
 
+static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
+	const Elf_Shdr *sechdrs, const char *name)
+{
+	const Elf_Shdr *s, *se;
+	const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+
+	for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++)
+		if (strcmp(name, secstrs + s->sh_name) == 0)
+			return s;
+
+	return NULL;
+}
+
+extern void fixup_smp(const void *, unsigned long);
+
 int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
 		    struct module *mod)
 {
+	const Elf_Shdr * __maybe_unused s = NULL;
 #ifdef CONFIG_ARM_UNWIND
 	const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
-	const Elf_Shdr *s, *sechdrs_end = sechdrs + hdr->e_shnum;
+	const Elf_Shdr *sechdrs_end = sechdrs + hdr->e_shnum;
 	struct mod_unwind_map maps[ARM_SEC_MAX];
 	int i;
 
@@ -315,6 +332,9 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
 					         maps[i].txt_sec->sh_addr,
 					         maps[i].txt_sec->sh_size);
 #endif
+	s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
+	if (s && !is_smp())
+		fixup_smp((void *)s->sh_addr, s->sh_size);
 	return 0;
 }
 

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 14:46                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 14:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> > Hi, apologies-- didn't see my mail for a bit.
> >
> > I get the problem with this tree and config (which builds with
> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
> >
> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> > dirty/arm/omap-thumb2+merged
> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

Thanks for the config.

> Note that this tree contains some extra patches (though I believe
> nothing is there which should cause the problem), and does not contain
> everything from rmk/devel -- so it's possible this has been fixed in
> the meantime or no longer occurs for some other reason...

No need - I now have some modules which contain SMP alternatives, so we
do need to fix the module loader for this, and keep the SMP alternatives
replacement code around.  It's not worth eliminating the code as if we
include an informative printk() to say why we're refusing to load the
module, the string would be larger than the code it eliminates.  So, I
think we need to merge the patch below to avoid run-time problems.

Of course, this conflicts rather badly with the p2v stuff...

 arch/arm/kernel/head.S   |   38 ++++++++++++++++++++++++++------------
 arch/arm/kernel/module.c |   22 +++++++++++++++++++++-
 2 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index c0225da..f06ff9f 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -391,6 +391,7 @@ ENDPROC(__turn_mmu_on)
 
 
 #ifdef CONFIG_SMP_ON_UP
+	__INIT
 __fixup_smp:
 	and	r3, r9, #0x000f0000	@ architecture version
 	teq	r3, #0x000f0000		@ CPU ID supported?
@@ -415,18 +416,7 @@ __fixup_smp_on_up:
 	sub	r3, r0, r3
 	add	r4, r4, r3
 	add	r5, r5, r3
-2:	cmp	r4, r5
-	movhs	pc, lr
-	ldmia	r4!, {r0, r6}
- ARM(	str	r6, [r0, r3]	)
- THUMB(	add	r0, r0, r3	)
-#ifdef __ARMEB__
- THUMB(	mov	r6, r6, ror #16	)	@ Convert word order for big-endian.
-#endif
- THUMB(	strh	r6, [r0], #2	)	@ For Thumb-2, store as two halfwords
- THUMB(	mov	r6, r6, lsr #16	)	@ to be robust against misaligned r3.
- THUMB(	strh	r6, [r0]	)
-	b	2b
+	b	__do_fixup_smp_on_up
 ENDPROC(__fixup_smp)
 
 	.align
@@ -440,7 +430,31 @@ smp_on_up:
 	ALT_SMP(.long	1)
 	ALT_UP(.long	0)
 	.popsection
+#endif
 
+	.text
+__do_fixup_smp_on_up:
+	cmp	r4, r5
+	movhs	pc, lr
+	ldmia	r4!, {r0, r6}
+ ARM(	str	r6, [r0, r3]	)
+ THUMB(	add	r0, r0, r3	)
+#ifdef __ARMEB__
+ THUMB(	mov	r6, r6, ror #16	)	@ Convert word order for big-endian.
 #endif
+ THUMB(	strh	r6, [r0], #2	)	@ For Thumb-2, store as two halfwords
+ THUMB(	mov	r6, r6, lsr #16	)	@ to be robust against misaligned r3.
+ THUMB(	strh	r6, [r0]	)
+	b	__do_fixup_smp_on_up
+ENDPROC(__do_fixup_smp_on_up)
+
+ENTRY(fixup_smp)
+	stmfd	sp!, {r4 - r6, lr}
+	mov	r4, r0
+	add	r5, r0, r1
+	mov	r3, #0
+	bl	__do_fixup_smp_on_up
+	ldmfd	sp!, {r4 - r6, pc}
+ENDPROC(fixup_smp)
 
 #include "head-common.S"
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 2cfe816..6d4105e 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -22,6 +22,7 @@
 
 #include <asm/pgtable.h>
 #include <asm/sections.h>
+#include <asm/smp_plat.h>
 #include <asm/unwind.h>
 
 #ifdef CONFIG_XIP_KERNEL
@@ -268,12 +269,28 @@ struct mod_unwind_map {
 	const Elf_Shdr *txt_sec;
 };
 
+static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
+	const Elf_Shdr *sechdrs, const char *name)
+{
+	const Elf_Shdr *s, *se;
+	const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+
+	for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++)
+		if (strcmp(name, secstrs + s->sh_name) == 0)
+			return s;
+
+	return NULL;
+}
+
+extern void fixup_smp(const void *, unsigned long);
+
 int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
 		    struct module *mod)
 {
+	const Elf_Shdr * __maybe_unused s = NULL;
 #ifdef CONFIG_ARM_UNWIND
 	const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
-	const Elf_Shdr *s, *sechdrs_end = sechdrs + hdr->e_shnum;
+	const Elf_Shdr *sechdrs_end = sechdrs + hdr->e_shnum;
 	struct mod_unwind_map maps[ARM_SEC_MAX];
 	int i;
 
@@ -315,6 +332,9 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
 					         maps[i].txt_sec->sh_addr,
 					         maps[i].txt_sec->sh_size);
 #endif
+	s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
+	if (s && !is_smp())
+		fixup_smp((void *)s->sh_addr, s->sh_size);
 	return 0;
 }
 

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 14:46                             ` Russell King - ARM Linux
@ 2011-02-10 18:29                               ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 18:29 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
>> > Hi, apologies-- didn't see my mail for a bit.
>> >
>> > I get the problem with this tree and config (which builds with
>> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>> >
>> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
>> > dirty/arm/omap-thumb2+merged
>> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> Thanks for the config.
>
>> Note that this tree contains some extra patches (though I believe
>> nothing is there which should cause the problem), and does not contain
>> everything from rmk/devel -- so it's possible this has been fixed in
>> the meantime or no longer occurs for some other reason...
>
> No need - I now have some modules which contain SMP alternatives, so we
> do need to fix the module loader for this, and keep the SMP alternatives
> replacement code around.  It's not worth eliminating the code as if we
> include an informative printk() to say why we're refusing to load the
> module, the string would be larger than the code it eliminates.  So, I
> think we need to merge the patch below to avoid run-time problems.

I thought the problem was not caused by removal of the fixup code, but
rather by the removal of code referenced by fixups?

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 18:29                               ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-10 18:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
>> > Hi, apologies-- didn't see my mail for a bit.
>> >
>> > I get the problem with this tree and config (which builds with
>> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>> >
>> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
>> > dirty/arm/omap-thumb2+merged
>> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> Thanks for the config.
>
>> Note that this tree contains some extra patches (though I believe
>> nothing is there which should cause the problem), and does not contain
>> everything from rmk/devel -- so it's possible this has been fixed in
>> the meantime or no longer occurs for some other reason...
>
> No need - I now have some modules which contain SMP alternatives, so we
> do need to fix the module loader for this, and keep the SMP alternatives
> replacement code around. ?It's not worth eliminating the code as if we
> include an informative printk() to say why we're refusing to load the
> module, the string would be larger than the code it eliminates. ?So, I
> think we need to merge the patch below to avoid run-time problems.

I thought the problem was not caused by removal of the fixup code, but
rather by the removal of code referenced by fixups?

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 18:29                               ` Dave Martin
@ 2011-02-10 19:11                                 ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 19:11 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> >> Note that this tree contains some extra patches (though I believe
> >> nothing is there which should cause the problem), and does not contain
> >> everything from rmk/devel -- so it's possible this has been fixed in
> >> the meantime or no longer occurs for some other reason...
> >
> > No need - I now have some modules which contain SMP alternatives, so we
> > do need to fix the module loader for this, and keep the SMP alternatives
> > replacement code around.  It's not worth eliminating the code as if we
> > include an informative printk() to say why we're refusing to load the
> > module, the string would be larger than the code it eliminates.  So, I
> > think we need to merge the patch below to avoid run-time problems.
> 
> I thought the problem was not caused by removal of the fixup code, but
> rather by the removal of code referenced by fixups?

It is.  But:

arm-linux-objdump -h sound/core/snd-timer.ko

sound/core/snd-timer.ko:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002f34  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .exit.text    00000070  00000000  00000000  00002f68  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .init.text    000001b4  00000000  00000000  00002fd8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  3 .rodata       000000bc  00000000  00000000  0000318c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  4 .rodata.str1.1 00000156  00000000  00000000  00003248  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .alt.smp.init 00000088  00000000  00000000  0000339e  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
...

Here we have a module which contains the spin_unlock assembly, which
contains the SMP alternatives.  If we insert that into a kernel also
built with SMP alternatives support, but which is running on a UP
system, we need to run these fixups as well when the module is loaded.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-10 19:11                                 ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-10 19:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> >> Note that this tree contains some extra patches (though I believe
> >> nothing is there which should cause the problem), and does not contain
> >> everything from rmk/devel -- so it's possible this has been fixed in
> >> the meantime or no longer occurs for some other reason...
> >
> > No need - I now have some modules which contain SMP alternatives, so we
> > do need to fix the module loader for this, and keep the SMP alternatives
> > replacement code around. ?It's not worth eliminating the code as if we
> > include an informative printk() to say why we're refusing to load the
> > module, the string would be larger than the code it eliminates. ?So, I
> > think we need to merge the patch below to avoid run-time problems.
> 
> I thought the problem was not caused by removal of the fixup code, but
> rather by the removal of code referenced by fixups?

It is.  But:

arm-linux-objdump -h sound/core/snd-timer.ko

sound/core/snd-timer.ko:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002f34  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .exit.text    00000070  00000000  00000000  00002f68  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .init.text    000001b4  00000000  00000000  00002fd8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  3 .rodata       000000bc  00000000  00000000  0000318c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  4 .rodata.str1.1 00000156  00000000  00000000  00003248  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .alt.smp.init 00000088  00000000  00000000  0000339e  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
...

Here we have a module which contains the spin_unlock assembly, which
contains the SMP alternatives.  If we insert that into a kernel also
built with SMP alternatives support, but which is running on a UP
system, we need to run these fixups as well when the module is loaded.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-10 19:11                                 ` Russell King - ARM Linux
@ 2011-02-11  9:33                                   ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11  9:33 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Thu, Feb 10, 2011 at 7:11 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> >> Note that this tree contains some extra patches (though I believe
>> >> nothing is there which should cause the problem), and does not contain
>> >> everything from rmk/devel -- so it's possible this has been fixed in
>> >> the meantime or no longer occurs for some other reason...
>> >
>> > No need - I now have some modules which contain SMP alternatives, so we
>> > do need to fix the module loader for this, and keep the SMP alternatives
>> > replacement code around.  It's not worth eliminating the code as if we
>> > include an informative printk() to say why we're refusing to load the
>> > module, the string would be larger than the code it eliminates.  So, I
>> > think we need to merge the patch below to avoid run-time problems.
>>
>> I thought the problem was not caused by removal of the fixup code, but
>> rather by the removal of code referenced by fixups?
>
> It is.  But:
>
> arm-linux-objdump -h sound/core/snd-timer.ko
>
> sound/core/snd-timer.ko:     file format elf32-littlearm
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .text         00002f34  00000000  00000000  00000034  2**2
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>  1 .exit.text    00000070  00000000  00000000  00002f68  2**2
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>  2 .init.text    000001b4  00000000  00000000  00002fd8  2**2
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>  3 .rodata       000000bc  00000000  00000000  0000318c  2**2
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>  4 .rodata.str1.1 00000156  00000000  00000000  00003248  2**0
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>  5 .alt.smp.init 00000088  00000000  00000000  0000339e  2**0
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> ...
>
> Here we have a module which contains the spin_unlock assembly, which
> contains the SMP alternatives.  If we insert that into a kernel also
> built with SMP alternatives support, but which is running on a UP
> system, we need to run these fixups as well when the module is loaded.
>

Agreed -- actually, I suspected we might need to support this.  But I
don't think solving this problem (= keeping the fixup implementation
in memory and enhancing the module loader) solved the
fixups-referencing-sections-discarded-from-vmlinux problem.  These
seem to be two separate issues.  I am filing to understand something?

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11  9:33                                   ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11  9:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Feb 10, 2011 at 7:11 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> >> Note that this tree contains some extra patches (though I believe
>> >> nothing is there which should cause the problem), and does not contain
>> >> everything from rmk/devel -- so it's possible this has been fixed in
>> >> the meantime or no longer occurs for some other reason...
>> >
>> > No need - I now have some modules which contain SMP alternatives, so we
>> > do need to fix the module loader for this, and keep the SMP alternatives
>> > replacement code around. ?It's not worth eliminating the code as if we
>> > include an informative printk() to say why we're refusing to load the
>> > module, the string would be larger than the code it eliminates. ?So, I
>> > think we need to merge the patch below to avoid run-time problems.
>>
>> I thought the problem was not caused by removal of the fixup code, but
>> rather by the removal of code referenced by fixups?
>
> It is. ?But:
>
> arm-linux-objdump -h sound/core/snd-timer.ko
>
> sound/core/snd-timer.ko: ? ? file format elf32-littlearm
>
> Sections:
> Idx Name ? ? ? ? ?Size ? ? ?VMA ? ? ? LMA ? ? ? File off ?Algn
> ?0 .text ? ? ? ? 00002f34 ?00000000 ?00000000 ?00000034 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?1 .exit.text ? ?00000070 ?00000000 ?00000000 ?00002f68 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?2 .init.text ? ?000001b4 ?00000000 ?00000000 ?00002fd8 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?3 .rodata ? ? ? 000000bc ?00000000 ?00000000 ?0000318c ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> ?4 .rodata.str1.1 00000156 ?00000000 ?00000000 ?00003248 ?2**0
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, READONLY, DATA
> ?5 .alt.smp.init 00000088 ?00000000 ?00000000 ?0000339e ?2**0
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> ...
>
> Here we have a module which contains the spin_unlock assembly, which
> contains the SMP alternatives. ?If we insert that into a kernel also
> built with SMP alternatives support, but which is running on a UP
> system, we need to run these fixups as well when the module is loaded.
>

Agreed -- actually, I suspected we might need to support this.  But I
don't think solving this problem (= keeping the fixup implementation
in memory and enhancing the module loader) solved the
fixups-referencing-sections-discarded-from-vmlinux problem.  These
seem to be two separate issues.  I am filing to understand something?

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11  9:33                                   ` Dave Martin
@ 2011-02-11 10:13                                     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 10:13 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
> Agreed -- actually, I suspected we might need to support this.  But I
> don't think solving this problem (= keeping the fixup implementation
> in memory and enhancing the module loader) solved the
> fixups-referencing-sections-discarded-from-vmlinux problem.  These
> seem to be two separate issues.  I am filing to understand something?

They are separate, but related issues.  They both ultimately have the
same cause - the placement of the spinlock code inline rather than
out of line, resulting in fixups appearing all over the place rather
than just in kernel/spinlock.o.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11 10:13                                     ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 10:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
> Agreed -- actually, I suspected we might need to support this.  But I
> don't think solving this problem (= keeping the fixup implementation
> in memory and enhancing the module loader) solved the
> fixups-referencing-sections-discarded-from-vmlinux problem.  These
> seem to be two separate issues.  I am filing to understand something?

They are separate, but related issues.  They both ultimately have the
same cause - the placement of the spinlock code inline rather than
out of line, resulting in fixups appearing all over the place rather
than just in kernel/spinlock.o.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11 10:13                                     ` Russell King - ARM Linux
@ 2011-02-11 10:52                                       ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11 10:52 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
>> Agreed -- actually, I suspected we might need to support this.  But I
>> don't think solving this problem (= keeping the fixup implementation
>> in memory and enhancing the module loader) solved the
>> fixups-referencing-sections-discarded-from-vmlinux problem.  These
>> seem to be two separate issues.  I am filing to understand something?
>
> They are separate, but related issues.  They both ultimately have the
> same cause - the placement of the spinlock code inline rather than
> out of line, resulting in fixups appearing all over the place rather
> than just in kernel/spinlock.o.

I guess what I want to understand is whether I (or someone) still
need(s) to sort out the vmlinux.lds issue.

If we're keeping inline spinlocks (I currently assume "yes"), then the
vmlinux.lds issue still needs fixing.  Is that correct?  However, if
we get rid of inline spinlocks we won't have the problem, though there
may be some performance impact -- hard to judge how significant.

Apologies if I'm being dense here...

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11 10:52                                       ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11 10:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
>> Agreed -- actually, I suspected we might need to support this. ?But I
>> don't think solving this problem (= keeping the fixup implementation
>> in memory and enhancing the module loader) solved the
>> fixups-referencing-sections-discarded-from-vmlinux problem. ?These
>> seem to be two separate issues. ?I am filing to understand something?
>
> They are separate, but related issues. ?They both ultimately have the
> same cause - the placement of the spinlock code inline rather than
> out of line, resulting in fixups appearing all over the place rather
> than just in kernel/spinlock.o.

I guess what I want to understand is whether I (or someone) still
need(s) to sort out the vmlinux.lds issue.

If we're keeping inline spinlocks (I currently assume "yes"), then the
vmlinux.lds issue still needs fixing.  Is that correct?  However, if
we get rid of inline spinlocks we won't have the problem, though there
may be some performance impact -- hard to judge how significant.

Apologies if I'm being dense here...

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11 10:52                                       ` Dave Martin
@ 2011-02-11 16:05                                         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 16:05 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 10:52:17AM +0000, Dave Martin wrote:
> On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
> >> Agreed -- actually, I suspected we might need to support this.  But I
> >> don't think solving this problem (= keeping the fixup implementation
> >> in memory and enhancing the module loader) solved the
> >> fixups-referencing-sections-discarded-from-vmlinux problem.  These
> >> seem to be two separate issues.  I am filing to understand something?
> >
> > They are separate, but related issues.  They both ultimately have the
> > same cause - the placement of the spinlock code inline rather than
> > out of line, resulting in fixups appearing all over the place rather
> > than just in kernel/spinlock.o.
> 
> I guess what I want to understand is whether I (or someone) still
> need(s) to sort out the vmlinux.lds issue.

Yes we do - if you build your kernel you should find that your link
fails because of discarded sections being referenced.

> If we're keeping inline spinlocks (I currently assume "yes"), then the
> vmlinux.lds issue still needs fixing.  Is that correct?  However, if
> we get rid of inline spinlocks we won't have the problem, though there
> may be some performance impact -- hard to judge how significant.

I don't see that we can get rid of inline spinlocks - it's controlled
by stuff external to the arch.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11 16:05                                         ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 16:05 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 10:52:17AM +0000, Dave Martin wrote:
> On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
> >> Agreed -- actually, I suspected we might need to support this. ?But I
> >> don't think solving this problem (= keeping the fixup implementation
> >> in memory and enhancing the module loader) solved the
> >> fixups-referencing-sections-discarded-from-vmlinux problem. ?These
> >> seem to be two separate issues. ?I am filing to understand something?
> >
> > They are separate, but related issues. ?They both ultimately have the
> > same cause - the placement of the spinlock code inline rather than
> > out of line, resulting in fixups appearing all over the place rather
> > than just in kernel/spinlock.o.
> 
> I guess what I want to understand is whether I (or someone) still
> need(s) to sort out the vmlinux.lds issue.

Yes we do - if you build your kernel you should find that your link
fails because of discarded sections being referenced.

> If we're keeping inline spinlocks (I currently assume "yes"), then the
> vmlinux.lds issue still needs fixing.  Is that correct?  However, if
> we get rid of inline spinlocks we won't have the problem, though there
> may be some performance impact -- hard to judge how significant.

I don't see that we can get rid of inline spinlocks - it's controlled
by stuff external to the arch.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11 16:05                                         ` Russell King - ARM Linux
@ 2011-02-11 16:17                                           ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11 16:17 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 4:05 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 11, 2011 at 10:52:17AM +0000, Dave Martin wrote:
>> On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
>> >> Agreed -- actually, I suspected we might need to support this.  But I
>> >> don't think solving this problem (= keeping the fixup implementation
>> >> in memory and enhancing the module loader) solved the
>> >> fixups-referencing-sections-discarded-from-vmlinux problem.  These
>> >> seem to be two separate issues.  I am filing to understand something?
>> >
>> > They are separate, but related issues.  They both ultimately have the
>> > same cause - the placement of the spinlock code inline rather than
>> > out of line, resulting in fixups appearing all over the place rather
>> > than just in kernel/spinlock.o.
>>
>> I guess what I want to understand is whether I (or someone) still
>> need(s) to sort out the vmlinux.lds issue.
>
> Yes we do - if you build your kernel you should find that your link
> fails because of discarded sections being referenced.

Yep -- I'm still applying my original patch to work around that, but
it sounds like I need to tidy that up.  Can you elaborate on what you
meant by defining a "KEEP_EXIT" macro to handle this?

>
>> If we're keeping inline spinlocks (I currently assume "yes"), then the
>> vmlinux.lds issue still needs fixing.  Is that correct?  However, if
>> we get rid of inline spinlocks we won't have the problem, though there
>> may be some performance impact -- hard to judge how significant.
>
> I don't see that we can get rid of inline spinlocks - it's controlled
> by stuff external to the arch.

That's fine -- just wanted to make sure I had the right understanding.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11 16:17                                           ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-11 16:17 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 4:05 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 11, 2011 at 10:52:17AM +0000, Dave Martin wrote:
>> On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Feb 11, 2011 at 09:33:56AM +0000, Dave Martin wrote:
>> >> Agreed -- actually, I suspected we might need to support this. ?But I
>> >> don't think solving this problem (= keeping the fixup implementation
>> >> in memory and enhancing the module loader) solved the
>> >> fixups-referencing-sections-discarded-from-vmlinux problem. ?These
>> >> seem to be two separate issues. ?I am filing to understand something?
>> >
>> > They are separate, but related issues. ?They both ultimately have the
>> > same cause - the placement of the spinlock code inline rather than
>> > out of line, resulting in fixups appearing all over the place rather
>> > than just in kernel/spinlock.o.
>>
>> I guess what I want to understand is whether I (or someone) still
>> need(s) to sort out the vmlinux.lds issue.
>
> Yes we do - if you build your kernel you should find that your link
> fails because of discarded sections being referenced.

Yep -- I'm still applying my original patch to work around that, but
it sounds like I need to tidy that up.  Can you elaborate on what you
meant by defining a "KEEP_EXIT" macro to handle this?

>
>> If we're keeping inline spinlocks (I currently assume "yes"), then the
>> vmlinux.lds issue still needs fixing. ?Is that correct? ?However, if
>> we get rid of inline spinlocks we won't have the problem, though there
>> may be some performance impact -- hard to judge how significant.
>
> I don't see that we can get rid of inline spinlocks - it's controlled
> by stuff external to the arch.

That's fine -- just wanted to make sure I had the right understanding.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11 16:17                                           ` Dave Martin
@ 2011-02-11 16:32                                             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 16:32 UTC (permalink / raw)
  To: Dave Martin; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 04:17:48PM +0000, Dave Martin wrote:
> Yep -- I'm still applying my original patch to work around that, but
> it sounds like I need to tidy that up.  Can you elaborate on what you
> meant by defining a "KEEP_EXIT" macro to handle this?

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..343d29f 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -21,6 +21,12 @@
 #define ARM_CPU_KEEP(x)
 #endif
 
+#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
+#define ARM_EXIT_KEEP(x)	x
+#else
+#define ARM_EXIT_KEEP(x)
+#endif
+
 OUTPUT_ARCH(arm)
 ENTRY(stext)
 
@@ -43,6 +49,7 @@ SECTIONS
 		_sinittext = .;
 			HEAD_TEXT
 			INIT_TEXT
+			ARM_EXIT_KEEP(EXIT_TEXT)
 		_einittext = .;
 		ARM_CPU_DISCARD(PROC_INFO)
 		__arch_info_begin = .;
@@ -71,6 +78,7 @@ SECTIONS
 #ifndef CONFIG_XIP_KERNEL
 		__init_begin = _stext;
 		INIT_DATA
+		ARM_EXIT_KEEP(EXIT_DATA)
 #endif
 	}
 
@@ -166,6 +174,7 @@ SECTIONS
 		. = ALIGN(PAGE_SIZE);
 		__init_begin = .;
 		INIT_DATA
+		ARM_EXIT_KEEP(EXIT_DATA)
 		. = ALIGN(PAGE_SIZE);
 		__init_end = .;
 #endif

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-11 16:32                                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 16:32 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 04:17:48PM +0000, Dave Martin wrote:
> Yep -- I'm still applying my original patch to work around that, but
> it sounds like I need to tidy that up.  Can you elaborate on what you
> meant by defining a "KEEP_EXIT" macro to handle this?

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 45b5651..343d29f 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -21,6 +21,12 @@
 #define ARM_CPU_KEEP(x)
 #endif
 
+#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
+#define ARM_EXIT_KEEP(x)	x
+#else
+#define ARM_EXIT_KEEP(x)
+#endif
+
 OUTPUT_ARCH(arm)
 ENTRY(stext)
 
@@ -43,6 +49,7 @@ SECTIONS
 		_sinittext = .;
 			HEAD_TEXT
 			INIT_TEXT
+			ARM_EXIT_KEEP(EXIT_TEXT)
 		_einittext = .;
 		ARM_CPU_DISCARD(PROC_INFO)
 		__arch_info_begin = .;
@@ -71,6 +78,7 @@ SECTIONS
 #ifndef CONFIG_XIP_KERNEL
 		__init_begin = _stext;
 		INIT_DATA
+		ARM_EXIT_KEEP(EXIT_DATA)
 #endif
 	}
 
@@ -166,6 +174,7 @@ SECTIONS
 		. = ALIGN(PAGE_SIZE);
 		__init_begin = .;
 		INIT_DATA
+		ARM_EXIT_KEEP(EXIT_DATA)
 		. = ALIGN(PAGE_SIZE);
 		__init_end = .;
 #endif

^ permalink raw reply related	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-10 13:12           ` Catalin Marinas
@ 2011-02-11 20:45             ` Nicolas Pitre
  -1 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-11 20:45 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Russell King - ARM Linux, linux-omap, Santosh Shilimkar,
	linux-arm-kernel

On Thu, 10 Feb 2011, Catalin Marinas wrote:

> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> > 
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
> 
> This may work but it is to restrictive IMHO. SWP emulation only requires
> that RO user pages are also RO for the kernel. And there is a simple fix
> for this:
> 

The patch below is making the code more straight forward regardless of 
any swp emulation issues.

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index ee57640..6e0b349 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
>  
>  void __init early_trap_init(void)
>  {
> -#if defined(CONFIG_CPU_USE_DOMAINS)
> -	unsigned long vectors = CONFIG_VECTORS_BASE;
> -#else
> -	unsigned long vectors = (unsigned long)vectors_page;
> -#endif
> +	unsigned long vectors;
>  	extern char __stubs_start[], __stubs_end[];
>  	extern char __vectors_start[], __vectors_end[];
>  	extern char __kuser_helper_start[], __kuser_helper_end[];
>  	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
>  
>  	/*
> +	 * On ARMv7, user RO pages are mapped as kernel RO.
> +	 */
> +	if (cpu_architecture() >= 7)
> +		vectors = (unsigned long)vectors_page;
> +	else
> +		vectors = CONFIG_VECTORS_BASE;
> +
> +	/*
>  	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
>  	 * into the vector page, mapped at 0xffff0000, and ensure these
>  	 * are visible to the instruction stream.
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 0c1172b..5f51592 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
>  
>  	tst	r1, #L_PTE_USER
>  	orrne	r3, r3, #PTE_EXT_AP1
> -#ifdef CONFIG_CPU_USE_DOMAINS
> -	@ allow kernel read/write access to read-only user pages
> -	tstne	r3, #PTE_EXT_APX
> -	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
> -#endif
>  
>  	tst	r1, #L_PTE_XN
>  	orrne	r3, r3, #PTE_EXT_XN
> 
> 
> -- 
> Catalin
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-11 20:45             ` Nicolas Pitre
  0 siblings, 0 replies; 254+ messages in thread
From: Nicolas Pitre @ 2011-02-11 20:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, 10 Feb 2011, Catalin Marinas wrote:

> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> > 
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
> 
> This may work but it is to restrictive IMHO. SWP emulation only requires
> that RO user pages are also RO for the kernel. And there is a simple fix
> for this:
> 

The patch below is making the code more straight forward regardless of 
any swp emulation issues.

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index ee57640..6e0b349 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
>  
>  void __init early_trap_init(void)
>  {
> -#if defined(CONFIG_CPU_USE_DOMAINS)
> -	unsigned long vectors = CONFIG_VECTORS_BASE;
> -#else
> -	unsigned long vectors = (unsigned long)vectors_page;
> -#endif
> +	unsigned long vectors;
>  	extern char __stubs_start[], __stubs_end[];
>  	extern char __vectors_start[], __vectors_end[];
>  	extern char __kuser_helper_start[], __kuser_helper_end[];
>  	int kuser_sz = __kuser_helper_end - __kuser_helper_start;
>  
>  	/*
> +	 * On ARMv7, user RO pages are mapped as kernel RO.
> +	 */
> +	if (cpu_architecture() >= 7)
> +		vectors = (unsigned long)vectors_page;
> +	else
> +		vectors = CONFIG_VECTORS_BASE;
> +
> +	/*
>  	 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
>  	 * into the vector page, mapped at 0xffff0000, and ensure these
>  	 * are visible to the instruction stream.
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 0c1172b..5f51592 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
>  
>  	tst	r1, #L_PTE_USER
>  	orrne	r3, r3, #PTE_EXT_AP1
> -#ifdef CONFIG_CPU_USE_DOMAINS
> -	@ allow kernel read/write access to read-only user pages
> -	tstne	r3, #PTE_EXT_APX
> -	bicne	r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
> -#endif
>  
>  	tst	r1, #L_PTE_XN
>  	orrne	r3, r3, #PTE_EXT_XN
> 
> 
> -- 
> Catalin
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
  2011-02-11 20:45             ` Nicolas Pitre
@ 2011-02-11 21:07               ` Russell King - ARM Linux
  -1 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 21:07 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Catalin Marinas, Santosh Shilimkar, linux-omap, linux-arm-kernel

On Fri, Feb 11, 2011 at 03:45:51PM -0500, Nicolas Pitre wrote:
> The patch below is making the code more straight forward regardless of 
> any swp emulation issues.

I don't know where you get that idea from.  What it does is make a kernel
built with a standard set of options have differing behaviour on v7 and
pre-v7 architectures.

On v7 architectures, the vectors page and user pages all become read only
to SVC mode.  On pre-v7 architectures on the same kernel, they are read-
write to SVC mode.

What we have now is that these pages are only read-only when CPU domains
are turned off - for everything.  So we know that if CPU domains are
enabled, it's read/write, otherwise it's read only.  That's more
straight forward than what this patch creates IMHO.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
@ 2011-02-11 21:07               ` Russell King - ARM Linux
  0 siblings, 0 replies; 254+ messages in thread
From: Russell King - ARM Linux @ 2011-02-11 21:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Feb 11, 2011 at 03:45:51PM -0500, Nicolas Pitre wrote:
> The patch below is making the code more straight forward regardless of 
> any swp emulation issues.

I don't know where you get that idea from.  What it does is make a kernel
built with a standard set of options have differing behaviour on v7 and
pre-v7 architectures.

On v7 architectures, the vectors page and user pages all become read only
to SVC mode.  On pre-v7 architectures on the same kernel, they are read-
write to SVC mode.

What we have now is that these pages are only read-only when CPU domains
are turned off - for everything.  So we know that if CPU domains are
enabled, it's read/write, otherwise it's read only.  That's more
straight forward than what this patch creates IMHO.

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-11 16:32                                             ` Russell King - ARM Linux
@ 2011-02-16 16:35                                               ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-16 16:35 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

Hi,

On Fri, Feb 11, 2011 at 04:32:47PM +0000, Russell King - ARM Linux wrote:

[...]

> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 45b5651..343d29f 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -21,6 +21,12 @@
>  #define ARM_CPU_KEEP(x)
>  #endif
>  
> +#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
> +#define ARM_EXIT_KEEP(x)	x
> +#else
> +#define ARM_EXIT_KEEP(x)
> +#endif
> +
>  OUTPUT_ARCH(arm)
>  ENTRY(stext)
>  
> @@ -43,6 +49,7 @@ SECTIONS
>  		_sinittext = .;
>  			HEAD_TEXT
>  			INIT_TEXT
> +			ARM_EXIT_KEEP(EXIT_TEXT)
>  		_einittext = .;
>  		ARM_CPU_DISCARD(PROC_INFO)
>  		__arch_info_begin = .;
> @@ -71,6 +78,7 @@ SECTIONS
>  #ifndef CONFIG_XIP_KERNEL
>  		__init_begin = _stext;
>  		INIT_DATA
> +		ARM_EXIT_KEEP(EXIT_DATA)
>  #endif
>  	}
>  
> @@ -166,6 +174,7 @@ SECTIONS
>  		. = ALIGN(PAGE_SIZE);
>  		__init_begin = .;
>  		INIT_DATA
> +		ARM_EXIT_KEEP(EXIT_DATA)
>  		. = ALIGN(PAGE_SIZE);
>  		__init_end = .;
>  #endif
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This works for me in a case known to fail without the patch.

Tested-by: Dave Martin <dave.martin@linaro.org>

I still don't quite understand the intricacies of how vmlinux
is laid out, but the patch looks sensible.

Do you need anything more from me on this?  If not, I will
throw away my patch and replace it with yours.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-16 16:35                                               ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-16 16:35 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Fri, Feb 11, 2011 at 04:32:47PM +0000, Russell King - ARM Linux wrote:

[...]

> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 45b5651..343d29f 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -21,6 +21,12 @@
>  #define ARM_CPU_KEEP(x)
>  #endif
>  
> +#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
> +#define ARM_EXIT_KEEP(x)	x
> +#else
> +#define ARM_EXIT_KEEP(x)
> +#endif
> +
>  OUTPUT_ARCH(arm)
>  ENTRY(stext)
>  
> @@ -43,6 +49,7 @@ SECTIONS
>  		_sinittext = .;
>  			HEAD_TEXT
>  			INIT_TEXT
> +			ARM_EXIT_KEEP(EXIT_TEXT)
>  		_einittext = .;
>  		ARM_CPU_DISCARD(PROC_INFO)
>  		__arch_info_begin = .;
> @@ -71,6 +78,7 @@ SECTIONS
>  #ifndef CONFIG_XIP_KERNEL
>  		__init_begin = _stext;
>  		INIT_DATA
> +		ARM_EXIT_KEEP(EXIT_DATA)
>  #endif
>  	}
>  
> @@ -166,6 +174,7 @@ SECTIONS
>  		. = ALIGN(PAGE_SIZE);
>  		__init_begin = .;
>  		INIT_DATA
> +		ARM_EXIT_KEEP(EXIT_DATA)
>  		. = ALIGN(PAGE_SIZE);
>  		__init_end = .;
>  #endif
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This works for me in a case known to fail without the patch.

Tested-by: Dave Martin <dave.martin@linaro.org>

I still don't quite understand the intricacies of how vmlinux
is laid out, but the patch looks sensible.

Do you need anything more from me on this?  If not, I will
throw away my patch and replace it with yours.

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

* Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
  2011-02-16 16:35                                               ` Dave Martin
@ 2011-02-18 17:52                                                 ` Dave Martin
  -1 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-18 17:52 UTC (permalink / raw)
  To: Russell King - ARM Linux; +Cc: Nicolas Pitre, linux-omap, linux-arm-kernel

Hi Russell,

On Wed, Feb 16, 2011 at 4:35 PM, Dave Martin <dave.martin@linaro.org> wrote:
> Hi,
>
> On Fri, Feb 11, 2011 at 04:32:47PM +0000, Russell King - ARM Linux wrote:
>
> [...]
>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>> index 45b5651..343d29f 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -21,6 +21,12 @@
>>  #define ARM_CPU_KEEP(x)
>>  #endif
>>
>> +#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
>> +#define ARM_EXIT_KEEP(x)     x
>> +#else
>> +#define ARM_EXIT_KEEP(x)
>> +#endif
>> +
>>  OUTPUT_ARCH(arm)
>>  ENTRY(stext)
>>
>> @@ -43,6 +49,7 @@ SECTIONS
>>               _sinittext = .;
>>                       HEAD_TEXT
>>                       INIT_TEXT
>> +                     ARM_EXIT_KEEP(EXIT_TEXT)
>>               _einittext = .;
>>               ARM_CPU_DISCARD(PROC_INFO)
>>               __arch_info_begin = .;
>> @@ -71,6 +78,7 @@ SECTIONS
>>  #ifndef CONFIG_XIP_KERNEL
>>               __init_begin = _stext;
>>               INIT_DATA
>> +             ARM_EXIT_KEEP(EXIT_DATA)
>>  #endif
>>       }
>>
>> @@ -166,6 +174,7 @@ SECTIONS
>>               . = ALIGN(PAGE_SIZE);
>>               __init_begin = .;
>>               INIT_DATA
>> +             ARM_EXIT_KEEP(EXIT_DATA)
>>               . = ALIGN(PAGE_SIZE);
>>               __init_end = .;
>>  #endif
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> This works for me in a case known to fail without the patch.
>
> Tested-by: Dave Martin <dave.martin@linaro.org>
>
> I still don't quite understand the intricacies of how vmlinux
> is laid out, but the patch looks sensible.
>
> Do you need anything more from me on this?  If not, I will
> throw away my patch and replace it with yours.

Are you still intending to merge your patch here?  I don't see it
anywhere yet, but I would like to get rid of my hack (which is rather
messy).

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 254+ messages in thread

* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
@ 2011-02-18 17:52                                                 ` Dave Martin
  0 siblings, 0 replies; 254+ messages in thread
From: Dave Martin @ 2011-02-18 17:52 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Russell,

On Wed, Feb 16, 2011 at 4:35 PM, Dave Martin <dave.martin@linaro.org> wrote:
> Hi,
>
> On Fri, Feb 11, 2011 at 04:32:47PM +0000, Russell King - ARM Linux wrote:
>
> [...]
>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>> index 45b5651..343d29f 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -21,6 +21,12 @@
>> ?#define ARM_CPU_KEEP(x)
>> ?#endif
>>
>> +#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
>> +#define ARM_EXIT_KEEP(x) ? ? x
>> +#else
>> +#define ARM_EXIT_KEEP(x)
>> +#endif
>> +
>> ?OUTPUT_ARCH(arm)
>> ?ENTRY(stext)
>>
>> @@ -43,6 +49,7 @@ SECTIONS
>> ? ? ? ? ? ? ? _sinittext = .;
>> ? ? ? ? ? ? ? ? ? ? ? HEAD_TEXT
>> ? ? ? ? ? ? ? ? ? ? ? INIT_TEXT
>> + ? ? ? ? ? ? ? ? ? ? ARM_EXIT_KEEP(EXIT_TEXT)
>> ? ? ? ? ? ? ? _einittext = .;
>> ? ? ? ? ? ? ? ARM_CPU_DISCARD(PROC_INFO)
>> ? ? ? ? ? ? ? __arch_info_begin = .;
>> @@ -71,6 +78,7 @@ SECTIONS
>> ?#ifndef CONFIG_XIP_KERNEL
>> ? ? ? ? ? ? ? __init_begin = _stext;
>> ? ? ? ? ? ? ? INIT_DATA
>> + ? ? ? ? ? ? ARM_EXIT_KEEP(EXIT_DATA)
>> ?#endif
>> ? ? ? }
>>
>> @@ -166,6 +174,7 @@ SECTIONS
>> ? ? ? ? ? ? ? . = ALIGN(PAGE_SIZE);
>> ? ? ? ? ? ? ? __init_begin = .;
>> ? ? ? ? ? ? ? INIT_DATA
>> + ? ? ? ? ? ? ARM_EXIT_KEEP(EXIT_DATA)
>> ? ? ? ? ? ? ? . = ALIGN(PAGE_SIZE);
>> ? ? ? ? ? ? ? __init_end = .;
>> ?#endif
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> This works for me in a case known to fail without the patch.
>
> Tested-by: Dave Martin <dave.martin@linaro.org>
>
> I still don't quite understand the intricacies of how vmlinux
> is laid out, but the patch looks sensible.
>
> Do you need anything more from me on this? ?If not, I will
> throw away my patch and replace it with yours.

Are you still intending to merge your patch here?  I don't see it
anywhere yet, but I would like to get rid of my hack (which is rather
messy).

Cheers
---Dave

^ permalink raw reply	[flat|nested] 254+ messages in thread

end of thread, other threads:[~2011-02-18 17:53 UTC | newest]

Thread overview: 254+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-17 19:20 [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels Russell King - ARM Linux
2011-01-17 19:20 ` Russell King - ARM Linux
2011-01-17 19:21 ` [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer Russell King - ARM Linux
2011-01-17 19:21   ` Russell King - ARM Linux
2011-01-18  6:00   ` Nicolas Pitre
2011-01-18  6:00     ` Nicolas Pitre
2011-01-18 14:30     ` Russell King - ARM Linux
2011-01-18 14:30       ` Russell King - ARM Linux
2011-01-18 18:20       ` Nicolas Pitre
2011-01-18 18:20         ` Nicolas Pitre
2011-01-18 15:11     ` Catalin Marinas
2011-01-18 15:11       ` Catalin Marinas
2011-01-25 19:50   ` Tony Lindgren
2011-01-25 19:50     ` Tony Lindgren
2011-01-17 19:21 ` [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex Russell King - ARM Linux
2011-01-17 19:21   ` Russell King - ARM Linux
2011-01-18  5:42   ` Nicolas Pitre
2011-01-18  5:42     ` Nicolas Pitre
2011-01-23  0:16   ` Russell King - ARM Linux
2011-01-23  0:16     ` Russell King - ARM Linux
2011-01-23  4:44     ` Nicolas Pitre
2011-01-23  4:44       ` Nicolas Pitre
2011-01-23  9:35       ` Russell King - ARM Linux
2011-01-23  9:35         ` Russell King - ARM Linux
2011-01-24  8:38         ` Poddar, Sourav
2011-01-24  8:38           ` Poddar, Sourav
2011-01-24  8:57           ` Poddar, Sourav
2011-01-24  8:57             ` Poddar, Sourav
2011-01-24 10:28             ` Russell King - ARM Linux
2011-01-24 10:28               ` Russell King - ARM Linux
2011-01-24 13:47               ` Poddar, Sourav
2011-01-24 13:47                 ` Poddar, Sourav
2011-01-24 14:11                 ` Russell King - ARM Linux
2011-01-24 14:11                   ` Russell King - ARM Linux
2011-01-24 14:54                   ` Poddar, Sourav
2011-01-24 14:54                     ` Poddar, Sourav
2011-01-24 15:00                     ` Russell King - ARM Linux
2011-01-24 15:00                       ` Russell King - ARM Linux
2011-01-25 13:57     ` Will Deacon
2011-01-25 13:57     ` Will Deacon
2011-01-25 14:11       ` Russell King - ARM Linux
2011-01-25 14:11         ` Russell King - ARM Linux
2011-01-25 14:19         ` Will Deacon
2011-01-25 14:19         ` Will Deacon
     [not found]     ` <000601cbbc97$cc6955d0$653c0170$%deacon@arm.com>
2011-01-25 21:38       ` Nicolas Pitre
2011-01-25 21:38         ` Nicolas Pitre
2011-01-25 19:51   ` Tony Lindgren
2011-01-25 19:51     ` Tony Lindgren
2011-01-17 19:22 ` [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h Russell King - ARM Linux
2011-01-17 19:22   ` Russell King - ARM Linux
2011-01-17 23:13   ` Tony Lindgren
2011-01-17 23:13     ` Tony Lindgren
2011-01-25 16:43   ` Dave Martin
2011-01-25 16:43     ` Dave Martin
2011-01-25 16:59     ` Russell King - ARM Linux
2011-01-25 16:59       ` Russell King - ARM Linux
2011-01-25 17:33       ` Dave Martin
2011-01-25 17:33         ` Dave Martin
2011-01-25 17:46         ` Russell King - ARM Linux
2011-01-25 17:46           ` Russell King - ARM Linux
2011-01-25 21:21           ` Nicolas Pitre
2011-01-25 21:21             ` Nicolas Pitre
2011-01-26 11:11             ` Dave Martin
2011-01-26 11:11               ` Dave Martin
2011-01-26 12:44               ` Russell King - ARM Linux
2011-01-26 12:44                 ` Russell King - ARM Linux
2011-01-26 17:25                 ` [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups Dave P. Martin
2011-01-26 17:25                   ` Dave P. Martin
2011-01-26 21:31                   ` Nicolas Pitre
2011-01-26 21:31                     ` Nicolas Pitre
2011-01-27 14:37                     ` [PATCH v2] ARM: Avoid discarding sections that might have SMP_ON_UP fixups " Dave Martin
2011-01-27 14:37                       ` Dave Martin
2011-01-27 16:46                       ` Russell King - ARM Linux
2011-01-27 16:46                         ` Russell King - ARM Linux
2011-02-09 14:22                   ` [PATCH] ARM: Avoid discarding sections that might have " Russell King - ARM Linux
2011-02-09 14:22                     ` Russell King - ARM Linux
2011-02-10 12:56                     ` Russell King - ARM Linux
2011-02-10 12:56                       ` Russell King - ARM Linux
2011-02-10 14:11                       ` Dave Martin
2011-02-10 14:11                         ` Dave Martin
2011-02-10 14:13                         ` Dave Martin
2011-02-10 14:13                           ` Dave Martin
2011-02-10 14:46                           ` Russell King - ARM Linux
2011-02-10 14:46                             ` Russell King - ARM Linux
2011-02-10 18:29                             ` Dave Martin
2011-02-10 18:29                               ` Dave Martin
2011-02-10 19:11                               ` Russell King - ARM Linux
2011-02-10 19:11                                 ` Russell King - ARM Linux
2011-02-11  9:33                                 ` Dave Martin
2011-02-11  9:33                                   ` Dave Martin
2011-02-11 10:13                                   ` Russell King - ARM Linux
2011-02-11 10:13                                     ` Russell King - ARM Linux
2011-02-11 10:52                                     ` Dave Martin
2011-02-11 10:52                                       ` Dave Martin
2011-02-11 16:05                                       ` Russell King - ARM Linux
2011-02-11 16:05                                         ` Russell King - ARM Linux
2011-02-11 16:17                                         ` Dave Martin
2011-02-11 16:17                                           ` Dave Martin
2011-02-11 16:32                                           ` Russell King - ARM Linux
2011-02-11 16:32                                             ` Russell King - ARM Linux
2011-02-16 16:35                                             ` Dave Martin
2011-02-16 16:35                                               ` Dave Martin
2011-02-18 17:52                                               ` Dave Martin
2011-02-18 17:52                                                 ` Dave Martin
2011-01-26 15:42               ` [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h Nicolas Pitre
2011-01-26 15:42                 ` Nicolas Pitre
2011-01-26 15:52                 ` Russell King - ARM Linux
2011-01-26 15:52                   ` Russell King - ARM Linux
2011-01-26 16:59                   ` Dave Martin
2011-01-26 16:59                     ` Dave Martin
2011-01-26 21:06                     ` Nicolas Pitre
2011-01-26 21:06                       ` Nicolas Pitre
2011-01-27 11:44                       ` Dave P. Martin
2011-01-27 11:44                         ` Dave P. Martin
2011-01-17 19:22 ` [PATCH 04/14] ARM: v6k: introduce CPU_V6K option Russell King - ARM Linux
2011-01-17 19:22   ` Russell King - ARM Linux
2011-01-17 23:14   ` Tony Lindgren
2011-01-17 23:14     ` Tony Lindgren
2011-01-18 10:36   ` Will Deacon
2011-01-18 10:36   ` Will Deacon
2011-01-18 11:09     ` Russell King - ARM Linux
2011-01-18 11:09       ` Russell King - ARM Linux
2011-01-18 13:35       ` Russell King - ARM Linux
2011-01-18 13:35         ` Russell King - ARM Linux
2011-01-18 15:22         ` Will Deacon
2011-01-18 15:22         ` Will Deacon
2011-01-17 19:22 ` [PATCH 05/14] ARM: v6k: Realview EB 11MPCore and PB11MPCore use V6K architecture CPUs Russell King - ARM Linux
2011-01-17 19:22   ` Russell King - ARM Linux
2011-01-17 19:23 ` [PATCH 06/14] ARM: v6k: Dove platforms " Russell King - ARM Linux
2011-01-17 19:23   ` Russell King - ARM Linux
2011-01-17 23:39   ` Nicolas Pitre
2011-01-17 23:39     ` Nicolas Pitre
2011-01-17 19:23 ` [PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants Russell King - ARM Linux
2011-01-17 19:23   ` Russell King - ARM Linux
2011-01-17 23:15   ` Tony Lindgren
2011-01-17 23:15     ` Tony Lindgren
2011-01-17 19:23 ` [PATCH 08/14] ARM: v6k: select cmpxchg code sequences " Russell King - ARM Linux
2011-01-17 19:23   ` Russell King - ARM Linux
2011-01-17 23:18   ` Tony Lindgren
2011-01-17 23:18     ` Tony Lindgren
2011-01-17 19:24 ` [PATCH 09/14] ARM: v6k: select generic atomic64 code " Russell King - ARM Linux
2011-01-17 19:24   ` Russell King - ARM Linux
2011-01-17 23:21   ` Tony Lindgren
2011-01-17 23:21     ` Tony Lindgren
2011-01-18 10:24   ` Will Deacon
2011-01-18 10:24   ` Will Deacon
2011-01-17 19:24 ` [PATCH 10/14] ARM: v6k: select TLS register " Russell King - ARM Linux
2011-01-17 19:24   ` Russell King - ARM Linux
2011-01-17 22:23   ` Nicolas Pitre
2011-01-17 22:23     ` Nicolas Pitre
2011-01-17 22:36     ` Russell King - ARM Linux
2011-01-17 22:36       ` Russell King - ARM Linux
2011-01-17 22:52       ` Russell King - ARM Linux
2011-01-17 22:52         ` Russell King - ARM Linux
2011-01-18  4:27         ` Nicolas Pitre
2011-01-18  4:27           ` Nicolas Pitre
2011-01-18  4:25       ` Nicolas Pitre
2011-01-18  4:25         ` Nicolas Pitre
2011-01-17 23:21     ` Tony Lindgren
2011-01-17 23:21       ` Tony Lindgren
2011-01-17 19:24 ` [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch < ARMv6K Russell King - ARM Linux
2011-01-17 19:24   ` Russell King - ARM Linux
2011-01-17 22:03   ` Nicolas Pitre
2011-01-17 22:03     ` Nicolas Pitre
2011-01-17 23:23     ` Tony Lindgren
2011-01-17 23:23       ` Tony Lindgren
2011-01-27 18:14   ` Catalin Marinas
2011-01-27 18:14     ` Catalin Marinas
2011-01-27 18:59     ` Russell King - ARM Linux
2011-01-27 18:59       ` Russell King - ARM Linux
2011-01-28  9:46       ` Catalin Marinas
2011-01-28  9:46         ` Catalin Marinas
2011-01-28  9:59         ` Russell King - ARM Linux
2011-01-28  9:59           ` Russell King - ARM Linux
2011-01-28 10:46           ` Catalin Marinas
2011-01-28 10:46             ` Catalin Marinas
2011-01-28 11:06             ` Russell King - ARM Linux
2011-01-28 11:06               ` Russell King - ARM Linux
2011-01-28 12:25               ` Catalin Marinas
2011-01-28 12:25                 ` Catalin Marinas
2011-01-28 13:05                 ` Russell King - ARM Linux
2011-01-28 13:05                   ` Russell King - ARM Linux
2011-01-28 13:10                   ` Catalin Marinas
2011-01-28 13:10                     ` Catalin Marinas
2011-01-28 13:22                     ` Russell King - ARM Linux
2011-01-28 13:22                       ` Russell King - ARM Linux
2011-01-28 13:21                 ` Russell King - ARM Linux
2011-01-28 13:21                   ` Russell King - ARM Linux
2011-01-28 15:11                   ` Catalin Marinas
2011-01-28 15:11                     ` Catalin Marinas
2011-01-28 16:49                     ` Tony Lindgren
2011-01-28 16:49                       ` Tony Lindgren
2011-01-17 19:25 ` [PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection Russell King - ARM Linux
2011-01-17 19:25   ` Russell King - ARM Linux
2011-01-17 23:24   ` Tony Lindgren
2011-01-17 23:24     ` Tony Lindgren
2011-01-17 19:25 ` [PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled Russell King - ARM Linux
2011-01-17 19:25   ` Russell King - ARM Linux
2011-01-17 23:24   ` Tony Lindgren
2011-01-17 23:24     ` Tony Lindgren
2011-01-17 19:25 ` [PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU Russell King - ARM Linux
2011-01-17 19:25   ` Russell King - ARM Linux
2011-01-17 23:25   ` Tony Lindgren
2011-01-17 23:25     ` Tony Lindgren
2011-01-17 22:21 ` [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels Tony Lindgren
2011-01-17 22:21   ` Tony Lindgren
2011-01-18 14:30 ` Kirill A. Shutemov
2011-01-18 14:30   ` Kirill A. Shutemov
2011-01-18 14:40   ` Russell King - ARM Linux
2011-01-18 14:40     ` Russell King - ARM Linux
2011-01-18 14:44     ` Kirill A. Shutemov
2011-01-18 14:44       ` Kirill A. Shutemov
2011-01-18 15:01       ` Russell King - ARM Linux
2011-01-18 15:01         ` Russell King - ARM Linux
2011-02-08 16:36 ` Santosh Shilimkar
2011-02-08 16:36   ` Santosh Shilimkar
2011-02-08 16:47   ` Russell King - ARM Linux
2011-02-08 16:47     ` Russell King - ARM Linux
2011-02-08 16:58     ` Santosh Shilimkar
2011-02-08 16:58       ` Santosh Shilimkar
2011-02-08 20:43       ` Nicolas Pitre
2011-02-08 20:43         ` Nicolas Pitre
2011-02-09  0:35         ` Tony Lindgren
2011-02-09  0:35           ` Tony Lindgren
2011-02-09  6:04           ` Santosh Shilimkar
2011-02-09  6:04             ` Santosh Shilimkar
2011-02-09  9:48             ` Dave Martin
2011-02-09  9:48               ` Dave Martin
2011-02-09 10:00               ` Santosh Shilimkar
2011-02-09 10:00                 ` Santosh Shilimkar
2011-02-09 16:24                 ` Tony Lindgren
2011-02-09 16:24                   ` Tony Lindgren
2011-02-09 16:27                   ` Santosh Shilimkar
2011-02-09 16:27                     ` Santosh Shilimkar
2011-02-09 16:32                   ` Russell King - ARM Linux
2011-02-09 16:32                     ` Russell King - ARM Linux
2011-02-09 16:44                     ` Russell King - ARM Linux
2011-02-09 16:44                       ` Russell King - ARM Linux
2011-02-09 16:45                     ` Nicolas Pitre
2011-02-09 16:45                       ` Nicolas Pitre
2011-02-09 17:48                       ` Tony Lindgren
2011-02-09 17:48                         ` Tony Lindgren
2011-02-09 10:01     ` Catalin Marinas
2011-02-09 10:01       ` Catalin Marinas
2011-02-10 13:04       ` Russell King - ARM Linux
2011-02-10 13:04         ` Russell King - ARM Linux
2011-02-10 13:12         ` Catalin Marinas
2011-02-10 13:12           ` Catalin Marinas
2011-02-10 13:16           ` Russell King - ARM Linux
2011-02-10 13:16             ` Russell King - ARM Linux
2011-02-11 20:45           ` Nicolas Pitre
2011-02-11 20:45             ` Nicolas Pitre
2011-02-11 21:07             ` Russell King - ARM Linux
2011-02-11 21:07               ` Russell King - ARM Linux

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.