1. 05 Mar, 2012 2 commits
  2. 02 Mar, 2012 1 commit
  3. 28 Feb, 2012 1 commit
  4. 26 Feb, 2012 3 commits
    • Grant Likely's avatar
      mfd: twl-core: Add IRQ_DOMAIN dependency · 280ad7fd
      Grant Likely authored
      TWL4030 depends on IRQ_DOMAIN support, so this patch selects it in Kconfig.
      It used to be that CONFIG_IRQ_DOMAIN must only be selected by the architecture,
      but recent cleanups have fixed it so that it is safe to select from anywhere.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      [grant.likely: Changed from a depends to a select]
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      280ad7fd
    • Grant Likely's avatar
      devicetree: Add empty of_platform_populate() for !CONFIG_OF_ADDRESS (sparc) · 964dba28
      Grant Likely authored
      Sparc has its own helpers for translating address ranges when the device
      tree is parsed at boot time, and it isn't able to use of_platform_populate().
      However, there are some device drivers that want to use that function on
      other DT enabled platforms (ie. TWL4030).  This patch adds an empty
      of_platform_populate() implementation that returns an error when
      CONFIG_OF_ADDRESS is not selected.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      964dba28
    • Grant Likely's avatar
      irq_domain: Centralize definition of irq_dispose_mapping() · d593f25f
      Grant Likely authored
      Several architectures define their own empty irq_dispose_mapping().  Since
      the irq_domain code is centralized now, there is little need to do so.  This
      patch removes them and creates a new empty copy when !CONFIG_IRQ_DOMAIN is
      selected.
      
      The patch also means that IRQ_DOMAIN becomes selectable on all architectures.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: sparclinux@vger.kernel.org
      Cc: linux@lists.openrisc.net
      d593f25f
  5. 24 Feb, 2012 1 commit
    • Grant Likely's avatar
      irq_domain/mips: Allow irq_domain on MIPS · abd2363f
      Grant Likely authored
      This patch makes IRQ_DOMAIN usable on MIPS.  It uses an ugly workaround
      to preserve current behaviour so that MIPS has time to add irq_domain
      registration to the irq controller drivers.  The workaround will be
      removed in Linux v3.6
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      abd2363f
  6. 23 Feb, 2012 3 commits
  7. 16 Feb, 2012 19 commits
  8. 15 Feb, 2012 1 commit
    • Ming Lei's avatar
      Fix circular locking dependency (3.3-rc2) · 864533ce
      Ming Lei authored
      Hi,
      
      On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
      > Hi guys,
      >
      > I have just triggered the folllowing:
      >
      > [   84.860321] ======================================================
      > [   84.860321] [ INFO: possible circular locking dependency detected ]
      > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
      > [   84.860321] -------------------------------------------------------
      > [   84.860321] bash/949 is trying to acquire lock:
      > [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
      > [   84.860321]
      > [   84.860321] but task is already holding lock:
      > [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   84.911468]
      > [   84.911468] which lock already depends on the new lock.
      > [   84.911468]
      > [   84.920043]
      > [   84.920043] the existing dependency chain (in reverse order) is:
      > [   84.920043]
      > [   84.927886] -> #1 (s_active#22){++++.+}:
      > [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100
      > [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100
      > [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
      > [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98
      > [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78
      > [   84.974670]        [<c02c29e8>] device_del+0x140/0x170
      > [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18
      > [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc
      > [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc
      > [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c
      > [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24
      > [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.035003]
      > [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
      > [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698
      > [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100
      > [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4
      > [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc
      > [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24
      > [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.109069]
      > [   85.109069] other info that might help us debug this:
      > [   85.109069]
      > [   85.117462]  Possible unsafe locking scenario:
      > [   85.117462]
      > [   85.117462]        CPU0                    CPU1
      > [   85.128417]        ----                    ----
      > [   85.128417]   lock(s_active#22);
      > [   85.128417]                                lock(sysfs_lock);
      > [   85.128417]                                lock(s_active#22);
      > [   85.142486]   lock(sysfs_lock);
      > [   85.151794]
      > [   85.151794]  *** DEADLOCK ***
      > [   85.151794]
      > [   85.151794] 2 locks held by bash/949:
      > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
      > [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   85.170349]
      > [   85.178588] stack backtrace:
      > [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
      > [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
      > [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
      > [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
      > [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
      > [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
      > [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
      > [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
      > [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
      > [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
      > [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
      > [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
      > [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
      > -bash: echo: write error: Operation not permitted
      >
      > the way to trigger is:
      >
      > root@legolas:~# cd /sys/class/gpio/
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# echo 2 > unexport
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# cd gpio2/
      > root@legolas:/sys/class/gpio/gpio2# echo 1 > value
      
      Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
      fix the problem.
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      864533ce
  9. 14 Feb, 2012 9 commits