linux.git/arch/arm/kernel, branch v2.6.37 Linux kernel source tree ARM: 6540/1: Stop irqsoff trace on return to user 2010-12-24T09:37:59+00:00 Todd Android Poynor toddpoynor@google.com 2010-12-23T00:52:44+00:00 d13e5edd7284bedcf5952e1b6490e39ad843cb91 If the irqsoff tracer is in use, stop tracing the interrupt disable interval when returning to userspace. Tracing userspace execution time as interrupts disabled time is not helpful for kernel performance analysis purposes. Only do so if the irqsoff tracer is enabled, to avoid overhead for lockdep, which doesn't care. Signed-off-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
If the irqsoff tracer is in use, stop tracing the interrupt disable
interval when returning to userspace.  Tracing userspace execution time
as interrupts disabled time is not helpful for kernel performance
analysis purposes.  Only do so if the irqsoff tracer is enabled, to
avoid overhead for lockdep, which doesn't care.

Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: smp: avoid incrementing mm_users on CPU startup 2010-12-18T13:57:00+00:00 Russell King rmk+kernel@arm.linux.org.uk 2010-12-18T13:57:00+00:00 1ae1b5f053cf36bd0f913e83f3b136fec8152d4d We should not be incrementing mm_users when we startup a secondary CPU - doing so results in mm_users incrementing by one each time we hotplug a CPU, which will eventually wrap, and will cause problems. Other architectures such as x86 do not increment mm_users, but only mm_count, so we follow that pattern. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
We should not be incrementing mm_users when we startup a secondary
CPU - doing so results in mm_users incrementing by one each time we
hotplug a CPU, which will eventually wrap, and will cause problems.

Other architectures such as x86 do not increment mm_users, but only
mm_count, so we follow that pattern.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpers 2010-12-04T11:01:12+00:00 Dave Martin dave.martin@linaro.org 2010-12-01T17:12:43+00:00 55afd264cdd5d5848753e90884ed596e11bce0ff The existing code invokes the syscall with rubbish in r7, due to what looks like an incorrect literal load idiom. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
The existing code invokes the syscall with rubbish in r7,
due to what looks like an incorrect literal load idiom.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6504/1: Thumb-2: Fix long-distance conditional branches in head.S for Thumb-2. 2010-11-30T13:44:26+00:00 Dave Martin dave.martin@linaro.org 2010-11-29T18:43:28+00:00 a75e5248c51af1eaeed936be6bd3497b93f09685 The 32-bit conditional branches in Thumb-2 have a shorter range (+/-512K) than their ARM counterparts (+/-32MB). The linker does not currently generate trampolines to extend the range of these Thumb-2 conditional branches, resulting in link errors when vmlinux is sufficiently large, e.g.: head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19 This patch forces the longer-range, unconditional branch encoding by use of an explicit IT instruction. The resulting branches are triggered on the same conditions as before. Signed-off-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
The 32-bit conditional branches in Thumb-2 have a shorter range
(+/-512K) than their ARM counterparts (+/-32MB).  The linker does
not currently generate trampolines to extend the range of these
Thumb-2 conditional branches, resulting in link errors when vmlinux
is sufficiently large, e.g.:

head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19

This patch forces the longer-range, unconditional branch encoding
by use of an explicit IT instruction.  The resulting branches are
triggered on the same conditions as before.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6500/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in kernel/head.S 2010-11-30T13:44:24+00:00 Dave Martin dave.martin@linaro.org 2010-11-29T18:43:24+00:00 4f79a5dd7c3e316e2230dc0ee665c40a39023a81 Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6497/1: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL 2010-11-30T13:44:23+00:00 Dave Martin dave.martin@linaro.org 2010-11-29T18:43:21+00:00 bc8b57f08c53344d13e3b5e644c56c0355899b47 Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: arch/arm/kernel/traps.c: Convert sprintf_symbol to %pS 2010-11-07T17:58:40+00:00 Joe Perches joe@perches.com 2010-11-05T23:12:34+00:00 69448c2a4d23e5883cbca21a173e3eb89f095746 Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: arch/arm/kernel/hw_breakpoint.c: Convert WARN_ON to WARN 2010-11-07T17:58:39+00:00 Joe Perches joe@perches.com 2010-10-30T21:21:24+00:00 235584b6f3b71bc1381be13a963a16f7107650cf Message isn't printed by WARN_ON. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Message isn't printed by WARN_ON.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6469/1: perf-events: squash compiler warning 2010-11-07T16:12:38+00:00 Will Deacon will.deacon@arm.com 2010-11-04T17:23:50+00:00 c3b291d98878a5f25fee56255bcfa420e85dff59 armv7_pmnc_counter_has_overflowed can return uninitialised data if an invalid counter is specified. This patch fixes the code to return 0 in this case, which squashes the compiler warning from GCC 4.5. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
armv7_pmnc_counter_has_overflowed can return uninitialised data
if an invalid counter is specified.

This patch fixes the code to return 0 in this case, which squashes
the compiler warning from GCC 4.5.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6468/1: backtrace: fix calculation of thread stack base 2010-11-07T16:12:37+00:00 Will Deacon will.deacon@arm.com 2010-11-04T17:22:51+00:00 d33aadbf8e9ba0b844c2a4a03723969c913ab03a When unwinding stack frames we must take care not to unwind areas of memory that lie outside of the known extent of the stack. This patch fixes an incorrect calculation of the stack base where THREAD_SIZE is added to the stack pointer after it has already been aligned to this value. Since the ALIGN macro performs this addition internally, we end up overshooting the base by 8k. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
When unwinding stack frames we must take care not to unwind
areas of memory that lie outside of the known extent of the stack.

This patch fixes an incorrect calculation of the stack base where
THREAD_SIZE is added to the stack pointer after it has already
been aligned to this value. Since the ALIGN macro performs this
addition internally, we end up overshooting the base by 8k.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>