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>

It's possible to have gpio chips hanging off unreliable remote buses
where the get() operation will fail to acquire a readout of the current
gpio state. Propagate these errors to the consumer so that they can
act on, retry or ignore these failing reads, instead of treating them as
the line being held high.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.

HW configuration which generates lockdep warning (TI dra7-evm):

[SOC GPIO bankA.gpioX]
  <- irq - [pcf875x.gpioY]
            <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
The issue was reported in [1] and discussed [2].

=============================================
[ INFO: possible recursive locking detected ]
4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
---------------------------------------------
sh/63 is trying to acquire lock:
 (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94

but task is already holding lock:
 (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(class);
  lock(class);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

7 locks held by sh/63:
 #0:  (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164
 #1:  (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0
 #2:  (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0
 #3:  (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4
 #4:  (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398
 #5:  (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94
 #6:  (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94

stack backtrace:
CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14)
[<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c)
[<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20)
[<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128)
[<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c)
[<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94)
[<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc)
[<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54)
[<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc)
[<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4)
[<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124)
[<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398)
[<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4)
[<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728)
[<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4)
[<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8)
[<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0)
[<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8)
[<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164)
[<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c)
[<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54)

Lets fix it by using separate lockdep class for each registered GPIO
IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.

The implementation of this patch inspired by solution done by Nicolas
Boichat for regmap [3]

[1] http://www.spinics.net/lists/linux-gpio/msg05844.html
[2] http://www.spinics.net/lists/linux-gpio/msg06021.html
[3] http://www.spinics.net/lists/arm-kernel/msg429834.html

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roger Quadros <rogerq@ti.com>
Reported-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the driver has specified its own irq_{request/release}_resources()
functions, don't override them.  The gpio-etraxfs driver will use this.
Signed-off-by: NRabin Vincent <rabin@rab.in>
[Added a small comment blurb]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
the pin controller isn't available.

Otherwise, the GPIO range wouldn't be set at all unless the pin
controller probed always before the GPIO chip.

With this change, the probe of the GPIO chip will be deferred and will
be retried at a later point, hopefully once the pin controller has been
registered and probed already.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed as most platforms don't use probing.
There appears to be a great deal of blind copy and paste of this code.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-tegra@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This variable is used as an iterator and initialized in the
list_for_each() loop.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Assign GPIO chip owner field to chip->dev->driver->owner if it was not
configured by GPIO driver.

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

Now nothing prevents GPIO driver from being unloaded if its gpios
were requested as GPIO IRQs only (without calling gpio_request()).

Hence, add calls of try_module_get()/module_put() into
gpiochip_irq_reqres/relres() to track such scenario properly.

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

gpiochip_add_pingroup_range() has a pctldev argument, not pinctrl.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Chained irq handlers usually set up handler data as well. We now have
a function to set both under irq_desc->lock. Replace the two calls
with one.

Search and conversion was done with coccinelle:
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org

Now that all[1] users of the gpiod_get functions are converted to make
use of the up to now optional flags parameter, make it mandatory which
allows to remove some cpp magic.

[1] all but etraxfs-uart which is broken anyhow and I'm allowed to
    ignore it by Jesper Nilsson :-)
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
but there were already ~63 of_node local variables or function parameters
(no single acpi_node though, but anyway).

After debugging undefined but used of_node local varible (which turned out
to reference static function of_node() instead) it became clear that the names
for the functions are too short and too generic for global scope.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes some issues given by checkpatch. Fixes include
bracket placement, spacing and indenting.
Signed-off-by: NDaniel Lockyer <thisisdaniellockyer@gmail.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When requesting own descriptors through hogs, it is useful to
get some details about what's going on if we encounter problems.
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

These error messages are helpful to see that we fail to get
hogs. Promote them to real errors so they appear in the boot
crawl.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There have been concerns that the function names gpiod_set_array() and
gpiod_get_array() might be confusing to users. One might expect
gpiod_get_array() to return array values, while it is actually the array
counterpart of gpiod_get(). To be consistent with the single descriptor API
we could rename gpiod_set_array() to gpiod_set_array_value(). This makes
some function names a bit lengthy: gpiod_set_raw_array_value_cansleep().
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fixed several spelling errors in gpio-lynxpoint, gpio-pca953x,
gpio-tegra, gpio-zynq, gpiolib-of, gpiolib.
Signed-off-by: NColin Cronin <colinpatrickcronin@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Clean up chained handler and handler data if they were set by
gpiochip_set_chained_irqchip().
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make sure to free any hogged gpios on errors in gpiochip_add.

Also move all forward declarations to the top of the file.

Fixes: f625d460 ("gpio: add GPIO hogging mechanism")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Rename the gpio-chip export/unexport functions to the more descriptive
names gpiochip_sysfs_register and gpiochip_sysfs_unregister.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Clean up gpiochip_remove somewhat and only output warning about removing
chip with GPIOs requested once.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If dev is NULL in __gpiod_get_index() and both ACPI and OF are
enabled, it will be checked twice before the code decides to give
up with DT/ACPI lookup, so avoid that.

Also use the observation that ACPI_COMPANION() is much more efficient
than ACPI_HANDLE(), because the latter uses the former and carries out
a check and a pointer dereference on top of it, so replace the
ACPI_HANDLE() check with an ACPI_COMPANION() one which does not
require the additional IS_ENABLED(CONFIG_ACPI) check too.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Introduce new functions for conveniently obtaining and disposing of
an entire array of GPIOs with one function call.

ACPI parts tested by Mika Westerberg, DT parts tested by Rojhalat
Ibrahim.

Change log:
v5: move the ACPI functions to gpiolib-acpi.c
v4: - use shorter names for members of struct gpio_descs
    - rename lut_gpio_count to platform_gpio_count for clarity
    - add check for successful memory allocation
    - use ERR_CAST()
v3: - rebase on current linux-gpio devel branch
    - fix ACPI GPIO counting
    - allow for zero-sized arrays
    - make the flags argument mandatory for the new functions
    - clarify documentation
v2: change interface
Suggested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Avoid multiple identical definitions of the gpio suffix strings by putting
them into a global constant array.
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NBenoit Parrot <bparrot@ti.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiolib uses a fixed string for the suffixes and defines it at 32 bytes.
Later in the code snprintf is used with this fixed value of 32. Using
sizeof() is safer in case the size for the suffixes is ever changed.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

On my previous patch I was overly hasty and made the suffixes string
array
const char const *suffixes, instaed of const char * const suffixes. This
patch corrects that
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Checkpatch complains, and probably with good reason that we should use
const char const * for the static constant array that never gets
changed.
Signed-off-by: NOlliver Schinagl <oliver@schinagl.nl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Move direct and indirect calls to gpiochip_remove_pin_ranges outside of
spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range.

Note that the pin ranges are already added outside of the lock.

Fixes: 9ef0d6f7 ("gpiolib: call pin removal in chip removal function")
Fixes: f23f1516 ("gpiolib: provide provision to register pin ranges")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix memory leak and sleep-while-atomic in gpiochip_remove.

The memory leak was introduced by afa82fab ("gpio / ACPI: Move event
handling registration to gpiolib irqchip helpers") that moved the
release of acpi interrupt resources to gpiochip_irqchip_remove, but by
then the resources are no longer accessible as the acpi_gpio_chip has
already been freed by acpi_gpiochip_remove.

Note that this also fixes a few potential sleep-while-atomics, which has
been around since 14250520 ("gpio: add IRQ chip helpers in gpiolib")
when the call to gpiochip_irqchip_remove while holding a spinlock was
added (a couple of irq-domain paths can end up grabbing mutexes).

Fixes: afa82fab ("gpio / ACPI: Move event handling registration to
gpiolib irqchip helpers")
Fixes: 14250520 ("gpio: add IRQ chip helpers in gpiolib")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Clean up gpiochip_add error handling.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix potential corruption of gpio-chip list due to failure to remove the
chip from the list before returning in gpiochip_add error path.

The chip could be long gone when the global list is next traversed,
something which could lead to a null-pointer dereference. In the best
case (chip not deallocated) we are just leaking the gpio range.

Fixes: 14e85c0e ("gpio: remove gpio_descs global array")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).

Fixes: 391c970c ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5a ("gpio / ACPI: register to ACPI events
automatically")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 14e85c0e ("gpio: remove gpio_descs global array") changed
gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers
not in the valid range, but also for all GPIOs whose controller has not
been probed yet. Although this behavior is more correct (nothing hints
that these GPIO numbers will be populated later), this affects
gpio_request() and gpio_request_one() which call gpiod_request() with a
NULL descriptor, causing it to return -EINVAL instead of the expected
-EPROBE_DEFER for a non-probed GPIO.

gpiod_request() is only called with a descriptor obtained from
gpio_to_desc() from these two functions, so address the issue there.

Other ways to obtain GPIOs rely on well-defined mappings and can thus
return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected
by this issue.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Although gpiod_get_direction() can be considered side-effect free for
consumers, its internals involve setting or clearing bits in the
affected GPIO descriptor, for which we need to force-cast the const
descriptor variable to non-const. This could lead to incorrect behavior
if the compiler decides to optimize here, so remove this const
attribute. The intent is to make gpiod_get_direction() private anyway,
so it does not really matter.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by
dynamically-allocated arrays for each GPIO chip.

This change makes gpio_to_desc() perform in O(n) (where n is the number
of GPIO chips registered) instead of O(1), however since n is rarely
bigger than 1 or 2 no noticeable performance issue is expected.
Besides this provides more incentive for GPIO consumers to move to the
gpiod interface. One could use a O(log(n)) structure to link the GPIO
chips together, but considering the low limit of n the hypothetical
performance benefit is probably not worth the added complexity.

This patch uses kcalloc() in gpiochip_add(), which removes the ability
to add a chip before kcalloc() can operate. I am not aware of such
cases, but if someone bisects up to this patch then I will be proven
wrong...
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It doesn't make much sense to make some (possible expensive) calls to
gpio_is_valid() first, and to ignore the result if the base number is
negative. Check for a positive base number first.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>