kernel/git/stable/linux-stable.git/arch/arm/include, branch linux-2.6.34.y

ARM: 6489/1: thumb2: fix incorrect optimisation in usracc

2011-04-17T20:15:53+00:00

commit 1142b71d85894dcff1466dd6c871ea3c89e0352c upstream. Commit 8b592783 added a Thumb-2 variant of usracc which, when it is called with \rept=2, calls usraccoff once with an offset of 0 and secondly with a hard-coded offset of 4 in order to avoid incrementing the pointer again. If \inc != 4 then we will store the data to the wrong offset from \ptr. Luckily, the only caller that passes \rept=2 to this function is __clear_user so we haven't been actively corrupting user data. This patch fixes usracc to pass \inc instead of #4 to usraccoff when it is called a second time. Reported-by: Tony Thompson Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Paul Gortmaker

ARM: Tighten check for allowable CPSR values

2010-08-26T23:43:29+00:00

commit 41e2e8fd34fff909a0e40129f6ac4233ecfa67a9 upstream. Reviewed-by: Arve Hjønnevåg Acked-by: Dima Zavin Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID

2010-08-13T20:27:24+00:00

commit cdf357f1e13a08a11261edacb3083746f65c1ed9 upstream. On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Tested-by: Rob Clark Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 6212/1: atomic ops: add memory constraints to inline asm

2010-08-02T17:29:55+00:00

commit 398aa66827155ef52bab58bebd24597d90968929 upstream. Currently, the 32-bit and 64-bit atomic operations on ARM do not include memory constraints in the inline assembly blocks. In the case of barrier-less operations [for example, atomic_add], this means that the compiler may constant fold values which have actually been modified by a call to an atomic operation. This issue can be observed in the atomic64_test routine in /lib/atomic64_test.c: 00000000 : 0: e1a0c00d mov ip, sp 4: e92dd830 push {r4, r5, fp, ip, lr, pc} 8: e24cb004 sub fp, ip, #4 c: e24dd008 sub sp, sp, #8 10: e24b3014 sub r3, fp, #20 14: e30d000d movw r0, #53261 ; 0xd00d 18: e3011337 movw r1, #4919 ; 0x1337 1c: e34c0001 movt r0, #49153 ; 0xc001 20: e34a1aa3 movt r1, #43683 ; 0xaaa3 24: e16300f8 strd r0, [r3, #-8]! 28: e30c0afe movw r0, #51966 ; 0xcafe 2c: e30b1eef movw r1, #48879 ; 0xbeef 30: e34d0eaf movt r0, #57007 ; 0xdeaf 34: e34d1ead movt r1, #57005 ; 0xdead 38: e1b34f9f ldrexd r4, [r3] 3c: e1a34f90 strexd r4, r0, [r3] 40: e3340000 teq r4, #0 44: 1afffffb bne 38 48: e59f0004 ldr r0, [pc, #4] ; 54 4c: e3a0101e mov r1, #30 50: ebfffffe bl 0 <__bug> 54: 00000000 .word 0x00000000 The atomic64_set (0x38-0x44) writes to the atomic64_t, but the compiler doesn't see this, assumes the test condition is always false and generates an unconditional branch to __bug. The rest of the test is optimised away. This patch adds suitable memory constraints to the atomic operations on ARM to ensure that the compiler is informed of the correct data hazards. We have to use the "Qo" constraints to avoid hitting the GCC anomaly described at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492 , where the compiler makes assumptions about the writeback in the addressing mode used by the inline assembly. These constraints forbid the use of auto{inc,dec} addressing modes, so it doesn't matter if we don't use the operand exactly once. Reviewed-by: Nicolas Pitre Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 6211/1: atomic ops: fix register constraints for atomic64_add_unless

2010-08-02T17:29:55+00:00

commit 068de8d1be48a04b92fd97f76bb7e113b7be82a8 upstream. The atomic64_add_unless function compares an atomic variable with a given value and, if they are not equal, adds another given value to the atomic variable. The function returns zero if the addition did not occur and non-zero otherwise. On ARM, the return value is initialised to 1 in C code. Inline assembly code then performs the atomic64_add_unless operation, setting the return value to 0 iff the addition does not occur. This means that when the addition *does* occur, the value of ret must be preserved across the inline assembly and therefore requires a "+r" constraint rather than the current one of "=&r". Thanks to Nicolas Pitre for helping to spot this. Reviewed-by: Nicolas Pitre Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 6125/1: ARM TWD: move TWD registers to common header

2010-05-12T10:18:13+00:00

This moves the TWD register set of MPcore to a common existing file so that watchdog driver can access it Signed-off-by: srinidhi kasagar Acked-by: Linus Walleij Signed-off-by: Russell King

ARM: 6112/1: Use the Inner Shareable I-cache and BTB ops on ARMv7 SMP

2010-05-08T09:44:30+00:00

The standard I-cache Invalidate All (ICIALLU) and Branch Predication Invalidate All (BPIALL) operations are not automatically broadcast to the other CPUs in an ARMv7 MP system. The patch adds the Inner Shareable variants, ICIALLUIS and BPIALLIS, if ARMv7 and SMP. Signed-off-by: Catalin Marinas Signed-off-by: Russell King

arch/arm/include/asm/elf.h: forward-declare the task-struct

2010-05-01T10:33:00+00:00

iop32x_defconfig: In file included from include/linux/elf.h:7, from kernel/elfcore.c:1: arch/arm/include/asm/elf.h:101: warning: "struct task_struct" declared inside parameter list arch/arm/include/asm/elf.h:101: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Andrew Morton Signed-off-by: Russell King

ARM: fix build error in arch/arm/kernel/process.c

2010-04-21T07:45:21+00:00

/tmp/ccJ3ssZW.s: Assembler messages: /tmp/ccJ3ssZW.s:1952: Error: can't resolve `.text' {.text section} - `.LFB1077' This is caused because: .section .data .section .text .section .text .previous does not return us to the .text section, but the .data section; this makes use of .previous dangerous if the ordering of previous sections is not known. Fix up the other users of .previous; .pushsection and .popsection are a safer pairing to use than .section and .previous. Signed-off-by: Russell King

ARM: 6051/1: VFP: preserve the HW context when calling signal handlers

2010-04-14T10:11:30+00:00

From: Imre Deak Signal handlers can use floating point, so prevent them to corrupt the main thread's VFP context. So far there were two signal stack frame formats defined based on the VFP implementation, but the user struct used for ptrace covers all posibilities, so use it for the signal stack too. Introduce also a new user struct for VFP exception registers. In this too fields not relevant to the current VFP architecture are ignored. Support to save / restore the exception registers was added by Will Deacon. Signed-off-by: Imre Deak Signed-off-by: Will Deacon Signed-off-by: Russell King