1. 05 8月, 2010 11 次提交
  2. 31 7月, 2010 3 次提交
  3. 29 7月, 2010 6 次提交
  4. 28 7月, 2010 1 次提交
  5. 26 7月, 2010 9 次提交
  6. 22 7月, 2010 2 次提交
  7. 21 7月, 2010 1 次提交
    • D
      Input: twl40300-keypad - fix handling of "all ground" rows · 3fea6026
      Dmitry Torokhov 提交于
      The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c)
      defines a key map for the matrix keypad keyboard. The hardware seems to
      use all of the 8 rows and 8 columns of the keypad, although not all
      possible locations are used.
      
      The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys
      are defined with a row and column number between 0 and 7, except
      
              KEY(0xff, 2, KEY_F9),
              KEY(0xff, 4, KEY_F10),
              KEY(0xff, 5, KEY_F11),
      
      which represent keycodes that should be emitted when entire row is
      connected to the ground.  since the driver handles this case as if we
      had an extra column in the key matrix. Unfortunately we do not allocate
      enough space and end up owerwriting some random memory.
      Reported-and-tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: stable@kernel.org
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3fea6026
  8. 15 7月, 2010 1 次提交
  9. 13 7月, 2010 5 次提交
  10. 10 7月, 2010 1 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King 提交于
      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: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e