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 <redacted>
Cc: Russell King <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <redacted>
Cc: Nicolas Pitre <redacted>
Cc: Russell King <redacted>
Cc: Dave Martin <redacted>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Dan Williams <redacted>
Cc: Neil Brown <redacted>
Cc: Kevin Hilman <redacted>
Cc: Sekhar Nori <redacted>
Cc: Andrey Porodko <redacted>
Cc: Russell King <redacted>
Cc: Kukjin Kim <redacted>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <redacted>
Cc: Bryan Wu <redacted>
Cc: Magnus Damm <redacted>
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 <redacted>
Cc: Neil Brown <redacted>
---
include/asm-generic/xor.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 <redacted>
Cc: Magnus Damm <redacted>
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 <redacted>
Cc: Sekhar Nori <redacted>
Cc: Andrey Porodko <redacted>
---
arch/arm/mach-davinci/board-neuros-osd2.c | 7 +++++++
1 file changed, 7 insertions(+)
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 <redacted>
---
arch/arm/mach-rpc/ecard.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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 <redacted>
---
arch/arm/Kconfig | 2 +-
arch/arm/Makefile | 1 -
arch/arm/mm/Kconfig | 12 ++----------
3 files changed, 3 insertions(+), 12 deletions(-)
@@ -70,7 +70,6 @@ endifarch-$(CONFIG_CPU_32v5):=-D__LINUX_ARM_ARCH__=5$(callcc-option,-march=armv5te,-march=armv4t)arch-$(CONFIG_CPU_32v4T):=-D__LINUX_ARM_ARCH__=4-march=armv4tarch-$(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
@@ -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.-configCPU_32v3-bool-selectTLS_REG_EMULifSMP||!MMU-selectNEEDS_SYSCALL_FOR_CMPXCHGifSMP-selectCPU_USE_DOMAINSifMMU-configCPU_32v4boolselectTLS_REG_EMULifSMP||!MMU
@@ -587,8 +580,7 @@ comment "Processor Features"configARM_LPAEbool"Support for the Large Physical Address Extension"-depends onMMU&&CPU_32v7&&!CPU_32v6&&!CPU_32v5&&\-!CPU_32v4&&!CPU_32v3+depends onMMU&&CPU_32v7&&!CPU_32v6&&!CPU_32v5&&!CPU_32v4helpSayYifyouhaveanARMv7processorsupportingtheLPAEpagetableformatandyouwouldliketoaccessmemorybeyondthe
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 <redacted>
Cc: Ben Dooks <ben-linux@fluff.org>
---
arch/arm/configs/tct_hammer_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -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
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 <redacted>
Cc: Nicolas Pitre <redacted>
---
arch/arm/mach-mv78xx0/addr-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 <redacted>
Cc: Dave Martin <redacted>
---
arch/arm/Makefile | 3 +++
1 file changed, 3 insertions(+)
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 <redacted>
Cc: Russell King <redacted>
---
drivers/char/ds1620.c | 8 ++++----
drivers/char/nwflash.c | 4 ++--
sound/oss/waveartist.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
__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(-)
On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann [off-list ref] 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
On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann [off-list ref] wrote:
quoted
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
From: Russell King - ARM Linux <hidden> Date: 2012-08-09 07:49:22
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.
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 <redacted>
Cc: Sekhar Nori <redacted>
Cc: Andrey Porodko <redacted>
From: Sekhar Nori <hidden> Date: 2012-08-09 18:24:49
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 <redacted>
Cc: Sekhar Nori <redacted>
Cc: Andrey Porodko <redacted>
From: Nicolas Pitre <hidden> Date: 2012-08-09 21:13:03
On Wed, 8 Aug 2012, Arnd Bergmann wrote:
quoted hunk
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 <redacted>
Cc: Dave Martin <redacted>
---
arch/arm/Makefile | 3 +++
1 file changed, 3 insertions(+)
From: Kukjin Kim <hidden> Date: 2012-08-10 06:07:43
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 <redacted>
Acked-by: Kukjin Kim <redacted>
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 [off-list ref], Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
@@ -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--
From: Dave Martin <hidden> Date: 2012-08-10 09:59:25
On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
quoted
On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
quoted
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
On Thursday 09 August 2012, Russell King - ARM Linux wrote:
On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
quoted
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
On Thu, Aug 09, 2012 at 05:22:30PM -0400, Nicolas Pitre wrote:
quoted
On Thu, 9 Aug 2012, Russell King - ARM Linux wrote:
quoted
On Thu, Aug 09, 2012 at 05:12:58PM -0400, Nicolas Pitre wrote:
quoted
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 <redacted>
Cc: Dave Martin <redacted>
@@ -21,8 +21,6 @@ endifOBJCOPYFLAGS:=-Obinary-R.comment-SGZFLAGS:=-9#KBUILD_CFLAGS +=-pipe-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:-KBUILD_CFLAGS+=$(callcc-option,-marm,)# Never generate .eh_frameKBUILD_CFLAGS+=$(callcc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endififeq ($(CONFIG_THUMB2_KERNEL),y)AFLAGS_AUTOIT:=$(callas-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)AFLAGS_NOWARN:=$(callas-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-callsendif+else+CFLAGS_ISA:=$(callcc-option,-marm,)+AFLAGS_ISA:=$(CFLAGS_ISA)endif# Need -Uarm for gcc < 3.x-KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_THUMB2)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm-KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_THUMB2)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-float+KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_ISA)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm+KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_ISA)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-floatCHECKFLAGS+=-D__arm__
From: Russell King - ARM Linux <hidden> Date: 2012-08-13 10:53:05
On Fri, Aug 10, 2012 at 11:03:58AM +0000, Arnd Bergmann wrote:
On Thursday 09 August 2012, Russell King - ARM Linux wrote:
quoted
On Wed, Aug 08, 2012 at 11:27:57PM +0200, Arnd Bergmann wrote:
quoted
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.
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-08-13 14:59:50
On Wed, Aug 08, 2012 at 11:27:51PM +0200, Arnd Bergmann wrote:
quoted hunk
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 <redacted>
Cc: Nicolas Pitre <redacted>
---
arch/arm/mach-mv78xx0/addr-map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)