1. 11 Jan, 2017 1 commit
  2. 24 Oct, 2016 1 commit
  3. 03 Oct, 2016 4 commits
  4. 26 Apr, 2016 1 commit
  5. 19 Feb, 2016 1 commit
  6. 15 Feb, 2016 2 commits
  7. 11 Feb, 2016 3 commits
    • Linus Walleij's avatar
      gpio: reflect base and ngpio into gpio_device · fdeb8e15
      Linus Walleij authored
      Some information about the GPIO chip need to stay around also
      after the gpio_chip has been removed and only the gpio_device
      persist. The base and ngpio are such things, for example we
      don't want a new chip arriving to overlap the number space
      of a dangling gpio_device, and the chardev may still query
      the device for the number of lines etc.
      
      Note that the code that assigns base and insert gpio_device
      into the global list no longer check for a missing gpio_chip:
      we respect the number space allocated by any other gpio_device.
      
      As a consequence of the gdev being referenced directly from
      the gpio_desc, we need to verify it differently from all
      in-kernel API calls that fall through to direct queries to
      the gpio_chip vtable: we first check that desc is !NULL, then
      that desc->gdev is !NULL, then, if desc->gdev->chip is NULL,
      we *BAIL OUT* without any error, so as to manage the case
      where operations are requested on a device that is gone.
      
      These checks were non-uniform and partly missing in the past:
      so to simplify: create the macros VALIDATE_DESC() that will
      return -EINVAL if the desc or desc->gdev is missing and just
      0 if the chip is gone, and conversely VALIDATE_DESC_VOID()
      for the case where the function does not return an error.
      By using these macros, we get warning messages about missing
      gdev with reference to the right function in the kernel log.
      
      Despite the macro business this simplifies the code and make
      it more readable than if we copy/paste the same descriptor
      checking code into all code ABI call sites (IMHO).
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fdeb8e15
    • Linus Walleij's avatar
      gpio: move descriptors into gpio_device · 1c3cdb18
      Linus Walleij authored
      We need gpio_device to hold the descriptors so that they can
      be lifecycled with the struct gpio_device held from userspace.
      Move the descriptor array into gpio_device. Also rename it from
      "desc" (singularis) to "descs" (pluralis) to reflect the fact
      that it is an array.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      1c3cdb18
    • Linus Walleij's avatar
      gpio: move sysfs mock device to the gpio_device · afbc4f31
      Linus Walleij authored
      Since gpio_device is the struct that survives if the backing
      gpio_chip is removed, move the sysfs mock device to this state
      container so it becomes part of the dangling state of the
      GPIO device on removal.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      afbc4f31
  8. 09 Feb, 2016 3 commits
    • Linus Walleij's avatar
      gpio: add a userspace chardev ABI for GPIOs · 3c702e99
      Linus Walleij authored
      A new chardev that is to be used for userspace GPIO access is
      added in this patch. It is intended to gradually replace the
      horribly broken sysfs ABI.
      
      Using a chardev has many upsides:
      
      - All operations are per-gpiochip, which is the actual
        device underlying the GPIOs, making us tie in to the
        kernel device model properly.
      
      - Hotpluggable GPIO controllers can come and go, as this
        kind of problem has been know to userspace for character
        devices since ages, and if a gpiochip handle is held in
        userspace we know we will break something, whereas the
        sysfs is stateless.
      
      - The one-value-per-file rule of sysfs is really hard to
        maintain when you want to twist more than one knob at a time,
        for example have in-kernel APIs to switch several GPIO
        lines at the same time, and this will be possible to do
        with a single ioctl() from userspace, saving a lot of
        context switching.
      
      We also need to add a new bus type for GPIO. This is
      necessary for example for userspace coldplug, where sysfs is
      traversed to find the boot-time device nodes and create the
      character devices in /dev.
      
      This new chardev ABI is *non* *optional* and can be counted
      on to be present in the future, emphasizing the preference
      of this ABI.
      
      The ABI only implements one single ioctl() to get the name
      and number of GPIO lines of a chip. Even this is debatable:
      see it as a minimal example for review. This ABI shall be
      ruthlessly reviewed and etched in stone.
      
      The old /sys/class/gpio is still optional to compile in,
      but will be deprecated.
      
      Unique device IDs are created using IDR, which is overkill
      and insanely scalable, but also well tested.
      
      Cc: Johan Hovold <johan@kernel.org>
      Cc: Michael Welling <mwelling@ieee.org>
      Cc: Markus Pargmann <mpa@pengutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3c702e99
    • Linus Walleij's avatar
      gpio: refer to gpio device in prints and debugfs · 34ffd85d
      Linus Walleij authored
      We use the new struct device inside gpio_chip to related debug
      prints and warnings, and we also add it to the debugfs dump.
      
      Cc: Johan Hovold <johan@kernel.org>
      Cc: Michael Welling <mwelling@ieee.org>
      Cc: Markus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      34ffd85d
    • Linus Walleij's avatar
      gpio: make the gpiochip a real device · ff2b1359
      Linus Walleij authored
      GPIO chips have been around for years, but were never real devices,
      instead they were piggy-backing on a parent device (such as a
      platform_device or amba_device) but this was always optional.
      GPIO chips could also exist without any device at all, with its
      struct device *parent (ex *dev) pointer being set to null.
      
      When sysfs was in use, a mock device would be created, with the
      optional parent assigned, or just floating orphaned with NULL
      as parent.
      
      If sysfs is active, it will use this device as parent.
      
      We now create a gpio_device struct containing a real
      struct device and move the subsystem over to using that. The
      list of struct gpio_chip:s is augmented to hold struct
      gpio_device:s and we find gpio_chips:s by first looking up
      the struct gpio_device.
      
      The struct gpio_device is designed to stay around even if the
      gpio_chip is removed, so as to satisfy users in userspace
      that need a backing data structure to hold the state of the
      session initiated with e.g. a character device even if there is
      no physical chip anymore.
      
      From this point on, gpiochips are devices.
      
      Cc: Johan Hovold <johan@kernel.org>
      Cc: Michael Welling <mwelling@ieee.org>
      Cc: Markus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ff2b1359
  9. 01 Jan, 2016 1 commit
  10. 13 Dec, 2015 1 commit
  11. 11 Dec, 2015 1 commit
  12. 19 Nov, 2015 1 commit
  13. 24 Sep, 2015 1 commit
    • Markus Pargmann's avatar
      gpio: Introduce gpio descriptor 'name' · c0017ed7
      Markus Pargmann authored
      The latest gpio hogging mechanism assigns each gpio a 'line-name' in the
      devicetree. The 'name' field is different from the 'label' field.
      'label' is only used for requested GPIOs to describe its current use by
      driver or userspace.
      
      The 'name' field describes the GPIO itself, not the use. This is most
      likely identical to the label in the schematic on the GPIO line and
      should help to find this particular GPIO.
      
      This is equivalent to the gpiochip->names array. However names should be
      stored in the GPIO descriptor. We will use gpiochip->names in the future
      only as initializer for the GPIO descriptors for drivers that assign
      GPIO names hardcoded. All other GPIO names will be parsed from DT and
      directly assigned to the GPIO descriptor.
      
      This patch adds a helper function to find gpio descriptors by name
      instead of gpio number.
      Signed-off-by: default avatarMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c0017ed7
  14. 14 Sep, 2015 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / property: Extend device_get_next_child_node() to data-only nodes · 504a3374
      Rafael J. Wysocki authored
      Make device_get_next_child_node() work with ACPI data-only subnodes
      introduced previously.
      
      Namely, replace acpi_get_next_child() with acpi_get_next_subnode()
      that can handle (and return) child device objects as well as child
      data-only subnodes of the given device and modify the ACPI part
      of the GPIO subsystem to handle data-only subnodes returned by it.
      
      To that end, introduce acpi_node_get_gpiod() taking a struct
      fwnode_handle pointer as the first argument.  That argument may
      point to an ACPI device object as well as to a data-only subnode
      and the function should do the right thing (ie. look for the matching
      GPIO descriptor correctly) in either case.
      
      Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod()
      instead of acpi_get_gpiod_by_index() which automatically causes
      devm_get_gpiod_from_child() to work with ACPI data-only subnodes
      that may be returned by device_get_next_child_node() which in turn
      is required by the users of that function (the gpio_keys_polled
      and gpio-leds drivers).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      504a3374
  15. 12 May, 2015 4 commits
  16. 16 Mar, 2015 1 commit
  17. 05 Mar, 2015 2 commits
  18. 04 Mar, 2015 1 commit
    • Benoit Parrot's avatar
      gpio: add GPIO hogging mechanism · f625d460
      Benoit Parrot authored
      Based on Boris Brezillion's work this is a reworked patch
      of his initial GPIO hogging mechanism.
      This patch provides a way to initially configure specific GPIO
      when the GPIO controller is probed.
      
      The actual DT scanning to collect the GPIO specific data is performed
      as part of gpiochip_add().
      
      The purpose of this is to allow specific GPIOs to be configured
      without any driver specific code.
      This is particularly useful because board design are getting
      increasingly complex and given SoC pins can now have more
      than 10 mux values, a lot of connections are now dependent on
      external IO muxes to switch various modes.
      
      Specific drivers should not necessarily need to be aware of
      what accounts to a specific board implementation. This board level
      "description" should be best kept as part of the dts file.
      Signed-off-by: default avatarBenoit Parrot <bparrot@ti.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f625d460
  19. 15 Jan, 2015 1 commit
  20. 04 Nov, 2014 1 commit
    • Mika Westerberg's avatar
      gpio / ACPI: Add support for _DSD device properties · 0d9a693c
      Mika Westerberg authored
      With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
      other things as well) returned by _CRS. Previously we were only able to
      use integer index to find the corresponding GPIO, which is pretty error
      prone if the order changes.
      
      With _DSD we can now query GPIOs using name instead of an integer index,
      like the below example shows:
      
        // Bluetooth device with reset and shutdown GPIOs
        Device (BTH)
        {
            Name (_HID, ...)
      
            Name (_CRS, ResourceTemplate ()
            {
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {15}
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
            })
      
            Name (_DSD, Package ()
            {
                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                Package ()
      	  {
                    Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
                    Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
                }
            })
        }
      
      The format of the supported GPIO property is:
      
        Package () { "name", Package () { ref, index, pin, active_low }}
      
        ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
              typically this is the device itself (BTH in our case).
        index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
        pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
        active_low - If 1 the GPIO is marked as active_low.
      
      Since ACPI GpioIo() resource does not have field saying whether it is
      active low or high, the "active_low" argument can be used here. Setting
      it to 1 marks the GPIO as active low.
      
      In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
      resource, second pin in that resource with the GPIO number of 31.
      
      This patch implements necessary support to gpiolib for extracting GPIOs
      using _DSD device properties.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0d9a693c
  21. 28 Jul, 2014 1 commit
  22. 24 Jul, 2014 1 commit
  23. 23 Jul, 2014 1 commit
  24. 09 Jul, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: move sysfs support to its own file · 0eb4c6c2
      Alexandre Courbot authored
      sysfs support is currently entangled within the core GPIO support, while
      it should relly just be a (privileged) user of the integer GPIO API.
      This patch is a first step towards making the gpiolib code more readable
      by splitting it into logical parts.
      
      Move all sysfs support to their own source file, and share static
      members of gpiolib that need to be in the private gpiolib.h file. In
      the future we will want to put some of them back into gpiolib.c, but this
      first patch let us at least identify them.
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      0eb4c6c2
  25. 21 May, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: make of_get_named_gpiod_flags() private · f01d9075
      Alexandre Courbot authored
      of_get_named_gpiod_flags() is visible and directly usable by GPIO
      consumers, but it really should not as the gpiod interface relies
      on the simpler gpiod_get() to provide properly-configured GPIOs.
      
      of_get_named_gpiod_flags() is just used internally by gpiolib to
      implement gpiod_get(), and by the old of_get_named_gpio_flags()
      function, therefore it makes sense to make it gpiolib-private.
      
      As a side-effect, the unused (and unneeded) of_get_gpiod_flags()
      inline function is also removed, and of_get_named_gpio_flags() is moved
      from a static inline function to a regular one in gpiolib-of.c
      
      This results in all references to gpiod_* functions in of_gpio.h being
      gone, which is the way it should be since this file is part of the old
      integer GPIO interface.
      
      Changes since v1:
      - Fixed compilation error when CONFIG_OF_GPIO is not defined
      - Fixed warning due to of_gpio_flags enum not being declared
        in private gpiolib.h header
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f01d9075
  26. 13 Mar, 2014 1 commit
    • 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: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      77c2d792
  27. 08 Jan, 2014 2 commits