* [PATCH 01/10] ARM: footbridge: nw_gpio_lock is raw_spin_lock
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-08 21:27 ` [PATCH 02/10] ARM: ks8695: __arch_virt_to_dma type handling Arnd Bergmann
` (8 subsequent siblings)
9 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Arnd Bergmann, Thomas Gleixner, Russell King
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 02/10] ARM: ks8695: __arch_virt_to_dma type handling
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
2012-08-08 21:27 ` [PATCH 01/10] ARM: footbridge: nw_gpio_lock is raw_spin_lock Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-08 21:27 ` [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype Arnd Bergmann
` (7 subsequent siblings)
9 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: arm, linux-kernel, 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
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
2012-08-08 21:27 ` [PATCH 01/10] ARM: footbridge: nw_gpio_lock is raw_spin_lock Arnd Bergmann
2012-08-08 21:27 ` [PATCH 02/10] ARM: ks8695: __arch_virt_to_dma type handling Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-13 14:59 ` Andrew Lunn
2012-08-08 21:27 ` [PATCH 04/10] ARM: pass -marm to gcc by default Arnd Bergmann
` (6 subsequent siblings)
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Arnd Bergmann, Andrew Lunn, Michael Walle,
Nicolas Pitre
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype
2012-08-08 21:27 ` [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype Arnd Bergmann
@ 2012-08-13 14:59 ` Andrew Lunn
0 siblings, 0 replies; 25+ messages in thread
From: Andrew Lunn @ 2012-08-13 14:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, arm, linux-kernel, Andrew Lunn, Michael Walle,
Nicolas Pitre
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (2 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-09 21:12 ` Nicolas Pitre
2012-08-08 21:27 ` [PATCH 05/10] asm-generic: xor: mark static functions as __maybe_unused Arnd Bergmann
` (5 subsequent siblings)
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Arnd Bergmann, Russell King, Dave Martin
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-08 21:27 ` [PATCH 04/10] ARM: pass -marm to gcc by default Arnd Bergmann
@ 2012-08-09 21:12 ` Nicolas Pitre
2012-08-09 21:17 ` Russell King - ARM Linux
0 siblings, 1 reply; 25+ messages in thread
From: Nicolas Pitre @ 2012-08-09 21:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, arm, linux-kernel, Russell King, Dave Martin
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-09 21:12 ` Nicolas Pitre
@ 2012-08-09 21:17 ` Russell King - ARM Linux
2012-08-09 21:22 ` Nicolas Pitre
0 siblings, 1 reply; 25+ messages in thread
From: Russell King - ARM Linux @ 2012-08-09 21:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Arnd Bergmann, linux-arm-kernel, arm, linux-kernel, Dave Martin
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-09 21:17 ` Russell King - ARM Linux
@ 2012-08-09 21:22 ` Nicolas Pitre
2012-08-10 9:59 ` Dave Martin
0 siblings, 1 reply; 25+ messages in thread
From: Nicolas Pitre @ 2012-08-09 21:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, linux-arm-kernel, arm, linux-kernel, Dave Martin
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-09 21:22 ` Nicolas Pitre
@ 2012-08-10 9:59 ` Dave Martin
2012-08-10 11:12 ` Arnd Bergmann
0 siblings, 1 reply; 25+ messages in thread
From: Dave Martin @ 2012-08-10 9:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel, arm,
linux-kernel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 04/10] ARM: pass -marm to gcc by default
2012-08-10 9:59 ` Dave Martin
@ 2012-08-10 11:12 ` Arnd Bergmann
0 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-10 11:12 UTC (permalink / raw)
To: Dave Martin
Cc: Nicolas Pitre, Russell King - ARM Linux, linux-arm-kernel, arm,
linux-kernel
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__
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 05/10] asm-generic: xor: mark static functions as __maybe_unused
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (3 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 04/10] ARM: pass -marm to gcc by default Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-08 21:27 ` [PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c Arnd Bergmann
` (4 subsequent siblings)
9 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Arnd Bergmann, Herbert Xu, Dan Williams, Neil Brown
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (4 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 05/10] asm-generic: xor: mark static functions as __maybe_unused Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-09 8:00 ` [PATCH v2 " Arnd Bergmann
2012-08-08 21:27 ` [PATCH 07/10] ARM: rpc: check device_register return code in ecard_probe Arnd Bergmann
` (3 subsequent siblings)
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Arnd Bergmann, Kevin Hilman, Sekhar Nori,
Andrey Porodko
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c
2012-08-08 21:27 ` [PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c Arnd Bergmann
@ 2012-08-09 8:00 ` Arnd Bergmann
2012-08-09 18:23 ` Sekhar Nori
0 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-09 8:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arm, linux-kernel, Kevin Hilman, Sekhar Nori, Andrey Porodko
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);
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c
2012-08-09 8:00 ` [PATCH v2 " Arnd Bergmann
@ 2012-08-09 18:23 ` Sekhar Nori
0 siblings, 0 replies; 25+ messages in thread
From: Sekhar Nori @ 2012-08-09 18:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, arm, linux-kernel, Kevin Hilman, Andrey Porodko
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 07/10] ARM: rpc: check device_register return code in ecard_probe
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (5 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 06/10] ARM: davinci: don't use broken ntosd2_init_i2c Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-08 21:27 ` [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer Arnd Bergmann
` (2 subsequent siblings)
9 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: arm, linux-kernel, Arnd Bergmann, Russell King
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (6 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 07/10] ARM: rpc: check device_register return code in ecard_probe Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-10 6:07 ` Kukjin Kim
2012-08-08 21:27 ` [PATCH 09/10] ARM: rpc: Fix building RiscPC Arnd Bergmann
2012-08-08 21:27 ` [PATCH 10/10] leds: renesas: fix error handling Arnd Bergmann
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: arm, linux-kernel, Arnd Bergmann, Kukjin Kim, Ben Dooks
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
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer
2012-08-08 21:27 ` [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer Arnd Bergmann
@ 2012-08-10 6:07 ` Kukjin Kim
0 siblings, 0 replies; 25+ messages in thread
From: Kukjin Kim @ 2012-08-10 6:07 UTC (permalink / raw)
To: 'Arnd Bergmann', linux-arm-kernel
Cc: arm, linux-kernel, 'Ben Dooks'
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 09/10] ARM: rpc: Fix building RiscPC
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (7 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-09 7:47 ` Russell King - ARM Linux
2012-08-08 21:27 ` [PATCH 10/10] leds: renesas: fix error handling Arnd Bergmann
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: arm, linux-kernel, Arnd Bergmann, Russell King
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC
2012-08-08 21:27 ` [PATCH 09/10] ARM: rpc: Fix building RiscPC Arnd Bergmann
@ 2012-08-09 7:47 ` Russell King - ARM Linux
2012-08-10 11:03 ` Arnd Bergmann
0 siblings, 1 reply; 25+ messages in thread
From: Russell King - ARM Linux @ 2012-08-09 7:47 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm, linux-kernel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC
2012-08-09 7:47 ` Russell King - ARM Linux
@ 2012-08-10 11:03 ` Arnd Bergmann
2012-08-13 10:52 ` Russell King - ARM Linux
0 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-10 11:03 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-arm-kernel, arm, linux-kernel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 09/10] ARM: rpc: Fix building RiscPC
2012-08-10 11:03 ` Arnd Bergmann
@ 2012-08-13 10:52 ` Russell King - ARM Linux
0 siblings, 0 replies; 25+ messages in thread
From: Russell King - ARM Linux @ 2012-08-13 10:52 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm, linux-kernel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 10/10] leds: renesas: fix error handling
2012-08-08 21:27 [PATCH 00/10] ARM: interesting warnings from defconfig builds Arnd Bergmann
` (8 preceding siblings ...)
2012-08-08 21:27 ` [PATCH 09/10] ARM: rpc: Fix building RiscPC Arnd Bergmann
@ 2012-08-08 21:27 ` Arnd Bergmann
2012-08-09 6:15 ` Bryan Wu
9 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-08 21:27 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: arm, linux-kernel, Arnd Bergmann, Bryan Wu, Magnus Damm
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 10/10] leds: renesas: fix error handling
2012-08-08 21:27 ` [PATCH 10/10] leds: renesas: fix error handling Arnd Bergmann
@ 2012-08-09 6:15 ` Bryan Wu
2012-08-09 7:34 ` Arnd Bergmann
0 siblings, 1 reply; 25+ messages in thread
From: Bryan Wu @ 2012-08-09 6:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm, linux-kernel, Magnus Damm
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 10/10] leds: renesas: fix error handling
2012-08-09 6:15 ` Bryan Wu
@ 2012-08-09 7:34 ` Arnd Bergmann
0 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2012-08-09 7:34 UTC (permalink / raw)
To: Bryan Wu; +Cc: linux-arm-kernel, arm, linux-kernel, Magnus Damm
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
^ permalink raw reply [flat|nested] 25+ messages in thread