Generic ARM fixes for randconfig
Subsystems (6)
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 atgit://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
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
@@ -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
Re: [PATCH 01/11] ARM: export rtc_lock for nvram driver
Quoted 17 lines · Arnd Bergmann
The
rtc_lockis 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.Signed-off-by Arnd Bergmann <[email protected]>--- arch/arm/kernel/time.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-)arch/arm/kernel/time.c +0
-0@@ -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?
PATCH 2/11 ARM: SMP depends on MMU
In reply to Arnd BergmannThe 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
@@ -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
PATCH 3/11 ARM: always use ARM_UNWIND for thumb2 kernels
In reply to Arnd BergmannThumb2 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
@@ -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
@@ -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
PATCH 4/11 ARM: allow building alignment.c without PROC_FS
In reply to Arnd BergmannThe 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
@@ -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
PATCH 5/11 ARM: vfp: use -mfloat-abi=soft to build vfp
In reply to Arnd BergmannDistros 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
@@ -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
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 VFPAdding -mfloat-abi=soft to the gcc command line fixes this.
Signed-off-by Arnd Bergmann <[email protected]>--- arch/arm/vfp/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/vfp/Makefile +0
-0
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
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 VFPAdding -mfloat-abi=soft to the gcc command line fixes this.
Signed-off-by Arnd Bergmann<[email protected]>--- arch/arm/vfp/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/vfp/Makefile +0
-0@@ -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:
Reviewed-by Dave Martin<[email protected]>Cheers
---Dave_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 6/11 ARM: pm: let platforms select cpu_suspend support
In reply to Arnd BergmannSupport 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 7/11 ARM: limit CONFIG_HAVE_IDE to platforms that do
In reply to Arnd BergmannSupport 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
@@ -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
@@ -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
PATCH 8/11 ARM: add io{read,write}{16,32}be functions
In reply to Arnd BergmannThese 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
@@ -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
PATCH 9/11 ARM: pci: always export pcibios_bus_to_resource
In reply to Arnd BergmannSome 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
@@ -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
PATCH 10/11 ARM: OC_ETM should not select ARM_AMBA
In reply to Arnd BergmannThe 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
@@ -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
PATCH 11/11 ARM: common/vic: use proper __iomem annotations
In reply to Arnd BergmannIn 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
@@ -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
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.Signed-off-by Arnd Bergmann <[email protected]>--- arch/arm/common/vic.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/common/vic.c +0
-0
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
[PATCH 12/11] ARM: include linux/highmem.h in uaccess functions
In reply to Arnd BergmannWhen 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
@@ -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>
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 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
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.