gpiochip_get_desc() already does the check, drop a duplicate in
gpiochip_is_requested().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

It's quite spread code to initialize IRQ domain options.
Let's fold it into a simple oneliner.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

When IRQ domain is created for an ACPI case, the name of it becomes unknown-%d
since for now it utilizes of_node member only and doesn't consider fwnode case.
Convert IRQ domain creation code to utilize fwnode instead.

Before/After the change on Intel Galileo Gen 2 with two GPIO (IRQ) controllers:

  unknown-1	==>	\_SB.PCI0.GIP0.GPO
  unknown-2	==>	\_SB.NIO3

Due to the nature of this change we may also deduplicate the WARN():s
because in either case (DT or ACPI) the fwnode will be set correctly
and %pfw is an equivalent to what the current code prints as a prefix.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

In the ACPI case we may use the firmware node in the similar way
as it's done for OF case. We may use that fwnode for other purposes
in the future.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The initial value of the OF node based on presence of parent, but
at the same time this operation somehow appeared separately from others
that handle the OF case. On the other hand there is no need to assign
dev->fwnode in the OF case if code properly retrieves fwnode, i.e.
via dev_fwnode() helper.

Amend gpiolib.c and gpiolib-of.c code in order to group OF operations.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

We have (historically) different approaches how we identify the type
of a given fwnode. Let's standardize them across the library code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

In case when the properties are supplied in the secondary fwnode
(for example, built-in device properties) the fwnode pointer left
unassigned. This makes unable to retrieve them.

Assign fwnode to parent's if no primary one provided.

Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Fixes: 2afa97e9868f ("gpiolib: Read "gpio-line-names" from a firmware node")
Reported-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 4731210c ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default")
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000,
see arch/arm/boot/dts/stm32mp151.dtsi. The driver for
pin-controller@50002000 is in drivers/pinctrl/stm32/pinctrl-stm32.c
and iterates over all of its DT subnodes when registering each GPIO
bank gpiochip. Each gpiochip has:

  - gpio_chip.parent = dev,
    where dev is the device node of the pin controller
  - gpio_chip.of_node = np,
    which is the OF node of the GPIO bank

Therefore, dev_fwnode(chip->parent) != of_fwnode_handle(chip.of_node),
i.e. pin-controller@50002000 != pin-controller@50002000/gpio@5000*000.

The original code behaved correctly, as it extracted the "gpio-line-names"
from of_fwnode_handle(chip.of_node) = pin-controller@50002000/gpio@5000*000.

To achieve the same behaviour, read property from the firmware node.

Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Reported-by: NMarek Vasut <marex@denx.de>
Reported-by: NRoman Guskov <rguskov@dh-electronics.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Make sure to hold the gpio_lock when removing the gpio device from the
gpio_devices list (when dropping the last reference) to avoid corrupting
the list when there are concurrent accesses.

Fixes: ff2b1359 ("gpio: make the gpiochip a real device")
Cc: stable@vger.kernel.org      # 4.6
Reviewed-by: NSaravana Kannan <saravanak@google.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Fix a NULL-pointer deference when deregistering the gpio character
device that was introduced by the recent stub-driver hack. When the new
"driver" is unbound as part of deregistration, driver core clears the
driver-data pointer which is used to retrieve the struct gpio_device in
its release callback.

Fix this by using container_of() in the release callback as should have
been done all along.

Fixes: 4731210c ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default")
Cc: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: syzbot+d27b4c8adbbff70fbfde@syzkaller.appspotmail.com
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Dmitry reported[1] boot error messages caused by
commit 4731210c ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default").

gpio-1022 (cpu-pwr-req-hog): hogged as input
max77620-pinctrl max77620-pinctrl: pin gpio4 already requested by max77620-pinctrl; cannot claim for gpiochip1
max77620-pinctrl max77620-pinctrl: pin-4 (gpiochip1) status -22
max77620-pinctrl max77620-pinctrl: could not request pin 4 (gpio4) from group gpio4  on device max77620-pinctrl
gpio_stub_drv gpiochip1: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip1 failed with error -22

This happens because when we try to probe a device, driver core calls
into pinctrl to set up the pins. However, if the GPIO DT node already
has a proper device created and probed, trying to probe the gpio_device
with a stub driver makes the pins be claimed twice. pinctrl doesn't like
this and throws an error.

So, this patch makes sure the gpio_stub_drv doesn't match with a
gpio_device if it's not the primary device for the fwnode.

[1] - https://lore.kernel.org/lkml/544ad0e4-0954-274c-8e77-866aaa5661a8@gmail.com/

Fixes: 4731210c ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default")
Tested-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210205020730.1746354-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After refactoring, we had two variables for the same thing. Remove the
second declaration, one is enough here. Found by cppcheck.

drivers/gpio/gpiolib.c:2551:17: warning: Local variable 'ret' shadows outer variable [shadowVariable]

Fixes: d377f56f ("gpio: gpiolib: Normalize return code variable name")
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

In gpiochip_add_data_with_key, we should check the return value of
dev_set_name to ensure that device name is allocated successfully
and then add a label on the error path to free device name to fix
kmemleak as below:

unreferenced object 0xc2d6fc40 (size 64):
  comm "kworker/0:1", pid 16, jiffies 4294937425 (age 65.120s)
  hex dump (first 32 bytes):
    67 70 69 6f 63 68 69 70 30 00 1a c0 54 63 1a c0  gpiochip0...Tc..
    0c ed 84 c0 48 ed 84 c0 3c ee 84 c0 10 00 00 00  ....H...<.......
  backtrace:
    [<962810f7>] kobject_set_name_vargs+0x2c/0xa0
    [<f50797e6>] dev_set_name+0x2c/0x5c
    [<94abbca9>] gpiochip_add_data_with_key+0xfc/0xce8
    [<5c4193e0>] omap_gpio_probe+0x33c/0x68c
    [<3402f137>] platform_probe+0x58/0xb8
    [<7421e210>] really_probe+0xec/0x3b4
    [<000f8ada>] driver_probe_device+0x58/0xb4
    [<67e0f7f7>] bus_for_each_drv+0x80/0xd0
    [<4de545dc>] __device_attach+0xe8/0x15c
    [<2e4431e7>] bus_probe_device+0x84/0x8c
    [<c18b1de9>] device_add+0x384/0x7c0
    [<5aff2995>] of_platform_device_create_pdata+0x8c/0xb8
    [<061c3483>] of_platform_bus_create+0x198/0x230
    [<5ee6d42a>] of_platform_populate+0x60/0xb8
    [<2647300f>] sysc_probe+0xd18/0x135c
    [<3402f137>] platform_probe+0x58/0xb8
Signed-off-by: NQuanyang Wang <quanyang.wang@windriver.com>
Cc: stable@vger.kernel.org
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

There are multiple instances of GPIO device tree nodes of the form:

foo {
	compatible = "acme,foo";
	...

	gpio0: gpio0@xxxxxxxx {
		compatible = "acme,bar";
		...
		gpio-controller;
	};

	gpio1: gpio1@xxxxxxxx {
		compatible = "acme,bar";
		...
		gpio-controller;
	};

	...
}

bazz {
	my-gpios = <&gpio0 ...>;
}

Case 1: The driver for "foo" populates struct device for these gpio*
nodes and then probes them using a driver that binds with "acme,bar".
This driver for "acme,bar" then registers the gpio* nodes with gpiolib.
This lines up with how DT nodes with the "compatible" property are
typically converted to struct devices and then registered with driver
core to probe them. This also allows the gpio* devices to hook into all
the driver core capabilities like runtime PM, probe deferral,
suspend/resume ordering, device links, etc.

Case 2: The driver for "foo" doesn't populate struct devices for these
gpio* nodes before registering them with gpiolib. Instead it just loops
through its child nodes and directly registers the gpio* nodes with
gpiolib.

Drivers that follow case 2 cause problems with fw_devlink=on. This is
because fw_devlink will prevent bazz from probing until there's a struct
device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO
supplier). Once the struct device is available, fw_devlink will create a
device link with gpio0 device as the supplier and bazz device as the
consumer. After this point, since the gpio0 device will never bind to a
driver, the device link will prevent bazz device from ever probing.

Finding and refactoring all the instances of drivers that follow case 2
will cause a lot of code churn and it is not something that can be done
in one shot. In some instances it might not even be possible to refactor
them cleanly. Examples of such instances are [1] [2].

This patch works around this problem and avoids all the code churn by
simply setting the fwnode of the gpio_device and creating a stub driver
to bind to the gpio_device. This allows all the consumers to continue
probing when the driver follows case 2.

[1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
[2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/

Fixes: e5904747 ("driver core: Set fw_devlink=on by default")
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

gpiochip->to_irq method is redefined in gpiochip_add_irqchip.

A lot of gpiod driver's still define ->to_irq method, let's give
a gentle warning that they can no longer rely on it, so they can remove
it on ocassion.

Fixes: e0d89728 ("gpio: Implement tighter IRQ chip integration")
Signed-off-by: NNikita Shubin <nikita.shubin@maquefel.me>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The usual pattern for the remove calls, like gpiod_remove_lookup_table(),
is to be NULL-aware, i.o.w. become a no-op whenever parameter is NULL.
Update gpiod_remove_lookup_table() call to follow this pattern.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@kernel.org>

irqchip shared with multiple gpiochips, leads to recursive call of
gpiochip_irq_mask/gpiochip_irq_unmask which was assigned to
rqchip->irq_mask/irqchip->irq_unmask, these happens becouse of
only irqchip->irq_enable == gpiochip_irq_enable is checked.

Let's add an additional check to make sure shared irqchip is detected
even if irqchip->irq_enable wasn't defined.

Fixes: a8173820 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
Signed-off-by: NNikita Shubin <nikita.shubin@maquefel.me>
Link: https://lore.kernel.org/r/20201210070514.13238-1-nikita.shubin@maquefel.meSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

When trying to export an nonexisting gpio ID, the kernel prints out a
big warning w/ stacktrace, sounding like a huge problem. In fact it's
a pretty normal situation, like file or device not found.

So, just print a more relaxed warning instead.

changes v2: drop defining pr_fmt()
Signed-off-by: NEnrico Weigelt <info@metux.net>
Link: https://lore.kernel.org/r/20201202133754.32045-1-info@metux.netSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

A similar check was added in gpiochip_generic_request, but not in free.
This has caused an imbalance count of request vs. free calls to the
pinctrl driver. This patch is targeted to fix that issue.

Fixes: 2ab73c6d ("gpio: Support GPIO controllers without pin-ranges")
Signed-off-by: NEdmond Chung <edmondchung@google.com>
Signed-off-by: NAndrew Chant <achant@google.com>
Signed-off-by: NWill McVicker <willmcvicker@google.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The gpiochip may have dependencies from pinmux and so got deferred. Now it
will print error message every time -EPROBE_DEFER is returned which is
unnecessary:

"gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517"

Hence, do suppress error message for -EPROBE_DEFER case.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

In some cases we would like to have debounce setter which doesn't fail
when a feature is not supported by a controller.

Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>

This function is useful for internal use in the GPIO library.
There will be new user coming, prepare a helper for the new comer
and the existing ones.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Move bias related code from gpio_set_config() to gpio_set_bias().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In the future we will need to have a separate function
that takes an arbitrary argument value.

Extract gpio_set_config_with_argument() for that purpose.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Instead of open coded macro use, call pinconf_to_config_packed().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

It's no difference in the functionality, but after the change the code
is less error prone to various checkers.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Replace unsigned by unsigned int in GPIO library code.
Note, legacy API left untouched.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In gpiochip_setup_dev() the call to gpiolib_cdev_register() indirectly
calls device_add().  This is still required for the sysfs even when
CONFIG_GPIO_CDEV is not selected in the build.

Replace the stubbed functions in gpiolib-cdev.h with macros in gpiolib.c
that perform the required device_add() and device_del() when
CONFIG_GPIO_CDEV is not selected.

Fixes: d143493c (gpiolib: make cdev a build option)
Reported-by: NNicolas Schichan <nschichan@freebox.fr>
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Tested-by: NNicolas Schichan <nschichan@freebox.fr>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Now that all gpiolib irqchip users have been over to use
the irqchip template, we can finally retire the old code
path and leave just one way in to the irqchip: set up the
template when registering the gpio_chip. For a while
we had two code paths for this which was a bit confusing.

This brings this work to a conclusion, there is now one
way of doing this.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org

First of all, bias has a special type as being a part of enum pin_config_param.
Second, 0 is also defined bias which is equivalent to BUS_HOLD.

Taking into account above, change type of bias variable and refactor
gpio_set_bias() in a way that it doesn't use BUS_HOLD as a place holder.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20201009184359.16427-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

For better maintenance and micro optimization split error path
in the gpiod_request_commit().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Half of the code in the GPIO library is written in an expectation that
any non-zero value returned from the ->request() callback is an error code,
while some code checks only for negative values.

Unify expectations about ->request() returned value to be non-zero
for an error and 0 for the success.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Several places in the code are using same idiom, i.e.
	IS_ERR(desc) && PTR_ERR(desc) == -ENOENT
which meaning is GPIO description is not found.

For better readability extract gpiod_not_found() helper and use it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add support for setting debounce on a line via the GPIO uAPI.
Where debounce is not supported by hardware, a software debounce is
provided.

The implementation of the software debouncer waits for the line to be
stable for the debounce period before determining if a level change,
and a corresponding edge event, has occurred.  This provides maximum
protection against glitches, but also introduces a debounce_period
latency to edge events.

The software debouncer is integrated with the edge detection as it
utilises the line interrupt, and integration is simpler than getting
the two to interwork.  Where software debounce AND edge detection is
required, the debouncer provides both.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add support for edge detection to lines requested using
GPIO_V2_GET_LINE_IOCTL.

The edge_detector implementation is based on the v1 lineevent
implementation.  Unlike the v1 implementation, an overflow of the event
buffer results in discarding older events, rather than the most
recent, so the final event in a burst will correspond to the current
state of the line.
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

It's possible for a GPIO chip to not have a parent device (whose
properties we inspect for 'gpio-line-names'). In this case we should
simply return from devprop_gpiochip_set_names(). Add an appropriate
check for this use-case.

Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Reported-by: NAnders Roxell <anders.roxell@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NAnders Roxell <anders.roxell@linaro.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that devprop_gpiochip_set_names() is only used in a single place
inside drivers/gpio/gpiolib.c, there's no need anymore for it to be
exported or to even live in its own source file. Pull this function into
the core source file for gpiolib.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() & of_fwnode_handle()
in ACPI and OF GPIO code respectively). Let's just switch to using the
generic device properties.

This allows us to pull the code setting line names directly into
gpiochip_add_data_with_key() instead of handling it separately for
ACPI and OF.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.

ida_simple_get(ida, 0, 0, gfp) is equivalent to
ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to
ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID
larger than INT_MAX.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>