1. 22 Jul, 2016 2 commits
  2. 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      78456d6f
    • 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
      cases.
      
      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: default avatarLinus Walleij <linus.walleij@linaro.org>
      da17f8a1
    • 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      acc6e331
  3. 04 Jul, 2016 3 commits
  4. 23 Jun, 2016 11 commits
  5. 18 Jun, 2016 2 commits
  6. 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
      GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE
      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: default avatarLinus Walleij <linus.walleij@linaro.org>
      bc0207a5
  7. 15 Jun, 2016 6 commits
    • Linus Walleij's avatar
      tools/gpio: add the gpio-event-mon tool · 97f69747
      Linus Walleij authored
      The gpio-event-mon is used from userspace as an example of how
      to monitor GPIO line events. It will latch on to a certain
      GPIO line on a certain gpiochip and print timestamped events
      as they arrive.
      
      Example output:
      $ gpio-event-mon -n gpiochip2 -o 0 -r -f
      Monitoring line 0 on gpiochip2
      Initial line value: 1
      GPIO EVENT 946685798487609863: falling edge
      GPIO EVENT 946685798732482910: rising edge
      GPIO EVENT 946685799115997314: falling edge
      GPIO EVENT 946685799381469726: rising edge
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      97f69747
    • 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
        line.
      
      - 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
        GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the
        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: default avatarLinus Walleij <linus.walleij@linaro.org>
      61f922db
    • Linus Walleij's avatar
      tools/gpio: add the gpio-hammer tool · 2a144dd0
      Linus Walleij authored
      The gpio-hammer is used from userspace as an example of how
      to retrieve a GPIO handle for one or several GPIO lines and
      hammer the outputs from low to high and back again. It will
      pulse the selected lines once per second for a specified
      number of times or indefinitely if no loop count is
      supplied.
      
      Example output:
      $ gpio-hammer -n gpiochip0 -o5 -o6 -o7
      Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1]
      [-] [5: 0, 6: 0, 7: 0]
      Tested-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2a144dd0
    • 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
        ioctl()
      - Use kmalloc() and kfree() for the linehandled, do not
        try to be fancy with devm_* it doesn't work the way I
        thought.
      - Fix const-correctness on the linehandle name field.
      Acked-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d7c51b47
    • Andy Shevchenko's avatar
      gpio: pca953x: enable driver on Intel Edison · 747e42a1
      Andy Shevchenko authored
      Intel Edison board has 4 GPIO expanders PCA9555a connected to I2C bus. Add an
      ID to support them.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      747e42a1
    • Rui Zhang's avatar
      gpio: acpi: add _DEP support for Acer One 10 · 3f86a635
      Rui Zhang authored
      On Acer One 10, the ACPI battery driver can not be probed because
      it depends on the GPIO controller as well as the I2C controller to work,
              Device (BATC)
              {
                  Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)
                  ...
                  Name (_DEP, Package (0x03)  // _DEP: Dependencies
                  {
                      I2C1,
                      GPO2,
                      GPO0
                  })
                  ...
              }
      
      The I2C dependency also exists on other platforms and has been fixed by commit
      40e7fcb1 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"),
      this patch resolves the GPIO dependency for Acer One 10.
      
      Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191Tested-by: default avatarStace A. Zacharov <stace75@gmail.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3f86a635
  8. 14 Jun, 2016 2 commits
  9. 13 Jun, 2016 2 commits
  10. 08 Jun, 2016 8 commits