In new code introduced by commit b17566a6 ("gpiolib: Implement fast
processing path in get/set array"), bitmap index is not updated with
next found zero bit position as it should while skipping over pins
already processed via fast bitmap path, possibly resulting in an
infinite loop.  Fix it.
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Give the HTC EGPIO chips unique names, htc-egpio-0,
htc-egpio-1 etc, so that it gets possible to associate
machine descriptor tables with individual chips.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We remove the references to anything but two-cell GPIO specifiers
and just mention that controllers need to specify their bindings
and that we strongly recommend two-cell bindings.

Cc: devicetree@vger.kernel.org
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In 2011 the commit bf859f84
("gpio/dt: Refine GPIO device tree binding") introduced an
experimental BNF notation for defining a regular grammar for
the GPIO phandles used by different devices.

This was an interesting approach, and shows that we have long
nutured the idea to formally verify device tree files using
regular grammar.

Most if not all other bindings use natural language to define
the bindings, and the recent thinking for verifying device
tree files is to use JSON schemas in separate definitions.

Cut the BNF business and replace it with natural language
so that it becomes more human-readable for now.

Cc: devicetree@vger.kernel.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

These defines, structs and inline functions are used only internally by
the driver, they do not belong in platform_data. Move them.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This macro does nothing and has only one user, remove it.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Previously we created a controller structure per bank of GPIO pins. This
has since been changed to one per controller, but the allocation size
was not changed. Fix this here.

This also leaves the variable 'nbank' unused, instead of removing it,
move it down and use it to clean up a loop. For loops with multiple
initializers and/or iteration expressions, especially ones that don't
use those loop counters are quite hard to follow, fix this.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use dev_name to get a unique label and use -1 for a base to get our
selection automatically. We pull in all GPIOs per chip now so this
does not have the effect of out of order labels like before.

We do these both together so we can drop all the static data in one
patch. This also lets us normalize the return paths as we don't need
any cleanup after this change.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This was added as part of the patch in the fixes below, but was
not needed or used, remove this here.

Fixes: 8e11047b ("gpio: davinci: Add support for multiple GPIO controllers")
Tested-by: NKeerthy <j-keerthy@ti.com>
Acked-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

A bunch of core gpiolib files still include the <linux/gpio.h>
legacy API header for no good reason. After this only the
gpiolib-legacy.c file includes it, which is fine.

The sysfs ABI code has a pointless wrapper function around
gpio_to_desc() we can just loose.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX license tag for these drivers.

Cc: patches@opensource.cirrus.com
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Mark Brown <broonie@kernel.org>
Acked-by: NRichard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

These are GPIO drivers so just include <linux/gpio/driver.h>.

Cc: patches@opensource.cirrus.com
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Mark Brown <broonie@kernel.org>
Acked-by: NRichard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX license tag for this file.

Cc: Kamlakant Patel <kamlakant.patel@cavium.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so include only <linux/gpio/driver.h>.

Cc: Kamlakant Patel <kamlakant.patel@cavium.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX header for the license.

Cc: Daniel Drake <drake@endlessm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so include only <linux/gpio/driver.h>.

Cc: Daniel Drake <drake@endlessm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX header for the license.

Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so include only <linux/gpio/driver.h>.

Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX header for the license.
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so include only <linux/gpio/driver.h>.
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This API is not used anywhere in the kernel and has remained
unused for years after being introduced.

Over time, we have developed a subsystem to deal with pin
control and this now managed pull up/down.

Delete the old and unused API. If this platform needs it,
we should implement a proper pin controller for it instead.

Cc: Yoichi Yuasa <yuasa@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This switches this file to use the SPDX license tag.

Cc: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so include only <linux/gpio/driver.h>.

Cc: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some drivers use a single irqchip for multiple gpiochips. As a result the
irqchip hooks are overridden for the first gpiochip that was added, but
for the other gpiochip instances this should not happen again, otherwise
we would go into an infinite recursion.

Check for this, but also log a message that the driver should be fixed
since this is bad practice.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

EINVAL is very generic, use ENOTSUPP in case the gpiochip does not
provide this function. While removing the assignment from the 'status'
variable, use better indentation in the declaration block.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Certain GPIO descriptor arrays returned by gpio_get_array() may contain
information on direct mapping of array members to pins of a single GPIO
chip in hardware order.  In such cases, bitmaps of values can be passed
directly from/to the chip's .get/set_multiple() callbacks without
wasting time on iterations.

Add respective code to gpiod_get/set_array_bitmap_complex() functions.
Pins not applicable for fast path are processed as before, skipping
over the 'fast' ones.

Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions.  Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a user builds an array itself from single GPIOs.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Peter Korsgaard <peter.korsgaard@barco.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Rojhalat Ibrahim <imr@rtschenk.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Certain GPIO array lookup results may map directly to GPIO pins of a
single GPIO chip in hardware order.  If that condition is recognized
and handled efficiently, significant performance gain of get/set array
functions may be possible.

While processing a request for an array of GPIO descriptors, identify
those which represent corresponding pins of a single GPIO chip.  Skip
over pins which require open source or open drain special processing.
Moreover, identify pins which require inversion.  Pass a pointer to
that information with the array to the caller so it can benefit from
enhanced performance as soon as get/set array functions can accept and
make efficient use of it.

Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most users of get/set array functions iterate consecutive bits of data,
usually a single integer, while processing array of results obtained
from, or building an array of values to be passed to those functions.
Save time wasted on those iterations by changing the functions' API to
accept bitmaps.

All current users are updated as well.

More benefits from the change are expected as soon as planned support
for accepting/passing those bitmaps directly from/to respective GPIO
chip callbacks if applicable is implemented.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Peter Korsgaard <peter.korsgaard@barco.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Rojhalat Ibrahim <imr@rtschenk.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This concerns gpio edge detection for GPIO IRQs used from
userspace for GPIO event listeners.

Trying to work out the right event if it's not sure that the
examined gpio actually moved is impossible.

Consider two gpios "gpioA" and "gpioB" that share an interrupt.
gpioA's irq should trigger on any edge, gpioB's on a falling edge.
If now the common irq fires and both gpio lines are high, there
are several possibilities that could have happend:

 a) gpioA just had a low-to-high edge
 b) gpioB just had a high-to-low-to-high spike
 c) a combination of both a) and b)

While c) is unlikely (in most setups) a) and b) alone are bad
enough. Currently the code assumes case a) unconditionally and
doesn't report an event for gpioB. Note that even if there is no
irq sharing involved a spike for a gpio might not result in an
event if it's configured to trigger for a single edge only.

The only way to improve this is to drop support for interrupt
sharing. This way a spike results in an event for the right gpio
at least. Note that apart from dropping IRQF_SHARED this
effectively undoes commit df1e76f2
("gpiolib: skip unwanted events, don't convert them to opposite edge").

This obviously breaks setups that rely on interrupt sharing,
but given that this cannot be reliable, this is probably an
acceptable trade-off.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
[Assuming there are no users of interrupt sharing yet]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Just use the SPDX identifier for the license.
Acked-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a GPIO driver so only include <linux/gpio/driver.h>.
Acked-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ';' was missing. And cosmetic: there was a space too much.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The SPI chipselects are assumed to be active low in the current
binding, so when we want to use GPIO descriptors and handle
the active low/high semantics in gpiolib, we need a special
parsing quirk to deal with this.

We check for the property "spi-cs-high" and if that is
NOT present we assume the CS line is active low.

If the line is tagged as active low in the device tree and
has no "spi-cs-high" property all is fine, the device
tree and the SPI bindings are in agreement.

If the line is tagged as active high in the device tree with
the second cell flag and has no "spi-cs-high" property we
enforce active low semantics (as this is the exception we can
just tag on the flag).

If the line is tagged as active low with the second cell flag
AND tagged with "spi-cs-high" the SPI active high property
takes precedence and we print a warning.

Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since this driver does not use the gpiolib irqchip helpers it will have to
allocate the irq resources and irq_en/disable itself.

Use the new gpiochip_req/relres_irq helpers to request/release all the
resources.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Ray Jui <rjui@broadcom.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Document these new functions.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When using the gpiolib irqchip helpers install irq_enable/disable
hooks for the irqchip to ensure that gpiolib knows when the irq
is enabled or disabled, allowing drivers to disable the irq and then
use it as an output pin, and later switch the direction to input and
re-enable the irq.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio
as an interrupt. This is done when the irq is requested and it marks the
gpio as in use by an interrupt.

This is problematic for cases where a gpio pin is used as an interrupt
pin, then, after the irq is disabled, is used as a regular gpio pin.
Currently it is not possible to do this other than by first freeing
the interrupt so gpiochip_unlock_as_irq is called, since an attempt to
switch the gpio direction for output will fail since gpiolib believes
that the gpio is in use for an interrupt and it does not know that it
the irq is actually disabled.

There are currently two drivers that would like to be able to do this:
the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
driver where you want to configure the gpio pin as an interrupt while
waiting for traffic over the CEC bus, or as a regular pin when receiving or
transmitting a CEC message.

The solution is to add a new flag that is set when the irq is enabled,
and have gpiod_direction_output check for that flag.

We also add functions that drivers that do not use GPIOLIB_IRQCHIP
can call when they enable/disable the irq.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>