1. 09 Feb, 2016 4 commits
    • Linus Walleij's avatar
      tools/gpio: create GPIO tools · 6d591c46
      Linus Walleij authored
      This creates GPIO tools under tools/gpio/* and adds a single
      example program to list the GPIOs on a system. When proper
      devices are created it provides this minimal output:
      
      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>
      6d591c46
    • 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
  2. 24 Jan, 2016 36 commits