Using a default trigger is a bad idea if using DT to configure
interrupts, as the device's interrupt specifier will always contain
the trigger configuration.

Let's warn about that particular situation, and revert to not
having a default. Hopefully, the couple of drivers still using
this feature will quickly be fixed.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The if...else... block after the loop can be dropped with
a slight refactoring.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit 7e7c059c.

I was wrong about trying to do this, as it breaks the
orthogonality between gpiochips and irqchips.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NThierry Reding <treding@nvidia.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NAlexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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
interface.

Cc: stable <stable@vger.kernel.org>	# 4.4
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The generic IRQ helper library just checks if the IRQ line is
set as input before activating it for interrupts. As we
recently started to check things better with .get_dir() it
turns out that it's good to try to convince the line to become
an input before attempting to lock it as IRQ.
Reviewed-by: NBjörn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most functions that take a GPIO descriptor in need to check the
descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC()
macro except for the gpiod_to_irq() function which needs special
handling.

Cc: stable@vger.kernel.org
Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

commit 54d77198
("gpio: bail out silently on NULL descriptors")
doesn't work for gpiod_to_irq(): drivers assume that NULL
descriptors will give negative IRQ numbers in return.

It has been pointed out that returning 0 is NO_IRQ and that
drivers should be amended to treat this as an error, but that
is for the longer term: now let us repair the semantics.

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Reported-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The lineevent_irq_thread is not exported, so make it static
to fix the following warning:

drivers/gpio/gpiolib.c:654:13: warning: symbol 'lineevent_irq_thread' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When initializing the GPIO handles, we use the iterator (i)
to back off if something goes wrong. But since the iterator
is also used after we pass the loop, we must decrement by
one after exiting the loop so that we point at the last
element in the array.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Walter Harms <wharms@bfs.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most functions that take a GPIO descriptor in need to check the
descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC()
macro except for the gpiod_to_irq() function which needs special
handling.

Cc: stable@vger.kernel.org
Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

commit 54d77198
("gpio: bail out silently on NULL descriptors")
doesn't work for gpiod_to_irq(): drivers assume that NULL
descriptors will give negative IRQ numbers in return.

It has been pointed out that returning 0 is NO_IRQ and that
drivers should be amended to treat this as an error, but that
is for the longer term: now let us repair the semantics.

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Reported-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NArnd Bergmann <arnd@arndb.de>
Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NLinus Walleij <linus.walleij@linaro.org>

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: NMichael Welling <mwelling@ieee.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiolib relies on the reference counters to clean up the gpio_device
structure.

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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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
0000000000000090
[  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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When adding the gpiochip, the GPIO HW drivers' callback get_direction()
could get called in atomic context. Some of the GPIO HW drivers may
sleep when accessing the register.

Move the lock before initializing the descriptors.
Reported-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In fdeb8e15
("gpio: reflect base and ngpio into gpio_device")
assumed that GPIO descriptors are either valid or error
pointers, but gpiod_get_[index_]optional() actually return
NULL descriptors and then all subsequent calls should just
bail out.

Cc: stable@vger.kernel.org
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Fixes: fdeb8e15 ("gpio: reflect base and ngpio into gpio_device")
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If we're using the compatible ioctl() we need to handle the
argument pointer in a special way or there will be trouble.

Fixes: 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs")
Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.

Else we get problems like this:

iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
  tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
  (irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22

Fixes: 72d32000 ("gpio: set up initial state from .get_direction()")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If a translation returns zero, that means NO_IRQ, so we
should return an error since the function is documented to
return a negative code on error.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the gpiochip supports the .get_direction() callback, then
the initial state of the descriptor flags should be set up
as output accordingly. Also put in comments explaining what is
going on.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This renames gpiod_set_array_value_priv() to
gpiod_set_array_value_complex() and moves it to the gpiolib.h
private header file so we can reuse it in the subsystem.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Print the error number of GPIO hog failed during its configurations.
This helps in identifying the failure without instrumenting the code.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since commit ff2b1359 ("gpio: make the gpiochip a real device"),
attempts to add a gpio chip prior to gpiolib initialization cause
the system to crash. This happens because gpio_bus_type has not been
registered yet. Defer creating gpio devices until after gpiolib has
been initialized to fix the problem.

Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Fixes: ff2b1359 ("gpio: make the gpiochip a real device")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It is possible that a gpio chip is registered before the gpiolib
initialization code has run. This means we can not use devm_ functions
to allocate memory at that time. Do it the old fashioned way.

Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When firmware does not use _DSD properties that allow properly name GPIO
resources, the kernel falls back on parsing _CRS resources, and will
return entries described as GpioInt() as general purpose GPIOs even
though they are meant to be used simply as interrupt sources for the
device:

Device (ETSA)
{
	Name (_HID, "ELAN0001")
	...

	Method(_CRS, 0x0, NotSerialized)
	{
		Name(BUF0,ResourceTemplate ()
		{
			I2CSerialBus(
				0x10,                     /* SlaveAddress */
				ControllerInitiated,      /* SlaveMode */
				400000,                   /* ConnectionSpeed */
				AddressingMode7Bit,       /* AddressingMode */
				"\\_SB.I2C1",             /* ResourceSource */
			)
			GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone,,
				 "\\_SB.GPSW") { BOARD_TOUCH_GPIO_INDEX }
		} )
		Return (BUF0)
	}
...
}

This gives troubles with drivers such as Elan Touchscreen driver
(elants_i2c) that uses devm_gpiod_get to look up "reset" GPIO line and
decide whether the driver is responsible for powering up and resetting
the device, or firmware is. In the above case the lookup succeeds, we
map GPIO as output and later fail to request client->irq interrupt that
is mapped to the same GPIO.

Let's ignore resources described as GpioInt() while parsing _CRS when
requesting output GPIOs (but allow them when requesting GPIOD_ASIS or
GPIOD_IN as some drivers, such as i2c-hid, do request GPIO as input and
then map it to interrupt with gpiod_to_irq).
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some GPIO controllers has a special hardware bit we can flip
to support open drain / source. This means that on these hardwares
we do not need to emulate OD/OS by setting the line to input
instead of actively driving it high/low. Add an optional vtable
callback to the driver set_single_ended() so that driver can
implement this in hardware if they have it.

We may need a pinctrl_gpio_set_config() call at some point to
propagate this down to a backing pin control device on systems
with split GPIO/pin control.
Reported-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fixes: 79a9becd ("gpiolib: export descriptor-based GPIO interface")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The original code of gpiodev_add_to_list is not very clear which
lead to bugs or compiling warning, reference the following patches:
Bugs:
1.  Commit ef7c7553 ("gpiolib: improve overlap check of range of
    gpio").
2.  Commit 96098df1 ("gpiolib: fix chip order in gpio list")

Warning:
1.  Commit e28ecca6 ("gpio: fix warning about iterator").
of gpio").

There is a off-list discussion about how to improve it consequently.
This commit try to follow this by rewriting the whole functions.

Tested pass with my gpio mockup driver and test scripts[1].

[1] http://www.spinics.net/lists/linux-gpio/msg09598.htmlSuggested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

I named the field representing the current user of GPIO line as
"label" but this is too vague and ambiguous. Before anyone gets
confused, rename it to "consumer" and indicate clearly in the
documentation that this is a string set by the user of the line.

Also clean up leftovers in the documentation.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add device managed APIs devm_gpiochip_add_data() and
devm_gpiochip_remove() for the APIs gpiochip_add_data()
and gpiochip_remove().

This helps in reducing code in error path and sometimes
removal of .remove callback for driver unbind.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>

This fixes the wrongly indicated lines in the userspace
ABI: test for the right BITS, do not treat bit numbers as
bitmasks.
Reported-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit cb464a88e1ed ("gpio: make the gpiochip a real device") call
gpiochip_sysfs_unregister after the gpiochip is empty. It lead to the
following crash:

[  163.503994] Unable to handle kernel NULL pointer dereference at virtual address 0000007c
[...]
[  163.525394] [<ffffffc0003719a0>] gpiochip_sysfs_unregister+0x44/0xa4
[  163.525611] [<ffffffc00036f6a0>] gpiochip_remove+0x24/0x154
[  163.525861] [<ffffffbffc00f0a4>] mockup_gpio_remove+0x38/0x64 [gpio_mockup]
[  163.526101] [<ffffffc00042b4b4>] platform_drv_remove+0x24/0x64
[  163.526313] [<ffffffc000429cc8>] __device_release_driver+0x7c/0xfc
[  163.526525] [<ffffffc000429e54>] driver_detach+0xbc/0xc0
[  163.526700] [<ffffffc000429014>] bus_remove_driver+0x58/0xac
[  163.526883] [<ffffffc00042a4cc>] driver_unregister+0x2c/0x4c
[  163.527067] [<ffffffc00042b5c0>] platform_driver_unregister+0x10/0x18
[  163.527284] [<ffffffbffc00f340>] mock_device_exit+0x10/0x38 [gpio_mockup]
[  163.527593] [<ffffffc00011cefc>] SyS_delete_module+0x1b8/0x1fc
[  163.527799] [<ffffffc000085d8c>] __sys_trace_return+0x0/0x4
[  163.528049] Code: 940d74b4 f9019abf aa1303e0 940d7439 (7940fac0)
[  163.536273] ---[ end trace 3d1329be504af609 ]---

This patch fix this by changing the code back.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds a GPIO line ABI for getting name, label and a few select
flags from the kernel.

This hides the kernel internals and only tells userspace what it
may need to know: the different in-kernel consumers are masked
behind the flag "kernel" and that is all userspace needs to know.

However electric characteristics like active low, open drain etc
are reflected to userspace, as this is important information.

We provide information on all lines on all chips, later on we will
likely add a flag for the chardev consumer so we can filter and
display only the lines userspace actually uses in e.g. lsgpio,
but then we first need an ABI for userspace to grab and use
(get/set/select direction) a GPIO line.

Sample output from "lsgpio" on ux500:

GPIO chip: gpiochip7, "8011e000.gpio", 32 GPIO lines
        line 0: unnamed unlabeled
        line 1: unnamed unlabeled
(...)
        line 25: unnamed "SFH7741 Proximity Sensor" [kernel output open-drain]
        line 26: unnamed unlabeled
(...)
Tested-by: NMichael Welling <mwelling@ieee.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The gpio_chip label is useful for userspace to understand what
kind of GPIO chip it is dealing with. Let's store a copy of this
label in the gpio_device, add it to the struct passed to userspace
for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>