The nested field in struct gpio_irq_chip currently has two meanings. On
one hand it marks an IRQ chip as being nested (as opposed to chained),
while on the other hand it also means that an IRQ chip uses nested
thread handlers.

However, nested IRQ chips can already be identified by the fact that
they don't pass a parent handler (the driver would instead already have
installed a nested handler using request_irq()).

Therefore, the only use for the nested attribute is to inform gpiolib
that an IRQ chip uses nested thread handlers (as opposed to regular,
non-threaded handlers). To clarify its purpose, rename the field to
"threaded".
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Export these functions so that drivers can explicitly use these when
setting up their IRQ domain.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Literally.

I expect "lose" was meant here, rather than "loose", though you could feasibly
use a somewhat uncommon definition of "loose" to mean what would be meant by
"lose": "Loose the hounds" for instance, as in "Release the hounds".
Substituting in "value" for "hounds" gives "release the value", and makes some
sense, but futher substituting back to loose gives "loose the value" which
overall just seems a bit anachronistic.

Instead, use modern, pragmatic English and save a character.

Cc: Russell Currey <ruscur@russell.cc>
Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace the two separate calls for clearing the irqchip's chained handler
and its data with a single irq_set_chained_handler_and_data() call.
Signed-off-by: NMartin Kaiser <martin@kaiser.cx>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

OPEN_DRAIN and OPEN_SOURCE flags only affect the way we drive a GPIO
line, so they only make sense for output mode. Just as we only allow
input mode for event handle requests, don't allow passing open-drain
and open-source flags for any other mode than explicit output.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There's no need to check the validity of handle request flags more
than once, right after copying the data from user. Move the check
out of the for loop and simplify the error path by bailing out before
allocating any resources.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

SPI-attached GPIO controllers typically read out all inputs in one go.
If callers desire the values of multipe inputs, ideally a single readout
should take place to return the desired values.  However the current
driver API only offers a ->get callback but no ->get_multiple (unlike
->set_multiple, which is present).  Thus, to read multiple inputs, a
full readout needs to be performed for every single value (barring
driver-internal caching), which is inefficient.

In fact, the lack of a ->get_multiple callback has been bemoaned
repeatedly by the gpio subsystem maintainer:
http://www.spinics.net/lists/linux-gpio/msg10571.html
http://www.spinics.net/lists/devicetree/msg121734.html

Introduce the missing callback.  Add corresponding consumer functions
such as gpiod_get_array_value().  Amend linehandle_ioctl() to take
advantage of the newly added infrastructure.  Update the documentation.

Cc: Rojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently calls to:
gpiod_direction_output_raw()
gpiod_set_raw_value()
gpiod_set_raw_array_value()
gpiod_set_raw_value_cansleep()
gpiod_set_raw_array_value_cansleep()

Respect that we do not want to invert the value written, but will
still apply special open drain/open source semantics if the line has
an open drain/open source flag.

It also forbids us from driving an output marked as an interrupt
line.

This does not fit with the function name and expected semantics. In
the w1 host driver (for example) we need to handle a line as open drain
but sometimes force it to pull up, which means we should be able to
use the gpiod_set_raw_value() for this, but it currently does not
work.

There are also use cases where users actually want to drive a line
used by an interrupt. This is what they should be expected to use
the *raw* accessors for.

I have looked over the current users of this API and they do not seem
to be using the *raw* accessors with open drain or open source so let's
augment this behaviour before we have users expecting the inconsistent
semantic.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The arbitrarily marking of a function with _ or __ is taking to mean
"perform some inner core of the caller" or something like that. At other
times, this syntax has a totally different meaning.

I don't like this since it is unambious and unhelpful to people reading
the code, so replace it with _commit() suffixes.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit 108d23e3.
It turns out this causes a regression on the OMAP, Marvell
and Renesas.
Reported-by: NTony Lindgren <tony@atomide.com>
Reported-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When converting legacy board to use gpiod API() there might be several
lookup tables in board file, let's provide a way to register them all at
once.
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some kerneldoc has become stale or wasn't quite correct from the outset.
Fix up the most serious issues to silence warnings when building the
documentation.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Tien Hock Loh <thloh@altera.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: NGregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in
gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and,
as result, leads to:
 - increasing of memory consumption for IRQ descriptors most of which will
never ever be used (espessially on platform with a high number of GPIOs).
(sizeof(struct irq_desc) == 256 on my tested platforms)
 - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements
GPIO IRQ functionality as IRQ crossbar/router which has only limited
number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8
IRQs).

Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and
instead replace irq_find_mapping() with irq_create_mapping() in
gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls
in gpiochip_to_irq() and gpiochip_irq_map().

After this change gpio2irq mapping will happen the following way when GPIO
irqchip APIs are used by gpio driver:
 - IRQ mappings will be created statically if driver passes first_irq>0
vlaue in gpiochip_irqchip_add_key().
 - IRQ mappings will be created dynamically from gpio_to_irq() or
of_irq_get().

Tested on am335x-evm and dra72-evm-revc.
- dra72-evm-revc: number of created irq mappings decreased from 402 -> 135
  Mem savings 267*256 = 68352 (66kB)
- am335x-evm: number of created irq mappings decreased from 188 -> 63
  Mem savings 125*256 = 32000 (31kB)

[1] https://lkml.org/lkml/2017/6/15/428Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Before querying a GPIO to determine its direction, the GPIO should be
formally requested.  This allows the GPIO driver to block access to
unavailable GPIOs, which makes it easier for some drivers to support
sparse GPIO maps.
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The previous fix for filtering out of unwatched events was not entirely
correct. Instead of skipping the events we don't want, they are now
interpreted as events with opposing edge.

In order to fix it: always read the GPIO line value on interrupt and
only emit the event if it corresponds with the event type we requested.

Cc: stable@vger.kernel.org
Fixes: ad537b82 ("gpiolib: fix filtering out unwanted events")
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.

The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.

Fix it by checking both RISING & FALLING flags explicitly.

Cc: stable@vger.kernel.org
Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This was left behind by a cleanup patch:

drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask':
drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' [-Werror=unused-variable]

Fixes: 923a654c ("gpiolib: Re-use bitmap_fill() instead of open coded loop")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NColin King <colin.king@canonical.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Re-use bitmap_fill() instead of open coded loop for setting an area of
bits in a bitmap.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This allows ACPI GPIO code to modify flags based on
ACPI GpioIo() / GpioInt() resources.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is preparatory patch for enabling GPIO ACPI to configure a pin
accordingly.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add new flags to allow users to specify that they are not concerned with
the status of GPIOs whilst in a sleep/low power state.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

For hot-pluggable devices adding GPIOs dynamically we need to
assemble and add the gpio lookup tables at probe time in modules,
so that requesting these GPIOs in attached drivers can work.
Export lookup table functions for modules.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Interrupt numbers are never negative, zero serves as the special invalid
value.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently, the GPIO interface is said to Open Drain if it is Single
Ended and active LOW. Similarly, it is said as Open Source if it is
Single Ended and active HIGH.

The active HIGH/LOW is used in the interface for setting the pin
state to HIGH or LOW when enabling/disabling the interface.

In Open Drain interface, pin is set to HIGH by putting pin in
high impedance and LOW by driving to the LOW.

In Open Source interface, pin is set to HIGH by driving pin to
HIGH and set to LOW by putting pin in high impedance.

With above, the Open Drain/Source is unrelated to the active LOW/HIGH
in interface. There is interface where the enable/disable of interface
is ether active LOW or HIGH but it is Open Drain type.

Hence decouple the Open Drain with Single Ended + Active LOW and
Open Source with Single Ended + Active HIGH.

Adding different flag for the Open Drain/Open Source which is valid
only when Single ended flag is enabled.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's unusual to have error checking like (ret <= 0) in cases when
counting GPIO resources. In case when it's mandatory we propagate the
error (-ENOENT), otherwise we don't use the result.

This makes consistent behaviour across all possible variants called in
gpiod_count().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Remove extra 'l' in "successfull".
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

devm_fwnode_get_gpiod_from_child() currently allows GPIO users to
request a GPIO that is defined in a child fwnode instead of directly in
the device fwnode.
Extend this API by adding the devm_fwnode_get_index_gpiod_from_child()
helper which does the same except you can also specify an index in case
the 'xx-gpios' property describe several GPIOs.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

"if (!x) WARN_ON(x)" can never trigger.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently we already have two pin configuration related callbacks
available for GPIO chips .set_single_ended() and .set_debounce(). In
future we expect to have even more, which does not scale well if we need
to add yet another callback to the GPIO chip structure for each possible
configuration parameter.

Better solution is to reuse what we already have available in the
generic pinconf.

To support this, we introduce a new .set_config() callback for GPIO
chips. The callback takes a single packed pin configuration value as
parameter. This can then be extended easily beyond what is currently
supported by just adding new types to the generic pinconf enum.

If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
just assign gpiochip_generic_config() (introduced in this patch) to
.set_config and that will take care configuration requests are directed
to the pinctrl driver.

We then convert the existing drivers over .set_config() and finally
remove the .set_single_ended() and .set_debounce() callbacks.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>