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>

The use of kmalloc() to allocate the gpio_device leaves the contained struct
device object in an unknown state.  Calling dev_set_name() on a struct device
of unknown state can trigger the free() of an invalid pointer, as seen in the
following backtrace (collected by Tony Lindgren):

  kfree
  kobject_set_name_vargs
  dev_set_name
  gpiochip_add_data
  omap_gpio_probe
  platform_drv_probe
  ...
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reported-by: NMichael Welling <mwelling@ieee.org>
Reported-by: NTony Lindgren <tony@atomide.com>
Tested-by: NMichael Welling <mwelling@ieee.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJosh Cartwright <joshc@ni.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

My left hand merges code to privatize the descriptor handling
while my right hand merges drivers that poke around and
disrespect with the same gpiolib internals.

So let's expose the proper APIs for drivers to ask the gpiolib
core if a line is marked as open drain or open source and
get some order around things so this driver compiles again.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We move to manage this pointer under gpiolib control rather than
leave it in the subdevice's gpio_chip. We can not NULL it after
gpiochip_remove so at to keep things tight.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of keeping this reference to the pin ranges in the
client driver-supplied gpio_chip, move it to the internal
gpio_device as the drivers have no need to inspect this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Every time a descriptor is retrieved from the gpiolib, we issue
module_get() to reference count the module supplying the GPIOs.
We also need to call device_get() and device_put() as we also
reference the backing gpio_device when doing this.

Since the sysfs GPIO interface is using gpiod_get() this will
also reference count the sysfs requests until all GPIOs are
unexported.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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

This kind of hacks disturbs the refactoring of the gpiolib.

The descriptor table belongs to the gpiolib, if we want to know
something about something in it, use or define the proper accessor
functions. Let's add this gpiochip_lins_is_irq() to do what the
sunxi driver is trying at so we can privatize the descriptors
properly.

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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

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

When the device core reference count for the device goes to
0 and it calls .release() we free resources and so can also
finally free up the GPIO state container, struct gpio_device.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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

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

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

In some situations the gpio_list order is not correct.
As a consequence gpiochip_find_base returns the same
base number twice. This happens when a first ship is added
with manual base number, then other ships are added using
automatic base number.

To prevent this behaviour, this patch add the new chip after
the last element of the gpio list.
Signed-off-by: NJulien Grossholtz <julien.grossholtz@savoirfairelinux.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We are not relying on container_of() now that we have
gpiochip_get_data().
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds a void * pointer to gpio_chip so that driver can
assign and retrieve some states. This is done to get rid of
container_of() calls for gpio_chips embedded inside state
containers, so we can remove the need to have the gpio_chip
or later (planned) struct gpio_device be dynamically allocated
at registration time, so that its struct device can be properly
reference counted and not bound to its parent device (e.g.
a platform_device) but instead live on after unregistration
if it is opened by e.g. a char device or sysfs.

The data is added with the new function gpiochip_add_data()
and for compatibility we add static inline wrapper function
gpiochip_add() that will call gpiochip_add_data() with
NULL as argument. The latter will be removed once we have
exorcised gpiochip_add() from the kernel.

gpiochip_get_data() is added as a static inline accessor
for drivers to quickly get their data out.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When a GPIO is used as an interrupt in ACPI, the irq_type was not
available for device driver.

Make available polarity and triggering information in acpi_find_gpio by
renaming acpi_gpio_info field active_low  to polarity and adding triggering
field (edge/level).

For sanity, in gpiolib.c replace info.active_low by
"info.polarity == GPIO_ACTIVE_LOW".

Set the irq_type if necessary in acpi_dev_gpio_irq_get.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We were getting build warning about "iterator" being used uninitialized.
Use iterator properly to fix the build warning and in the process remove
the variable "pos" which is not required now.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit 45ad7db9.

We have fixed all the drivers that were returning ambious values
not clamped to [0,1] or an error code, so return the error
propagating behaviour of the API.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

commit e20538b8
("gpio: Propagate errors from chip->get()")
started to propagate errors from the .get() functions since
we can get errors from the infrastructure of e.g. slowbus
GPIO expanders.

However it turns out a bunch of drivers relied on the core
to clamp the value, so we need to revert to the old behaviour
and go over all drivers and fix them to conform to the
expectations of the core before we go back to propagating
the error code.

Cc: stable@vger.kernel.org # 4.3+
Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Fixes: e20538b8 ("gpio: Propagate errors from chip->get()")
Reported-by: NMichael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We should not fall back to the legacy unnamed gpio lookup style if the
driver requests gpios with different names, because we'll give out the same
gpio twice. Let's keep track of the names that were used for the device and
only do the fallback for the first name used.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit f4d566a8a0e6 ("gpio: change member .dev to .parent") changes
member of gpiochip from .dev to .parent. Update the corresponding
comment.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit c0017ed7 ("gpio: Introduce gpio descriptor 'name'") causes
OOPS on boot on LPC32xx boards:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0+ #707
    Hardware name: LPC32XX SoC (Flattened Device Tree)
    task: c381baa0 ti: c381e000 task.ti: c381e000
    PC is at strcmp+0x10/0x40
    LR is at gpiochip_add+0x3d0/0x4d4
    pc : [<>]    lr : [<>]    psr: a0000093
    sp : c381fd60  ip : c381fd70  fp : c381fd6c

    [snip]

    Backtrace:
    [<>] (strcmp) from [<>] (gpiochip_add+0x3d0/0x4d4)
    [<>] (gpiochip_add) from [<>] (lpc32xx_gpio_probe+0x44/0x60)
    [<>] (lpc32xx_gpio_probe) from [<>] (platform_drv_probe+0x40/0x8c)
    [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x110/0x294)
    [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
    [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
    [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
    [<>] (driver_attach) from [<>] (bus_add_driver+0xd4/0x1f0)
    [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
    [<>] (driver_register) from [<>] (__platform_driver_register+0x38/0x4c)
    [<>] (__platform_driver_register) from [<>] (lpc32xx_gpio_driver_init+0x18/0x20)
    [<>] (lpc32xx_gpio_driver_init) from [<>] (do_one_initcall+0x108/0x1c8)
    [<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4)
    [<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec)
    [<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24)

This is caused by the fact that at the moment some GPIO names are set
to NULL, there is a hole in linear representation of one GPI bank, see
drivers/gpio/gpio-lpc32xx.c / gpi_p3_names[] for details.

The same problem most probably affects also gpio-cs5535.c, see
cs5535_gpio_names[].
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We need to check if number of gpio is positive if there is no
such check in devicetree or acpi or whatever called before
gpiochip_add.

I suppose that devicetree and acpi do not allow insert gpiochip
with zero number but I do not know if it is enough to ignore
this check in gpiochip_add.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There are limitations for the current checker:
1.  Could not check the overlap if the new gpiochip is the secondly
    gpiochip.
2.  Could not check the overlap if the new gpiochip is overlap
    with the left of gpiochip. E.g. if we insert [c, d] between
    [a,b] and [e, f], and e >= c + d, it will successful even if
    c < a + b.
3.  Allow overlap of base of different gpiochip.

This patch fix these issues by checking the overlap of both right and
left gpiochip in the same loop statement.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
[Tweaked to remove unnecessary ret variable]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The commit f881bab0 ("gpio: keep the GPIO line names internal")
change the error to warning in gpiochip_set_desc_names. Update the
comment accordingly.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We should not fall back to the legacy unnamed gpio lookup style if the
driver requests gpios with different names, because we'll give out the same
gpio twice. Let's keep track of the names that were used for the device and
only do the fallback for the first name used.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The flag matches the DT GPIO_SINGLE_ENDED flag and allows drivers to
parse and use the DT flag to handle single-ended (open-drain or
open-source) GPIOs.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When requesting a GPIO through the legacy or the gpiod_* API the
gpiochip request operation is first called and then the GPIO flags are
parsed and the GPIO is configured. This prevents the gpiochip from
rejecting the request if the flags are not supported by the device.

To fix this split the parse-and-configure operation in two and parse
flags before requesting the GPIO.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Provide generic request/free implementations that pinctrl aware gpio
drivers can use instead of open coding if they use a 1:1 pin to gpio
signal mapping.
Signed-off-by: NJonas Gorski <jogo@openwrt.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The parameter offset is an unsigned, so it makes no sense to compare
it for >= 0. Fix the compiler warning regarding this by removing this
comparison.

As the macro GPIO_OFFSET_VALID is only used at this single place, simplify
the code by dropping the macro completely and dropping the invert, too.

No functional change.
Signed-off-by: NDirk Behme <dirk.behme@gmail.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This refactors the changes to the GPIO line naming mechanism to
not have so widespread effects, instead we conclude the patch series
by having created a name attribute in the GPIO descriptor, that need
not be globally unique, and it will be initialized from the old
.names array in struct gpio_chip if it exists, then used in the legacy
sysfs code like the array was used previously.

The associated changes to name lines from the device tree are
controversial and need to stand alone from this. Resulting changes:

1. Remove the export and the header for the gpio_name_to_desc() as so
far the only use is inside gpiolib.c. Staticize gpio_name_to_desc()
and move it above the only function using it.

2. Only print a warning if there are two GPIO lines with the same name.
The reason is to preserve current behaviour: before the previous
changes to the naming mechanism this would not reject probing the
driver, instead the error would occur when trying to export the line
in sysfs, so restore this behaviour, but print a friendly warning
if names collide.

Cc: Johan Hovold <johan@kernel.org>
Cc: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add some information about gpio names to the debugfs gpio file. name and
label of a GPIO are then displayed next to each other. This way it is
easy to see what the real name of GPIO is and what the driver requested
it for.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
[Dropped unsolicited sysfs ABI patch hunk]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds GPIO names to the GPIO descriptors when initializing the
gpiochip. It also introduces a check whether any of the new names will
conflict with an existing GPIO name.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>