1. 24 10月, 2016 1 次提交
  2. 05 1月, 2016 1 次提交
    • L
      gpio: generic: factor into gpio_chip struct · 0f4630f3
      Linus Walleij 提交于
      The separate struct bgpio_chip has been a pain to handle, both
      by being confusingly similar in name to struct gpio_chip and
      for being contained inside a struct so that struct gpio_chip
      is contained in a struct contained in a struct, making several
      steps of dereferencing necessary.
      
      Make things simpler: include the fields directly into
      <linux/gpio/driver.h>, #ifdef:ed for CONFIG_GENERIC_GPIO, and
      get rid of the <linux/basic_mmio_gpio.h> altogether. Prefix
      some of the member variables with bgpio_* and add proper
      kerneldoc while we're at it.
      
      Modify all users to handle the change and use a struct
      gpio_chip directly. And while we're at it: replace all
      container_of() dereferencing by gpiochip_get_data() and
      registering the gpio_chip with gpiochip_add_data().
      
      Cc: arm@kernel.org
      Cc: Alexander Shiyan <shc_work@mail.ru>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: bcm-kernel-feedback-list@broadcom.com
      Acked-by: NGregory Fong <gregory.0xf0@gmail.com>
      Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      0f4630f3
  3. 16 9月, 2015 1 次提交
    • T
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner 提交于
      Most interrupt flow handlers do not use the irq argument. Those few
      which use it can retrieve the irq number from the irq descriptor.
      
      Remove the argument.
      
      Search and replace was done with coccinelle and some extra helper
      scripts around it. Thanks to Julia for her help!
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      bd0b9ac4
  4. 14 9月, 2015 1 次提交
  5. 14 7月, 2015 1 次提交
  6. 18 6月, 2015 1 次提交
  7. 12 5月, 2015 1 次提交
  8. 28 11月, 2014 1 次提交
  9. 20 10月, 2014 1 次提交
  10. 27 3月, 2014 1 次提交
    • M
      gpio: mxs: Allow for recursive enable_irq_wake() call · a585f87c
      Marek Vasut 提交于
      The scenario here is that someone calls enable_irq_wake() from somewhere
      in the code. This will result in the lockdep producing a backtrace as can
      be seen below. In my case, this problem is triggered when using the wl1271
      (TI WlCore) driver found in drivers/net/wireless/ti/ .
      
      The problem cause is rather obvious from the backtrace, but let's outline
      the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
      which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
      calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
      grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
      irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
      marked as recursive, lockdep will spew the stuff below.
      
      We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
      fix the spew.
      
       =============================================
       [ INFO: possible recursive locking detected ]
       3.10.33-00012-gf06b763-dirty #61 Not tainted
       ---------------------------------------------
       kworker/0:1/18 is trying to acquire lock:
        (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       but task is already holding lock:
        (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&irq_desc_lock_class);
         lock(&irq_desc_lock_class);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       3 locks held by kworker/0:1/18:
        #0:  (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4
        #1:  ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4
        #2:  (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       stack backtrace:
       CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
       Workqueue: events request_firmware_work_func
       [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14)
       [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64)
       [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104)
       [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58)
       [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88)
       [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4)
       [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24)
       [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44)
       [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4)
       [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c)
       [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58)
       [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4)
       [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394)
       [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0)
       [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34)
       wlcore: loaded
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a585f87c
  11. 06 11月, 2013 1 次提交
  12. 21 5月, 2013 1 次提交
  13. 29 1月, 2013 1 次提交
  14. 23 1月, 2013 1 次提交
  15. 29 11月, 2012 1 次提交
  16. 03 9月, 2012 1 次提交
  17. 20 5月, 2012 1 次提交
    • S
      gpio/generic: initialize basic_mmio_gpio shadow variables properly · 3e11f7b8
      Shawn Guo 提交于
      It fixes the issue in gpio-generic that commit fb149218 (gpio/mxc: add
      missing initialization of basic_mmio_gpio shadow variables) manged to
      fix in gpio-mxc driver, so that other platform specific drivers do not
      suffer from the same problem over and over again.
      
      Changes since v1:
      * Turn the last parameter of bgpio_init() "bool big_endian" into
        "unsigned long flags" and give those really quirky hardwares a
        chance to tell that reg_set and reg_dir are unreadable.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      [grant.likely: Fix big-endian usage to explicitly set BBGPIOF_BIG_ENDIAN]
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      3e11f7b8
  18. 12 5月, 2012 3 次提交
  19. 01 11月, 2011 1 次提交
  20. 17 8月, 2011 1 次提交
  21. 20 7月, 2011 1 次提交
  22. 07 6月, 2011 4 次提交
  23. 06 6月, 2011 1 次提交
  24. 29 3月, 2011 2 次提交
  25. 08 3月, 2011 1 次提交
  26. 24 2月, 2011 1 次提交
  27. 28 1月, 2011 2 次提交
  28. 26 1月, 2011 1 次提交
  29. 21 12月, 2010 1 次提交