1. 02 Mar, 2018 1 commit
    • Arnd Bergmann's avatar
      gpio: raspberrypi-ext: fix firmware dependency · 7ed91505
      Arnd Bergmann authored
      When the firmware driver is a loadable module, the gpio driver cannot be
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_set':
      gpio-raspberrypi-exp.c:(.text+0xb4): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get':
      gpio-raspberrypi-exp.c:(.text+0x1ec): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get_direction':
      gpio-raspberrypi-exp.c:(.text+0x360): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get_polarity':
      gpio-raspberrypi-exp.c:(.text+0x4d4): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_dir_out':
      gpio-raspberrypi-exp.c:(.text+0x670): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o:gpio-raspberrypi-exp.c:(.text+0x7fc): more undefined references to `rpi_firmware_property' follow
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_dir_in':
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_probe':
      gpio-raspberrypi-exp.c:(.text+0x93c): undefined reference to `rpi_firmware_get'
      We already have a Kconfig dependency for it, but when compile-testing, it
      is disregarded.
      This changes the dependency so that compile-testing is only done when the
      firmware driver is completely disabled.
      Fixes: a98d90e7
       ("gpio: raspberrypi-exp: Driver for RPi3 GPIO expander via mailbox service")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  2. 01 Mar, 2018 1 commit
  3. 26 Feb, 2018 1 commit
  4. 22 Feb, 2018 3 commits
  5. 11 Jan, 2018 1 commit
    • Arnd Bergmann's avatar
      gpio: winbond: fix ISA_BUS_API dependency · 92a8046c
      Arnd Bergmann authored
      The newly added GPIO driver for winbond chipsets causes a
      circular dependency warning in Kconfig:
      drivers/gpio/Kconfig:13:error: recursive dependency detected!
      drivers/gpio/Kconfig:13:	symbol GPIOLIB is selected by STX104
      drivers/iio/adc/Kconfig:699:	symbol STX104 depends on ISA_BUS_API
      arch/Kconfig:830:	symbol ISA_BUS_API is selected by GPIO_WINBOND
      drivers/gpio/Kconfig:701:	symbol GPIO_WINBOND depends on GPIOLIB
      The underlying problem is that ISA_BUS_API is not meant to be selected by
      device drivers, instead it is provided by the architectures that support
      ISA add-on card devices, or in case of x86 have this explicitly enabled.
      This particular driver appears to be different from the other ISA_BUS_API
      based drivers, in that it is not normally an add-on card (ISA or PC104)
      but instead is an LPC-attached component on the mainboard. We already
      support other functionality provided by this chip, at least
      drivers/watchdog/w83627hf_wdt.c and drivers/hwmon/w83627ehf.c, plus
      there is a discovery function for this hardware in
      If we want to use this driver without having to enable CONFIG_EXPERT,
      it might be better to not use the isa_bus_type for it, but rather
      turn it into a platform_driver, acpi_driver or add an MFD for it that
      is shared with the wdt and hwmon portions and does the probing.
      For now, this patch fixes the dependency by changing 'select' into
      'depends on'.
      Cc: William Breathitt Gray <vilhelm.gray@gmail.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Fixes: a0d65009
       ("gpio: winbond: Add driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  6. 10 Jan, 2018 1 commit
    • William Breathitt Gray's avatar
      gpio: Add GPIO support for the ACCES PCIe-IDIO-24 family · 58556204
      William Breathitt Gray authored
      The ACCES PCIe-IDIO-24 device provides 56 lines of digital I/O (24 lines
      of optically-isolated non-polarized digital inputs for AC and DC control
      signals, 24 lines of isolated solid state FET digital outputs, and 8
      non-isolated TTL/CMOS compatible programmable I/O). An interrupt is
      generated when any of the inputs change state (low to high or high to
      Input filter control is not supported by this driver, and input filters
      are deactivated by this driver. These devices are capable of
      get_multiple and set_multiple functionality, but these functions have
      not yet been implemented for this driver. Change-Of-State (COS)
      detection functionality may be configured to fire interrupts on
      exclusively rising/falling edges, but this driver currently only
      implements COS detection for either both edges or none.
      Signed-off-by: default avatarWilliam Breathitt Gray <vilhelm.gray@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  7. 09 Jan, 2018 1 commit
  8. 07 Dec, 2017 1 commit
  9. 08 Nov, 2017 1 commit
  10. 31 Oct, 2017 2 commits
  11. 23 Oct, 2017 1 commit
    • Masahiro Yamada's avatar
      gpio: uniphier: add UniPhier GPIO controller driver · dbe776c2
      Masahiro Yamada authored
      This GPIO controller is used on UniPhier SoC family.
      It also serves as an interrupt controller, but interrupt signals are
      just delivered to the parent irqchip without any latching or OR'ing.
      This type of hardware can be well described with hierarchy IRQ domain.
      One unfortunate thing for this device is that the interrupt mapping to
      the interrupt parent is not contiguous.
      I asked how DT can describe interrupt mapping between two irqchips [1],
      but I could not find a good solution (at least in the framework level).
      In fact, irqchip drivers using hierarchy domain generally hard-code the
      DT binding of their parent.
      After tackling on several approaches such as hard-code of hwirqs,
      irq_domain_push_irq(), I ended up with a vendor specific property.
      If we come up with a good idea to support this in the framework, we
      can migrate over to it, but we can live with a driver-level solution
      for now.
      [1] https://lkml.org/lkml/2017/7/6/758
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  12. 19 Oct, 2017 1 commit
    • Lukas Wunner's avatar
      gpio: Add driver for Maxim MAX3191x industrial serializer · b2f68edf
      Lukas Wunner authored
      The driver was developed for and tested with the MAX31913 built into
      the Revolution Pi by KUNBUS, but should work with all members of the
      MAX3191x family:
      MAX31910: low power
      MAX31911: LED drivers
      MAX31912: LED drivers + 2nd voltage monitor + low power
      MAX31913: LED drivers + 2nd voltage monitor
      MAX31953: LED drivers + 2nd voltage monitor + isolation
      MAX31963: LED drivers + 2nd voltage monitor + isolation + buck regulator
      Cc: Mathias Duckeck <m.duckeck@kunbus.de>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  13. 17 Oct, 2017 1 commit
  14. 19 Sep, 2017 1 commit
  15. 22 Aug, 2017 1 commit
  16. 20 Aug, 2017 1 commit
  17. 14 Aug, 2017 1 commit
  18. 01 Aug, 2017 1 commit
  19. 21 Jun, 2017 1 commit
  20. 31 May, 2017 1 commit
  21. 29 May, 2017 2 commits
  22. 23 May, 2017 3 commits
  23. 22 May, 2017 2 commits
  24. 28 Apr, 2017 1 commit
  25. 27 Apr, 2017 1 commit
  26. 24 Apr, 2017 1 commit
  27. 24 Mar, 2017 1 commit
    • Russell King's avatar
      gpio: add generic single-register fixed-direction GPIO driver · 380639c7
      Russell King authored
      Add a simple, generic, single register fixed-direction GPIO driver.
      This is able to support a single register with a mixture of inputs
      and outputs.
      This is different from gpio-mmio and gpio-74xx-mmio:
      * gpio-mmio doesn't allow a fixed direction, it assumes there is always
        a direction register.
      * gpio-74xx-mmio only supports all-in or all-out setups
      * gpio-74xx-mmio is DT only, this needs to support legacy too
      * they don't double-read when getting the GPIO value, as required by
        some implementations that this driver supports
      * we need to always do 32-bit reads, which bgpio doesn't guarantee
      * the current output state may not be readable from the hardware
        register - reading may reflect input status but not output status.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  28. 22 Mar, 2017 2 commits
  29. 16 Mar, 2017 1 commit
  30. 15 Mar, 2017 1 commit
  31. 13 Feb, 2017 1 commit
  32. 06 Feb, 2017 1 commit