1. 24 Sep, 2015 3 commits
  2. 14 Sep, 2015 1 commit
  3. 17 Aug, 2015 1 commit
    • Grygorii Strashko's avatar
      gpiolib: irqchip: use different lockdep class for each gpio irqchip · a0a8bcf4
      Grygorii Strashko authored
      Since IRQ chip helpers were introduced drivers lose ability to
      register separate lockdep classes for each registered GPIO IRQ
      chip and the gpiolib now is using shared lockdep class for
      all GPIO IRQ chips (gpiochip_irq_lock_class).
      As result, lockdep will produce warning when there are min two
      stacked GPIO chips and all of them are interrupt controllers.
      HW configuration which generates lockdep warning (TI dra7-evm):
      [SOC GPIO bankA.gpioX]
        <- irq - [pcf875x.gpioY]
                  <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
      The issue was reported in [1] and discussed [2].
      [ INFO: possible recursive locking detected ]
      4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
      sh/63 is trying to acquire lock:
       (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      but task is already holding lock:
       (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      other info that might help us debug this:
       Possible unsafe locking scenario:
       *** DEADLOCK ***
       May be due to missing lock nesting notation
      7 locks held by sh/63:
       #0:  (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164
       #1:  (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0
       #2:  (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0
       #3:  (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4
       #4:  (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398
       #5:  (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94
       #6:  (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      stack backtrace:
      CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
      Hardware name: Generic DRA74X (Flattened Device Tree)
      [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14)
      [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c)
      [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20)
      [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128)
      [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c)
      [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94)
      [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc)
      [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54)
      [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc)
      [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4)
      [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124)
      [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398)
      [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4)
      [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728)
      [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4)
      [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8)
      [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0)
      [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8)
      [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164)
      [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c)
      [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
      Lets fix it by using separate lockdep class for each registered GPIO
      IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.
      The implementation of this patch inspired by solution done by Nicolas
      Boichat for regmap [3]
      [1] http://www.spinics.net/lists/linux-gpio/msg05844.html
      [2] http://www.spinics.net/lists/linux-gpio/msg06021.html
      [3] http://www.spinics.net/lists/arm-kernel/msg429834.html
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roger Quadros <rogerq@ti.com>
      Reported-by: default avatarRoger Quadros <rogerq@ti.com>
      Tested-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  4. 03 Aug, 2015 1 commit
  5. 28 Jul, 2015 2 commits
    • Tomeu Vizoso's avatar
      gpio: defer probe if pinctrl cannot be found · 28355f81
      Tomeu Vizoso authored
      When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
      the pin controller isn't available.
      Otherwise, the GPIO range wouldn't be set at all unless the pin
      controller probed always before the GPIO chip.
      With this change, the probe of the GPIO chip will be deferred and will
      be retried at a later point, hopefully once the pin controller has been
      registered and probed already.
      Signed-off-by: default avatarTomeu Vizoso <tomeu.vizoso@collabora.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Rob Herring's avatar
      gpio: kill off set_irq_flags usage · 23393d49
      Rob Herring authored
      set_irq_flags is ARM specific with custom flags which have genirq
      equivalents. Convert drivers to use the genirq interfaces directly, so we
      can kill off set_irq_flags. The translation of flags is as follows:
      For IRQs managed by an irqdomain, the irqdomain core code handles clearing
      and setting IRQ_NOREQUEST already, so there is no need to do this in
      .map() functions and we can simply remove the set_irq_flags calls. Some
      users also modify IRQ_NOPROBE and this has been maintained although it
      is not clear that is really needed as most platforms don't use probing.
      There appears to be a great deal of blind copy and paste of this code.
      Signed-off-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Cc: Michael Hennerich <michael.hennerich@analog.com>
      Acked-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Ray Jui <rjui@broadcom.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: linux-tegra@vger.kernel.org
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  6. 27 Jul, 2015 1 commit
  7. 21 Jul, 2015 1 commit
  8. 16 Jul, 2015 2 commits
  9. 15 Jul, 2015 1 commit
  10. 14 Jul, 2015 1 commit
  11. 06 Jul, 2015 1 commit
  12. 24 Jun, 2015 1 commit
  13. 16 Jun, 2015 1 commit
  14. 10 Jun, 2015 2 commits
  15. 01 Jun, 2015 1 commit
  16. 19 May, 2015 1 commit
  17. 13 May, 2015 1 commit
  18. 12 May, 2015 3 commits
  19. 19 Mar, 2015 1 commit
  20. 05 Mar, 2015 2 commits
  21. 04 Mar, 2015 1 commit
    • Benoit Parrot's avatar
      gpio: add GPIO hogging mechanism · f625d460
      Benoit Parrot authored
      Based on Boris Brezillion's work this is a reworked patch
      of his initial GPIO hogging mechanism.
      This patch provides a way to initially configure specific GPIO
      when the GPIO controller is probed.
      The actual DT scanning to collect the GPIO specific data is performed
      as part of gpiochip_add().
      The purpose of this is to allow specific GPIOs to be configured
      without any driver specific code.
      This is particularly useful because board design are getting
      increasingly complex and given SoC pins can now have more
      than 10 mux values, a lot of connections are now dependent on
      external IO muxes to switch various modes.
      Specific drivers should not necessarily need to be aware of
      what accounts to a specific board implementation. This board level
      "description" should be best kept as part of the dts file.
      Signed-off-by: default avatarBenoit Parrot <bparrot@ti.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  22. 30 Jan, 2015 1 commit
  23. 29 Jan, 2015 1 commit
  24. 15 Jan, 2015 1 commit
  25. 14 Jan, 2015 6 commits
  26. 02 Dec, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: fix deferred probe detection for legacy API · 0e9a5edf
      Alexandre Courbot authored
      Commit 14e85c0e ("gpio: remove gpio_descs global array") changed
      gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers
      not in the valid range, but also for all GPIOs whose controller has not
      been probed yet. Although this behavior is more correct (nothing hints
      that these GPIO numbers will be populated later), this affects
      gpio_request() and gpio_request_one() which call gpiod_request() with a
      NULL descriptor, causing it to return -EINVAL instead of the expected
      -EPROBE_DEFER for a non-probed GPIO.
      gpiod_request() is only called with a descriptor obtained from
      gpio_to_desc() from these two functions, so address the issue there.
      Other ways to obtain GPIOs rely on well-defined mappings and can thus
      return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected
      by this issue.
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  27. 28 Nov, 2014 1 commit