[GIT PULL 0/9] ARM architecture fixes for 3.7

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Arnd Bergmann]

From: <arnd@arndb.de>

Hi Russell,

Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.

These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

	Arnd

The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems:
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Cc: bryan.wu@canonical.com
Cc: catalin.marinas@arm.com
Cc: dave.martin@linaro.org
Cc: jeremy@goop.org
Cc: jonathan.austin@arm.com
Cc: konrad.wilk@oracle.com
Cc: leif.lindholm@arm.com
Cc: linus.walleij@linaro.org
Cc: damm@opensource.se
Cc: mmarek@suse.cz
Cc: rjw@sisk.pl
Cc: rmk+kernel@arm.linux.org.uk
Cc: stefano.stabellini@eu.citrix.com
Cc: sboyd@codeaurora.org
Cc: tglx@linutronix.de
Cc: will.deacon@arm.com
Cc: xen-devel@lists.xensource.com

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Arnd Bergmann]

From: <arnd@arndb.de>

Hi Russell,

Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.

These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

	Arnd

The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems:
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Cc: bryan.wu at canonical.com
Cc: catalin.marinas at arm.com
Cc: dave.martin at linaro.org
Cc: jeremy at goop.org
Cc: jonathan.austin at arm.com
Cc: konrad.wilk at oracle.com
Cc: leif.lindholm at arm.com
Cc: linus.walleij at linaro.org
Cc: damm at opensource.se
Cc: mmarek at suse.cz
Cc: rjw at sisk.pl
Cc: rmk+kernel at arm.linux.org.uk
Cc: stefano.stabellini at eu.citrix.com
Cc: sboyd at codeaurora.org
Cc: tglx at linutronix.de
Cc: will.deacon at arm.com
Cc: xen-devel at lists.xensource.com

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Arnd Bergmann]

From: <arnd@arndb.de>

Hi Russell,

Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.

These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

	Arnd

The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems:
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Cc: bryan.wu@canonical.com
Cc: catalin.marinas@arm.com
Cc: dave.martin@linaro.org
Cc: jeremy@goop.org
Cc: jonathan.austin@arm.com
Cc: konrad.wilk@oracle.com
Cc: leif.lindholm@arm.com
Cc: linus.walleij@linaro.org
Cc: damm@opensource.se
Cc: mmarek@suse.cz
Cc: rjw@sisk.pl
Cc: rmk+kernel@arm.linux.org.uk
Cc: stefano.stabellini@eu.citrix.com
Cc: sboyd@codeaurora.org
Cc: tglx@linutronix.de
Cc: will.deacon@arm.com
Cc: xen-devel@lists.xensource.com

[PATCH 1/9] ARM: kprobes: make more tests conditional

[Arnd Bergmann]

The mls instruction is not available in ARMv6K or below, so we
should make the test conditional on at least ARMv7. ldrexd/strexd
are available in ARMv6K or ARMv7, which we can test by checking
the CONFIG_CPU_32v6K symbol.

/tmp/ccuMTZ8D.s: Assembler messages:
/tmp/ccuMTZ8D.s:22188: Error: selected processor does not support ARM mode `mls r0,r1,r2,r3'
/tmp/ccuMTZ8D.s:22222: Error: selected processor does not support ARM mode `mlshi r7,r8,r9,r10'
/tmp/ccuMTZ8D.s:22252: Error: selected processor does not support ARM mode `mls lr,r1,r2,r13'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Leif Lindholm <leif.lindholm@arm.com>
---
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 38c1a3b..8393129 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -366,7 +366,9 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(".word 0xe04f0392 @ umaal r0, pc, r2, r3")
 	TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
 	TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+#endif
 
+#if __LINUX_ARM_ARCH__ >= 7
 	TEST_RRR(  "mls		r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(  "mlshi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(   "mls		lr, r",1, VAL2,", r",2, VAL3,", r13")
@@ -456,6 +458,8 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(".word	0xe1700090") /* Unallocated space */
 #if __LINUX_ARM_ARCH__ >= 6
 	TEST_UNSUPPORTED("ldrex	r2, [sp]")
+#endif
+#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
 	TEST_UNSUPPORTED("strexd	r0, r2, r3, [sp]")
 	TEST_UNSUPPORTED("ldrexd	r2, r3, [sp]")
 	TEST_UNSUPPORTED("strexb	r0, r2, [sp]")
-- 
1.7.10

[PATCH 1/9] ARM: kprobes: make more tests conditional

[Arnd Bergmann]

The mls instruction is not available in ARMv6K or below, so we
should make the test conditional on at least ARMv7. ldrexd/strexd
are available in ARMv6K or ARMv7, which we can test by checking
the CONFIG_CPU_32v6K symbol.

/tmp/ccuMTZ8D.s: Assembler messages:
/tmp/ccuMTZ8D.s:22188: Error: selected processor does not support ARM mode `mls r0,r1,r2,r3'
/tmp/ccuMTZ8D.s:22222: Error: selected processor does not support ARM mode `mlshi r7,r8,r9,r10'
/tmp/ccuMTZ8D.s:22252: Error: selected processor does not support ARM mode `mls lr,r1,r2,r13'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Leif Lindholm <leif.lindholm@arm.com>
---
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 38c1a3b..8393129 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -366,7 +366,9 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(".word 0xe04f0392 @ umaal r0, pc, r2, r3")
 	TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
 	TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+#endif
 
+#if __LINUX_ARM_ARCH__ >= 7
 	TEST_RRR(  "mls		r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(  "mlshi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(   "mls		lr, r",1, VAL2,", r",2, VAL3,", r13")
@@ -456,6 +458,8 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(".word	0xe1700090") /* Unallocated space */
 #if __LINUX_ARM_ARCH__ >= 6
 	TEST_UNSUPPORTED("ldrex	r2, [sp]")
+#endif
+#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
 	TEST_UNSUPPORTED("strexd	r0, r2, r3, [sp]")
 	TEST_UNSUPPORTED("ldrexd	r2, r3, [sp]")
 	TEST_UNSUPPORTED("strexb	r0, r2, [sp]")
-- 
1.7.10

[PATCH 2/9] ARM: export set_irq_flags

[Arnd Bergmann]

The recently added Emma Mobile GPIO driver calls set_irq_flags
and irq_set_chip_and_handler for the interrupts it exports and
it can be built as a module, which currently fails with

ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!

We either need to replace the call to set_irq_flags with something
else or export that function. This patch does the latter.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Magnus Damm <damm@opensource.se>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/irq.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 16cedb4..8961650 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -34,6 +34,7 @@
 #include <linux/list.h>
 #include <linux/kallsyms.h>
 #include <linux/proc_fs.h>
+#include <linux/export.h>
 
 #include <asm/exception.h>
 #include <asm/mach/arch.h>
@@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
 	/* Order is clear bits in "clr" then set bits in "set" */
 	irq_modify_status(irq, clr, set & ~clr);
 }
+EXPORT_SYMBOL_GPL(set_irq_flags);
 
 void __init init_IRQ(void)
 {
-- 
1.7.10

[PATCH 2/9] ARM: export set_irq_flags

[Arnd Bergmann]

The recently added Emma Mobile GPIO driver calls set_irq_flags
and irq_set_chip_and_handler for the interrupts it exports and
it can be built as a module, which currently fails with

ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!

We either need to replace the call to set_irq_flags with something
else or export that function. This patch does the latter.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Magnus Damm <damm@opensource.se>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/irq.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 16cedb4..8961650 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -34,6 +34,7 @@
 #include <linux/list.h>
 #include <linux/kallsyms.h>
 #include <linux/proc_fs.h>
+#include <linux/export.h>
 
 #include <asm/exception.h>
 #include <asm/mach/arch.h>
@@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
 	/* Order is clear bits in "clr" then set bits in "set" */
 	irq_modify_status(irq, clr, set & ~clr);
 }
+EXPORT_SYMBOL_GPL(set_irq_flags);
 
 void __init init_IRQ(void)
 {
-- 
1.7.10

[PATCH 3/9] ARM: Fix another build warning in arch/arm/mm/alignment.c

[Arnd Bergmann]

One such warning was recently fixed in a761cebf "ARM: Fix build warning
in arch/arm/mm/alignment.c" but only for the thumb2 case, this fixes
the other half.

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: error: 'offset.un' may be used uninitialized in this function
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/alignment.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index b9f60eb..023f4437 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -856,8 +856,10 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 		if (thumb2_32b) {
 			offset.un = 0;
 			handler = do_alignment_t32_to_handler(&instr, regs, &offset);
-		} else
+		} else {
+			offset.un = 0;
 			handler = do_alignment_ldmstm;
+		}
 		break;
 
 	default:
-- 
1.7.10

[PATCH 3/9] ARM: Fix another build warning in arch/arm/mm/alignment.c

[Arnd Bergmann]

One such warning was recently fixed in a761cebf "ARM: Fix build warning
in arch/arm/mm/alignment.c" but only for the thumb2 case, this fixes
the other half.

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: error: 'offset.un' may be used uninitialized in this function
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/alignment.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index b9f60eb..023f4437 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -856,8 +856,10 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 		if (thumb2_32b) {
 			offset.un = 0;
 			handler = do_alignment_t32_to_handler(&instr, regs, &offset);
-		} else
+		} else {
+			offset.un = 0;
 			handler = do_alignment_ldmstm;
+		}
 		break;
 
 	default:
-- 
1.7.10

[PATCH 4/9] ARM: export default read_current_timer

[Arnd Bergmann]

read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
add registration mechanism for delay timer sources", and get_cycles
can be used by device drivers in loadable modules, so it has to
be exported.

Without this patch, building imote2_defconfig fails with

ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Jonathan Austin <jonathan.austin@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/lib/delay.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index 9d0a300..0dc5385 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c
@@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
 	*timer_val = delay_timer->read_current_timer();
 	return 0;
 }
+EXPORT_SYMBOL_GPL(read_current_timer);
 
 static void __timer_delay(unsigned long cycles)
 {
-- 
1.7.10

[PATCH 4/9] ARM: export default read_current_timer

[Arnd Bergmann]

read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
add registration mechanism for delay timer sources", and get_cycles
can be used by device drivers in loadable modules, so it has to
be exported.

Without this patch, building imote2_defconfig fails with

ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Jonathan Austin <jonathan.austin@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/lib/delay.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index 9d0a300..0dc5385 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c
@@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
 	*timer_val = delay_timer->read_current_timer();
 	return 0;
 }
+EXPORT_SYMBOL_GPL(read_current_timer);
 
 static void __timer_delay(unsigned long cycles)
 {
-- 
1.7.10

[PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

* The XEN_BALLOON code requires the balloon infrastructure that is not
  getting built on ARM.

* The tmem hypercall is not available on ARM

* ARMv6 does not support cmpxchg on 16-bit words that are used in the

* sys-hypervisor.c needs to include linux/err.h in order to use the
  IS_ERR/PTR_ERR/ERR_PTR family of functions.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
---
 arch/arm/Kconfig             |    1 +
 drivers/xen/Kconfig          |    2 ++
 drivers/xen/sys-hypervisor.c |    1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..85eaac3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1846,6 +1846,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM (EXPERIMENTAL)"
 	depends on EXPERIMENTAL && ARM && OF
+	depends on !CPU_V6
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..126d8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -3,6 +3,7 @@ menu "Xen driver support"
 
 config XEN_BALLOON
 	bool "Xen memory balloon driver"
+	depends on !ARM
 	default y
 	help
 	  The balloon driver allows the Xen domain to request more memory from
@@ -145,6 +146,7 @@ config SWIOTLB_XEN
 
 config XEN_TMEM
 	bool
+	depends on !ARM
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/kobject.h>
+#include <linux/err.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
-- 
1.7.10

[PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

* The XEN_BALLOON code requires the balloon infrastructure that is not
  getting built on ARM.

* The tmem hypercall is not available on ARM

* ARMv6 does not support cmpxchg on 16-bit words that are used in the

* sys-hypervisor.c needs to include linux/err.h in order to use the
  IS_ERR/PTR_ERR/ERR_PTR family of functions.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel at lists.xensource.com
---
 arch/arm/Kconfig             |    1 +
 drivers/xen/Kconfig          |    2 ++
 drivers/xen/sys-hypervisor.c |    1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..85eaac3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1846,6 +1846,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM (EXPERIMENTAL)"
 	depends on EXPERIMENTAL && ARM && OF
+	depends on !CPU_V6
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..126d8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -3,6 +3,7 @@ menu "Xen driver support"
 
 config XEN_BALLOON
 	bool "Xen memory balloon driver"
+	depends on !ARM
 	default y
 	help
 	  The balloon driver allows the Xen domain to request more memory from
@@ -145,6 +146,7 @@ config SWIOTLB_XEN
 
 config XEN_TMEM
 	bool
+	depends on !ARM
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/kobject.h>
+#include <linux/err.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
-- 
1.7.10

[PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler

[Arnd Bergmann]

The Linaro cross toolchain and probably others nowadays default to
building in THUMB2 mode. When building a kernel for a CPU that does
not support THUMB2, the compiler complains about incorrect flags.
We can work around this by setting -marm for all non-T2 builds.

Without this patch, building assabet_defconfig results in:

usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
(and many more)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/Makefile |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index f023e3a..5f914fc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -21,8 +21,6 @@ endif
 OBJCOPYFLAGS	:=-O binary -R .comment -S
 GZFLAGS		:=-9
 #KBUILD_CFLAGS	+=-pipe
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-KBUILD_CFLAGS	+=$(call cc-option,-marm,)
 
 # Never generate .eh_frame
 KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endif
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 AFLAGS_AUTOIT	:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
-CFLAGS_THUMB2	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
-AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
+CFLAGS_ISA	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
+AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
 # Work around buggy relocation from gas if requested:
 ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
 CFLAGS_MODULE	+=-fno-optimize-sibling-calls
 endif
+else
+CFLAGS_ISA	:=$(call cc-option,-marm,)
+AFLAGS_ISA	:=$(CFLAGS_ISA)
 endif
 
 # Need -Uarm for gcc < 3.x
-KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
-KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
+KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
+KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
 
 CHECKFLAGS	+= -D__arm__
 
-- 
1.7.10

[PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler

[Arnd Bergmann]

The Linaro cross toolchain and probably others nowadays default to
building in THUMB2 mode. When building a kernel for a CPU that does
not support THUMB2, the compiler complains about incorrect flags.
We can work around this by setting -marm for all non-T2 builds.

Without this patch, building assabet_defconfig results in:

usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
(and many more)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/Makefile |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index f023e3a..5f914fc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -21,8 +21,6 @@ endif
 OBJCOPYFLAGS	:=-O binary -R .comment -S
 GZFLAGS		:=-9
 #KBUILD_CFLAGS	+=-pipe
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-KBUILD_CFLAGS	+=$(call cc-option,-marm,)
 
 # Never generate .eh_frame
 KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endif
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 AFLAGS_AUTOIT	:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
-CFLAGS_THUMB2	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
-AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
+CFLAGS_ISA	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
+AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
 # Work around buggy relocation from gas if requested:
 ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
 CFLAGS_MODULE	+=-fno-optimize-sibling-calls
 endif
+else
+CFLAGS_ISA	:=$(call cc-option,-marm,)
+AFLAGS_ISA	:=$(CFLAGS_ISA)
 endif
 
 # Need -Uarm for gcc < 3.x
-KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
-KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
+KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
+KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
 
 CHECKFLAGS	+= -D__arm__
 
-- 
1.7.10

[PATCH 7/9] ARM: be really quiet when building with 'make -s'

[Arnd Bergmann]

Sometimes we want the kernel build process to only print messages
on errors, e.g. in automated build testing. This uses the "kecho"
macro that the build system provides to hide a few informational
messages. Nothing changes for a regular "make" or "make V=1".

Without this patch, building any ARM kernel results in:

  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Marek <mmarek@suse.cz>
---
 arch/arm/boot/Makefile  |   10 +++++-----
 arch/arm/tools/Makefile |    2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 3fdab01..f2aa09e 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -33,7 +33,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
 
 $(obj)/xipImage: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
+	$(kecho) '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
 
 $(obj)/Image $(obj)/zImage: FORCE
 	@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
@@ -48,14 +48,14 @@ $(obj)/xipImage: FORCE
 
 $(obj)/Image: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 $(obj)/compressed/vmlinux: $(obj)/Image FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
 $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 endif
 
@@ -90,7 +90,7 @@ fi
 $(obj)/uImage:	$(obj)/zImage FORCE
 	@$(check_for_multiple_loadaddr)
 	$(call if_changed,uimage)
-	@echo '  Image $@ is ready'
+	$(kecho) '  Image $@ is ready'
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
@@ -98,7 +98,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 
 $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 PHONY += initrd FORCE
 initrd:
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index 635cb18..cd60a81 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -5,6 +5,6 @@
 #
 
 include/generated/mach-types.h: $(src)/gen-mach-types $(src)/mach-types
-	@echo '  Generating $@'
+	$(kecho) '  Generating $@'
 	@mkdir -p $(dir $@)
 	$(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }
-- 
1.7.10

[PATCH 7/9] ARM: be really quiet when building with 'make -s'

[Arnd Bergmann]

Sometimes we want the kernel build process to only print messages
on errors, e.g. in automated build testing. This uses the "kecho"
macro that the build system provides to hide a few informational
messages. Nothing changes for a regular "make" or "make V=1".

Without this patch, building any ARM kernel results in:

  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Marek <mmarek@suse.cz>
---
 arch/arm/boot/Makefile  |   10 +++++-----
 arch/arm/tools/Makefile |    2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 3fdab01..f2aa09e 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -33,7 +33,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
 
 $(obj)/xipImage: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
+	$(kecho) '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
 
 $(obj)/Image $(obj)/zImage: FORCE
 	@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
@@ -48,14 +48,14 @@ $(obj)/xipImage: FORCE
 
 $(obj)/Image: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 $(obj)/compressed/vmlinux: $(obj)/Image FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
 $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 endif
 
@@ -90,7 +90,7 @@ fi
 $(obj)/uImage:	$(obj)/zImage FORCE
 	@$(check_for_multiple_loadaddr)
 	$(call if_changed,uimage)
-	@echo '  Image $@ is ready'
+	$(kecho) '  Image $@ is ready'
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
@@ -98,7 +98,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 
 $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
 	$(call if_changed,objcopy)
-	@echo '  Kernel: $@ is ready'
+	$(kecho) '  Kernel: $@ is ready'
 
 PHONY += initrd FORCE
 initrd:
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index 635cb18..cd60a81 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -5,6 +5,6 @@
 #
 
 include/generated/mach-types.h: $(src)/gen-mach-types $(src)/mach-types
-	@echo '  Generating $@'
+	$(kecho) '  Generating $@'
 	@mkdir -p $(dir $@)
 	$(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }
-- 
1.7.10

[PATCH 8/9] ARM: binfmt_flat: unused variable 'persistent'

[Arnd Bergmann]

The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.

Without this patch, building at91x40_defconfig results in:

fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
---
 arch/arm/include/asm/flat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 59426a4..e847d23 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -8,7 +8,7 @@
 #define	flat_argvp_envp_on_stack()		1
 #define	flat_old_ram_flag(flags)		(flags)
 #define	flat_reloc_valid(reloc, size)		((reloc) <= (size))
-#define	flat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp)
+#define	flat_get_addr_from_rp(rp, relval, flags, persistent) ((void)persistent,get_unaligned(rp))
 #define	flat_put_addr_at_rp(rp, val, relval)	put_unaligned(val,rp)
 #define	flat_get_relocate_addr(rel)		(rel)
 #define	flat_set_persistent(relval, p)		0
-- 
1.7.10

[PATCH 8/9] ARM: binfmt_flat: unused variable 'persistent'

[Arnd Bergmann]

The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.

Without this patch, building at91x40_defconfig results in:

fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
---
 arch/arm/include/asm/flat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 59426a4..e847d23 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -8,7 +8,7 @@
 #define	flat_argvp_envp_on_stack()		1
 #define	flat_old_ram_flag(flags)		(flags)
 #define	flat_reloc_valid(reloc, size)		((reloc) <= (size))
-#define	flat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp)
+#define	flat_get_addr_from_rp(rp, relval, flags, persistent) ((void)persistent,get_unaligned(rp))
 #define	flat_put_addr_at_rp(rp, val, relval)	put_unaligned(val,rp)
 #define	flat_get_relocate_addr(rel)		(rel)
 #define	flat_set_persistent(relval, p)		0
-- 
1.7.10

[PATCH 9/9] ARM: warnings in arch/arm/include/asm/uaccess.h

[Arnd Bergmann]

On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.

Without this patch, building at91x40_defconfig results in:

fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/uaccess.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7e1f760 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
 #define USER_DS			KERNEL_DS
 
 #define segment_eq(a,b)		(1)
-#define __addr_ok(addr)		(1)
-#define __range_ok(addr,size)	(0)
+#define __addr_ok(addr)		((void)(addr),1)
+#define __range_ok(addr,size)	((void)(addr),0)
 #define get_fs()		(KERNEL_DS)
 
 static inline void set_fs(mm_segment_t fs)
-- 
1.7.10

[PATCH 9/9] ARM: warnings in arch/arm/include/asm/uaccess.h

[Arnd Bergmann]

On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.

Without this patch, building at91x40_defconfig results in:

fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/uaccess.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7e1f760 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
 #define USER_DS			KERNEL_DS
 
 #define segment_eq(a,b)		(1)
-#define __addr_ok(addr)		(1)
-#define __range_ok(addr,size)	(0)
+#define __addr_ok(addr)		((void)(addr),1)
+#define __range_ok(addr,size)	((void)(addr),0)
 #define get_fs()		(KERNEL_DS)
 
 static inline void set_fs(mm_segment_t fs)
-- 
1.7.10

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.

I've got patches to enable this, but not for 3.7 so this looks good for
now.

> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

missing the end of this sentence?

> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.

I tripped over this too. Not sure where that patch got to though.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.

I've got patches to enable this, but not for 3.7 so this looks good for
now.

> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

missing the end of this sentence?

> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.

I tripped over this too. Not sure where that patch got to though.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel at lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.

I've got patches to enable this, but not for 3.7 so this looks good for
now.

> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

missing the end of this sentence?

> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.

I tripped over this too. Not sure where that patch got to though.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

Thanks for the patch and sorry for the build breakage!

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

Considering that we rely on the virtualization extensions, this one can
be:

    depends on CPU_V7

The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> -- 
> 1.7.10
> 

[PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

Thanks for the patch and sorry for the build breakage!

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel at lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

Considering that we rely on the virtualization extensions, this one can
be:

    depends on CPU_V7

The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> -- 
> 1.7.10
> 

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

Thanks for the patch and sorry for the build breakage!

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

Considering that we rely on the virtualization extensions, this one can
be:

    depends on CPU_V7

The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/kobject.h>
> +#include <linux/err.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> -- 
> 1.7.10
> 

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> missing the end of this sentence?

Right, I meant to say 

* ARMv6 does not support cmpxchg on 16-bit words that are used in the
  Xen grant table code, so we must ensure that Xen support is only built
  on ARMv7-only kernels not combined ARMv6/v7 kernels.

This should be fixed differently in the future.

	Arnd

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> missing the end of this sentence?

Right, I meant to say 

* ARMv6 does not support cmpxchg on 16-bit words that are used in the
  Xen grant table code, so we must ensure that Xen support is only built
  on ARMv7-only kernels not combined ARMv6/v7 kernels.

This should be fixed differently in the future.

	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> missing the end of this sentence?

Right, I meant to say 

* ARMv6 does not support cmpxchg on 16-bit words that are used in the
  Xen grant table code, so we must ensure that Xen support is only built
  on ARMv7-only kernels not combined ARMv6/v7 kernels.

This should be fixed differently in the future.

	Arnd

Re: [PATCH 4/9] ARM: export default read_current_timer

[Jonathan Austin]

Hi Arnd,

On 09/10/12 16:22, Arnd Bergmann wrote:

> read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
> add registration mechanism for delay timer sources", and get_cycles
> can be used by device drivers in loadable modules, so it has to
> be exported.
> 
> Without this patch, building imote2_defconfig fails with
> 
> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
[...]

>  arch/arm/lib/delay.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> index 9d0a300..0dc5385 100644
> --- a/arch/arm/lib/delay.c
> +++ b/arch/arm/lib/delay.c
> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
>  	*timer_val = delay_timer->read_current_timer();
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(read_current_timer);


Perhaps this fits better in armksyms.c? That way it lives with
arm_delay_ops and friends.

I've got a patch doing it like that, which I can put in Russell's
patch-system, unless you prefer doing it in delay.c for any reason?

Jonny

(Here's the original patch sent to the kernel-janitors list and Will Deacon)
-------8<---------
On ARM, get_cycles() is implemented in terms of read_current_timer(), but
the latter is not exported to modules, resulting in failure to link:

  ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!

This patch exports the symbol as required.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
---
 arch/arm/kernel/armksyms.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 60d3b73..6a37f8d 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -50,6 +50,7 @@ extern void fpundefinstr(void);
 
        /* platform dependent support */
 EXPORT_SYMBOL(arm_delay_ops);
+EXPORT_SYMBOL(read_current_timer);
 
        /* networking */
 EXPORT_SYMBOL(csum_partial);
-- 
1.7.1

[PATCH 4/9] ARM: export default read_current_timer

[Jonathan Austin]

Hi Arnd,

On 09/10/12 16:22, Arnd Bergmann wrote:

> read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
> add registration mechanism for delay timer sources", and get_cycles
> can be used by device drivers in loadable modules, so it has to
> be exported.
> 
> Without this patch, building imote2_defconfig fails with
> 
> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
[...]

>  arch/arm/lib/delay.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> index 9d0a300..0dc5385 100644
> --- a/arch/arm/lib/delay.c
> +++ b/arch/arm/lib/delay.c
> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
>  	*timer_val = delay_timer->read_current_timer();
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(read_current_timer);


Perhaps this fits better in armksyms.c? That way it lives with
arm_delay_ops and friends.

I've got a patch doing it like that, which I can put in Russell's
patch-system, unless you prefer doing it in delay.c for any reason?

Jonny

(Here's the original patch sent to the kernel-janitors list and Will Deacon)
-------8<---------
On ARM, get_cycles() is implemented in terms of read_current_timer(), but
the latter is not exported to modules, resulting in failure to link:

  ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!

This patch exports the symbol as required.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
---
 arch/arm/kernel/armksyms.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 60d3b73..6a37f8d 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -50,6 +50,7 @@ extern void fpundefinstr(void);
 
        /* platform dependent support */
 EXPORT_SYMBOL(arm_delay_ops);
+EXPORT_SYMBOL(read_current_timer);
 
        /* networking */
 EXPORT_SYMBOL(csum_partial);
-- 
1.7.1

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

"in the" what?

[PATCH 5/9] ARM: Xen: fix initial build problems:

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

"in the" what?

Re: [PATCH 4/9] ARM: export default read_current_timer

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote:
> Hi Arnd,
> 
> On 09/10/12 16:22, Arnd Bergmann wrote:
> > diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> > index 9d0a300..0dc5385 100644
> > --- a/arch/arm/lib/delay.c
> > +++ b/arch/arm/lib/delay.c
> > @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
> >  	*timer_val = delay_timer->read_current_timer();
> >  	return 0;
> >  }
> > +EXPORT_SYMBOL_GPL(read_current_timer);
> 
> 
> Perhaps this fits better in armksyms.c? That way it lives with
> arm_delay_ops and friends.

It's always much better to put things next to where they're defined
rather than spreading them around.

armksyms.c is a reminant of the 1.x days of doing things... but still
remains to allow what are mostly assembly symbols to be exported.

[PATCH 4/9] ARM: export default read_current_timer

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote:
> Hi Arnd,
> 
> On 09/10/12 16:22, Arnd Bergmann wrote:
> > diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> > index 9d0a300..0dc5385 100644
> > --- a/arch/arm/lib/delay.c
> > +++ b/arch/arm/lib/delay.c
> > @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
> >  	*timer_val = delay_timer->read_current_timer();
> >  	return 0;
> >  }
> > +EXPORT_SYMBOL_GPL(read_current_timer);
> 
> 
> Perhaps this fits better in armksyms.c? That way it lives with
> arm_delay_ops and friends.

It's always much better to put things next to where they're defined
rather than spreading them around.

armksyms.c is a reminant of the 1.x days of doing things... but still
remains to allow what are mostly assembly symbols to be exported.

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> Here are some patches that belong into your domain, I hope you can
> just send the lot to Linus the next time you send other patches.
> 
> These bug fixes all address problems found with automated build testing.
> Some of them have been around for a long time, other bugs are
> regressions since the merge window.

Apart from the sliced off comment in one commit (which XEN people need
to confirm they're happy with the final version), I think these are
otherwise fine... I'll hold off pulling them until that can be fixed.

Thanks.

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> Here are some patches that belong into your domain, I hope you can
> just send the lot to Linus the next time you send other patches.
> 
> These bug fixes all address problems found with automated build testing.
> Some of them have been around for a long time, other bugs are
> regressions since the merge window.

Apart from the sliced off comment in one commit (which XEN people need
to confirm they're happy with the final version), I think these are
otherwise fine... I'll hold off pulling them until that can be fixed.

Thanks.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > 
> > missing the end of this sentence?
> 
> Right, I meant to say 
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>   Xen grant table code, so we must ensure that Xen support is only built
>   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> 
> This should be fixed differently in the future.

Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?

I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.

Ian.

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > 
> > missing the end of this sentence?
> 
> Right, I meant to say 
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>   Xen grant table code, so we must ensure that Xen support is only built
>   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> 
> This should be fixed differently in the future.

Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?

I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.

Ian.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > 
> > missing the end of this sentence?
> 
> Right, I meant to say 
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>   Xen grant table code, so we must ensure that Xen support is only built
>   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> 
> This should be fixed differently in the future.

Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?

I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.

Ian.

Re: [PATCH 2/9] ARM: export set_irq_flags

[Thomas Gleixner]

On Tue, 9 Oct 2012, Arnd Bergmann wrote:

> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
> 
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
> 
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Magnus Damm <damm@opensource.se>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>

Acked-by-me

> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/irq.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 16cedb4..8961650 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -34,6 +34,7 @@
>  #include <linux/list.h>
>  #include <linux/kallsyms.h>
>  #include <linux/proc_fs.h>
> +#include <linux/export.h>
>  
>  #include <asm/exception.h>
>  #include <asm/mach/arch.h>
> @@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
>  	/* Order is clear bits in "clr" then set bits in "set" */
>  	irq_modify_status(irq, clr, set & ~clr);
>  }
> +EXPORT_SYMBOL_GPL(set_irq_flags);
>  
>  void __init init_IRQ(void)
>  {
> -- 
> 1.7.10
> 
> 

[PATCH 2/9] ARM: export set_irq_flags

[Thomas Gleixner]

On Tue, 9 Oct 2012, Arnd Bergmann wrote:

> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
> 
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
> 
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Magnus Damm <damm@opensource.se>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>

Acked-by-me

> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/irq.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 16cedb4..8961650 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -34,6 +34,7 @@
>  #include <linux/list.h>
>  #include <linux/kallsyms.h>
>  #include <linux/proc_fs.h>
> +#include <linux/export.h>
>  
>  #include <asm/exception.h>
>  #include <asm/mach/arch.h>
> @@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
>  	/* Order is clear bits in "clr" then set bits in "set" */
>  	irq_modify_status(irq, clr, set & ~clr);
>  }
> +EXPORT_SYMBOL_GPL(set_irq_flags);
>  
>  void __init init_IRQ(void)
>  {
> -- 
> 1.7.10
> 
> 

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

I am OK with the comment being truncated.

I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

I am OK with the comment being truncated.

I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

I am OK with the comment being truncated.

I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.

Re: [PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler

[Dave Martin]

On Tue, Oct 09, 2012 at 05:23:00PM +0200, Arnd Bergmann wrote:
> The Linaro cross toolchain and probably others nowadays default to
> building in THUMB2 mode. When building a kernel for a CPU that does
> not support THUMB2, the compiler complains about incorrect flags.
> We can work around this by setting -marm for all non-T2 builds.
> 
> Without this patch, building assabet_defconfig results in:
> 
> usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> (and many more)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Dave Martin <dave.martin@linaro.org>

This looks like a sensible fix, but it could be worth amending the
commit message to explain what was fixed, since it took me a moment or
two to puzzle out why the code this patch removes was broken.  Maybe
something like:

-marm was passed unconditionally for C files previously, but nothing was
passed to the gcc frontend when processing .S files, resulting in a
warning.  The assembler never defaults to ARM unless -Wa,-mthumb is
supplied explicitly, so the files were still assembled correctly.

This patch makes sure that -marm is passed for .S files too, and also
avoids the redundant gcc -marm -mthumb in Thumb kernels.


Preferably with that (or equivalent):

Acked-by: Dave Martin <dave.martin@linaro.org>

> ---
>  arch/arm/Makefile |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index f023e3a..5f914fc 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -21,8 +21,6 @@ endif
>  OBJCOPYFLAGS	:=-O binary -R .comment -S
>  GZFLAGS		:=-9
>  #KBUILD_CFLAGS	+=-pipe
> -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
> -KBUILD_CFLAGS	+=$(call cc-option,-marm,)
>  
>  # Never generate .eh_frame
>  KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
> @@ -105,17 +103,20 @@ endif
>  ifeq ($(CONFIG_THUMB2_KERNEL),y)
>  AFLAGS_AUTOIT	:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
>  AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
> -CFLAGS_THUMB2	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> -AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
> +CFLAGS_ISA	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> +AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
>  # Work around buggy relocation from gas if requested:
>  ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
>  CFLAGS_MODULE	+=-fno-optimize-sibling-calls
>  endif
> +else
> +CFLAGS_ISA	:=$(call cc-option,-marm,)
> +AFLAGS_ISA	:=$(CFLAGS_ISA)
>  endif
>  
>  # Need -Uarm for gcc < 3.x
> -KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> -KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> +KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> +KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>  
>  CHECKFLAGS	+= -D__arm__
>  
> -- 
> 1.7.10
> 

[PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler

[Dave Martin]

On Tue, Oct 09, 2012 at 05:23:00PM +0200, Arnd Bergmann wrote:
> The Linaro cross toolchain and probably others nowadays default to
> building in THUMB2 mode. When building a kernel for a CPU that does
> not support THUMB2, the compiler complains about incorrect flags.
> We can work around this by setting -marm for all non-T2 builds.
> 
> Without this patch, building assabet_defconfig results in:
> 
> usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> (and many more)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Dave Martin <dave.martin@linaro.org>

This looks like a sensible fix, but it could be worth amending the
commit message to explain what was fixed, since it took me a moment or
two to puzzle out why the code this patch removes was broken.  Maybe
something like:

-marm was passed unconditionally for C files previously, but nothing was
passed to the gcc frontend when processing .S files, resulting in a
warning.  The assembler never defaults to ARM unless -Wa,-mthumb is
supplied explicitly, so the files were still assembled correctly.

This patch makes sure that -marm is passed for .S files too, and also
avoids the redundant gcc -marm -mthumb in Thumb kernels.


Preferably with that (or equivalent):

Acked-by: Dave Martin <dave.martin@linaro.org>

> ---
>  arch/arm/Makefile |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index f023e3a..5f914fc 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -21,8 +21,6 @@ endif
>  OBJCOPYFLAGS	:=-O binary -R .comment -S
>  GZFLAGS		:=-9
>  #KBUILD_CFLAGS	+=-pipe
> -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
> -KBUILD_CFLAGS	+=$(call cc-option,-marm,)
>  
>  # Never generate .eh_frame
>  KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
> @@ -105,17 +103,20 @@ endif
>  ifeq ($(CONFIG_THUMB2_KERNEL),y)
>  AFLAGS_AUTOIT	:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
>  AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
> -CFLAGS_THUMB2	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> -AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
> +CFLAGS_ISA	:=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> +AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
>  # Work around buggy relocation from gas if requested:
>  ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
>  CFLAGS_MODULE	+=-fno-optimize-sibling-calls
>  endif
> +else
> +CFLAGS_ISA	:=$(call cc-option,-marm,)
> +AFLAGS_ISA	:=$(CFLAGS_ISA)
>  endif
>  
>  # Need -Uarm for gcc < 3.x
> -KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> -KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> +KBUILD_CFLAGS	+=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> +KBUILD_AFLAGS	+=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>  
>  CHECKFLAGS	+= -D__arm__
>  
> -- 
> 1.7.10
> 

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > > 
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > 
> > > missing the end of this sentence?
> > 
> > Right, I meant to say 
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >   Xen grant table code, so we must ensure that Xen support is only built
> >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > 
> > This should be fixed differently in the future.
> 
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
> 
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.

The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from

static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
                                      unsigned long new, int size)
{
        unsigned long oldval, res;

        switch (size) {
#ifndef CONFIG_CPU_V6   /* min ARCH >= ARMv6K */
        case 1:
		...
                break;
        case 2:
		...
                break;
#endif
        case 4:
		...
                break;
        default:
                __bad_cmpxchg(ptr, size);
                oldval = 0;
        }
        return oldval;
}

The possible solutions I can see for this are:

* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
  rather than cmpxchg if ARMv6 is enabled.

	Arnd

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > > 
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > 
> > > missing the end of this sentence?
> > 
> > Right, I meant to say 
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >   Xen grant table code, so we must ensure that Xen support is only built
> >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > 
> > This should be fixed differently in the future.
> 
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
> 
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.

The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from

static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
                                      unsigned long new, int size)
{
        unsigned long oldval, res;

        switch (size) {
#ifndef CONFIG_CPU_V6   /* min ARCH >= ARMv6K */
        case 1:
		...
                break;
        case 2:
		...
                break;
#endif
        case 4:
		...
                break;
        default:
                __bad_cmpxchg(ptr, size);
                oldval = 0;
        }
        return oldval;
}

The possible solutions I can see for this are:

* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
  rather than cmpxchg if ARMv6 is enabled.

	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > > 
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > 
> > > missing the end of this sentence?
> > 
> > Right, I meant to say 
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >   Xen grant table code, so we must ensure that Xen support is only built
> >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > 
> > This should be fixed differently in the future.
> 
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
> 
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.

The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from

static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
                                      unsigned long new, int size)
{
        unsigned long oldval, res;

        switch (size) {
#ifndef CONFIG_CPU_V6   /* min ARCH >= ARMv6K */
        case 1:
		...
                break;
        case 2:
		...
                break;
#endif
        case 4:
		...
                break;
        default:
                __bad_cmpxchg(ptr, size);
                oldval = 0;
        }
        return oldval;
}

The possible solutions I can see for this are:

* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
  rather than cmpxchg if ARMv6 is enabled.

	Arnd

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Stefano Stabellini wrote:
> >  config XEN
> >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> >       depends on EXPERIMENTAL && ARM && OF
> > +     depends on !CPU_V6
> >       help
> >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> 
> Considering that we rely on the virtualization extensions, this one can
> be:
> 
>     depends on CPU_V7
> 
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.

CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.

	Arnd

[PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Stefano Stabellini wrote:
> >  config XEN
> >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> >       depends on EXPERIMENTAL && ARM && OF
> > +     depends on !CPU_V6
> >       help
> >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> 
> Considering that we rely on the virtualization extensions, this one can
> be:
> 
>     depends on CPU_V7
> 
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.

CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.

	Arnd

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Tuesday 09 October 2012, Stefano Stabellini wrote:
> >  config XEN
> >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> >       depends on EXPERIMENTAL && ARM && OF
> > +     depends on !CPU_V6
> >       help
> >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> 
> Considering that we rely on the virtualization extensions, this one can
> be:
> 
>     depends on CPU_V7
> 
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.

CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.

	Arnd

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Arnd Bergmann]

On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> 
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

Fixed that now, and I also added the Acks that I got in the meantime,
changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
description for patch 6 as Dave suggested.

	Arnd

8<---
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

----------------------------------------------------------------
These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Arnd Bergmann]

On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> 
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

Fixed that now, and I also added the Acks that I got in the meantime,
changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
description for patch 6 as Dave suggested.

	Arnd

8<---
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

----------------------------------------------------------------
These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Dan Magenheimer]

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, October 09, 2012 9:36 AM
> To: Arnd Bergmann
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> 
> On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > * The XEN_BALLOON code requires the balloon infrastructure that is not
> >   getting built on ARM.
> 
> I've got patches to enable this, but not for 3.7 so this looks good for
> now.
> 
> > * The tmem hypercall is not available on ARM

[reduced cc list to just us Xen chickens]

Any reason that the tmem hypercall is not available on ARM?
At a minimum, it should be available, but always return failure.
Then an ARM Linux kernel can be ready for the Xen implementation
when the Xen hypervisor supports it.

Ballooning also... why disable it rather than just have
the hypervisor fail all calls?

Wondering if it just has never been tried/tested, or if there
are known problems since everything should have been coded
quite portably.  (I do recall some arch-specific code in
the hypervisor, now that I think of it, but it was pretty small.)

I haven't been plugged in to Xen/ARM, so I don't know the
target market, but I do know that some
Android distros have been using the in-kernel tmem version
(called zcache) even though it is still a Linux staging driver,
so there probably will be demand for Xen tmem too.

Dan

Re: [PATCH 2/9] ARM: export set_irq_flags

[Linus Walleij]

On Tue, Oct 9, 2012 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
>
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
>
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.

Argh! And I cannot think of anything more elegant so
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 2/9] ARM: export set_irq_flags

[Linus Walleij]

On Tue, Oct 9, 2012 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
>
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
>
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.

Argh! And I cannot think of anything more elegant so
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, October 09, 2012 9:36 AM
> > To: Arnd Bergmann
> > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > 
> > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > >   getting built on ARM.
> > 
> > I've got patches to enable this, but not for 3.7 so this looks good for
> > now.
> > 
> > > * The tmem hypercall is not available on ARM
> 
> [reduced cc list to just us Xen chickens]
> 
> Any reason that the tmem hypercall is not available on ARM?
> At a minimum, it should be available, but always return failure.

The hypercall is available from a hypervisor point of view, although it
will return -Esomething since some of the required arch functions are
still stubs.

The issue Arnd is fixing is that the client code in the kernel doesn't
currently compile because we haven't added all the required per-arch
scaffolding yet. Or at least that is the case for ballooning, I haven't
tried building tmem myself but I assume Arnd wouldn't be sending the
patch if it built.

I posted a series to enable ballooning on ARM last week (see
<1349363496.866.49.camel@zakaz.uk.xensource.com>).

Ian.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > >  config XEN
> > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >       depends on EXPERIMENTAL && ARM && OF
> > > +     depends on !CPU_V6
> > >       help
> > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > 
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> > 
> >     depends on CPU_V7
> > 
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
> 
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.

I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor. 

Stefano, does that sound right?

Ian.

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > >  config XEN
> > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >       depends on EXPERIMENTAL && ARM && OF
> > > +     depends on !CPU_V6
> > >       help
> > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > 
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> > 
> >     depends on CPU_V7
> > 
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
> 
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.

I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor. 

Stefano, does that sound right?

Ian.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > >  config XEN
> > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >       depends on EXPERIMENTAL && ARM && OF
> > > +     depends on !CPU_V6
> > >       help
> > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > 
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> > 
> >     depends on CPU_V7
> > 
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
> 
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.

I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor. 

Stefano, does that sound right?

Ian.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > > 
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > > 
> > > > missing the end of this sentence?
> > > 
> > > Right, I meant to say 
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >   Xen grant table code, so we must ensure that Xen support is only built
> > >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > > 
> > > This should be fixed differently in the future.
> > 
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> > 
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
> 
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from

OK, then your fix is the best one for now.

> [...]
> The possible solutions I can see for this are:
> 
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.

I'd need to check the grant table semantics to see if this will be
possible.

> * implement your own cmpxchg wrapper that may be implemented using a spinlock
>   rather than cmpxchg if ARMv6 is enabled.

Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.

> 
> 	Arnd

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > > 
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > > 
> > > > missing the end of this sentence?
> > > 
> > > Right, I meant to say 
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >   Xen grant table code, so we must ensure that Xen support is only built
> > >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > > 
> > > This should be fixed differently in the future.
> > 
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> > 
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
> 
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from

OK, then your fix is the best one for now.

> [...]
> The possible solutions I can see for this are:
> 
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.

I'd need to check the grant table semantics to see if this will be
possible.

> * implement your own cmpxchg wrapper that may be implemented using a spinlock
>   rather than cmpxchg if ARMv6 is enabled.

Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.

> 
> 	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > > 
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > > 
> > > > missing the end of this sentence?
> > > 
> > > Right, I meant to say 
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >   Xen grant table code, so we must ensure that Xen support is only built
> > >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > > 
> > > This should be fixed differently in the future.
> > 
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> > 
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
> 
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from

OK, then your fix is the best one for now.

> [...]
> The possible solutions I can see for this are:
> 
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.

I'd need to check the grant table semantics to see if this will be
possible.

> * implement your own cmpxchg wrapper that may be implemented using a spinlock
>   rather than cmpxchg if ARMv6 is enabled.

Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.

> 
> 	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> >   rather than cmpxchg if ARMv6 is enabled.
> 
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.

Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is

        while (!((flags = *pflags) & GTF_transfer_committed)) {
                if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

which should transform nicely into a few lines of inline assembly.

	Arnd

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> >   rather than cmpxchg if ARMv6 is enabled.
> 
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.

Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is

        while (!((flags = *pflags) & GTF_transfer_committed)) {
                if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

which should transform nicely into a few lines of inline assembly.

	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Arnd Bergmann]

On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> >   rather than cmpxchg if ARMv6 is enabled.
> 
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.

Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is

        while (!((flags = *pflags) & GTF_transfer_committed)) {
                if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

which should transform nicely into a few lines of inline assembly.

	Arnd

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > >  config XEN
> > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > >       depends on EXPERIMENTAL && ARM && OF
> > > > +     depends on !CPU_V6
> > > >       help
> > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > 
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > > 
> > >     depends on CPU_V7
> > > 
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> > 
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
> 
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor. 
> 
> Stefano, does that sound right?

Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > >  config XEN
> > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > >       depends on EXPERIMENTAL && ARM && OF
> > > > +     depends on !CPU_V6
> > > >       help
> > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > 
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > > 
> > >     depends on CPU_V7
> > > 
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> > 
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
> 
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor. 
> 
> Stefano, does that sound right?

Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > >  config XEN
> > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > >       depends on EXPERIMENTAL && ARM && OF
> > > > +     depends on !CPU_V6
> > > >       help
> > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > 
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > > 
> > >     depends on CPU_V7
> > > 
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> > 
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
> 
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor. 
> 
> Stefano, does that sound right?

Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.

Re: [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, October 09, 2012 9:36 AM
> > > To: Arnd Bergmann
> > > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > > 
> > > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > > >   getting built on ARM.
> > > 
> > > I've got patches to enable this, but not for 3.7 so this looks good for
> > > now.
> > > 
> > > > * The tmem hypercall is not available on ARM
> > 
> > [reduced cc list to just us Xen chickens]
> > 
> > Any reason that the tmem hypercall is not available on ARM?
> > At a minimum, it should be available, but always return failure.
> 
> The hypercall is available from a hypervisor point of view, although it
> will return -Esomething since some of the required arch functions are
> still stubs.

We are probably just missing the implementation of HYPERVISOR_tmem_op.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > >  config XEN
> > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > +     depends on !CPU_V6
> > > > >       help
> > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > 
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > > 
> > > >     depends on CPU_V7
> > > > 
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > > 
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> > 
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor. 
> > 
> > Stefano, does that sound right?
> 
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.

I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.

Ian.

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > >  config XEN
> > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > +     depends on !CPU_V6
> > > > >       help
> > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > 
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > > 
> > > >     depends on CPU_V7
> > > > 
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > > 
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> > 
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor. 
> > 
> > Stefano, does that sound right?
> 
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.

I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.

Ian.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Ian Campbell]

On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > >  config XEN
> > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > +     depends on !CPU_V6
> > > > >       help
> > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > 
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > > 
> > > >     depends on CPU_V7
> > > > 
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > > 
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> > 
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor. 
> > 
> > Stefano, does that sound right?
> 
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.

I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.

Ian.

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.

Thanks for the update, the new Xen patch is fine by me

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.

Thanks for the update, the new Xen patch is fine by me

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Stefano Stabellini]

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.

Thanks for the update, the new Xen patch is fine by me

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> > On Wed, 10 Oct 2012, Ian Campbell wrote:
> > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > >  config XEN
> > > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > > +     depends on !CPU_V6
> > > > > >       help
> > > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > > 
> > > > > Considering that we rely on the virtualization extensions, this one can
> > > > > be:
> > > > > 
> > > > >     depends on CPU_V7
> > > > > 
> > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > > CPU_V7 later, if you prefer.
> > > > 
> > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > > with virtualization extensions, but that is a different issue. We don't
> > > > actually have a configuration symbol for that yet, as far as I can tell.
> > > 
> > > I don't think the guest kernels (including dom0) need the extensions to
> > > run under Xen, they are only need by Xen itself. The guests should just
> > > see a relatively normal v7 processor. 
> > > 
> > > Stefano, does that sound right?
> > 
> > Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> > introduced with the virtualization extensions, if I am not mistaken.
> 
> I think we can ignore that in this context since it is only used by bits
> which are already virtualisation aware -- i.e. you wouldn't want to add
> it to the Kconfig as a dependency for Xen.

Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux
had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our
list of dependencies. It is more accurate than CPU_V7 after all.

But I don't think that it is necessary to introduce one now only for
Xen, because like you said, we only need HVC and that is only used in
virtualization aware code.

[Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> > On Wed, 10 Oct 2012, Ian Campbell wrote:
> > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > >  config XEN
> > > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > > +     depends on !CPU_V6
> > > > > >       help
> > > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > > 
> > > > > Considering that we rely on the virtualization extensions, this one can
> > > > > be:
> > > > > 
> > > > >     depends on CPU_V7
> > > > > 
> > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > > CPU_V7 later, if you prefer.
> > > > 
> > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > > with virtualization extensions, but that is a different issue. We don't
> > > > actually have a configuration symbol for that yet, as far as I can tell.
> > > 
> > > I don't think the guest kernels (including dom0) need the extensions to
> > > run under Xen, they are only need by Xen itself. The guests should just
> > > see a relatively normal v7 processor. 
> > > 
> > > Stefano, does that sound right?
> > 
> > Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> > introduced with the virtualization extensions, if I am not mistaken.
> 
> I think we can ignore that in this context since it is only used by bits
> which are already virtualisation aware -- i.e. you wouldn't want to add
> it to the Kconfig as a dependency for Xen.

Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux
had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our
list of dependencies. It is more accurate than CPU_V7 after all.

But I don't think that it is necessary to introduce one now only for
Xen, because like you said, we only need HVC and that is only used in
virtualization aware code.

Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:

[Stefano Stabellini]

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> > On Wed, 10 Oct 2012, Ian Campbell wrote:
> > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > >  config XEN
> > > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > > +     depends on !CPU_V6
> > > > > >       help
> > > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > > 
> > > > > Considering that we rely on the virtualization extensions, this one can
> > > > > be:
> > > > > 
> > > > >     depends on CPU_V7
> > > > > 
> > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > > CPU_V7 later, if you prefer.
> > > > 
> > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > > with virtualization extensions, but that is a different issue. We don't
> > > > actually have a configuration symbol for that yet, as far as I can tell.
> > > 
> > > I don't think the guest kernels (including dom0) need the extensions to
> > > run under Xen, they are only need by Xen itself. The guests should just
> > > see a relatively normal v7 processor. 
> > > 
> > > Stefano, does that sound right?
> > 
> > Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> > introduced with the virtualization extensions, if I am not mistaken.
> 
> I think we can ignore that in this context since it is only used by bits
> which are already virtualisation aware -- i.e. you wouldn't want to add
> it to the Kconfig as a dependency for Xen.

Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux
had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our
list of dependencies. It is more accurate than CPU_V7 after all.

But I don't think that it is necessary to introduce one now only for
Xen, because like you said, we only need HVC and that is only used in
virtualization aware code.

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Will Deacon]

Hi Arnd, Russell,

On Tue, Oct 09, 2012 at 07:40:24PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
> 
> 	Arnd
> 
> 8<---
> The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
> 
>   Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
> 
> for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:
> 
>   ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

It would be good to see these for -rc1 if there's still time. I'm tired of
seeing patches to fix the export of the read_current_timer symbol!

Cheers,

Will

[GIT PULL 0/9] ARM architecture fixes for 3.7

[Will Deacon]

Hi Arnd, Russell,

On Tue, Oct 09, 2012 at 07:40:24PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
> 
> 	Arnd
> 
> 8<---
> The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
> 
>   Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
> 
> for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:
> 
>   ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

It would be good to see these for -rc1 if there's still time. I'm tired of
seeing patches to fix the export of the read_current_timer symbol!

Cheers,

Will

Re: [GIT PULL 0/9] ARM architecture fixes for 3.7

[Will Deacon]

Hi Arnd, Russell,

On Tue, Oct 09, 2012 at 07:40:24PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
> 
> 	Arnd
> 
> 8<---
> The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
> 
>   Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
> 
> for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:
> 
>   ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

It would be good to see these for -rc1 if there's still time. I'm tired of
seeing patches to fix the export of the read_current_timer symbol!

Cheers,

Will

Re: [PATCH 4/9] ARM: export default read_current_timer

[Alexander Holler]

Am 09.10.2012 18:06, schrieb Russell King - ARM Linux:
> On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote:
>> Hi Arnd,
>>
>> On 09/10/12 16:22, Arnd Bergmann wrote:
>>> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
>>> index 9d0a300..0dc5385 100644
>>> --- a/arch/arm/lib/delay.c
>>> +++ b/arch/arm/lib/delay.c
>>> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
>>>   	*timer_val = delay_timer->read_current_timer();
>>>   	return 0;
>>>   }
>>> +EXPORT_SYMBOL_GPL(read_current_timer);
>>
>>
>> Perhaps this fits better in armksyms.c? That way it lives with
>> arm_delay_ops and friends.
>
> It's always much better to put things next to where they're defined
> rather than spreading them around.
>
> armksyms.c is a reminant of the 1.x days of doing things... but still
> remains to allow what are mostly assembly symbols to be exported.

I needed that to build udlfb as a module.

For the 3.6 stable kernels this has to be done in
arch/arm/kernel/arch_timer.c (along with an #include <linux/export.h>)

So I'm not sure if an Cc: <stable@vger.kernel.org> can be used here, but 
a patch should be submitted for inclusion into the 3.6 stable series too.

Regards,

Alexander

[PATCH 4/9] ARM: export default read_current_timer

[Alexander Holler]

Am 09.10.2012 18:06, schrieb Russell King - ARM Linux:
> On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote:
>> Hi Arnd,
>>
>> On 09/10/12 16:22, Arnd Bergmann wrote:
>>> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
>>> index 9d0a300..0dc5385 100644
>>> --- a/arch/arm/lib/delay.c
>>> +++ b/arch/arm/lib/delay.c
>>> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
>>>   	*timer_val = delay_timer->read_current_timer();
>>>   	return 0;
>>>   }
>>> +EXPORT_SYMBOL_GPL(read_current_timer);
>>
>>
>> Perhaps this fits better in armksyms.c? That way it lives with
>> arm_delay_ops and friends.
>
> It's always much better to put things next to where they're defined
> rather than spreading them around.
>
> armksyms.c is a reminant of the 1.x days of doing things... but still
> remains to allow what are mostly assembly symbols to be exported.

I needed that to build udlfb as a module.

For the 3.6 stable kernels this has to be done in
arch/arm/kernel/arch_timer.c (along with an #include <linux/export.h>)

So I'm not sure if an Cc: <stable@vger.kernel.org> can be used here, but 
a patch should be submitted for inclusion into the 3.6 stable series too.

Regards,

Alexander