1. 29 Aug, 2014 1 commit
  2. 28 Jul, 2014 3 commits
    • Alexandre Courbot's avatar
      gpio: add flags argument to gpiod_get*() functions · 39b2bbe3
      Alexandre Courbot authored
      The huge majority of GPIOs have their direction and initial value set
      right after being obtained by one of the gpiod_get() functions. The
      integer GPIO API had gpio_request_one() that took a convenience flags
      parameter allowing to specify an direction and value applied to the
      returned GPIO. This feature greatly simplifies client code and ensures
      errors are always handled properly.
      
      A similar feature has been requested for the gpiod API. Since setting
      the direction of a GPIO is so often the very next action done after
      obtaining its descriptor, we prefer to extend the existing functions
      instead of introducing new functions that would raise the
      number of gpiod getters to 16 (!).
      
      The drawback of this approach is that all gpiod clients need to be
      updated. To limit the pain, temporary macros are introduced that allow
      gpiod_get*() to be called with or without the extra flags argument. They
      will be removed once all consumer code has been updated.
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Reviewed-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      39b2bbe3
    • Mika Westerberg's avatar
      gpio / ACPI: Move event handling registration to gpiolib irqchip helpers · afa82fab
      Mika Westerberg authored
      Since now we have irqchip helpers that the GPIO chip drivers are supposed
      to use if possible, we can move the registration of ACPI events to happen
      in these helpers. This seems to be more natural place and might encourage
      GPIO chip driver writers to take advantage of the irqchip helpers.
      
      We make the functions available to GPIO chip drivers via private gpiolib.h,
      just in case generic irqchip helpers are not suitable.
      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>
      afa82fab
    • Linus Walleij's avatar
      gpio: split gpiod board registration into machine header · 0a6d3158
      Linus Walleij authored
      As per example from the regulator subsystem: put all defines and
      functions related to registering board info for GPIO descriptors
      into a separate <linux/gpio/machine.h> header.
      
      Cc: Andrew Victor <linux@maxim.org.za>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Acked-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: default avatarAlexandre Courbot <gnurou@gmail.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      0a6d3158
  3. 24 Jul, 2014 1 commit
  4. 23 Jul, 2014 3 commits
  5. 09 Jul, 2014 3 commits
  6. 12 Jun, 2014 1 commit
  7. 09 May, 2014 1 commit
    • Thierry Reding's avatar
      gpio: Add helpers for optional GPIOs · 29a1f233
      Thierry Reding authored
      Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers
      that make it easier for drivers to handle optional GPIOs.
      
      Currently in order to handle optional GPIOs, a driver needs to special
      case error handling for -ENOENT, such as this:
      
      	gpio = gpiod_get(dev, "foo");
      	if (IS_ERR(gpio)) {
      		if (PTR_ERR(gpio) != -ENOENT)
      			return PTR_ERR(gpio);
      
      		gpio = NULL;
      	}
      
      	if (gpio) {
      		/* set up GPIO */
      	}
      
      With these new helpers the above is reduced to:
      
      	gpio = gpiod_get_optional(dev, "foo");
      	if (IS_ERR(gpio))
      		return PTR_ERR(gpio);
      
      	if (gpio) {
      		/* set up GPIO */
      	}
      
      While at it, device-managed variants of these functions are also
      provided.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      29a1f233
  8. 02 May, 2014 1 commit
  9. 28 Apr, 2014 5 commits
  10. 14 Apr, 2014 1 commit
  11. 28 Mar, 2014 1 commit
  12. 26 Mar, 2014 1 commit
  13. 14 Mar, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: clamp returned values to the boolean range · 23600969
      Alexandre Courbot authored
      Nothing prevents GPIO drivers from returning values outside the
      boolean range, and as it turns out a few drivers are actually doing so.
      These values were passed as-is to unsuspecting consumers and created
      confusion.
      
      This patch makes the internal _gpiod_get_raw_value() function return a
      bool, effectively clamping the GPIO value to the boolean range no
      matter what the driver does.
      
      While we are at it, we also change the value parameter of
      _gpiod_set_raw_value() to bool type before drivers start doing funny
      things with it as well.
      
      Another way to fix this would be to change the prototypes of the driver
      interface to use bool directly, but this would require a huge
      cross-systems patch so this simpler solution is preferred.
      
      Changes since v1:
      - Change local variable type to bool as well, use boolean values in
        code
      - Also change prototype of open drain/open source setting functions
        since they are only called from _gpiod_set_raw_value()
      
      This probably calls for a larger booleanization of gpiolib, but let's
      keep that for a latter change - right now we need to address the issue
      of non-boolean values returned by drivers.
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      23600969
  14. 13 Mar, 2014 2 commits
    • Mika Westerberg's avatar
      gpio / ACPI: Rework ACPI GPIO event handling · 6072b9dc
      Mika Westerberg authored
      The current ACPI GPIO event handling code was never tested against real
      hardware with functioning GPIO triggered events (at the time such hardware
      wasn't available). Thus it misses certain things like requesting the GPIOs
      properly, passing correct flags to the interrupt handler and so on.
      
      This patch reworks ACPI GPIO event handling so that we:
      
       1) Use struct acpi_gpio_event for all GPIO signaled events.
       2) Switch to use GPIO descriptor API and request GPIOs by calling
          gpiochip_request_own_desc() that we added in a previous patch.
       3) Pass proper flags from ACPI GPIO resource to request_threaded_irq().
      
      Also instead of open-coding the _AEI iteration loop we can use
      acpi_walk_resources(). This simplifies the code a bit and fixes memory leak
      that was caused by missing kfree() for buffer returned by
      acpi_get_event_resources().
      
      Since the remove path now calls gpiochip_free_own_desc() which takes GPIO
      spinlock we need to call acpi_gpiochip_remove() outside of that lock
      (analogous to acpi_gpiochip_add() path where the lock is released before
      those funtions are called).
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      6072b9dc
    • Mika Westerberg's avatar
      gpiolib: Allow GPIO chips to request their own GPIOs · 77c2d792
      Mika Westerberg authored
      Sometimes it is useful to allow GPIO chips themselves to request GPIOs they
      own through gpiolib API. One use case is ACPI ASL code that should be able
      to toggle GPIOs through GPIO operation regions.
      
      We can't use gpio_request() because it will pin the module to the kernel
      forever (it calls try_module_get()). To solve this we move module refcount
      manipulation to gpiod_request() and let __gpiod_request() handle the actual
      request. This changes the sequence a bit as now try_module_get() is called
      outside of gpio_lock (I think this is safe, try_module_get() handles
      serialization it needs already).
      
      Then we provide gpiolib internal functions gpiochip_request/free_own_desc()
      that do the same as gpio_request() but don't manipulate module refrence
      count. This allows the GPIO chip driver to request and free descriptors it
      owns without being pinned to the kernel forever.
      Signed-off-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      77c2d792
  15. 07 Mar, 2014 1 commit
  16. 12 Feb, 2014 2 commits
  17. 07 Feb, 2014 1 commit
  18. 08 Jan, 2014 2 commits
  19. 12 Dec, 2013 1 commit
  20. 11 Dec, 2013 1 commit
    • Tejun Heo's avatar
      kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly · 324a56e1
      Tejun Heo authored
      kernfs has just been separated out from sysfs and we're already in
      full conflict mode.  Nothing can make the situation any worse.  Let's
      take the chance to name things properly.
      
      This patch performs the following renames.
      
      * s/sysfs_elem_dir/kernfs_elem_dir/
      * s/sysfs_elem_symlink/kernfs_elem_symlink/
      * s/sysfs_elem_attr/kernfs_elem_file/
      * s/sysfs_dirent/kernfs_node/
      * s/sd/kn/ in kernfs proper
      * s/parent_sd/parent/
      * s/target_sd/target/
      * s/dir_sd/parent/
      * s/to_sysfs_dirent()/rb_to_kn()/
      * misc renames of local vars when they conflict with the above
      
      Because md, mic and gpio dig into sysfs details, this patch ends up
      modifying them.  All are sysfs_dirent renames and trivial.  While we
      can avoid these by introducing a dummy wrapping struct sysfs_dirent
      around kernfs_node, given the limited usage outside kernfs and sysfs
      proper, I don't think such workaround is called for.
      
      This patch is strictly rename only and doesn't introduce any
      functional difference.
      
      - mic / gpio renames were missing.  Spotted by kbuild test robot.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
      Cc: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      324a56e1
  21. 09 Dec, 2013 4 commits
  22. 04 Dec, 2013 2 commits
  23. 03 Dec, 2013 1 commit