[PATCH 00/10] ARM: interesting warnings from defconfig builds

[PATCH 00/10] ARM: interesting warnings from defconfig builds

[Arnd Bergmann]

Most of these have been around for quite a while, but I think we
should fix them nonetheless. In some cases, I'm not very sure about
my solution, so I'd appreciate any ACK or NAK I can get.

	Arnd

Arnd Bergmann (10):
  ARM: footbridge: nw_gpio_lock is raw_spin_lock
  ARM: ks8695: __arch_virt_to_dma type handling
  ARM: mv78xx0: fix win_cfg_base prototype
  ARM: pass -marm to gcc by default
  asm-generic: xor: mark static functions as __maybe_unused
  ARM: davinci: don't use broken ntosd2_init_i2c
  ARM: rpc: check device_register return code in ecard_probe
  ARM: s3c24xx: enable CONFIG_BUG for tct_hammer
  ARM: rpc: Fix building RiscPC
  leds: renesas: fix error handling

 arch/arm/Kconfig                           |    2 +-
 arch/arm/Makefile                          |    4 +++-
 arch/arm/configs/tct_hammer_defconfig      |    2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c  |    7 +++++++
 arch/arm/mach-ks8695/include/mach/memory.h |    3 ++-
 arch/arm/mach-mv78xx0/addr-map.c           |    2 +-
 arch/arm/mach-rpc/ecard.c                  |    4 +++-
 arch/arm/mm/Kconfig                        |   12 ++----------
 drivers/char/ds1620.c                      |    8 ++++----
 drivers/char/nwflash.c                     |    4 ++--
 drivers/leds/leds-renesas-tpu.c            |    2 +-
 include/asm-generic/xor.h                  |    4 ++--
 sound/oss/waveartist.c                     |    4 ++--
 13 files changed, 31 insertions(+), 27 deletions(-)

-- 
1.7.10

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Magnus Damm <damm@opensource.se>

[PATCH 00/10] ARM: interesting warnings from defconfig builds

[Arnd Bergmann]

Most of these have been around for quite a while, but I think we
should fix them nonetheless. In some cases, I'm not very sure about
my solution, so I'd appreciate any ACK or NAK I can get.

	Arnd

Arnd Bergmann (10):
  ARM: footbridge: nw_gpio_lock is raw_spin_lock
  ARM: ks8695: __arch_virt_to_dma type handling
  ARM: mv78xx0: fix win_cfg_base prototype
  ARM: pass -marm to gcc by default
  asm-generic: xor: mark static functions as __maybe_unused
  ARM: davinci: don't use broken ntosd2_init_i2c
  ARM: rpc: check device_register return code in ecard_probe
  ARM: s3c24xx: enable CONFIG_BUG for tct_hammer
  ARM: rpc: Fix building RiscPC
  leds: renesas: fix error handling

 arch/arm/Kconfig                           |    2 +-
 arch/arm/Makefile                          |    4 +++-
 arch/arm/configs/tct_hammer_defconfig      |    2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c  |    7 +++++++
 arch/arm/mach-ks8695/include/mach/memory.h |    3 ++-
 arch/arm/mach-mv78xx0/addr-map.c           |    2 +-
 arch/arm/mach-rpc/ecard.c                  |    4 +++-
 arch/arm/mm/Kconfig                        |   12 ++----------
 drivers/char/ds1620.c                      |    8 ++++----
 drivers/char/nwflash.c                     |    4 ++--
 drivers/leds/leds-renesas-tpu.c            |    2 +-
 include/asm-generic/xor.h                  |    4 ++--
 sound/oss/waveartist.c                     |    4 ++--
 13 files changed, 31 insertions(+), 27 deletions(-)

-- 
1.7.10

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Magnus Damm <damm@opensource.se>

[PATCH 01/10] ARM: footbridge: nw_gpio_lock is raw_spin_lock

[Arnd Bergmann]

bd31b85960a "locking, ARM: Annotate low level hw locks as raw"
made nw_gpio_lock a raw spinlock, but did not change all the
users in device drivers. This fixes the remaining ones.

sound/oss/waveartist.c: In function 'vnc_mute_spkr':
sound/oss/waveartist.c:1485:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/ds1620.c: In function 'netwinder_lock':
drivers/char/ds1620.c:77:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/nwflash.c: In function 'kick_open':
drivers/char/nwflash.c:620:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/char/ds1620.c  |    8 ++++----
 drivers/char/nwflash.c |    4 ++--
 sound/oss/waveartist.c |    4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/char/ds1620.c b/drivers/char/ds1620.c
index aab9605..24ffd8c 100644
--- a/drivers/char/ds1620.c
+++ b/drivers/char/ds1620.c
@@ -74,21 +74,21 @@ static inline void netwinder_ds1620_reset(void)
 
 static inline void netwinder_lock(unsigned long *flags)
 {
-	spin_lock_irqsave(&nw_gpio_lock, *flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, *flags);
 }
 
 static inline void netwinder_unlock(unsigned long *flags)
 {
-	spin_unlock_irqrestore(&nw_gpio_lock, *flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, *flags);
 }
 
 static inline void netwinder_set_fan(int i)
 {
 	unsigned long flags;
 
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_gpio_modify_op(GPIO_FAN, i ? GPIO_FAN : 0);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 }
 
 static inline int netwinder_get_fan(void)
diff --git a/drivers/char/nwflash.c b/drivers/char/nwflash.c
index d45c334..04e2a94 100644
--- a/drivers/char/nwflash.c
+++ b/drivers/char/nwflash.c
@@ -617,9 +617,9 @@ static void kick_open(void)
 	 * we want to write a bit pattern XXX1 to Xilinx to enable
 	 * the write gate, which will be open for about the next 2ms.
 	 */
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_cpld_modify(CPLD_FLASH_WR_ENABLE, CPLD_FLASH_WR_ENABLE);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 
 	/*
 	 * let the ISA bus to catch on...
diff --git a/sound/oss/waveartist.c b/sound/oss/waveartist.c
index 24c430f..672af8b 100644
--- a/sound/oss/waveartist.c
+++ b/sound/oss/waveartist.c
@@ -1482,9 +1482,9 @@ vnc_mute_spkr(wavnc_info *devc)
 {
 	unsigned long flags;
 
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_cpld_modify(CPLD_UNMUTE, devc->spkr_mute_state ? 0 : CPLD_UNMUTE);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 }
 
 static void
-- 
1.7.10

[PATCH 01/10] ARM: footbridge: nw_gpio_lock is raw_spin_lock

[Arnd Bergmann]

bd31b85960a "locking, ARM: Annotate low level hw locks as raw"
made nw_gpio_lock a raw spinlock, but did not change all the
users in device drivers. This fixes the remaining ones.

sound/oss/waveartist.c: In function 'vnc_mute_spkr':
sound/oss/waveartist.c:1485:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/ds1620.c: In function 'netwinder_lock':
drivers/char/ds1620.c:77:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/nwflash.c: In function 'kick_open':
drivers/char/nwflash.c:620:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/char/ds1620.c  |    8 ++++----
 drivers/char/nwflash.c |    4 ++--
 sound/oss/waveartist.c |    4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/char/ds1620.c b/drivers/char/ds1620.c
index aab9605..24ffd8c 100644
--- a/drivers/char/ds1620.c
+++ b/drivers/char/ds1620.c
@@ -74,21 +74,21 @@ static inline void netwinder_ds1620_reset(void)
 
 static inline void netwinder_lock(unsigned long *flags)
 {
-	spin_lock_irqsave(&nw_gpio_lock, *flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, *flags);
 }
 
 static inline void netwinder_unlock(unsigned long *flags)
 {
-	spin_unlock_irqrestore(&nw_gpio_lock, *flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, *flags);
 }
 
 static inline void netwinder_set_fan(int i)
 {
 	unsigned long flags;
 
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_gpio_modify_op(GPIO_FAN, i ? GPIO_FAN : 0);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 }
 
 static inline int netwinder_get_fan(void)
diff --git a/drivers/char/nwflash.c b/drivers/char/nwflash.c
index d45c334..04e2a94 100644
--- a/drivers/char/nwflash.c
+++ b/drivers/char/nwflash.c
@@ -617,9 +617,9 @@ static void kick_open(void)
 	 * we want to write a bit pattern XXX1 to Xilinx to enable
 	 * the write gate, which will be open for about the next 2ms.
 	 */
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_cpld_modify(CPLD_FLASH_WR_ENABLE, CPLD_FLASH_WR_ENABLE);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 
 	/*
 	 * let the ISA bus to catch on...
diff --git a/sound/oss/waveartist.c b/sound/oss/waveartist.c
index 24c430f..672af8b 100644
--- a/sound/oss/waveartist.c
+++ b/sound/oss/waveartist.c
@@ -1482,9 +1482,9 @@ vnc_mute_spkr(wavnc_info *devc)
 {
 	unsigned long flags;
 
-	spin_lock_irqsave(&nw_gpio_lock, flags);
+	raw_spin_lock_irqsave(&nw_gpio_lock, flags);
 	nw_cpld_modify(CPLD_UNMUTE, devc->spkr_mute_state ? 0 : CPLD_UNMUTE);
-	spin_unlock_irqrestore(&nw_gpio_lock, flags);
+	raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
 }
 
 static void
-- 
1.7.10

[PATCH 02/10] ARM: ks8695: __arch_virt_to_dma type handling

[Arnd Bergmann]

__arch_virt_to_dma expects a virtual address pointer, but
the ks8695 implementation of this macro treats it as an
integer. Adding a type cast avoids hundreds of identical
warning messages.

Without this patch, building acs5k_defconfig results in:

arch/arm/include/asm/dma-mapping.h: In function 'virt_to_dma':
arch/arm/include/asm/dma-mapping.h:60:2: warning: passing argument 1 of '__virt_to_phys' makes integer from pointer without a cast [enabled by default]
arch/arm/include/asm/memory.h:172:60: note: expected 'long unsigned int' but argument is of type 'void *'
In file included from include/linux/dma-mapping.h:73:0,
                 from include/linux/skbuff.h:33,
                 from security/commoncap.c:21:

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-ks8695/include/mach/memory.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ks8695/include/mach/memory.h b/arch/arm/mach-ks8695/include/mach/memory.h
index f7e1b9b..95e731a 100644
--- a/arch/arm/mach-ks8695/include/mach/memory.h
+++ b/arch/arm/mach-ks8695/include/mach/memory.h
@@ -34,7 +34,8 @@ extern struct bus_type platform_bus_type;
 #define __arch_dma_to_virt(dev, x)	({ (void *) (is_lbus_device(dev) ? \
 					__phys_to_virt(x) : __bus_to_virt(x)); })
 #define __arch_virt_to_dma(dev, x)	({ is_lbus_device(dev) ? \
-					(dma_addr_t)__virt_to_phys(x) : (dma_addr_t)__virt_to_bus(x); })
+					(dma_addr_t)__virt_to_phys((unsigned long)x) \
+					: (dma_addr_t)__virt_to_bus(x); })
 #define __arch_pfn_to_dma(dev, pfn)	\
 	({ dma_addr_t __dma = __pfn_to_phys(pfn); \
 	   if (!is_lbus_device(dev)) \
-- 
1.7.10

[PATCH 02/10] ARM: ks8695: __arch_virt_to_dma type handling

[Arnd Bergmann]

__arch_virt_to_dma expects a virtual address pointer, but
the ks8695 implementation of this macro treats it as an
integer. Adding a type cast avoids hundreds of identical
warning messages.

Without this patch, building acs5k_defconfig results in:

arch/arm/include/asm/dma-mapping.h: In function 'virt_to_dma':
arch/arm/include/asm/dma-mapping.h:60:2: warning: passing argument 1 of '__virt_to_phys' makes integer from pointer without a cast [enabled by default]
arch/arm/include/asm/memory.h:172:60: note: expected 'long unsigned int' but argument is of type 'void *'
In file included from include/linux/dma-mapping.h:73:0,
                 from include/linux/skbuff.h:33,
                 from security/commoncap.c:21:

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-ks8695/include/mach/memory.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ks8695/include/mach/memory.h b/arch/arm/mach-ks8695/include/mach/memory.h
index f7e1b9b..95e731a 100644
--- a/arch/arm/mach-ks8695/include/mach/memory.h
+++ b/arch/arm/mach-ks8695/include/mach/memory.h
@@ -34,7 +34,8 @@ extern struct bus_type platform_bus_type;
 #define __arch_dma_to_virt(dev, x)	({ (void *) (is_lbus_device(dev) ? \
 					__phys_to_virt(x) : __bus_to_virt(x)); })
 #define __arch_virt_to_dma(dev, x)	({ is_lbus_device(dev) ? \
-					(dma_addr_t)__virt_to_phys(x) : (dma_addr_t)__virt_to_bus(x); })
+					(dma_addr_t)__virt_to_phys((unsigned long)x) \
+					: (dma_addr_t)__virt_to_bus(x); })
 #define __arch_pfn_to_dma(dev, pfn)	\
 	({ dma_addr_t __dma = __pfn_to_phys(pfn); \
 	   if (!is_lbus_device(dev)) \
-- 
1.7.10

[PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype

[Arnd Bergmann]

Patch b6d1c33a31 "ARM: Orion: Consolidate the address map setup" tried
to merge the address map for the four orion platforms, but apparently
got it wrong for mv78xx0. Admittedly I don't understand what this
code actually does, but it's clear that the current version is
wrong.

Without this patch, building mv78xx0_defconfig results in:

arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>
Cc: Nicolas Pitre <nico@linaro.org>
---
 arch/arm/mach-mv78xx0/addr-map.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
index 62b53d7..a9bc841 100644
--- a/arch/arm/mach-mv78xx0/addr-map.c
+++ b/arch/arm/mach-mv78xx0/addr-map.c
@@ -37,7 +37,7 @@
 #define WIN0_OFF(n)		(BRIDGE_VIRT_BASE + 0x0000 + ((n) << 4))
 #define WIN8_OFF(n)		(BRIDGE_VIRT_BASE + 0x0900 + (((n) - 8) << 4))
 
-static void __init __iomem *win_cfg_base(int win)
+static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
 {
 	/*
 	 * Find the control register base address for this window.
-- 
1.7.10

[PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype

[Arnd Bergmann]

Patch b6d1c33a31 "ARM: Orion: Consolidate the address map setup" tried
to merge the address map for the four orion platforms, but apparently
got it wrong for mv78xx0. Admittedly I don't understand what this
code actually does, but it's clear that the current version is
wrong.

Without this patch, building mv78xx0_defconfig results in:

arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>
Cc: Nicolas Pitre <nico@linaro.org>
---
 arch/arm/mach-mv78xx0/addr-map.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
index 62b53d7..a9bc841 100644
--- a/arch/arm/mach-mv78xx0/addr-map.c
+++ b/arch/arm/mach-mv78xx0/addr-map.c
@@ -37,7 +37,7 @@
 #define WIN0_OFF(n)		(BRIDGE_VIRT_BASE + 0x0000 + ((n) << 4))
 #define WIN8_OFF(n)		(BRIDGE_VIRT_BASE + 0x0900 + (((n) - 8) << 4))
 
-static void __init __iomem *win_cfg_base(int win)
+static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
 {
 	/*
 	 * Find the control register base address for this window.
-- 
1.7.10

[PATCH 04/10] ARM: pass -marm to gcc by default

[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>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/Makefile |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..b4c2296 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -111,6 +111,9 @@ AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
 ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
 CFLAGS_MODULE	+=-fno-optimize-sibling-calls
 endif
+else
+CFLAGS_THUMB2  :=-marm
+AFLAGS_THUMB2	:=-marm
 endif
 
 # Need -Uarm for gcc < 3.x
-- 
1.7.10

[PATCH 04/10] ARM: pass -marm to gcc by default

[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>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/Makefile |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..b4c2296 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -111,6 +111,9 @@ AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
 ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
 CFLAGS_MODULE	+=-fno-optimize-sibling-calls
 endif
+else
+CFLAGS_THUMB2  :=-marm
+AFLAGS_THUMB2	:=-marm
 endif
 
 # Need -Uarm for gcc < 3.x
-- 
1.7.10

[PATCH 05/10] asm-generic: xor: mark static functions as __maybe_unused

[Arnd Bergmann]

The asm-generic/xor.h header file is nasty and defines static functions
that are not inline. The header file is include by the ARM version of
asm/xor.h, which uses some but not all of the symbols defined there.

Marking the extraneous functions as __maybe_unused lets gcc drop them
without complaining.

Without this patch, building iop13xx_defconfig results in:

include/asm-generic/xor.h:696:34: warning: 'xor_block_8regs_p' defined but not used [-Wunused-variable]
include/asm-generic/xor.h:704:34: warning: 'xor_block_32regs_p' defined but not used [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Neil Brown <neilb@suse.de>
---
 include/asm-generic/xor.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/xor.h b/include/asm-generic/xor.h
index 6028fb8..b4d8432 100644
--- a/include/asm-generic/xor.h
+++ b/include/asm-generic/xor.h
@@ -693,7 +693,7 @@ static struct xor_block_template xor_block_32regs = {
 	.do_5 = xor_32regs_5,
 };
 
-static struct xor_block_template xor_block_8regs_p = {
+static struct xor_block_template xor_block_8regs_p __maybe_unused = {
 	.name = "8regs_prefetch",
 	.do_2 = xor_8regs_p_2,
 	.do_3 = xor_8regs_p_3,
@@ -701,7 +701,7 @@ static struct xor_block_template xor_block_8regs_p = {
 	.do_5 = xor_8regs_p_5,
 };
 
-static struct xor_block_template xor_block_32regs_p = {
+static struct xor_block_template xor_block_32regs_p __maybe_unused = {
 	.name = "32regs_prefetch",
 	.do_2 = xor_32regs_p_2,
 	.do_3 = xor_32regs_p_3,
-- 
1.7.10

[PATCH 05/10] asm-generic: xor: mark static functions as __maybe_unused

[Arnd Bergmann]

The asm-generic/xor.h header file is nasty and defines static functions
that are not inline. The header file is include by the ARM version of
asm/xor.h, which uses some but not all of the symbols defined there.

Marking the extraneous functions as __maybe_unused lets gcc drop them
without complaining.

Without this patch, building iop13xx_defconfig results in:

include/asm-generic/xor.h:696:34: warning: 'xor_block_8regs_p' defined but not used [-Wunused-variable]
include/asm-generic/xor.h:704:34: warning: 'xor_block_32regs_p' defined but not used [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Neil Brown <neilb@suse.de>
---
 include/asm-generic/xor.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/xor.h b/include/asm-generic/xor.h
index 6028fb8..b4d8432 100644
--- a/include/asm-generic/xor.h
+++ b/include/asm-generic/xor.h
@@ -693,7 +693,7 @@ static struct xor_block_template xor_block_32regs = {
 	.do_5 = xor_32regs_5,
 };
 
-static struct xor_block_template xor_block_8regs_p = {
+static struct xor_block_template xor_block_8regs_p __maybe_unused = {
 	.name = "8regs_prefetch",
 	.do_2 = xor_8regs_p_2,
 	.do_3 = xor_8regs_p_3,
@@ -701,7 +701,7 @@ static struct xor_block_template xor_block_8regs_p = {
 	.do_5 = xor_8regs_p_5,
 };
 
-static struct xor_block_template xor_block_32regs_p = {
+static struct xor_block_template xor_block_32regs_p __maybe_unused = {
 	.name = "32regs_prefetch",
 	.do_2 = xor_32regs_p_2,
 	.do_3 = xor_32regs_p_3,
-- 
1.7.10

[PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Arnd Bergmann]

ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
be populated with at least one member. gcc correctly warns about
the out-of-bounds access here.

Without this patch, building davinci_all_defconfig results in:

arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>
---
 arch/arm/mach-davinci/board-neuros-osd2.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 5de69f2..9d40df9 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -162,6 +162,7 @@ static void __init davinci_ntosd2_map_io(void)
 	dm644x_init();
 }
 
+#if 0
 /*
  I2C initialization
 */
@@ -193,6 +194,12 @@ static	int ntosd2_init_i2c(void)
 	}
 	return status;
 }
+#else
+static  int ntosd2_init_i2c(void)
+{
+	return 0;
+}
+#endif
 
 static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 	.wires		= 4,
-- 
1.7.10

[PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Arnd Bergmann]

ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
be populated with at least one member. gcc correctly warns about
the out-of-bounds access here.

Without this patch, building davinci_all_defconfig results in:

arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>
---
 arch/arm/mach-davinci/board-neuros-osd2.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 5de69f2..9d40df9 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -162,6 +162,7 @@ static void __init davinci_ntosd2_map_io(void)
 	dm644x_init();
 }
 
+#if 0
 /*
  I2C initialization
 */
@@ -193,6 +194,12 @@ static	int ntosd2_init_i2c(void)
 	}
 	return status;
 }
+#else
+static  int ntosd2_init_i2c(void)
+{
+	return 0;
+}
+#endif
 
 static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 	.wires		= 4,
-- 
1.7.10

[PATCH 07/10] ARM: rpc: check device_register return code in ecard_probe

[Arnd Bergmann]

device_register is marked __must_check, so we better propagate the error
value by returning it from ecard_probe.

Without this patch, building rpc_defconfig results in:

arch/arm/mach-rpc/ecard.c: In function 'ecard_probe':
arch/arm/mach-rpc/ecard.c:963:17: warning: ignoring return value of 'device_register', declared with attribute warn_unused_result [-Wunused-result]

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

diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index b91bc87..fcb1d59 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -960,7 +960,9 @@ static int __init ecard_probe(int slot, unsigned irq, card_type_t type)
 	*ecp = ec;
 	slot_to_expcard[slot] = ec;
 
-	device_register(&ec->dev);
+	rc = device_register(&ec->dev);
+	if (rc)
+		goto nodev;
 
 	return 0;
 
-- 
1.7.10

[PATCH 07/10] ARM: rpc: check device_register return code in ecard_probe

[Arnd Bergmann]

device_register is marked __must_check, so we better propagate the error
value by returning it from ecard_probe.

Without this patch, building rpc_defconfig results in:

arch/arm/mach-rpc/ecard.c: In function 'ecard_probe':
arch/arm/mach-rpc/ecard.c:963:17: warning: ignoring return value of 'device_register', declared with attribute warn_unused_result [-Wunused-result]

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

diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index b91bc87..fcb1d59 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -960,7 +960,9 @@ static int __init ecard_probe(int slot, unsigned irq, card_type_t type)
 	*ecp = ec;
 	slot_to_expcard[slot] = ec;
 
-	device_register(&ec->dev);
+	rc = device_register(&ec->dev);
+	if (rc)
+		goto nodev;
 
 	return 0;
 
-- 
1.7.10

[PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer

[Arnd Bergmann]

Disabling CONFIG_BUG creates an insane amount of build warnings, which
makes it useless to check for building defconfigs to see if new
warnings show up.

Without this patch, building tct_hammer_defconfig results in:

net/packet/af_packet.c: In function 'tpacket_rcv':
net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used uninitialized in this function [-Wuninitialized]
net/core/ethtool.c: In function 'ethtool_get_feature_mask':
net/core/ethtool.c:213:1: warning: control reaches end of non-void function [-Wreturn-type]
block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:2914:1: warning: control reaches end of non-void function [-Wreturn-type]
mm/bootmem.c: In function 'mark_bootmem':
mm/bootmem.c:352:1: warning: control reaches end of non-void function [-Wreturn-type]
net/core/dev.c: In function 'skb_warn_bad_offload':
net/core/dev.c:1904:33: warning: unused variable 'null_features' [-Wunused-variable]
drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
(and many more)

The size of vmlinux increases by 1.78% because of this:

size obj-arm/vmlinux.nobug
   text    data     bss     dec     hex filename
   2108474  116916   55352 2280742  22cd26 obj-arm/vmlinux
size obj-arm/vmlinux.bug
   text    data     bss     dec     hex filename
   2150804  116916   53696 2321416  236c08 obj-arm/vmlinux

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/configs/tct_hammer_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/tct_hammer_defconfig b/arch/arm/configs/tct_hammer_defconfig
index 1d24f84..71277a1 100644
--- a/arch/arm/configs/tct_hammer_defconfig
+++ b/arch/arm/configs/tct_hammer_defconfig
@@ -7,7 +7,7 @@ CONFIG_SYSFS_DEPRECATED_V2=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_KALLSYMS is not set
-# CONFIG_BUG is not set
+# CONFIG_BUGVERBOSE is not set
 # CONFIG_ELF_CORE is not set
 # CONFIG_SHMEM is not set
 CONFIG_SLOB=y
-- 
1.7.10

[PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer

[Arnd Bergmann]

Disabling CONFIG_BUG creates an insane amount of build warnings, which
makes it useless to check for building defconfigs to see if new
warnings show up.

Without this patch, building tct_hammer_defconfig results in:

net/packet/af_packet.c: In function 'tpacket_rcv':
net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used uninitialized in this function [-Wuninitialized]
net/core/ethtool.c: In function 'ethtool_get_feature_mask':
net/core/ethtool.c:213:1: warning: control reaches end of non-void function [-Wreturn-type]
block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:2914:1: warning: control reaches end of non-void function [-Wreturn-type]
mm/bootmem.c: In function 'mark_bootmem':
mm/bootmem.c:352:1: warning: control reaches end of non-void function [-Wreturn-type]
net/core/dev.c: In function 'skb_warn_bad_offload':
net/core/dev.c:1904:33: warning: unused variable 'null_features' [-Wunused-variable]
drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
(and many more)

The size of vmlinux increases by 1.78% because of this:

size obj-arm/vmlinux.nobug
   text    data     bss     dec     hex filename
   2108474  116916   55352 2280742  22cd26 obj-arm/vmlinux
size obj-arm/vmlinux.bug
   text    data     bss     dec     hex filename
   2150804  116916   53696 2321416  236c08 obj-arm/vmlinux

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/configs/tct_hammer_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/tct_hammer_defconfig b/arch/arm/configs/tct_hammer_defconfig
index 1d24f84..71277a1 100644
--- a/arch/arm/configs/tct_hammer_defconfig
+++ b/arch/arm/configs/tct_hammer_defconfig
@@ -7,7 +7,7 @@ CONFIG_SYSFS_DEPRECATED_V2=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_KALLSYMS is not set
-# CONFIG_BUG is not set
+# CONFIG_BUGVERBOSE is not set
 # CONFIG_ELF_CORE is not set
 # CONFIG_SHMEM is not set
 CONFIG_SLOB=y
-- 
1.7.10

[PATCH 09/10] ARM: rpc: Fix building RiscPC

[Arnd Bergmann]

ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
support in place for building RiscPC. However, this does not actually
build in my test setup.

This is probably not the right solution, but maybe someone has a better
idea for how to deal with this.

Without this patch, building rpc_defconfig results in:

arch/arm/lib/io-readsw-armv4.S: Assembler messages:
arch/arm/lib/io-readsw-armv4.S:23: Error: selected processor does not support ARM mode `ldrh ip,[r0]'
arch/arm/lib/io-readsw-armv4.S:25: Error: selected processor does not support ARM mode `strh ip,[r1],#2'
arch/arm/lib/io-readsw-armv4.S:38: Error: selected processor does not support ARM mode `ldrh r3,[r0]'
make[2]: *** [arch/arm/lib/io-readsw-armv4.o] Error 1
make[1]: *** [arch/arm/lib] Error 2

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig    |    2 +-
 arch/arm/Makefile   |    1 -
 arch/arm/mm/Kconfig |   12 ++----------
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..1e435185 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2259,7 +2259,7 @@ config FPE_NWFPE_XP
 
 config FPE_FASTFPE
 	bool "FastFPE math emulation (EXPERIMENTAL)"
-	depends on (!AEABI || OABI_COMPAT) && !CPU_32v3 && EXPERIMENTAL
+	depends on (!AEABI || OABI_COMPAT) && EXPERIMENTAL
 	---help---
 	  Say Y here to include the FAST floating point emulator in the kernel.
 	  This is an experimental much faster emulator which now also has full
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b4c2296..2c53344 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -70,7 +70,6 @@ endif
 arch-$(CONFIG_CPU_32v5)		:=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
 arch-$(CONFIG_CPU_32v4T)	:=-D__LINUX_ARM_ARCH__=4 -march=armv4t
 arch-$(CONFIG_CPU_32v4)		:=-D__LINUX_ARM_ARCH__=4 -march=armv4
-arch-$(CONFIG_CPU_32v3)		:=-D__LINUX_ARM_ARCH__=3 -march=armv3
 
 # This selects how we optimise for the processor.
 tune-$(CONFIG_CPU_ARM7TDMI)	:=-mtune=arm7tdmi
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 101b968..28773e6 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -265,8 +265,7 @@ config CPU_ARM1026
 # SA110
 config CPU_SA110
 	bool "Support StrongARM(R) SA-110 processor" if ARCH_RPC
-	select CPU_32v3 if ARCH_RPC
-	select CPU_32v4 if !ARCH_RPC
+	select CPU_32v4
 	select CPU_ABRT_EV4
 	select CPU_PABRT_LEGACY
 	select CPU_CACHE_V4WB
@@ -395,12 +394,6 @@ config CPU_V7
 
 # Figure out what processor architecture version we should be using.
 # This defines the compiler instruction set which depends on the machine type.
-config CPU_32v3
-	bool
-	select TLS_REG_EMUL if SMP || !MMU
-	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
-	select CPU_USE_DOMAINS if MMU
-
 config CPU_32v4
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
@@ -587,8 +580,7 @@ comment "Processor Features"
 
 config ARM_LPAE
 	bool "Support for the Large Physical Address Extension"
-	depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
-		!CPU_32v4 && !CPU_32v3
+	depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && !CPU_32v4
 	help
 	  Say Y if you have an ARMv7 processor supporting the LPAE page
 	  table format and you would like to access memory beyond the
-- 
1.7.10

[PATCH 09/10] ARM: rpc: Fix building RiscPC

[Arnd Bergmann]

ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
support in place for building RiscPC. However, this does not actually
build in my test setup.

This is probably not the right solution, but maybe someone has a better
idea for how to deal with this.

Without this patch, building rpc_defconfig results in:

arch/arm/lib/io-readsw-armv4.S: Assembler messages:
arch/arm/lib/io-readsw-armv4.S:23: Error: selected processor does not support ARM mode `ldrh ip,[r0]'
arch/arm/lib/io-readsw-armv4.S:25: Error: selected processor does not support ARM mode `strh ip,[r1],#2'
arch/arm/lib/io-readsw-armv4.S:38: Error: selected processor does not support ARM mode `ldrh r3,[r0]'
make[2]: *** [arch/arm/lib/io-readsw-armv4.o] Error 1
make[1]: *** [arch/arm/lib] Error 2

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/Kconfig    |    2 +-
 arch/arm/Makefile   |    1 -
 arch/arm/mm/Kconfig |   12 ++----------
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..1e435185 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2259,7 +2259,7 @@ config FPE_NWFPE_XP
 
 config FPE_FASTFPE
 	bool "FastFPE math emulation (EXPERIMENTAL)"
-	depends on (!AEABI || OABI_COMPAT) && !CPU_32v3 && EXPERIMENTAL
+	depends on (!AEABI || OABI_COMPAT) && EXPERIMENTAL
 	---help---
 	  Say Y here to include the FAST floating point emulator in the kernel.
 	  This is an experimental much faster emulator which now also has full
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b4c2296..2c53344 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -70,7 +70,6 @@ endif
 arch-$(CONFIG_CPU_32v5)		:=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
 arch-$(CONFIG_CPU_32v4T)	:=-D__LINUX_ARM_ARCH__=4 -march=armv4t
 arch-$(CONFIG_CPU_32v4)		:=-D__LINUX_ARM_ARCH__=4 -march=armv4
-arch-$(CONFIG_CPU_32v3)		:=-D__LINUX_ARM_ARCH__=3 -march=armv3
 
 # This selects how we optimise for the processor.
 tune-$(CONFIG_CPU_ARM7TDMI)	:=-mtune=arm7tdmi
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 101b968..28773e6 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -265,8 +265,7 @@ config CPU_ARM1026
 # SA110
 config CPU_SA110
 	bool "Support StrongARM(R) SA-110 processor" if ARCH_RPC
-	select CPU_32v3 if ARCH_RPC
-	select CPU_32v4 if !ARCH_RPC
+	select CPU_32v4
 	select CPU_ABRT_EV4
 	select CPU_PABRT_LEGACY
 	select CPU_CACHE_V4WB
@@ -395,12 +394,6 @@ config CPU_V7
 
 # Figure out what processor architecture version we should be using.
 # This defines the compiler instruction set which depends on the machine type.
-config CPU_32v3
-	bool
-	select TLS_REG_EMUL if SMP || !MMU
-	select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
-	select CPU_USE_DOMAINS if MMU
-
 config CPU_32v4
 	bool
 	select TLS_REG_EMUL if SMP || !MMU
@@ -587,8 +580,7 @@ comment "Processor Features"
 
 config ARM_LPAE
 	bool "Support for the Large Physical Address Extension"
-	depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
-		!CPU_32v4 && !CPU_32v3
+	depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && !CPU_32v4
 	help
 	  Say Y if you have an ARMv7 processor supporting the LPAE page
 	  table format and you would like to access memory beyond the
-- 
1.7.10

[PATCH 10/10] leds: renesas: fix error handling

[Arnd Bergmann]

bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
cleanup error exit path" introduced a possible case in which r_tpu_probe
calls iounmap on a wild pointer. This changes the one case that was
missed in the same way as the other error paths.

Without this patch, building kota2_defconfig results in:

drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Magnus Damm <damm@opensource.se>

--- a/drivers/leds/leds-renesas-tpu.c
+++ b/drivers/leds/leds-renesas-tpu.c
@@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)

        if (!cfg) {
                dev_err(&pdev->dev, "missing platform data\n");
-               goto err0;
+               return -ENODEV;
        }

        p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
---
 drivers/leds/leds-renesas-tpu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-renesas-tpu.c b/drivers/leds/leds-renesas-tpu.c
index 9ee12c2..771ea06 100644
--- a/drivers/leds/leds-renesas-tpu.c
+++ b/drivers/leds/leds-renesas-tpu.c
@@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
 
 	if (!cfg) {
 		dev_err(&pdev->dev, "missing platform data\n");
-		goto err0;
+		return -ENODEV;
 	}
 
 	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
-- 
1.7.10

[PATCH 10/10] leds: renesas: fix error handling

[Arnd Bergmann]

bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
cleanup error exit path" introduced a possible case in which r_tpu_probe
calls iounmap on a wild pointer. This changes the one case that was
missed in the same way as the other error paths.

Without this patch, building kota2_defconfig results in:

drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Magnus Damm <damm@opensource.se>

--- a/drivers/leds/leds-renesas-tpu.c
+++ b/drivers/leds/leds-renesas-tpu.c
@@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)

        if (!cfg) {
                dev_err(&pdev->dev, "missing platform data\n");
-               goto err0;
+               return -ENODEV;
        }

        p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
---
 drivers/leds/leds-renesas-tpu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-renesas-tpu.c b/drivers/leds/leds-renesas-tpu.c
index 9ee12c2..771ea06 100644
--- a/drivers/leds/leds-renesas-tpu.c
+++ b/drivers/leds/leds-renesas-tpu.c
@@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
 
 	if (!cfg) {
 		dev_err(&pdev->dev, "missing platform data\n");
-		goto err0;
+		return -ENODEV;
 	}
 
 	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
-- 
1.7.10

Re: [PATCH 10/10] leds: renesas: fix error handling

[Bryan Wu]

On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
> cleanup error exit path" introduced a possible case in which r_tpu_probe
> calls iounmap on a wild pointer. This changes the one case that was
> missed in the same way as the other error paths.
>
> Without this patch, building kota2_defconfig results in:
>
> drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
> drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
> drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]
>

Thanks, Arnd. If you don't mind, I will apply this fixing through my led tree.

-Bryan

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bryan Wu <bryan.wu@canonical.com>
> Cc: Magnus Damm <damm@opensource.se>
>
> --- a/drivers/leds/leds-renesas-tpu.c
> +++ b/drivers/leds/leds-renesas-tpu.c
> @@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
>
>         if (!cfg) {
>                 dev_err(&pdev->dev, "missing platform data\n");
> -               goto err0;
> +               return -ENODEV;
>         }
>
>         p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
> ---
>  drivers/leds/leds-renesas-tpu.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-renesas-tpu.c b/drivers/leds/leds-renesas-tpu.c
> index 9ee12c2..771ea06 100644
> --- a/drivers/leds/leds-renesas-tpu.c
> +++ b/drivers/leds/leds-renesas-tpu.c
> @@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
>
>         if (!cfg) {
>                 dev_err(&pdev->dev, "missing platform data\n");
> -               goto err0;
> +               return -ENODEV;
>         }
>
>         p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
> --
> 1.7.10
>



-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.186-168-78255 Mobile
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com

[PATCH 10/10] leds: renesas: fix error handling

[Bryan Wu]

On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
> cleanup error exit path" introduced a possible case in which r_tpu_probe
> calls iounmap on a wild pointer. This changes the one case that was
> missed in the same way as the other error paths.
>
> Without this patch, building kota2_defconfig results in:
>
> drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
> drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
> drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]
>

Thanks, Arnd. If you don't mind, I will apply this fixing through my led tree.

-Bryan

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bryan Wu <bryan.wu@canonical.com>
> Cc: Magnus Damm <damm@opensource.se>
>
> --- a/drivers/leds/leds-renesas-tpu.c
> +++ b/drivers/leds/leds-renesas-tpu.c
> @@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
>
>         if (!cfg) {
>                 dev_err(&pdev->dev, "missing platform data\n");
> -               goto err0;
> +               return -ENODEV;
>         }
>
>         p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
> ---
>  drivers/leds/leds-renesas-tpu.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-renesas-tpu.c b/drivers/leds/leds-renesas-tpu.c
> index 9ee12c2..771ea06 100644
> --- a/drivers/leds/leds-renesas-tpu.c
> +++ b/drivers/leds/leds-renesas-tpu.c
> @@ -247,7 +247,7 @@ static int __devinit r_tpu_probe(struct platform_device *pdev)
>
>         if (!cfg) {
>                 dev_err(&pdev->dev, "missing platform data\n");
> -               goto err0;
> +               return -ENODEV;
>         }
>
>         p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
> --
> 1.7.10
>



-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.186-168-78255 Mobile
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com

Re: [PATCH 10/10] leds: renesas: fix error handling

[Arnd Bergmann]

On Thursday 09 August 2012, Bryan Wu wrote:
> 
> On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
> > cleanup error exit path" introduced a possible case in which r_tpu_probe
> > calls iounmap on a wild pointer. This changes the one case that was
> > missed in the same way as the other error paths.
> >
> > Without this patch, building kota2_defconfig results in:
> >
> > drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
> > drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
> > drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]
> >
> 
> Thanks, Arnd. If you don't mind, I will apply this fixing through my led tree.
> 

Ok, excellent. One less patch for me to worry about. Dropped from my tree now.

	Arnd

[PATCH 10/10] leds: renesas: fix error handling

[Arnd Bergmann]

On Thursday 09 August 2012, Bryan Wu wrote:
> 
> On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > bfe4c041 "leds: convert Renesas TPU LED driver to devm_kzalloc() and
> > cleanup error exit path" introduced a possible case in which r_tpu_probe
> > calls iounmap on a wild pointer. This changes the one case that was
> > missed in the same way as the other error paths.
> >
> > Without this patch, building kota2_defconfig results in:
> >
> > drivers/leds/leds-renesas-tpu.c: In function 'r_tpu_probe':
> > drivers/leds/leds-renesas-tpu.c:246:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
> > drivers/leds/leds-renesas-tpu.c:308:17: warning: 'p' may be used uninitialized in this function [-Wuninitialized]
> >
> 
> Thanks, Arnd. If you don't mind, I will apply this fixing through my led tree.
> 

Ok, excellent. One less patch for me to worry about. Dropped from my tree now.

	Arnd

Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC

[Russell King - ARM Linux]

On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> support in place for building RiscPC. However, this does not actually
> build in my test setup.
> 
> This is probably not the right solution, but maybe someone has a better
> idea for how to deal with this.

This isn't the right solution.  The RiscPC bus does not support half-word
load/stores, so we must continue to build that target for the 32v3
architecture (which is why I carefully left that stuff behind.)

The mistake is in what I did with arch/arm/lib - the armv3 code in there
needs to be resurected instead.

[PATCH 09/10] ARM: rpc: Fix building RiscPC

[Russell King - ARM Linux]

On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> support in place for building RiscPC. However, this does not actually
> build in my test setup.
> 
> This is probably not the right solution, but maybe someone has a better
> idea for how to deal with this.

This isn't the right solution.  The RiscPC bus does not support half-word
load/stores, so we must continue to build that target for the 32v3
architecture (which is why I carefully left that stuff behind.)

The mistake is in what I did with arch/arm/lib - the armv3 code in there
needs to be resurected instead.

Re: [PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Arnd Bergmann]

On second thought, there is probably no use in keeping the broken function
around, and we can just kill it off. If someone wants to add an i2c
device to the bus, they can always add the init code back as well.

8<-----
Subject: ARM: davinci: don't use broken ntosd2_init_i2c

ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
be populated with at least one member. gcc correctly warns about
the out-of-bounds access here.

Since this can not possibly work, it's better to disable i2c
support entirely on this board.

Without this patch, building davinci_all_defconfig results in:

arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 5de69f2..f6b9fc7 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -162,38 +162,6 @@ static void __init davinci_ntosd2_map_io(void)
 	dm644x_init();
 }
 
-/*
- I2C initialization
-*/
-static struct davinci_i2c_platform_data ntosd2_i2c_pdata = {
-	.bus_freq	= 20 /* kHz */,
-	.bus_delay	= 100 /* usec */,
-};
-
-static struct i2c_board_info __initdata ntosd2_i2c_info[] =  {
-};
-
-static	int ntosd2_init_i2c(void)
-{
-	int	status;
-
-	davinci_init_i2c(&ntosd2_i2c_pdata);
-	status = gpio_request(NTOSD2_MSP430_IRQ, ntosd2_i2c_info[0].type);
-	if (status == 0) {
-		status = gpio_direction_input(NTOSD2_MSP430_IRQ);
-		if (status == 0) {
-			status = gpio_to_irq(NTOSD2_MSP430_IRQ);
-			if (status > 0) {
-				ntosd2_i2c_info[0].irq = status;
-				i2c_register_board_info(1,
-					ntosd2_i2c_info,
-					ARRAY_SIZE(ntosd2_i2c_info));
-			}
-		}
-	}
-	return status;
-}
-
 static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 	.wires		= 4,
 	.version	= MMC_CTLR_VERSION_1
@@ -218,7 +186,6 @@ static __init void davinci_ntosd2_init(void)
 {
 	struct clk *aemif_clk;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	int	status;
 
 	aemif_clk = clk_get(NULL, "aemif");
 	clk_enable(aemif_clk);
@@ -242,12 +209,6 @@ static __init void davinci_ntosd2_init(void)
 	platform_add_devices(davinci_ntosd2_devices,
 				ARRAY_SIZE(davinci_ntosd2_devices));
 
-	/* Initialize I2C interface specific for this board */
-	status = ntosd2_init_i2c();
-	if (status < 0)
-		pr_warning("davinci_ntosd2_init: msp430 irq setup failed:"
-						"	 %d\n", status);
-
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_ntosd2_snd_data);
 

[PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Arnd Bergmann]

On second thought, there is probably no use in keeping the broken function
around, and we can just kill it off. If someone wants to add an i2c
device to the bus, they can always add the init code back as well.

8<-----
Subject: ARM: davinci: don't use broken ntosd2_init_i2c

ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
be populated with at least one member. gcc correctly warns about
the out-of-bounds access here.

Since this can not possibly work, it's better to disable i2c
support entirely on this board.

Without this patch, building davinci_all_defconfig results in:

arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 5de69f2..f6b9fc7 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -162,38 +162,6 @@ static void __init davinci_ntosd2_map_io(void)
 	dm644x_init();
 }
 
-/*
- I2C initialization
-*/
-static struct davinci_i2c_platform_data ntosd2_i2c_pdata = {
-	.bus_freq	= 20 /* kHz */,
-	.bus_delay	= 100 /* usec */,
-};
-
-static struct i2c_board_info __initdata ntosd2_i2c_info[] =  {
-};
-
-static	int ntosd2_init_i2c(void)
-{
-	int	status;
-
-	davinci_init_i2c(&ntosd2_i2c_pdata);
-	status = gpio_request(NTOSD2_MSP430_IRQ, ntosd2_i2c_info[0].type);
-	if (status == 0) {
-		status = gpio_direction_input(NTOSD2_MSP430_IRQ);
-		if (status == 0) {
-			status = gpio_to_irq(NTOSD2_MSP430_IRQ);
-			if (status > 0) {
-				ntosd2_i2c_info[0].irq = status;
-				i2c_register_board_info(1,
-					ntosd2_i2c_info,
-					ARRAY_SIZE(ntosd2_i2c_info));
-			}
-		}
-	}
-	return status;
-}
-
 static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 	.wires		= 4,
 	.version	= MMC_CTLR_VERSION_1
@@ -218,7 +186,6 @@ static __init void davinci_ntosd2_init(void)
 {
 	struct clk *aemif_clk;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	int	status;
 
 	aemif_clk = clk_get(NULL, "aemif");
 	clk_enable(aemif_clk);
@@ -242,12 +209,6 @@ static __init void davinci_ntosd2_init(void)
 	platform_add_devices(davinci_ntosd2_devices,
 				ARRAY_SIZE(davinci_ntosd2_devices));
 
-	/* Initialize I2C interface specific for this board */
-	status = ntosd2_init_i2c();
-	if (status < 0)
-		pr_warning("davinci_ntosd2_init: msp430 irq setup failed:"
-						"	 %d\n", status);
-
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_ntosd2_snd_data);
 

Re: [PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Sekhar Nori]

Hi Arnd,

On 8/9/2012 1:30 PM, Arnd Bergmann wrote:
> On second thought, there is probably no use in keeping the broken function
> around, and we can just kill it off. If someone wants to add an i2c
> device to the bus, they can always add the init code back as well.
> 
> 8<-----
> Subject: ARM: davinci: don't use broken ntosd2_init_i2c
> 
> ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
> be populated with at least one member. gcc correctly warns about
> the out-of-bounds access here.
> 
> Since this can not possibly work, it's better to disable i2c
> support entirely on this board.
> 
> Without this patch, building davinci_all_defconfig results in:
> 
> arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
> arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Andrey Porodko <panda@chelcom.ru>

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

[PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c

[Sekhar Nori]

Hi Arnd,

On 8/9/2012 1:30 PM, Arnd Bergmann wrote:
> On second thought, there is probably no use in keeping the broken function
> around, and we can just kill it off. If someone wants to add an i2c
> device to the bus, they can always add the init code back as well.
> 
> 8<-----
> Subject: ARM: davinci: don't use broken ntosd2_init_i2c
> 
> ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
> be populated with at least one member. gcc correctly warns about
> the out-of-bounds access here.
> 
> Since this can not possibly work, it's better to disable i2c
> support entirely on this board.
> 
> Without this patch, building davinci_all_defconfig results in:
> 
> arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
> arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Andrey Porodko <panda@chelcom.ru>

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

Re: [PATCH 04/10] ARM: pass -marm to gcc by default

[Nicolas Pitre]

On Wed, 8 Aug 2012, 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>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Dave Martin <dave.martin@linaro.org>
> ---
>  arch/arm/Makefile |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 30eae87..b4c2296 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -111,6 +111,9 @@ AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
>  ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
>  CFLAGS_MODULE	+=-fno-optimize-sibling-calls
>  endif
> +else
> +CFLAGS_THUMB2  :=-marm
> +AFLAGS_THUMB2	:=-marm

CFLAGS_THUMB2 should probably be renamed to something more appropriate 
in this case, e.g. CFLAGS_MODE.


Nicolas

[PATCH 04/10] ARM: pass -marm to gcc by default

[Nicolas Pitre]

On Wed, 8 Aug 2012, 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>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Dave Martin <dave.martin@linaro.org>
> ---
>  arch/arm/Makefile |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 30eae87..b4c2296 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -111,6 +111,9 @@ AFLAGS_THUMB2	:=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
>  ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
>  CFLAGS_MODULE	+=-fno-optimize-sibling-calls
>  endif
> +else
> +CFLAGS_THUMB2  :=-marm
> +AFLAGS_THUMB2	:=-marm

CFLAGS_THUMB2 should probably be renamed to something more appropriate 
in this case, e.g. CFLAGS_MODE.


Nicolas

Re: [PATCH 04/10] ARM: pass -marm to gcc by default

[Russell King - ARM Linux]

On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> in this case, e.g. CFLAGS_MODE.

CFLAGS_ISA would be more relevant to it, because it's selecting the
instruction set.

[PATCH 04/10] ARM: pass -marm to gcc by default

[Russell King - ARM Linux]

On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> in this case, e.g. CFLAGS_MODE.

CFLAGS_ISA would be more relevant to it, because it's selecting the
instruction set.

Re: [PATCH 04/10] ARM: pass -marm to gcc by default

[Nicolas Pitre]

On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:

> On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > in this case, e.g. CFLAGS_MODE.
> 
> CFLAGS_ISA would be more relevant to it, because it's selecting the
> instruction set.

Agreed.  This particular TLA escaped my mind somehow.


Nicolas

[PATCH 04/10] ARM: pass -marm to gcc by default

[Nicolas Pitre]

On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:

> On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > in this case, e.g. CFLAGS_MODE.
> 
> CFLAGS_ISA would be more relevant to it, because it's selecting the
> instruction set.

Agreed.  This particular TLA escaped my mind somehow.


Nicolas

RE: [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Disabling CONFIG_BUG creates an insane amount of build warnings, which
> makes it useless to check for building defconfigs to see if new
> warnings show up.
> 
> Without this patch, building tct_hammer_defconfig results in:
> 
> net/packet/af_packet.c: In function 'tpacket_rcv':
> net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used
> uninitialized in this function [-Wuninitialized]
> net/core/ethtool.c: In function 'ethtool_get_feature_mask':
> net/core/ethtool.c:213:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> block/cfq-iosched.c: In function 'cfq_async_queue_prio':
> block/cfq-iosched.c:2914:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> mm/bootmem.c: In function 'mark_bootmem':
> mm/bootmem.c:352:1: warning: control reaches end of non-void function [-
> Wreturn-type]
> net/core/dev.c: In function 'skb_warn_bad_offload':
> net/core/dev.c:1904:33: warning: unused variable 'null_features' [-
> Wunused-variable]
> drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
> include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized
> in this function [-Wuninitialized]
> include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
> include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized
> in this function [-Wuninitialized]
> (and many more)
> 
> The size of vmlinux increases by 1.78% because of this:
> 
> size obj-arm/vmlinux.nobug
>    text    data     bss     dec     hex filename
>    2108474  116916   55352 2280742  22cd26 obj-arm/vmlinux
> size obj-arm/vmlinux.bug
>    text    data     bss     dec     hex filename
>    2150804  116916   53696 2321416  236c08 obj-arm/vmlinux
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

BTW, I'm not sure we should still keep the tct_hammer_defconfig because
s3c2410_defconfig is including MACH_TCT_HAMMER, its selection are different
though.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/configs/tct_hammer_defconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/tct_hammer_defconfig
> b/arch/arm/configs/tct_hammer_defconfig
> index 1d24f84..71277a1 100644
> --- a/arch/arm/configs/tct_hammer_defconfig
> +++ b/arch/arm/configs/tct_hammer_defconfig
> @@ -7,7 +7,7 @@ CONFIG_SYSFS_DEPRECATED_V2=y
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_EXPERT=y
>  # CONFIG_KALLSYMS is not set
> -# CONFIG_BUG is not set
> +# CONFIG_BUGVERBOSE is not set
>  # CONFIG_ELF_CORE is not set
>  # CONFIG_SHMEM is not set
>  CONFIG_SLOB=y
> --
> 1.7.10

[PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Disabling CONFIG_BUG creates an insane amount of build warnings, which
> makes it useless to check for building defconfigs to see if new
> warnings show up.
> 
> Without this patch, building tct_hammer_defconfig results in:
> 
> net/packet/af_packet.c: In function 'tpacket_rcv':
> net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used
> uninitialized in this function [-Wuninitialized]
> net/core/ethtool.c: In function 'ethtool_get_feature_mask':
> net/core/ethtool.c:213:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> block/cfq-iosched.c: In function 'cfq_async_queue_prio':
> block/cfq-iosched.c:2914:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> mm/bootmem.c: In function 'mark_bootmem':
> mm/bootmem.c:352:1: warning: control reaches end of non-void function [-
> Wreturn-type]
> net/core/dev.c: In function 'skb_warn_bad_offload':
> net/core/dev.c:1904:33: warning: unused variable 'null_features' [-
> Wunused-variable]
> drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
> include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized
> in this function [-Wuninitialized]
> include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
> include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized
> in this function [-Wuninitialized]
> (and many more)
> 
> The size of vmlinux increases by 1.78% because of this:
> 
> size obj-arm/vmlinux.nobug
>    text    data     bss     dec     hex filename
>    2108474  116916   55352 2280742  22cd26 obj-arm/vmlinux
> size obj-arm/vmlinux.bug
>    text    data     bss     dec     hex filename
>    2150804  116916   53696 2321416  236c08 obj-arm/vmlinux
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

BTW, I'm not sure we should still keep the tct_hammer_defconfig because
s3c2410_defconfig is including MACH_TCT_HAMMER, its selection are different
though.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/configs/tct_hammer_defconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/tct_hammer_defconfig
> b/arch/arm/configs/tct_hammer_defconfig
> index 1d24f84..71277a1 100644
> --- a/arch/arm/configs/tct_hammer_defconfig
> +++ b/arch/arm/configs/tct_hammer_defconfig
> @@ -7,7 +7,7 @@ CONFIG_SYSFS_DEPRECATED_V2=y
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_EXPERT=y
>  # CONFIG_KALLSYMS is not set
> -# CONFIG_BUG is not set
> +# CONFIG_BUGVERBOSE is not set
>  # CONFIG_ELF_CORE is not set
>  # CONFIG_SHMEM is not set
>  CONFIG_SLOB=y
> --
> 1.7.10

Re: [PATCH 04/10] ARM: pass -marm to gcc by default

[Dave Martin]

On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
> 
> > On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > > in this case, e.g. CFLAGS_MODE.
> > 
> > CFLAGS_ISA would be more relevant to it, because it's selecting the
> > instruction set.
> 
> Agreed.  This particular TLA escaped my mind somehow.

Seems fair enough.  It doesn't quite match the official architectural
terminology, but it clear enough what it means, and less cumbersome than
the alternatives.

Best not to use MODE though.  That word is way too overloaded.

---Dave

[PATCH 04/10] ARM: pass -marm to gcc by default

[Dave Martin]

On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
> 
> > On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > > in this case, e.g. CFLAGS_MODE.
> > 
> > CFLAGS_ISA would be more relevant to it, because it's selecting the
> > instruction set.
> 
> Agreed.  This particular TLA escaped my mind somehow.

Seems fair enough.  It doesn't quite match the official architectural
terminology, but it clear enough what it means, and less cumbersome than
the alternatives.

Best not to use MODE though.  That word is way too overloaded.

---Dave

Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC

[Arnd Bergmann]

On Thursday 09 August 2012, Russell King - ARM Linux wrote:
> On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> > ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> > ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> > support in place for building RiscPC. However, this does not actually
> > build in my test setup.
> > 
> > This is probably not the right solution, but maybe someone has a better
> > idea for how to deal with this.
> 
> This isn't the right solution.  The RiscPC bus does not support half-word
> load/stores, so we must continue to build that target for the 32v3
> architecture (which is why I carefully left that stuff behind.)
> 
> The mistake is in what I did with arch/arm/lib - the armv3 code in there
> needs to be resurected instead.

Ok, I'll drop my patch from the series then and wait for you to
fix this properly.

	Arnd

[PATCH 09/10] ARM: rpc: Fix building RiscPC

[Arnd Bergmann]

On Thursday 09 August 2012, Russell King - ARM Linux wrote:
> On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> > ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> > ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> > support in place for building RiscPC. However, this does not actually
> > build in my test setup.
> > 
> > This is probably not the right solution, but maybe someone has a better
> > idea for how to deal with this.
> 
> This isn't the right solution.  The RiscPC bus does not support half-word
> load/stores, so we must continue to build that target for the 32v3
> architecture (which is why I carefully left that stuff behind.)
> 
> The mistake is in what I did with arch/arm/lib - the armv3 code in there
> needs to be resurected instead.

Ok, I'll drop my patch from the series then and wait for you to
fix this properly.

	Arnd

Re: [PATCH 04/10] ARM: pass -marm to gcc by default

[Arnd Bergmann]

On Friday 10 August 2012, Dave Martin wrote:
> On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
> > On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
> > 
> > > On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > > > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > > > in this case, e.g. CFLAGS_MODE.
> > > 
> > > CFLAGS_ISA would be more relevant to it, because it's selecting the
> > > instruction set.
> > 
> > Agreed.  This particular TLA escaped my mind somehow.
> 
> Seems fair enough.  It doesn't quite match the official architectural
> terminology, but it clear enough what it means, and less cumbersome than
> the alternatives.
> 
> Best not to use MODE though.  That word is way too overloaded.

Ok. I already noticed that we already set -marm in KBUILD_CFLAGS but
not in the AFLAGS. This new version should cover all the issues
and make it more obvious what's actually going on.

	Arnd

8<----
>From 34763772164d1442509f27d7f8a09326ff4b7878 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 30 Apr 2012 12:40:00 +0000
Subject: [PATCH] ARM: pass -marm to gcc by default for both C and assembler

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>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..ca0dabc 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__
 

[PATCH 04/10] ARM: pass -marm to gcc by default

[Arnd Bergmann]

On Friday 10 August 2012, Dave Martin wrote:
> On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
> > On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
> > 
> > > On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
> > > > CFLAGS_THUMB2 should probably be renamed to something more appropriate 
> > > > in this case, e.g. CFLAGS_MODE.
> > > 
> > > CFLAGS_ISA would be more relevant to it, because it's selecting the
> > > instruction set.
> > 
> > Agreed.  This particular TLA escaped my mind somehow.
> 
> Seems fair enough.  It doesn't quite match the official architectural
> terminology, but it clear enough what it means, and less cumbersome than
> the alternatives.
> 
> Best not to use MODE though.  That word is way too overloaded.

Ok. I already noticed that we already set -marm in KBUILD_CFLAGS but
not in the AFLAGS. This new version should cover all the issues
and make it more obvious what's actually going on.

	Arnd

8<----
>From 34763772164d1442509f27d7f8a09326ff4b7878 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 30 Apr 2012 12:40:00 +0000
Subject: [PATCH] ARM: pass -marm to gcc by default for both C and assembler

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>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..ca0dabc 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__
 

Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC

[Russell King - ARM Linux]

On Fri, Aug 10, 2012 at 11:03:58AM +0000, Arnd Bergmann wrote:
> On Thursday 09 August 2012, Russell King - ARM Linux wrote:
> > On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> > > ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> > > ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> > > support in place for building RiscPC. However, this does not actually
> > > build in my test setup.
> > > 
> > > This is probably not the right solution, but maybe someone has a better
> > > idea for how to deal with this.
> > 
> > This isn't the right solution.  The RiscPC bus does not support half-word
> > load/stores, so we must continue to build that target for the 32v3
> > architecture (which is why I carefully left that stuff behind.)
> > 
> > The mistake is in what I did with arch/arm/lib - the armv3 code in there
> > needs to be resurected instead.
> 
> Ok, I'll drop my patch from the series then and wait for you to
> fix this properly.

I've just reverted the arch/arm/lib part of
357c9c1f07d4546bc3fbc0fd1044d96b114d14ed (ARM: Remove support for ARMv3
ARM610 and ARM710 CPUs) so when I push my fixes branch this should resolve
your build error.

[PATCH 09/10] ARM: rpc: Fix building RiscPC

[Russell King - ARM Linux]

On Fri, Aug 10, 2012 at 11:03:58AM +0000, Arnd Bergmann wrote:
> On Thursday 09 August 2012, Russell King - ARM Linux wrote:
> > On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
> > > ARMv3 support was removed in 357c9c1f07 "ARM: Remove support for ARMv3
> > > ARM610 and ARM710 CPUs", which explicitly left parts of the CPU32v3
> > > support in place for building RiscPC. However, this does not actually
> > > build in my test setup.
> > > 
> > > This is probably not the right solution, but maybe someone has a better
> > > idea for how to deal with this.
> > 
> > This isn't the right solution.  The RiscPC bus does not support half-word
> > load/stores, so we must continue to build that target for the 32v3
> > architecture (which is why I carefully left that stuff behind.)
> > 
> > The mistake is in what I did with arch/arm/lib - the armv3 code in there
> > needs to be resurected instead.
> 
> Ok, I'll drop my patch from the series then and wait for you to
> fix this properly.

I've just reverted the arch/arm/lib part of
357c9c1f07d4546bc3fbc0fd1044d96b114d14ed (ARM: Remove support for ARMv3
ARM610 and ARM710 CPUs) so when I push my fixes branch this should resolve
your build error.

Re: [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype

[Andrew Lunn]

On Wed, Aug 08, 2012 at 11:27:51PM +0200, Arnd Bergmann wrote:
> Patch b6d1c33a31 "ARM: Orion: Consolidate the address map setup" tried
> to merge the address map for the four orion platforms, but apparently
> got it wrong for mv78xx0. Admittedly I don't understand what this
> code actually does, but it's clear that the current version is
> wrong.
> 
> Without this patch, building mv78xx0_defconfig results in:
> 
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Nicolas Pitre <nico@linaro.org>
> ---
>  arch/arm/mach-mv78xx0/addr-map.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
> index 62b53d7..a9bc841 100644
> --- a/arch/arm/mach-mv78xx0/addr-map.c
> +++ b/arch/arm/mach-mv78xx0/addr-map.c
> @@ -37,7 +37,7 @@
>  #define WIN0_OFF(n)		(BRIDGE_VIRT_BASE + 0x0000 + ((n) << 4))
>  #define WIN8_OFF(n)		(BRIDGE_VIRT_BASE + 0x0900 + (((n) - 8) << 4))
>  
> -static void __init __iomem *win_cfg_base(int win)
> +static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
>  {
>  	/*
>  	 * Find the control register base address for this window.
> -- 
> 1.7.10
> 

Acked-by: Andrew Lunn <andrew@lunn.ch>

	  Andrew

[PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype

[Andrew Lunn]

On Wed, Aug 08, 2012 at 11:27:51PM +0200, Arnd Bergmann wrote:
> Patch b6d1c33a31 "ARM: Orion: Consolidate the address map setup" tried
> to merge the address map for the four orion platforms, but apparently
> got it wrong for mv78xx0. Admittedly I don't understand what this
> code actually does, but it's clear that the current version is
> wrong.
> 
> Without this patch, building mv78xx0_defconfig results in:
> 
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Nicolas Pitre <nico@linaro.org>
> ---
>  arch/arm/mach-mv78xx0/addr-map.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
> index 62b53d7..a9bc841 100644
> --- a/arch/arm/mach-mv78xx0/addr-map.c
> +++ b/arch/arm/mach-mv78xx0/addr-map.c
> @@ -37,7 +37,7 @@
>  #define WIN0_OFF(n)		(BRIDGE_VIRT_BASE + 0x0000 + ((n) << 4))
>  #define WIN8_OFF(n)		(BRIDGE_VIRT_BASE + 0x0900 + (((n) - 8) << 4))
>  
> -static void __init __iomem *win_cfg_base(int win)
> +static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
>  {
>  	/*
>  	 * Find the control register base address for this window.
> -- 
> 1.7.10
> 

Acked-by: Andrew Lunn <andrew@lunn.ch>

	  Andrew