1. 23 3月, 2017 3 次提交
  2. 11 1月, 2017 1 次提交
  3. 25 11月, 2016 1 次提交
    • L
      gpio: simplify adding threaded interrupts · d245b3f9
      Linus Walleij 提交于
      This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when
      using threaded interrupts: add a new call
      gpiochip_irqchip_add_nested() to indicate that we're dealing
      with a nested rather than a chained irqchip, then create a
      separate gpiochip_set_nested_irqchip() to mirror
      the gpiochip_set_chained_irqchip() call to connect the
      parent and child interrupts.
      
      In the nested case gpiochip_set_nested_irqchip() does nothing
      more than call irq_set_parent() on each valid child interrupt,
      which has little semantic effect in the kernel, but this is
      probably still formally correct.
      
      Update all drivers using nested interrupts to use
      gpiochip_irqchip_add_nested() so we can now see clearly
      which these users are.
      
      The DLN2 driver can drop its specific hack with
      .irq_not_threaded as we now recognize whether a chip is
      threaded or not from its use of gpiochip_irqchip_add_nested()
      signature rather than from inspecting .can_sleep.
      
      We rename the .irq_parent to .irq_chained_parent since this
      parent IRQ is only really kept around for the chained
      interrupt handlers.
      
      Cc: Lars Poeschel <poeschel@lemonage.de>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Daniel Baluta <daniel.baluta@intel.com>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
      Cc: Semen Protsenko <semen.protsenko@globallogic.com>
      Cc: Alexander Stein <alexander.stein@systec-electronic.com>
      Cc: Phil Reid <preid@electromag.com.au>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      d245b3f9
  4. 08 11月, 2016 2 次提交
  5. 24 10月, 2016 1 次提交
  6. 12 10月, 2016 1 次提交
  7. 24 9月, 2016 2 次提交
    • W
      gpio: pca953x: variable 'id' was used twice · 6212e1d6
      Wolfram Sang 提交于
      sparse  rightfully said:
      
      drivers/gpio/gpio-pca953x.c:771:45: warning: symbol 'id' shadows an earlier one
      drivers/gpio/gpio-pca953x.c:742:36: originally declared here
      
      So, name them explicitly 'i2c_id' and 'acpi_id' to avoid any confusion.
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      6212e1d6
    • B
      gpio: pca953x: fix an incorrect lockdep warning · 559b4699
      Bartosz Golaszewski 提交于
      If an I2C GPIO multiplexer is driven by a GPIO provided by an expander
      when there's a second expander using the same device driver on one of
      the I2C bus segments, lockdep prints a deadlock warning when trying to
      set the direction or the value of the GPIOs provided by the second
      expander.
      
      The below diagram presents the setup:
      
                                                     - - - - -
       -------             ---------  Bus segment 1 |         |
      |       |           |         |---------------  Devices
      |       | SCL/SDA   |         |               |         |
      | Linux |-----------| I2C MUX |                - - - - -
      |       |    |      |         | Bus segment 2
      |       |    |      |         |-------------------
       -------     |       ---------                    |
                   |           |                    - - - - -
              ------------     | MUX GPIO          |         |
             |            |    |                     Devices
             |    GPIO    |    |                   |         |
             | Expander 1 |----                     - - - - -
             |            |                             |
              ------------                              | SCL/SDA
                                                        |
                                                   ------------
                                                  |            |
                                                  |    GPIO    |
                                                  | Expander 2 |
                                                  |            |
                                                   ------------
      
      The reason for lockdep warning is that we take the chip->i2c_lock in
      pca953x_gpio_set_value() or pca953x_gpio_direction_output() and then
      come right back to pca953x_gpio_set_value() when the GPIO mux kicks
      in. The locks actually protect different expanders, but for lockdep
      both are of the same class, so it says:
      
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&chip->i2c_lock);
         lock(&chip->i2c_lock);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
      In order to get rid of the warning, retrieve the adapter nesting depth
      and use it as lockdep subclass for chip->i2c_lock.
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Acked-by: NPeter Rosin <peda@axentia.se>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      559b4699
  8. 13 9月, 2016 1 次提交
  9. 12 9月, 2016 6 次提交
  10. 07 9月, 2016 1 次提交
  11. 11 8月, 2016 1 次提交
  12. 15 6月, 2016 1 次提交
  13. 13 6月, 2016 1 次提交
  14. 08 6月, 2016 1 次提交
    • A
      gpio: pca953x: enfore type for i2c_smbus_write_word_data() · c4d1cbd7
      Andy Shevchenko 提交于
      The commit 9b8e3ec3 ("gpio: pca953x: Use correct u16 value for register
      word write") fixed regression in pca953x_write_regs(). At the same time the
      solution introduced a sparse warning:
      
      drivers/gpio/gpio-pca953x.c:168:39: warning: incorrect type in argument 3 (different base types)
      drivers/gpio/gpio-pca953x.c:168:39:    expected unsigned short [unsigned] [usertype] value
      drivers/gpio/gpio-pca953x.c:168:39:    got restricted __le16 [usertype] <noident>
      
      Fix the code by enforcing the type of i2c_smbus_write_word_data() parameter.
      
      Cc: Yong Li <sdliyong@gmail.com>
      Cc: Phil Reid <preid@electromag.com.au>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c4d1cbd7
  15. 07 6月, 2016 2 次提交
  16. 10 4月, 2016 1 次提交
  17. 08 4月, 2016 1 次提交
  18. 16 3月, 2016 1 次提交
  19. 23 2月, 2016 1 次提交
  20. 05 1月, 2016 1 次提交
  21. 11 12月, 2015 1 次提交
  22. 09 12月, 2015 3 次提交
    • L
      gpio: pca953x: make inclusion of <linux/of_platform.h> unconditional · c2369d3f
      Linus Walleij 提交于
      After adding the DT matching in
      commit 6f29c9af
      "gpio: pca935x: fix of-only probed devices"
      compilation fails like this:
      
      CC [M]  drivers/gpio/gpio-pca953x.o
      gpio-pca953x.c: In function ‘pca953x_probe’:
      gpio-pca953x.c:693:11: error: implicit declaration of
      function ‘of_match_device’ [-Werror=implicit-function-declaration]
      match = of_match_device(pca953x_dt_ids, &client->dev);
              ^
      gpio-pca953x.c:693:9: warning: assignment makes pointer from
      integer without a cast [-Wint-conversion]
      match = of_match_device(pca953x_dt_ids, &client->dev);
              ^
      cc1: some warnings being treated as errors
      ../scripts/Makefile.build:264: recipe for target
      'drivers/gpio/gpio-pca953x.o' failed
      
      After removing the conditional inclusion guards compilation
      works fine again. Might be a module problem so that
      fix.
      
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c2369d3f
    • B
      gpio: pca935x: fix of-only probed devices · 6f29c9af
      Ben Dooks 提交于
      If the pca953x device is probed from OF using the proper OF probing then
      the i2c-client will be NULL and the device probe will fail as id is NULL
      and it isn't an ACPI device (previous drivers would simply OOPS out).
      
      Add support for the of_device_id table having the same data as the others
      so that the correct paths will be taken when registering a device.
      
      An example of current valid of node which did not work:
      
      	gpio@38 {
      		compatible = "onsemi,pca9654", "nxp,pca9534";
      		reg = <0x38>;
      		interrupt-parent = <&gpio5>;
      		interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
      	};
      Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6f29c9af
    • B
      gpio: pca953x: add onsemi,pca9654 id · 9f49f6dd
      Ben Dooks 提交于
      Add onsemi,pca9654 which is also compatible with the nxp,pca9524 as it
      is an 8bit expander with an interrupt output.
      Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9f49f6dd
  23. 19 11月, 2015 1 次提交
    • L
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij 提交于
      The name .dev in a struct is normally reserved for a struct device
      that is let us say a superclass to the thing described by the struct.
      struct gpio_chip stands out by confusingly using a struct device *dev
      to point to the parent device (such as a platform_device) that
      represents the hardware. As we want to give gpio_chip:s real devices,
      this is not working. We need to rename this member to parent.
      
      This was done by two coccinelle scripts, I guess it is possible to
      combine them into one, but I don't know such stuff. They look like
      this:
      
      @@
      struct gpio_chip *var;
      @@
      -var->dev
      +var->parent
      
      and:
      
      @@
      struct gpio_chip var;
      @@
      -var.dev
      +var.parent
      
      and:
      
      @@
      struct bgpio_chip *var;
      @@
      -var->gc.dev
      +var->gc.parent
      
      Plus a few instances of bgpio that I couldn't figure out how
      to teach Coccinelle to rewrite.
      
      This patch hits all over the place, but I *strongly* prefer this
      solution to any piecemal approaches that just exercise patch
      mechanics all over the place. It mainly hits drivers/gpio and
      drivers/pinctrl which is my own backyard anyway.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Alek Du <alek.du@intel.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      58383c78
  24. 05 10月, 2015 2 次提交
  25. 03 10月, 2015 1 次提交
  26. 02 10月, 2015 1 次提交
  27. 16 7月, 2015 1 次提交
    • G
      gpio: pca953x: fix nested irqs rescheduling · fdd50409
      Grygorii Strashko 提交于
      pca953x interrupt controller functionality is implemented using
      nested threaded IRQs which require parent_irq to be configured
      properly otherwise below warning can be seen if IRQ core
      will try re-schedule nested IRQ:
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 12 at kernel/irq/manage.c:696 irq_nested_primary_handler+0x30/0x38()
      Primary handler called for nested irq 301
      Modules linked in: uinput ipv6 smsc95xx usbnet mii imx2_wdt etnaviv(C) matrix_keypad matrix_keymap ar1021_i2c
      CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: G        WC    4.1.1 #9
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Backtrace:
      [<c0013298>] (dump_backtrace) from [<c0013488>] (show_stack+0x20/0x24)
      [<c0013468>] (show_stack) from [<c05743c4>] (dump_stack+0x70/0xc0)
      [<c0574354>] (dump_stack) from [<c002b7b8>] (warn_slowpath_common+0x88/0xc0)
      [<c002b730>] (warn_slowpath_common) from [<c002b8ac>] (warn_slowpath_fmt+0x40/0x48)
      [<c002b870>] (warn_slowpath_fmt) from [<c0075798>] (irq_nested_primary_handler+0x30/0x38)
      [<c0075768>] (irq_nested_primary_handler) from [<c0075200>] (handle_irq_event_percpu+0x70/0x2d0)
      [<c0075190>] (handle_irq_event_percpu) from [<c00754ac>] (handle_irq_event+0x4c/0x6c)
      [<c0075460>] (handle_irq_event) from [<c0078204>] (handle_simple_irq+0xa4/0xc8)
      [<c0078160>] (handle_simple_irq) from [<c0077cd4>] (resend_irqs+0x50/0x7c)
      [<c0077c84>] (resend_irqs) from [<c002f99c>] (tasklet_action+0x94/0x140)
      [<c002f908>] (tasklet_action) from [<c002eea8>] (__do_softirq+0xa0/0x3c8)
      [<c002ee08>] (__do_softirq) from [<c002f208>] (run_ksoftirqd+0x38/0x54)
      [<c002f1d0>] (run_ksoftirqd) from [<c004b1e4>] (smpboot_thread_fn+0x1f8/0x2f0)
      [<c004afec>] (smpboot_thread_fn) from [<c0047744>] (kthread+0xe8/0x104)
      [<c004765c>] (kthread) from [<c000fac8>] (ret_from_fork+0x14/0x2c)
      ---[ end trace 96052cda48865769 ]---
      
      The issue was reported and described in details by Lothar Waßmann and
      Christian Gmeiner in https://lkml.org/lkml/2014/9/9/123.
      
      Fix it by adding missed call of gpiochip_set_chained_irqchip()
      so GPIO IRQ chip helpers will set parent_irq for nested IRQs
      properly.
      Reported-by: NLothar Waßmann <LW@KARO-electronics.de>
      Tested-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fdd50409