Skip to contentSkip to conversation

Generic ARM fixes for randconfig

PATCH In review Arnd Bergmann 5 participants 20 messages Oct 1, 2011 – Oct 5, 2011

Subsystems (6)
lore
Share & tools
lore
#0 lore raw

cover Generic ARM fixes for randconfig

Hi Russell,

This is a set of patches that I've been sitting on for a while without ever getting them ready for inclusion. Out of the total ~150 patches I have to make 'make randconfig' work for a number of ARM platforms, these are the ones that mostly for common code within the ARM architecture.

I've now started going through the whole set and split them up by topic so I can reduce the number of patches that are required.

Please pull these into your tree, or alternatively cherry-pick the ones that you are happy with if you disagree with some of them.

This branch is available from

git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/arm

For reference, I have another branch "for-next+randconfig" that contains my entire set of patches merged with the arm-soc for-next branch, and the individual branches are available at
git://git.linaro.org/people/arnd/linux.git

Arnd Bergmann (11):
ARM: export rtc_lock for nvram driver
ARM: SMP depends on MMU
ARM: always use ARM_UNWIND for thumb2 kernels
ARM: allow building alignment.c without PROC_FS
ARM: vfp: use -mfloat-abi=soft to build vfp
ARM: pm: let platforms select cpu_suspend support
ARM: limit CONFIG_HAVE_IDE to platforms that do
ARM: add io{read,write}{16,32}be functions
ARM: pci: always export pcibios_bus_to_resource
ARM: OC_ETM should not select ARM_AMBA
ARM: common/vic: use proper __iomem annotations

 arch/arm/Kconfig              |   12 +++++++++++-
 arch/arm/Kconfig.debug        |    2 +-
 arch/arm/common/vic.c         |    3 ++-
 arch/arm/include/asm/io.h     |    6 ++++++
 arch/arm/kernel/Makefile      |    2 +-
 arch/arm/kernel/bios32.c      |    9 ++++-----
 arch/arm/kernel/time.c        |    6 ++----
 arch/arm/mach-exynos4/Kconfig |    1 +
 arch/arm/mach-omap2/Kconfig   |    2 ++
 arch/arm/mm/alignment.c       |   20 ++++++++++----------
 arch/arm/mm/proc-v7.S         |    2 +-
 arch/arm/plat-omap/Kconfig    |    1 +
 arch/arm/vfp/Makefile         |    2 +-
 lib/Kconfig.debug             |    4 ++--
 14 files changed, 45 insertions(+), 27 deletions(-)
Signature · 1 line
1.7.5.4
#1 lore raw

PATCH 1/11 ARM: export rtc_lock for nvram driver

The rtc_lock is used by both the nvram and rtc drivers, so we need to export it if at least one of the two is built, not just for the rtc driver.

---
 arch/arm/kernel/time.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)
arch/arm/kernel/time.c +2 -4
index cb634c3..5a54b95 100644
@@ -39,13 +39,11 @@
  */
 static struct sys_timer *system_timer;
 
-#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE)
+#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
+    defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
 /* this needs a better home */
 DEFINE_SPINLOCK(rtc_lock);
-
-#ifdef CONFIG_RTC_DRV_CMOS_MODULE
 EXPORT_SYMBOL(rtc_lock);
-#endif
 #endif	/* pc-style 'CMOS' RTC support */
 
 /* change this if you have some constant time drift */
Signature · 1 line
1.7.5.4
#2 lore raw

Re: [PATCH 01/11] ARM: export rtc_lock for nvram driver

Quoted 17 lines · Arnd Bergmann

The rtc_lock is used by both the nvram and rtc drivers, so we need to export it if at least one of the two is built, not just for the rtc driver.

---
 arch/arm/kernel/time.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)
arch/arm/kernel/time.c +0 -0
index cb634c3..5a54b95 100644
@@ -39,13 +39,11 @@
  */
 static struct sys_timer *system_timer;
 

arch/arm/kernel/time.c line 47

Quoted 10 lines
arch/arm/kernel/time.c +2 -4
-#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE)
+#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
+    defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
 /* this needs a better home */
 DEFINE_SPINLOCK(rtc_lock);
-
-#ifdef CONFIG_RTC_DRV_CMOS_MODULE
 EXPORT_SYMBOL(rtc_lock);
-#endif
 #endif	/* pc-style 'CMOS' RTC support */

Some architectures always define this lock and export it irrespective of the configuration. Others define it, but never export it. Some define it but only export it for 32-bit builds.

One thing springs to mind here - why isn't there a symbol to enable the presence of rtc_lock in the kernel? A second related point is why is this in arch code?

#3 lore raw

PATCH 2/11 ARM: SMP depends on MMU

In reply to Arnd Bergmann

The SMP implementation on ARM heavily depends on MMU-only code. As long as nobody is interested in fixing this, let's disable the SMP option when building for nommu.

---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/Kconfig +1 -0
index 5ebc5d9..4e1eee0c 100644
@@ -1349,6 +1349,7 @@ config SMP
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
 		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+	depends on MMU
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help
Signature · 1 line
1.7.5.4
#4 lore raw

PATCH 3/11 ARM: always use ARM_UNWIND for thumb2 kernels

In reply to Arnd Bergmann

Thumb2 kernels cannot be built with frame pointers, but can use the ARM_UNWIND feature for unwinding instead. This makes sure that all features that rely on unwinding includeing CONFIG_LATENCYTOP and FAULT_INJECTION_STACKTRACE_FILTER do not enable frame pointers when the unwinder is already selected, and we always build with the unwinder when we want a thumb2 kernel, to make sure we do not get the frame pointers instead.

A different option would be to redefine the CONFIG_FRAME_POINTERS option on ARM to mean builing with either frame pointers or the unwinder, and then select which one to use based on the CPU architecture or another user option. That would still allow building thumb2 kernels without the unwinder but would also be more confusing.

---
 arch/arm/Kconfig  |    1 +
 lib/Kconfig.debug |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
arch/arm/Kconfig +1 -0
index 4e1eee0c..497af51 100644
@@ -1457,6 +1457,7 @@ config THUMB2_KERNEL
 	depends on CPU_V7 && !CPU_V6 && !CPU_V6K && EXPERIMENTAL
 	select AEABI
 	select ARM_ASM_UNIFIED
+	select ARM_UNWIND
 	help
 	  By enabling this option, the kernel will be compiled in
 	  Thumb-2 mode. A compiler/assembler that understand the unified
lib/Kconfig.debug +2 -2
index c0cb9c4..103c171 100644
@@ -1081,7 +1081,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER
 	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
 	depends on !X86_64
 	select STACKTRACE
-	select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE
+	select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
 	help
 	  Provide stacktrace filter for fault-injection capabilities
 
@@ -1091,7 +1091,7 @@ config LATENCYTOP
 	depends on DEBUG_KERNEL
 	depends on STACKTRACE_SUPPORT
 	depends on PROC_FS
-	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE
+	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
 	select KALLSYMS
 	select KALLSYMS_ALL
 	select STACKTRACE
Signature · 1 line
1.7.5.4
#5 lore raw

PATCH 4/11 ARM: allow building alignment.c without PROC_FS

In reply to Arnd Bergmann

The two functions cpu_is_v6_unaligned and safe_usermode are only defined when CONFIG_PROC_FS is enabled, but are used outside of the #ifdef.

---
 arch/arm/mm/alignment.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)
arch/arm/mm/alignment.c +10 -10
index cfbcf8b..c335c76 100644
@@ -86,16 +86,6 @@ core_param(alignment, ai_usermode, int, 0600);
 #define UM_FIXUP	(1 << 1)
 #define UM_SIGNAL	(1 << 2)
 
-#ifdef CONFIG_PROC_FS
-static const char *usermode_action[] = {
-	"ignored",
-	"warn",
-	"fixup",
-	"fixup+warn",
-	"signal",
-	"signal+warn"
-};
-
 /* Return true if and only if the ARMv6 unaligned access model is in use. */
 static bool cpu_is_v6_unaligned(void)
 {
@@ -123,6 +113,16 @@ static int safe_usermode(int new_usermode, bool warn)
 	return new_usermode;
 }
 
+#ifdef CONFIG_PROC_FS
+static const char *usermode_action[] = {
+	"ignored",
+	"warn",
+	"fixup",
+	"fixup+warn",
+	"signal",
+	"signal+warn"
+};
+
 static int alignment_proc_show(struct seq_file *m, void *v)
 {
 	seq_printf(m, "User:\t\t%lu\n", ai_user);
Signature · 1 line
1.7.5.4
#6 lore raw

PATCH 5/11 ARM: vfp: use -mfloat-abi=soft to build vfp

In reply to Arnd Bergmann

Distros are starting to ship with toolchains defaulting to hardfloat. Using such a compiler to build the kernel fails in the VFP directory with

arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

Adding -mfloat-abi=soft to the gcc command line fixes this.

---
 arch/arm/vfp/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/vfp/Makefile +1 -1
index 6de73aa..a81404c 100644
@@ -7,7 +7,7 @@
 # ccflags-y := -DDEBUG
 # asflags-y := -DDEBUG
 
-KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp)
+KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)
 LDFLAGS		+=--no-warn-mismatch
 
 obj-y			+= vfp.o
Signature · 1 line
1.7.5.4
Reviewed-by on v1 5/11
#7 lore raw

Re: [PATCH 05/11] ARM: vfp: use -mfloat-abi=soft to build vfp

Quoted 18 lines · Arnd Bergmann

Distros are starting to ship with toolchains defaulting to hardfloat. Using such a compiler to build the kernel fails in the VFP directory with

arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

Adding -mfloat-abi=soft to the gcc command line fixes this.

---
 arch/arm/vfp/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/vfp/Makefile +0 -0
index 6de73aa..a81404c 100644

arch/arm/vfp/Makefile line 10

Quoted 5 lines
arch/arm/vfp/Makefile +1 -1
@@ -7,7 +7,7 @@
 # ccflags-y := -DDEBUG
 # asflags-y := -DDEBUG
 
-KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp)
+KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)

Although -mfpu=softvfp+vfp and -mfloat-abi=soft look mutually contradictory, this seems to have the correct effect, i.e. the assembler allows floating-point instructions but marks the resulting object as using the soft-float calling conventions.

The binutils documentation also seems to confirm that that's what should happen.

I don't see another combination of options for getting this effect.

So, if you like:

Cheers
---Dave

#8 lore raw

PATCH 5/11 ARM: vfp: use -mfloat-abi=soft to build vfp

Quoted 22 lines · Dave Martin
Quoted 21 lines · Arnd Bergmann

Distros are starting to ship with toolchains defaulting to hardfloat. Using such a compiler to build the kernel fails in the VFP directory with

arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

Adding -mfloat-abi=soft to the gcc command line fixes this.

---
  arch/arm/vfp/Makefile |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/vfp/Makefile +0 -0
index 6de73aa..a81404c 100644
@@ -7,7 +7,7 @@
  # ccflags-y := -DDEBUG
  # asflags-y := -DDEBUG
 
Quoted 7 lines

arch/arm/vfp/Makefile line 10

Quoted 2 lines
arch/arm/vfp/Makefile +1 -1
-KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp)
+KBUILD_AFLAGS	:=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)

Although -mfpu=softvfp+vfp and -mfloat-abi=soft look mutually contradictory, this seems to have the correct effect, i.e. the assembler allows floating-point instructions but marks the resulting object as using the soft-float calling conventions.

I was wondering if this could also be achieved with -mfloat-abi=softfp this will also add Tag_FP_arch: VFPv2 into .attributes section and -Wa,-mfpu=softvfp+vfp may not be needed.

Quoted 18 lines

The binutils documentation also seems to confirm that that's what should happen.

I don't see another combination of options for getting this effect.

So, if you like:

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#9 lore raw

PATCH 6/11 ARM: pm: let platforms select cpu_suspend support

In reply to Arnd Bergmann

Support for the cpu_suspend functions is only built-in when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4 and pxa always call cpu_suspend when CONFIG_PM is enabled.

---
 arch/arm/Kconfig              |    4 ++++
 arch/arm/kernel/Makefile      |    2 +-
 arch/arm/mach-exynos4/Kconfig |    1 +
 arch/arm/mach-omap2/Kconfig   |    2 ++
 arch/arm/mm/proc-v7.S         |    2 +-
 5 files changed, 9 insertions(+), 2 deletions(-)
arch/arm/Kconfig +4 -0
index 497af51..3445f50 100644
@@ -631,6 +631,7 @@ config ARCH_PXA
 	select SPARSE_IRQ
 	select AUTO_ZRELADDR
 	select MULTI_IRQ_HANDLER
+	select ARM_CPU_SUSPEND if PM
 	help
 	  Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
 
@@ -2077,6 +2078,9 @@ config ARCH_SUSPEND_POSSIBLE
 		CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE
 	def_bool y
 
+config ARM_CPU_SUSPEND
+	def_bool PM_SLEEP
+
 endmenu
 
 source "net/Kconfig"
arch/arm/kernel/Makefile +1 -1
index f7887dc..4ce3303 100644
@@ -29,7 +29,7 @@ obj-$(CONFIG_MODULES)		+= armksyms.o module.o
 obj-$(CONFIG_ARTHUR)		+= arthur.o
 obj-$(CONFIG_ISA_DMA)		+= dma-isa.o
 obj-$(CONFIG_PCI)		+= bios32.o isa.o
-obj-$(CONFIG_PM_SLEEP)		+= sleep.o
+obj-$(CONFIG_ARM_CPU_SUSPEND)	+= sleep.o
 obj-$(CONFIG_HAVE_SCHED_CLOCK)	+= sched_clock.o
 obj-$(CONFIG_SMP)		+= smp.o smp_tlb.o
 obj-$(CONFIG_HAVE_ARM_SCU)	+= smp_scu.o
arch/arm/mach-exynos4/Kconfig +1 -0
index 0c77ab9..fc1f92d 100644
@@ -12,6 +12,7 @@ if ARCH_EXYNOS4
 config CPU_EXYNOS4210
 	bool
 	select S3C_PL330_DMA
+	select ARM_CPU_SUSPEND if PM
 	help
 	  Enable EXYNOS4210 CPU support
 
arch/arm/mach-omap2/Kconfig +2 -0
index 57b66d5..89bfb49 100644
@@ -36,6 +36,7 @@ config ARCH_OMAP3
 	select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
+	select ARM_CPU_SUSPEND if PM
 
 config ARCH_OMAP4
 	bool "TI OMAP4"
@@ -50,6 +51,7 @@ config ARCH_OMAP4
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI
+	select ARM_CPU_SUSPEND if PM
 
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
arch/arm/mm/proc-v7.S +1 -1
index a30e785..591accd 100644
@@ -217,7 +217,7 @@ ENDPROC(cpu_v7_set_pte_ext)
 /* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
 .globl	cpu_v7_suspend_size
 .equ	cpu_v7_suspend_size, 4 * 9
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
 ENTRY(cpu_v7_do_suspend)
 	stmfd	sp!, {r4 - r11, lr}
 	mrc	p15, 0, r4, c13, c0, 0	@ FCSE/PID
Signature · 1 line
1.7.5.4
#10 lore raw

PATCH 7/11 ARM: limit CONFIG_HAVE_IDE to platforms that do

In reply to Arnd Bergmann

Support for IDE drivers should not be automatic, since most platforms cannot actually support any IDE low-level drivers. This partly reverts 2064c946e "ARM: always select HAVE_IDE" to set this symbol only when either a PC-style bus (PCI, ISA, PCMCIA) is enabled or a platform is used that is known to have an existing driver in drivers/ide.

New platforms should not need this option and just use CONFIG_ATA with drivers/ata/.

---
 arch/arm/Kconfig           |    6 +++++-
 arch/arm/plat-omap/Kconfig |    1 +
 2 files changed, 6 insertions(+), 1 deletions(-)
arch/arm/Kconfig +5 -1
index 3445f50..ed69fcd 100644
@@ -3,7 +3,7 @@ config ARM
 	default y
 	select HAVE_AOUT
 	select HAVE_DMA_API_DEBUG
-	select HAVE_IDE
+	select HAVE_IDE if PCI || ISA || PCMCIA
 	select HAVE_MEMBLOCK
 	select RTC_LIB
 	select SYS_SUPPORTS_APM_EMULATION
@@ -385,6 +385,7 @@ config ARCH_FOOTBRIDGE
 	select CPU_SA110
 	select FOOTBRIDGE
 	select GENERIC_CLOCKEVENTS
+	select HAVE_IDE
 	help
 	  Support for systems based on the DC21285 companion chip
 	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
@@ -632,6 +633,7 @@ config ARCH_PXA
 	select AUTO_ZRELADDR
 	select MULTI_IRQ_HANDLER
 	select ARM_CPU_SUSPEND if PM
+	select HAVE_IDE
 	help
 	  Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
 
@@ -672,6 +674,7 @@ config ARCH_RPC
 	select NO_IOPORT
 	select ARCH_SPARSEMEM_ENABLE
 	select ARCH_USES_GETTIMEOFFSET
+	select HAVE_IDE
 	help
 	  On the Acorn Risc-PC, Linux can support the internal IDE disk and
 	  CD-ROM interface, serial and parallel port, and the floppy drive.
@@ -690,6 +693,7 @@ config ARCH_SA1100
 	select HAVE_SCHED_CLOCK
 	select TICK_ONESHOT
 	select ARCH_REQUIRE_GPIOLIB
+	select HAVE_IDE
 	help
 	  Support for StrongARM 11x0 based boards.
 
arch/arm/plat-omap/Kconfig +1 -0
index bb8f4a6..5b605a9 100644
@@ -14,6 +14,7 @@ config ARCH_OMAP1
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
 	select GENERIC_IRQ_CHIP
+	select HAVE_IDE
 	help
 	  "Systems based on omap7xx, omap15xx or omap16xx"
 
Signature · 1 line
1.7.5.4
#11 lore raw

PATCH 8/11 ARM: add io{read,write}{16,32}be functions

In reply to Arnd Bergmann

These functions are used in some PCI drivers with big-endian MMIO space, and they are trivial to add here.

---
 arch/arm/include/asm/io.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/include/asm/io.h +6 -0
index d66605d..bad7bfb 100644
@@ -260,10 +260,16 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
 #define ioread16(p)	({ unsigned int __v = le16_to_cpu((__force __le16)__raw_readw(p)); __iormb(); __v; })
 #define ioread32(p)	({ unsigned int __v = le32_to_cpu((__force __le32)__raw_readl(p)); __iormb(); __v; })
 
+#define ioread16be(p)	({ unsigned int __v = be16_to_cpu((__force __be16)__raw_readw(p)); __iormb(); __v; })
+#define ioread32be(p)	({ unsigned int __v = be32_to_cpu((__force __be32)__raw_readl(p)); __iormb(); __v; })
+
 #define iowrite8(v,p)	({ __iowmb(); (void)__raw_writeb(v, p); })
 #define iowrite16(v,p)	({ __iowmb(); (void)__raw_writew((__force __u16)cpu_to_le16(v), p); })
 #define iowrite32(v,p)	({ __iowmb(); (void)__raw_writel((__force __u32)cpu_to_le32(v), p); })
 
+#define iowrite16be(v,p) ({ __iowmb(); (void)__raw_writew((__force __u16)cpu_to_be16(v), p); })
+#define iowrite32be(v,p) ({ __iowmb(); (void)__raw_writel((__force __u32)cpu_to_be32(v), p); })
+
 #define ioread8_rep(p,d,c)	__raw_readsb(p,d,c)
 #define ioread16_rep(p,d,c)	__raw_readsw(p,d,c)
 #define ioread32_rep(p,d,c)	__raw_readsl(p,d,c)
Signature · 1 line
1.7.5.4
#12 lore raw

PATCH 9/11 ARM: pci: always export pcibios_bus_to_resource

In reply to Arnd Bergmann

Some PCI drivers call pcibios_bus_to_resource directly, but it is only exported when CONFIG_HOTPLUG is set, because it was initially mean for pccard support.

Moving the export out of the #ifdef lets us avoid these build errors:

ERROR: "pcibios_bus_to_resource" [drivers/video/vt8623fb.ko] undefined!
ERROR: "pcibios_bus_to_resource" [drivers/video/arkfb.ko] undefined!
ERROR: "pcibios_bus_to_resource" [drivers/video/s3fb.ko] undefined!

---
 arch/arm/kernel/bios32.c |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)
arch/arm/kernel/bios32.c +4 -5
index d6df359..c0d9203 100644
@@ -412,6 +412,9 @@ void pcibios_fixup_bus(struct pci_bus *bus)
 	printk(KERN_INFO "PCI: bus%d: Fast back to back transfers %sabled\n",
 		bus->number, (features & PCI_COMMAND_FAST_BACK) ? "en" : "dis");
 }
+#ifdef CONFIG_HOTPLUG
+EXPORT_SYMBOL(pcibios_fixup_bus);
+#endif
 
 /*
  * Convert from Linux-centric to bus-centric addresses for bridge devices.
@@ -431,6 +434,7 @@ pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
 	region->start = res->start - offset;
 	region->end   = res->end - offset;
 }
+EXPORT_SYMBOL(pcibios_resource_to_bus);
 
 void __devinit
 pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
@@ -447,12 +451,7 @@ pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
 	res->start = region->start + offset;
 	res->end   = region->end + offset;
 }
-
-#ifdef CONFIG_HOTPLUG
-EXPORT_SYMBOL(pcibios_fixup_bus);
-EXPORT_SYMBOL(pcibios_resource_to_bus);
 EXPORT_SYMBOL(pcibios_bus_to_resource);
-#endif
 
 /*
  * Swizzle the device pin each time we cross a bridge.
Signature · 1 line
1.7.5.4
#13 lore raw

PATCH 10/11 ARM: OC_ETM should not select ARM_AMBA

In reply to Arnd Bergmann

The CONFIG_ARM_AMBA symbol is selected by the platforms that support AMBA, and the other platforms (e.g. orion) might not be able to build that code at all when they do not support the clk API.

Instead, make sure that OC_ETM is only built on platforms that do support the amba subsystem already.

---
 arch/arm/Kconfig.debug |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/Kconfig.debug +1 -1
index 81cbe40..0c7a4f5 100644
@@ -94,7 +94,7 @@ config DEBUG_ICEDCC
 
 config OC_ETM
 	bool "On-chip ETM and ETB"
-	select ARM_AMBA
+	depends on ARM_AMBA
 	help
 	  Enables the on-chip embedded trace macrocell and embedded trace
 	  buffer driver that will allow you to collect traces of the
Signature · 1 line
1.7.5.4
#14 lore raw

PATCH 11/11 ARM: common/vic: use proper __iomem annotations

In reply to Arnd Bergmann

In vic_init, we pass addr into readl, so it needs to be a pointer, not a u32 address.

---
 arch/arm/common/vic.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/common/vic.c +2 -1
index 7aa4262..adccf6d 100644
@@ -347,7 +347,8 @@ void __init vic_init(void __iomem *base, unsigned int irq_start,
 
 	/* Identify which VIC cell this one is, by reading the ID */
 	for (i = 0; i < 4; i++) {
-		u32 addr = ((u32)base & PAGE_MASK) + 0xfe0 + (i * 4);
+		void __iomem *addr;
+		addr = (void __iomem *)((u32)base & PAGE_MASK) + 0xfe0 + (i * 4);
 		cellid |= (readl(addr) & 0xff) << (8 * i);
 	}
 	vendor = (cellid >> 12) & 0xff;
Signature · 1 line
1.7.5.4
#15 lore raw

RE: [PATCH 11/11] ARM: common/vic: use proper __iomem annotations

Quoted 14 lines · Arnd Bergmann

In vic_init, we pass addr into readl, so it needs to be a pointer, not a u32 address.

---
 arch/arm/common/vic.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/common/vic.c +0 -0
index 7aa4262..adccf6d 100644

arch/arm/common/vic.c void __init vic_init(void __iomem *base, unsigned int irq_start, · line 354

Quoted 9 lines
arch/arm/common/vic.c +2 -1
@@ -347,7 +347,8 @@ void __init vic_init(void __iomem *base, unsigned int irq_start,
 
 	/* Identify which VIC cell this one is, by reading the ID */
 	for (i = 0; i < 4; i++) {
-		u32 addr = ((u32)base & PAGE_MASK) + 0xfe0 + (i * 4);
+		void __iomem *addr;
+		addr = (void __iomem *)((u32)base & PAGE_MASK) + 0xfe0 + (i * 4);
 		cellid |= (readl(addr) & 0xff) << (8 * i);
 	}
 	vendor = (cellid >> 12) & 0xff;

Arnd,

This has already been fixed by Patch 7028/2 in Russell's patch tracking system.

Regards,
Hartley

#16 lore raw

[PATCH 12/11] ARM: include linux/highmem.h in uaccess functions

In reply to Arnd Bergmann

When highpte support is enabled, this is required to build the kernel.

---
I was missing this patch at first, but now found it in the omap branch.

arch/arm/lib/uaccess_with_memcpy.c +1 -0
index 8b9b136..025f742 100644
@@ -17,6 +17,7 @@
 #include <linux/sched.h>
 #include <linux/hardirq.h> /* for in_atomic() */
 #include <linux/gfp.h>
+#include <linux/highmem.h>
 #include <asm/current.h>
 #include <asm/page.h>
 
#17 lore raw
In reply to Arnd Bergmann
Quoted 2 lines · Arnd Bergmann

Please pull these into your tree, or alternatively cherry-pick the ones that you are happy with if you disagree with some of them.

I think I'll merge all but the first from this - I think the first should be part of a cross-arch cleanup.

#18 lore raw
Quoted 6 lines · On Sunday 02 October 2011 16:36:46 Russell King - ARM Linux wrote:
Quoted 2 lines · Arnd Bergmann

Please pull these into your tree, or alternatively cherry-pick the ones that you are happy with if you disagree with some of them.

I think I'll merge all but the first from this - I think the first should be part of a cross-arch cleanup.

Ok, thanks!

I'll put the remaining patch into my 'randconfig/hacks' branch, which already contains a number of other things that need a proper fix but for which there is an easier circumvention.

Once all the low-hanging fruit are dealt with, I'll get back to that branch.

Arnd

#19 lore raw
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Sunday 02 October 2011 16:36:46 Russell King - ARM Linux wrote:
Quoted 2 lines · Arnd Bergmann

Please pull these into your tree, or alternatively cherry-pick the ones that you are happy with if you disagree with some of them.

I think I'll merge all but the first from this - I think the first should be part of a cross-arch cleanup.

Quoted 8 lines

Ok, thanks!

I'll put the remaining patch into my 'randconfig/hacks' branch, which already contains a number of other things that need a proper fix but for which there is an easier circumvention.

Once all the low-hanging fruit are dealt with, I'll get back to that branch.

Second thought, I'll take the lot because it fixes build problems, and the comment on patch 1 can be addressed later.