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 <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: Nicolas Pitre <[email protected]>
Cc: Russell King <[email protected]>
Cc: Dave Martin <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Neil Brown <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Andrey Porodko <[email protected]>
Cc: Russell King <[email protected]>
Cc: Kukjin Kim <[email protected]>
Cc: Ben Dooks <[email protected]>
Cc: Russell King <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Magnus Damm <[email protected]>
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 <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Magnus Damm <[email protected]>
--- 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
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 <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Andrey Porodko <[email protected]>
---
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
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 <[email protected]>
Cc: Russell King <[email protected]>
---
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
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 <[email protected]>
Cc: Russell King <[email protected]>
---
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
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 <[email protected]>
Cc: Kukjin Kim <[email protected]>
Cc: Ben Dooks <[email protected]>
---
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 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 <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: Nicolas Pitre <[email protected]>
---
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
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 <[email protected]>
Cc: Russell King <[email protected]>
Cc: Dave Martin <[email protected]>
---
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
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 <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Russell King <[email protected]>
---
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
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 <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Neil Brown <[email protected]>
---
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
__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 <[email protected]>
---
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
On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Bryan Wu <[email protected]>
> Cc: Magnus Damm <[email protected]>
>
> --- 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 <[email protected]>
Kernel Developer +86.186-168-78255 Mobile
Canonical Ltd. http://www.canonical.com
Ubuntu - Linux for human beings | http://www.ubuntu.com
On Thursday 09 August 2012, Bryan Wu wrote:
>
> On Thu, Aug 9, 2012 at 5:27 AM, Arnd Bergmann <[email protected]> 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
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 <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Andrey Porodko <[email protected]>
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);
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 <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> Cc: Sekhar Nori <[email protected]>
> Cc: Andrey Porodko <[email protected]>
Acked-by: Sekhar Nori <[email protected]>
Thanks,
Sekhar
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 <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Dave Martin <[email protected]>
> ---
> 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
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.
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
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 <[email protected]>
> Cc: Kukjin Kim <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
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 <[email protected]>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Cc: Ben Dooks <[email protected]>
> ---
> 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
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
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
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 <[email protected]>
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 <[email protected]>
Cc: Russell King <[email protected]>
Cc: Dave Martin <[email protected]>
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__
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.
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 <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Michael Walle <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> ---
> 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 <[email protected]>
Andrew