1. 01 Oct, 2010 12 commits
    • Frederic Weisbecker's avatar
      reiserfs: fix unwanted reiserfs lock recursion · 9d8117e7
      Frederic Weisbecker authored
      Prevent from recursively locking the reiserfs lock in reiserfs_unpack()
      because we may call journal_begin() that requires the lock to be taken
      only once, otherwise it won't be able to release the lock while taking
      other mutexes, ending up in inverted dependencies between the journal
      mutex and the reiserfs lock for example.
      
      This fixes:
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        2.6.35.4.4a #3
        -------------------------------------------------------
        lilo/1620 is trying to acquire lock:
         (&journal->j_mutex){+.+...}, at: [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
      
        but task is already holding lock:
         (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
               [<c10562b7>] lock_acquire+0x67/0x80
               [<c12facad>] __mutex_lock_common+0x4d/0x410
               [<c12fb0c8>] mutex_lock_nested+0x18/0x20
               [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
               [<d0325c06>] do_journal_begin_r+0x86/0x340 [reiserfs]
               [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
               [<d0315be4>] reiserfs_remount+0x224/0x530 [reiserfs]
               [<c10b6a20>] do_remount_sb+0x60/0x110
               [<c10cee25>] do_mount+0x625/0x790
               [<c10cf014>] sys_mount+0x84/0xb0
               [<c12fca3d>] syscall_call+0x7/0xb
      
        -> #0 (&journal->j_mutex){+.+...}:
               [<c10560f6>] __lock_acquire+0x1026/0x1180
               [<c10562b7>] lock_acquire+0x67/0x80
               [<c12facad>] __mutex_lock_common+0x4d/0x410
               [<c12fb0c8>] mutex_lock_nested+0x18/0x20
               [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
               [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
               [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
               [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs]
               [<c10db9db>] __block_prepare_write+0x1bb/0x3a0
               [<c10dbbe6>] block_prepare_write+0x26/0x40
               [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs]
               [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs]
               [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs]
               [<c10c3188>] vfs_ioctl+0x28/0xa0
               [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0
               [<c10c3eb3>] sys_ioctl+0x63/0x70
               [<c12fca3d>] syscall_call+0x7/0xb
      
        other info that might help us debug this:
      
        2 locks held by lilo/1620:
         #0:  (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d032945a>] reiserfs_unpack+0x6a/0x120 [reiserfs]
         #1:  (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        stack backtrace:
        Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3
        Call Trace:
         [<c10560f6>] __lock_acquire+0x1026/0x1180
         [<c10562b7>] lock_acquire+0x67/0x80
         [<c12facad>] __mutex_lock_common+0x4d/0x410
         [<c12fb0c8>] mutex_lock_nested+0x18/0x20
         [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
         [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
         [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
         [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs]
         [<c10db9db>] __block_prepare_write+0x1bb/0x3a0
         [<c10dbbe6>] block_prepare_write+0x26/0x40
         [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs]
         [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs]
         [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs]
         [<c10c3188>] vfs_ioctl+0x28/0xa0
         [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0
         [<c10c3eb3>] sys_ioctl+0x63/0x70
         [<c12fca3d>] syscall_call+0x7/0xb
      Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: All since 2.6.32 <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9d8117e7
    • Frederic Weisbecker's avatar
      reiserfs: fix dependency inversion between inode and reiserfs mutexes · 3f259d09
      Frederic Weisbecker authored
      The reiserfs mutex already depends on the inode mutex, so we can't lock
      the inode mutex in reiserfs_unpack() without using the safe locking API,
      because reiserfs_unpack() is always called with the reiserfs mutex locked.
      
      This fixes:
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        2.6.35c #13
        -------------------------------------------------------
        lilo/1606 is trying to acquire lock:
         (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
      
        but task is already holding lock:
         (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
               [<c1056347>] lock_acquire+0x67/0x80
               [<c12f083d>] __mutex_lock_common+0x4d/0x410
               [<c12f0c58>] mutex_lock_nested+0x18/0x20
               [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
               [<d0329e9a>] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs]
               [<d0316b81>] reiserfs_fill_super+0x941/0xe60 [reiserfs]
               [<c10b7d17>] get_sb_bdev+0x117/0x170
               [<d0313e21>] get_super_block+0x21/0x30 [reiserfs]
               [<c10b74ba>] vfs_kern_mount+0x6a/0x1b0
               [<c10b7659>] do_kern_mount+0x39/0xe0
               [<c10cebe0>] do_mount+0x340/0x790
               [<c10cf0b4>] sys_mount+0x84/0xb0
               [<c12f25cd>] syscall_call+0x7/0xb
      
        -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}:
               [<c1056186>] __lock_acquire+0x1026/0x1180
               [<c1056347>] lock_acquire+0x67/0x80
               [<c12f083d>] __mutex_lock_common+0x4d/0x410
               [<c12f0c58>] mutex_lock_nested+0x18/0x20
               [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
               [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs]
               [<c10c3228>] vfs_ioctl+0x28/0xa0
               [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0
               [<c10c3f53>] sys_ioctl+0x63/0x70
               [<c12f25cd>] syscall_call+0x7/0xb
      
        other info that might help us debug this:
      
        1 lock held by lilo/1606:
         #0:  (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        stack backtrace:
        Pid: 1606, comm: lilo Not tainted 2.6.35c #13
        Call Trace:
         [<c1056186>] __lock_acquire+0x1026/0x1180
         [<c1056347>] lock_acquire+0x67/0x80
         [<c12f083d>] __mutex_lock_common+0x4d/0x410
         [<c12f0c58>] mutex_lock_nested+0x18/0x20
         [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
         [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs]
         [<c10c3228>] vfs_ioctl+0x28/0xa0
         [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0
         [<c10c3f53>] sys_ioctl+0x63/0x70
         [<c12f25cd>] syscall_call+0x7/0xb
      Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: <stable@kernel.org>		[2.6.32 and later]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3f259d09
    • Kukjin Kim's avatar
      MAINTAINERS: update maintainer for S5P ARM ARCHITECTURES · f556cb07
      Kukjin Kim authored
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Acked-by: default avatarBen Dooks <ben-linux@fluff.org>
      Acked-by: default avatarRussell King <rmk@arm.linux.org.uk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f556cb07
    • Petr Vandrovec's avatar
      MAINTAINERS: update matroxfb & ncpfs status · 52653199
      Petr Vandrovec authored
      I moved couple years ago, so let's update my email and snail mail.
      
      And I do not have any access to Matrox hardware anymore, and I'm quite
      unresponsive to matroxfb bug reports (sorry Alan), so saying that I'm
      maintainer is a bit far fetched.
      
      For ncpfs I do not use ncpfs in my daily life either, but at least I can
      test that one, so I can stay listed here for odd fixes.
      Signed-off-by: default avatarPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      52653199
    • Jiri Olsa's avatar
      proc: make /proc/pid/limits world readable · 3036e7b4
      Jiri Olsa authored
      Having the limits file world readable will ease the task of system
      management on systems where root privileges might be restricted.
      
      Having admin restricted with root priviledges, he/she could not check
      other users process' limits.
      
      Also it'd align with most of the /proc stat files.
      Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Eugene Teo <eugene@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3036e7b4
    • Don Mullis's avatar
      lib/list_sort: do not pass bad pointers to cmp callback · f015ac3e
      Don Mullis authored
      If the original list is a POT in length, the first callback from line 73
      will pass a==b both pointing to the original list_head.  This is dangerous
      because the 'list_sort()' user can use 'container_of()' and accesses the
      "containing" object, which does not necessary exist for the list head.  So
      the user can access RAM which does not belong to him.  If this is a write
      access, we can end up with memory corruption.
      Signed-off-by: default avatarDon Mullis <don.mullis@gmail.com>
      Tested-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f015ac3e
    • Dan Rosenberg's avatar
      sys_semctl: fix kernel stack leakage · 982f7c2b
      Dan Rosenberg authored
      The semctl syscall has several code paths that lead to the leakage of
      uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO,
      IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete
      version of the semid_ds struct.
      
      The copy_semid_to_user() function declares a semid_ds struct on the stack
      and copies it back to the user without initializing or zeroing the
      "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers,
      allowing the leakage of 16 bytes of kernel stack memory.
      
      The code is still reachable on 32-bit systems - when calling semctl()
      newer glibc's automatically OR the IPC command with the IPC_64 flag, but
      invoking the syscall directly allows users to use the older versions of
      the struct.
      Signed-off-by: default avatarDan Rosenberg <dan.j.rosenberg@gmail.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      982f7c2b
    • Marcin Slusarz's avatar
      i7core_edac: fix panic in udimm sysfs attributes registration · 64aab720
      Marcin Slusarz authored
      Array of udimm sysfs attributes was not ended with NULL marker, leading to
      dereference of random memory.
      
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm0
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm1
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm2
        BUG: unable to handle kernel NULL pointer dereference at 00000000000001a4
        IP: [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        Pid: 1, comm: swapper Not tainted 2.6.36-rc3-nv+ #483 P6T SE/System Product Name
        RIP: 0010:[<ffffffff81330b36>]  [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        (...)
        Call Trace:
         [<ffffffff81330b86>] edac_create_mci_instance_attributes+0x198/0x1f1
         [<ffffffff81330c9a>] edac_create_sysfs_mci_device+0xbb/0x2b2
         [<ffffffff8132f533>] edac_mc_add_mc+0x46b/0x557
         [<ffffffff81428901>] i7core_probe+0xccf/0xec0
        RIP  [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        ---[ end trace 20de320855b81d78 ]---
        Kernel panic - not syncing: Attempted to kill init!
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: default avatarDoug Thompson <dougthompson@xmission.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      64aab720
    • Andrew Morton's avatar
      drivers/serial/mrst_max3110.c needs linux/irq.h · c044391b
      Andrew Morton authored
      sparc64 allmodconfig:
      
        drivers/serial/mrst_max3110.c: In function `serial_m3110_startup':
        drivers/serial/mrst_max3110.c:470: error: `IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function)
      
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c044391b
    • Andrew Morton's avatar
      arch/m68k/mac/macboing.c: use unsigned long for irqflags · e53ced1b
      Andrew Morton authored
      Fix the warnings
      
        arch/m68k/mac/macboing.c: In function 'mac_mksound':
        arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell':
        arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell':
        arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast
      
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e53ced1b
    • Andrew Morton's avatar
      drivers/serial/mfd.c needs slab.h · 63d66cab
      Andrew Morton authored
      alpha allmodconfig:
      
        drivers/serial/mfd.c:144: error: implicit declaration of function 'kzalloc'
        drivers/serial/mfd.c:144: warning: assignment makes pointer from integer without a cast
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      63d66cab
    • Ira W. Snyder's avatar
      kfifo: fix scatterlist usage · 399f1e30
      Ira W. Snyder authored
      The kfifo_dma family of functions use sg_mark_end() on the last element in
      their scatterlist.  This forces use of a fresh scatterlist for each DMA
      operation, which makes recycling a single scatterlist impossible.
      
      Change the behavior of the kfifo_dma functions to match the usage of the
      dma_map_sg function.  This means that users must respect the returned
      nents value.  The sample code is updated to reflect the change.
      
      This bug is trivial to cause: call kfifo_dma_in_prepare() such that it
      prepares a scatterlist with a single entry comprising the whole fifo.
      This is the case when you map the entirety of a newly created empty fifo.
      This causes the setup_sgl() function to mark the first scatterlist entry
      as the end of the chain, no matter what comes after it.
      
      Afterwards, add and remove some data from the fifo such that another call
      to kfifo_dma_in_prepare() will create two scatterlist entries.  It returns
      nents=2.  However, due to the previous sg_mark_end() call, sg_is_last()
      will now return true for the first scatterlist element.  This causes the
      sample code to print a single scatterlist element when it should print
      two.
      
      By removing the call to sg_mark_end(), we make the API as similar as
      possible to the DMA mapping API.  All users are required to respect the
      returned nents.
      Signed-off-by: default avatarIra W. Snyder <iws@ovro.caltech.edu>
      Cc: Stefani Seibold <stefani@seibold.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      399f1e30
  2. 30 Sep, 2010 4 commits
  3. 29 Sep, 2010 8 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs · 4193d916
      Linus Torvalds authored
      * 'for-linus' of git://oss.sgi.com/xfs/xfs:
        xfs: force background CIL push under sustained load
      4193d916
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 · 9d457c60
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
        mfd: Fix max8925 irq control bit incorrect setting
        mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types
      9d457c60
    • Daniel J Blueman's avatar
      fix OMAP2 MTD build failure · f12f662f
      Daniel J Blueman authored
      Fix build failure from recent interface change and merge.
      
      Tested on OMAP3430.
      Signed-off-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f12f662f
    • Dave Chinner's avatar
      xfs: force background CIL push under sustained load · 80168676
      Dave Chinner authored
      I have been seeing occasional pauses in transaction throughput up to
      30s long under heavy parallel workloads. The only notable thing was
      that the xfsaild was trying to be active during the pauses, but
      making no progress. It was running exactly 20 times a second (on the
      50ms no-progress backoff), and the number of pushbuf events was
      constant across this time as well.  IOWs, the xfsaild appeared to be
      stuck on buffers that it could not push out.
      
      Further investigation indicated that it was trying to push out inode
      buffers that were pinned and/or locked. The xfsbufd was also getting
      woken at the same frequency (by the xfsaild, no doubt) to push out
      delayed write buffers. The xfsbufd was not making any progress
      because all the buffers in the delwri queue were pinned. This scan-
      and-make-no-progress dance went one in the trace for some seconds,
      before the xfssyncd came along an issued a log force, and then
      things started going again.
      
      However, I noticed something strange about the log force - there
      were way too many IO's issued. 516 log buffers were written, to be
      exact. That added up to 129MB of log IO, which got me very
      interested because it's almost exactly 25% of the size of the log.
      He delayed logging code is suppose to aggregate the minimum of 25%
      of the log or 8MB worth of changes before flushing. That's what
      really puzzled me - why did a log force write 129MB instead of only
      8MB?
      
      Essentially what has happened is that no CIL pushes had occurred
      since the previous tail push which cleared out 25% of the log space.
      That caused all the new transactions to block because there wasn't
      log space for them, but they kick the xfsaild to push the tail.
      However, the xfsaild was not making progress because there were
      buffers it could not lock and flush, and the xfsbufd could not flush
      them because they were pinned. As a result, both the xfsaild and the
      xfsbufd could not move the tail of the log forward without the CIL
      first committing.
      
      The cause of the problem was that the background CIL push, which
      should happen when 8MB of aggregated changes have been committed, is
      being held off by the concurrent transaction commit load. The
      background push does a down_write_trylock() which will fail if there
      is a concurrent transaction commit holding the push lock in read
      mode. With 8 CPUs all doing transactions as fast as they can, there
      was enough concurrent transaction commits to hold off the background
      push until tail-pushing could no longer free log space, and the halt
      would occur.
      
      It should be noted that there is no reason why it would halt at 25%
      of log space used by a single CIL checkpoint. This bug could
      definitely violate the "no transaction should be larger than half
      the log" requirement and hence result in corruption if the system
      crashed under heavy load. This sort of bug is exactly the reason why
      delayed logging was tagged as experimental....
      
      The fix is to start blocking background pushes once the threshold
      has been exceeded. Rework the threshold calculations to keep the
      amount of log space a CIL checkpoint can use to below that of the
      AIL push threshold to avoid the problem completely.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarAlex Elder <aelder@sgi.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      80168676
    • Kevin Liu's avatar
      mfd: Fix max8925 irq control bit incorrect setting · 90182317
      Kevin Liu authored
      In max8925_irq_sync_unlock(), irq control bit is set at the same time.
      Zero means enabling irq, and one means disabling irq.
      
      The original code is:
      	irq_chg[0] &= irq_data->enable;
      
      It should be changed to:
      	irq_chg[0] &= ~irq_data->enable;
      
      Otherwise, irq control bit is mess.
      Signed-off-by: default avatarKevin Liu <kliu5@marvell.com>
      Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@marvell.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      90182317
    • Mark Brown's avatar
      mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types · c9d66d35
      Mark Brown authored
      The driver was originally tested with an additional patch which
      made this unneeded but that patch had issuges and got lost on the
      way to mainline, causing problems when the errors are reported.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Cc: stable@kernel.org
      c9d66d35
    • Linus Torvalds's avatar
      Linux 2.6.36-rc6 · 899611ee
      Linus Torvalds authored
      899611ee
    • David Howells's avatar
      MN10300: Handle missing sys_cacheflush() when caching disabled · 62bdb288
      David Howells authored
      When caching is disabled on the MN10300 arch, the sys_cacheflush()
      function is removed by conditional stuff in the makefiles, but is still
      referred to by the syscall table.
      
      Provide a null version that just returns 0 when caching is disabled (or
      -EINVAL if the arguments are silly).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62bdb288
  4. 28 Sep, 2010 9 commits
  5. 27 Sep, 2010 7 commits