1. 26 Jan, 2017 1 commit
    • Mika Westerberg's avatar
      pinctrl / gpio: Introduce .set_config() callback for GPIO chips · 2956b5d9
      Mika Westerberg authored
      Currently we already have two pin configuration related callbacks
      available for GPIO chips .set_single_ended() and .set_debounce(). In
      future we expect to have even more, which does not scale well if we need
      to add yet another callback to the GPIO chip structure for each possible
      configuration parameter.
      Better solution is to reuse what we already have available in the
      generic pinconf.
      To support this, we introduce a new .set_config() callback for GPIO
      chips. The callback takes a single packed pin configuration value as
      parameter. This can then be extended easily beyond what is currently
      supported by just adding new types to the generic pinconf enum.
      If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
      just assign gpiochip_generic_config() (introduced in this patch) to
      .set_config and that will take care configuration requests are directed
      to the pinctrl driver.
      We then convert the existing drivers over .set_config() and finally
      remove the .set_single_ended() and .set_debounce() callbacks.
      Suggested-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  2. 07 Dec, 2016 1 commit
    • Lars-Peter Clausen's avatar
      gpio: chardev: Return error for seek operations · f4e81c52
      Lars-Peter Clausen authored
      The GPIO chardev is used for management tasks (allocating line and event
      handles) and does neither support read() nor write() operations. Hence it
      does not make much sense to allow seek operations.
      Currently the chardev uses noop_llseek() for its seek implementation. This
      function does not move the pointer and simply returns the current position
      (always 0 for the GPIO chardev). noop_llseek() is primarily meant for
      devices that can not support seek, but where there might be a user that
      depends on the seek() operation succeeding. For newly added devices that
      can not support seek operations it is recommended to use no_llseek(), which
      will return an error. For more information see commit 6038f373
      ("llseek: automatically add .llseek fop").
      Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
      But it is highly unlikely that since then userspace applications have
      appeared that rely on being able to perform non-failing seek operations on
      a GPIO chardev file descriptor. So it should be safe to change from
      noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
      open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
      from the file. Neither of these should be set on a file that does not
      support seek operations.
      Cc: stable@vger.kernel.org
      Fixes: 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  3. 25 Nov, 2016 1 commit
    • Linus Walleij's avatar
      gpio: simplify adding threaded interrupts · d245b3f9
      Linus Walleij authored
      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: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  4. 15 Nov, 2016 3 commits
    • Linus Walleij's avatar
      gpio: tag line labels used for interrupts · 3940c34a
      Linus Walleij authored
      When a GPIO line is marked as used for an interrupt, it is
      helpful to set the label to "interrupt" so we know what is
      going on when inspecting the lines.
      If a GPIO is already properly named by gpiod_get*() we don't
      need to do this. It only happens when a line is used from
      the irqchip side of a GPIO driver without communicating
      with the GPIO side, such as when gpiochip is used as interrupt
      provider in the device tree.
      If the line is still marked as used by "interrupt" when we
      unmark it as used by an interrupt, also remove this label
      from the descriptor.
      Also shape up the code around unmarking IRQ lines.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Linus Walleij's avatar
      gpio: clamp values on gpio[d]_direction_output() · ad17731d
      Linus Walleij authored
      I saw weird values != [0,1] being passed down to drivers
      in their .set_direction_output() callbacks. Go over the
      gpiolib and make sure to hammer it to [0,1] before hitting
      the driver to avoid undesired side effects.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Linus Walleij's avatar
      gpio: do not double-check direction on sleeping chips · 60f8339e
      Linus Walleij authored
      When locking a GPIO line as IRQ, we go to lengths to
      double-check that the line is really set as input before
      marking it as used for IRQ. This is not good on GPIO chips
      that can sleep, because this function is called in IRQ-safe
      context. Just skip this if it can't be checked quickly.
      Currently this happens on sleeping expanders such as STMPE
      or TC3589x:
      BUG: scheduling while atomic: swapper/1/0x00000002
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38
      Hardware name: Nomadik STn8815
      [<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14)
      [<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80)
      [<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460)
      [<c042df14>] (__schedule) from [<c042e028>] (schedule+0x54/0xb8)
      This patch fixes that problem and relies on the direction
      read from the chip when it was added.
      Cc: stable@vger.kernel.org
      Fixes: 9c10280d ("gpio: flush direction status in gpiochip_lock_as_irq()")
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  5. 31 Oct, 2016 1 commit
    • Lars-Peter Clausen's avatar
      gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak · 953b956a
      Lars-Peter Clausen authored
      When allocating a new line handle or event a file is allocated that it is
      associated to. The file is attached to a file descriptor of the current
      process and the file descriptor is returned to userspace using
      copy_to_user(). If this copy operation fails the line handle or event
      allocation is aborted, all acquired resources are freed and an error is
      But the file struct is not freed and left attached to the userspace
      application and even though the file descriptor number was not copied it is
      trivial to guess. If a userspace application performs a IOCTL on such a
      left over file descriptor it will trigger a use-after-free and if the file
      descriptor is closed (latest when the application exits) a double-free is
      anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
      file descriptor for the current process and install the file struct in the
      file descriptor. As soon as the file struct is installed in the file
      descriptor it is accessible by userspace (even if the IOCTL itself hasn't
      completed yet), this means uninstalling the fd on the error path is not an
      option, since userspace might already got a reference to the file.
      Instead anon_inode_getfd() needs to be broken into its individual steps.
      The allocation of the file struct and file descriptor is done first, then
      the copy_to_user() is executed and only if it succeeds the file is
      Since the file struct is reference counted it can not be just freed, but
      its reference needs to be dropped, which will also call the release()
      callback, which will free the state attached to the file. So in this case
      the normal error cleanup path should not be taken.
      Cc: stable@vger.kernel.org
      Fixes: d932cd49 ("gpio: free handles in fringe cases")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  6. 21 Oct, 2016 8 commits
  7. 03 Oct, 2016 2 commits
    • Linus Walleij's avatar
      gpio: acpi: separation of concerns · 031ba28a
      Linus Walleij authored
      The generic GPIO library directly implement code for acpi_find_gpio()
      which is only used with CONFIG_ACPI. This was probably done because
      OF did the same thing, but I removed that so remove this too.
      Rename the internal acpi_find_gpio() in gpiolib-acpi.c to
      acpi_populate_gpio_lookup() which seems to be more appropriate anyway
      so as to avoid a namespace clash with the same function.
      Make the stub return -ENOENT rather than -ENOSYS (as that is for
      For some reason the sunxi pin control driver was including the private
      gpiolib header, it works just fine without it so remove that oneliner.
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Linus Walleij's avatar
      gpio: OF: separation of concerns · ea713bc4
      Linus Walleij authored
      The generic GPIO library directly implement code for of_find_gpio()
      which is only used with CONFIG_OF and causes compilation problems
      on archs that do not even have stubs for OF functions, especially
      on UM that does not implement any IO remap functions.
      Move the function to gpiolib-of.c, implement a static inline stub
      in gpiolib.h returning PTR_ERR(-ENOENT) if CONFIG_OF_GPIO is not
      set and be done with it.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  8. 23 Sep, 2016 1 commit
    • Mika Westerberg's avatar
      gpiolib: Make it possible to exclude GPIOs from IRQ domain · 79b804cb
      Mika Westerberg authored
      When using GPIO irqchip helpers to setup irqchip for a gpiolib based
      driver, it is not possible to select which GPIOs to add to the IRQ domain.
      Instead it just adds all GPIOs which is not always desired. For example
      there might be GPIOs that for some reason cannot generated normal
      interrupts at all.
      To support this we add a flag irq_need_valid_mask to struct gpio_chip. When
      this flag is set the core allocates irq_valid_mask that holds one bit for
      each GPIO the chip has. By default all bits are set but drivers can
      manipulate this using set_bit() and clear_bit() accordingly.
      Then when gpiochip_irqchip_add() is called, this mask is checked and all
      GPIOs with bit is set are added to the IRQ domain created for the GPIO
      Suggested-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  9. 13 Sep, 2016 1 commit
  10. 12 Sep, 2016 1 commit
  11. 19 Aug, 2016 1 commit
  12. 22 Jul, 2016 1 commit
  13. 06 Jul, 2016 3 commits
    • Linus Walleij's avatar
      Revert "gpio: convince line to become input in irq helper" · 78456d6f
      Linus Walleij authored
      This reverts commit 7e7c059c.
      I was wrong about trying to do this, as it breaks the
      orthogonality between gpiochips and irqchips.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Lars-Peter Clausen's avatar
      gpiolib: of_find_gpio(): Don't discard errors · da17f8a1
      Lars-Peter Clausen authored
      Since commit dd34c37a ("gpio: of: Allow -gpio suffix for property
      names") when requesting a GPIO from the devicetree gpiolib looks for
      properties with both the '-gpio' and the '-gpios' suffix. This was
      implemented by first searching for the property with the '-gpios' suffix
      and if that yields an error try the '-gpio' suffix. This approach has the
      issue that any error returned when looking for the '-gpios' suffix is
      silently discarded.
      Commit 06fc3b70 ("gpio: of: Fix handling for deferred probe for -gpio
      suffix") partially addressed the issue by treating the EPROBE_DEFER error
      as a special condition. This fixed the case when the property is specified,
      but the GPIO provider is not ready yet. But there are other cases in which
      of_get_named_gpiod_flags() returns an error even though the property is
      specified, e.g. if the specification is incorrect.
      of_find_gpio() should only try to look for the property with the '-gpio'
      suffix if no property with the '-gpios' suffix was found. If the property
      was not found of_get_named_gpiod_flags() will return -ENOENT, so update the
      condition to abort and propagate the error to the caller in all other
      This is important for gpiod_get_optinal() and friends to behave correctly
      in case the specifier contains errors. Without this patch they'll return
      NULL if the property uses the '-gpios' suffix and the specifier contains
      errors, which falsely indicates to the caller that no GPIO was specified.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Thierry Reding's avatar
      gpio: of: Allow overriding the device node · acc6e331
      Thierry Reding authored
      When registering a GPIO chip, drivers can override the device tree node
      associated with the chip by setting the chip's ->of_node field. If set,
      this field is supposed to take precedence over the ->parent->of_node
      field, but the code doesn't actually do that.
      Commit 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and
      struct gg_data") exposes this because it now no longer matches on the
      GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
      is set using the procedure described above.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  14. 04 Jul, 2016 2 commits
    • Linus Walleij's avatar
      gpio: free handles in fringe cases · d932cd49
      Linus Walleij authored
      If we fail when copying the ioctl() struct to userspace we still
      need to clean up the cruft otherwise left behind or it will stay
      around until the issuing process terminates the file handle.
      Reported-by: default avatarAlexander Stein <alexander.stein@systec-electronic.com>
      Acked-by: default avatarAlexander Stein <alexander.stein@systec-electronic.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Johan Hovold's avatar
      Revert "gpiolib: Split GPIO flags parsing and GPIO configuration" · 85b03b30
      Johan Hovold authored
      This reverts commit 923b93e4.
      Make sure consumers do not overwrite gpio flags for pins that have
      already been claimed.
      While adding support for gpio drivers to refuse a request using
      unsupported flags, the order of when the requested flag was checked and
      the new flags were applied was reversed to that consumers could
      overwrite flags for already requested gpios.
      This not only affects device-tree setups where two drivers could request
      the same gpio using conflicting configurations, but also allowed user
      space to clear gpio flags for already claimed pins simply by attempting
      to export them through the sysfs interface. By for example clearing the
      FLAG_ACTIVE_LOW flag this way, user space could effectively change the
      polarity of a signal.
      Reverting this change obviously prevents gpio drivers from doing sanity
      checks on the flags in their request callbacks. Fortunately only one
      recently added driver (gpio-tps65218 in v4.6) appears to do this, and a
      follow up patch could restore this functionality through a different
      Cc: stable <stable@vger.kernel.org>	# 4.4
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  15. 23 Jun, 2016 1 commit
  16. 22 Jun, 2016 2 commits
  17. 18 Jun, 2016 2 commits
  18. 17 Jun, 2016 2 commits
  19. 16 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      gpiolib: avoid uninitialized data in gpio kfifo · bc0207a5
      Arnd Bergmann authored
      gcc reports a theoretical case for returning uninitialized data in
      the kfifo when a GPIO interrupt happens and neither
      are set:
      drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
      drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      This case should not happen, but to be on the safe side, let's
      return from the irq handler without adding data to the FIFO
      to ensure we can never leak stack data to user space.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events")
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  20. 15 Jun, 2016 2 commits
    • Linus Walleij's avatar
      gpio: userspace ABI for reading GPIO line events · 61f922db
      Linus Walleij authored
      This adds an ABI for listening to events on GPIO lines.
      The mechanism returns an anonymous file handle to a request
      to listen to a specific offset on a specific gpiochip.
      To fetch the stream of events from the file handle, userspace
      simply reads an event.
      - Events can be requested with the same flags as ordinary
        handles, i.e. open drain or open source. An ioctl() call
        GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired
      - Events can be requested for falling edge events, rising
        edge events, or both.
      - All events are timestamped using the kernel real time
        nanosecond timestamp (the same as is used by IIO).
      - The supplied consumer label will appear in "lsgpio"
        listings of the lines, and in /proc/interrupts as the
        mechanism will request an interrupt from the gpio chip.
      - Events are not supported on gpiochips that do not serve
        interrupts (no legal .to_irq() call). The event interrupt
        is threaded to avoid any realtime problems.
      - It is possible to also directly read the current value
        of the registered GPIO line by issuing the same
        line handles. Setting the value is not supported: we
        do not listen to events on output lines.
      This ABI is strongly influenced by Industrial I/O and surpasses
      the old sysfs ABI by providing proper precision timestamps,
      making it possible to set flags like open drain, and put
      consumer names on the GPIO lines.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Linus Walleij's avatar
      gpio: userspace ABI for reading/writing GPIO lines · d7c51b47
      Linus Walleij authored
      This adds a userspace ABI for reading and writing GPIO lines.
      The mechanism returns an anonymous file handle to a request
      to read/write n offsets from a gpiochip. This file handle
      in turn accepts two ioctl()s: one that reads and one that
      writes values to the selected lines.
      - Handles can be requested as input/output, active low,
        open drain, open source, however when you issue a request
        for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all
        have the same flags, i.e. all inputs or all outputs, all
        open drain etc. If a granular control of the flags for
        each line is desired, they need to be requested
        individually, not in a batch.
      - The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be
        issued also to output lines to verify that the hardware
        is in the expected state.
      - It reads and writes up to GPIOHANDLES_MAX lines at once,
        utilizing the .set_multiple() call in the driver if
        possible, making the call efficient if several lines
        can be written with a single register update.
      The limitation of GPIOHANDLES_MAX to 64 lines is done under
      the assumption that we may expect hardware that can issue a
      transaction updating 64 bits at an instant but unlikely
      anything larger than that.
      ChangeLog v2->v3:
      - Use gpiod_get_value_cansleep() so we support also slowpath
        GPIO drivers.
      - Fix up the UAPI docs kerneldoc.
      - Allocate the anonymous fd last, so that the release
        function don't get called until that point of something
        fails. After this point, skip the errorpath.
      ChangeLog v1->v2:
      - Handle ioctl_compat() properly based on a similar patch
        to the other ioctl() handling code.
      - Use _IOWR() as we pass pointers both in and out of the
      - Use kmalloc() and kfree() for the linehandled, do not
        try to be fancy with devm_* it doesn't work the way I
      - Fix const-correctness on the linehandle name field.
      Acked-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  21. 08 Jun, 2016 2 commits
    • Ricardo Ribalda Delgado's avatar
      gpiolib: Fix unaligned used of reference counters · f4833b8c
      Ricardo Ribalda Delgado authored
      gpiolib relies on the reference counters to clean up the gpio_device
      Although the number of get/put is properly aligned on gpiolib.c
      itself, it does not take into consideration how the referece counters
      are affected by other external functions such as cdev_add and device_add.
      Because of this, after the last call to put_device, the reference counter
      has a value of +3, therefore never calling gpiodevice_release.
      Due to the fact that some of the device  has already been cleaned on
      gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call
      to of_gpiochip_find_and_xlate).
      Cc: stable@vger.kernel.org
      Signed-off-by: Ricardo Ribalda Delgado's avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
    • Ricardo Ribalda Delgado's avatar
      gpiolib: Fix NULL pointer deference · 11f33a6d
      Ricardo Ribalda Delgado authored
      Under some circumstances, a gpiochip might be half cleaned from the
      gpio_device list.
      This patch makes sure that the chip pointer is still valid, before
      calling the match function.
      [  104.088296] BUG: unable to handle kernel NULL pointer dereference at
      [  104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80
      [  104.128273] Call Trace:
      [  104.129802]  [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0
      [  104.131353]  [<ffffffff813cd910>] gpiochip_find+0x60/0x90
      [  104.132868]  [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120
      [  104.141586]  [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360
      Cc: stable@vger.kernel.org
      Signed-off-by: Ricardo Ribalda Delgado's avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  22. 30 May, 2016 1 commit