1. 16 Jul, 2010 2 commits
  2. 14 Jul, 2010 1 commit
  3. 12 Jul, 2010 1 commit
  4. 10 Jul, 2010 1 commit
    • Russell King's avatar
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King authored
      CPU: Testing write buffer coherency: ok
      ------------[ cut here ]------------
      WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
      Modules linked in:
      [<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
      [<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
      [<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
      [<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
      [<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
      [<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
      [<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
      [<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
      [<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
      ---[ end trace 1b75b31a2719ed1c ]---
      possible reason: unannotated irqs-on.
      irq event stamp: 3
      hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
      hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
      softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
      softirqs last disabled at (0): [<(null)>] (null)
      Fix this by ensuring that the lockdep interrupt state is manipulated in
      the appropriate places.  We essentially treat userspace as an entirely
      separate environment which isn't relevant to lockdep (lockdep doesn't
      monitor userspace.)  We don't tell lockdep that IRQs will be enabled
      in that environment.
      Instead, when creating kernel threads (which is a rare event compared
      to entering/leaving userspace) we have to update the lockdep state.  Do
      this by starting threads with IRQs disabled, and in the kthread helper,
      tell lockdep that IRQs are enabled, and enable them.
      This provides lockdep with a consistent view of the current IRQ state
      in kernel space.
      This also revert portions of 0d928b0b
      which didn't fix the problem.
      Tested-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  5. 09 Jul, 2010 4 commits
    • Linus Walleij's avatar
      ARM: 6184/2: ux500: use neutral PRCMU base · d9e38040
      Linus Walleij authored
      The MTU wallclock timing fix-up patch was hardwired to the DB8500
      causing a regression. This makes it work on the DB5500 as well.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Will Deacon's avatar
      ARM: 6212/1: atomic ops: add memory constraints to inline asm · 398aa668
      Will Deacon authored
      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
      <kernel root>/lib/atomic64_test.c:
      00000000 <test_atomic64>:
         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 <test_atomic64+0x38>
        48:	e59f0004 	ldr	r0, [pc, #4]	; 54 <test_atomic64+0x54>
        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
       , 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.
      Cc: stable@kernel.org
      Reviewed-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Will Deacon's avatar
      ARM: 6211/1: atomic ops: fix register constraints for atomic64_add_unless · 068de8d1
      Will Deacon authored
      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.
      Cc: stable@kernel.org
      Reviewed-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Sascha Hauer's avatar
      ARM: 6210/1: Do not rely on reset defaults of L2X0_AUX_CTRL · 4082cfa7
      Sascha Hauer authored
      On i.MX35 the L2X0_AUX_CTRL register does not have sensible reset
      default values. Allow them to be overwritten with the aux_val/aux_mask
      arguments passed to l2x0_init().
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  6. 05 Jul, 2010 5 commits
  7. 04 Jul, 2010 1 commit
    • Will Deacon's avatar
      ARM: 6205/1: perf: ensure counter delta is treated as unsigned · 446a5a8b
      Will Deacon authored
      Hardware performance counters on ARM are 32-bits wide but atomic64_t
      variables are used to represent counter data in the hw_perf_event structure.
      The armpmu_event_update function right-shifts a signed 64-bit delta variable
      and adds the result to the event count. This can lead to shifting in sign-bits
      if the MSB of the 32-bit counter value is set. This results in perf output
      such as:
       Performance counter stats for 'sleep 20':
       18446744073460670464  cycles             <-- 0xFFFFFFFFF12A6000
              7783773  instructions             #      0.000 IPC
                  465  context-switches
                  161  page-faults
              1172393  branches
         20.154242147  seconds time elapsed
      This patch ensures that the delta value is treated as unsigned so that the
      right shift sets the upper bits to zero.
      Cc: <stable@kernel.org>
      Acked-by: default avatarJamie Iles <jamie.iles@picochip.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  8. 02 Jul, 2010 2 commits
  9. 01 Jul, 2010 8 commits
  10. 27 Jun, 2010 1 commit
  11. 23 Jun, 2010 1 commit
  12. 16 Jun, 2010 1 commit
  13. 13 Jun, 2010 4 commits
  14. 10 Jun, 2010 3 commits
  15. 09 Jun, 2010 4 commits
  16. 08 Jun, 2010 1 commit
    • Khem Raj's avatar
      ARM: 6164/1: Add kto and kfrom to input operands list. · 9a40ac86
      Khem Raj authored
      When functions incoming parameters are not in input operands list gcc
      4.5 does not load the parameters into registers before calling this
      function but the inline assembly assumes valid addresses inside this
      function. This breaks the code because r0 and r1 are invalid when
      execution enters v4wb_copy_user_page ()
      Also the constant needs to be used as third input operand so account
      for that as well.
      Tested on qemu arm.
      CC: <stable@kernel.org>
      Signed-off-by: default avatarKhem Raj <raj.khem@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>