Some gpio controllers ignores pin value writing when that pin is
configured as input mode. As a result, bgpio_dir_out should set
pin to output before configuring pin values or gpio pin values
can't be set up properly.
Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first
and bgpio_dir_out_dir_first, and assign direction_output according
to a new flag: BGPIOF_NO_SET_ON_INPUT.

Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Tested-by: René van Dorst <opensource@vdorst.com>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

If '-o' was used more than 64 times in a single invocation of gpio-hammer,
this could lead to an overflow of the 'lines' array. This commit fixes
this by avoiding the overflow and giving a proper diagnostic back to the
user

Signed-off-by: Gabriel Ravier <gabravier@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

platform_get_irq() will generate an error message if the requested irq
is not present

  mvebu-gpio f1010140.gpio: IRQ index 3 not found

use platform_get_irq_optional() to avoid the error message being
generated.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXS driver for better compile
testing coverage.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXC driver for better compile
testing coverage.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Existing (irq < 0) condition is always false because adev->irq has unsigned
type and contains 0 in case of failed irq_of_parse_and_map(). Up to now all
the mapping errors were silently ignored.

Seems that repairing this check would be backwards-incompatible and might
break the probe() for the implementations without IRQ support. Therefore
warn the user instead.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Two literal blocks there are marked with both "::" and

	.. code-block:: c

This causes Sphinx (2.4.1) to do the wrong thing, causing
lots of warnings:

    Documentation/driver-api/gpio/driver.rst:425: WARNING: Unexpected indentation.
    Documentation/driver-api/gpio/driver.rst:423: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:427: WARNING: Block quote ends without a blank line; unexpected unindent.
    Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:429: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:433: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:446: WARNING: Unexpected indentation.
    Documentation/driver-api/gpio/driver.rst:440: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:440: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:447: WARNING: Block quote ends without a blank line; unexpected unindent.
    Documentation/driver-api/gpio/driver.rst:449: WARNING: Definition list ends without a blank line; unexpected unindent.
    Documentation/driver-api/gpio/driver.rst:462: WARNING: Unexpected indentation.
    Documentation/driver-api/gpio/driver.rst:460: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:462: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:465: WARNING: Block quote ends without a blank line; unexpected unindent.
    Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:467: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:471: WARNING: Inline emphasis start-string without end-string.
    Documentation/driver-api/gpio/driver.rst:478: WARNING: Inline emphasis start-string without end-string.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Character arrays can be considered empty strings (if they are
immediately terminated), but they cannot be NULL.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

These two devres functions devm_gpiochip_[add|remove]()
were in the wrong file. They should be in gpiolib-devres.c
not gpiolib.c.

Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.org


Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

This reverts commit a522f1d0.

With cpu_pm handling fixed for omaps, and with gpio-omap now returning
notify error on pending interrupts, we can drop the old workaround for
seeing if there may be pending edge interrupts.

Depends-on: ARM: OMAP2+: Handle errors for cpu_pm
Depends-on: gpio: omap: Block idle on pending gpio interrupts
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

With the SoC cpuidle handling fixed for cpu_pm, we can now start to
return NOTIFY_BAD if there there are pending gpio interrupts.

This way the deeper SoC idle states can get blocked, and gpio latency
is improved in some cases. Note that this will not help with the
latency if the SoC has already entered a deeper idle state.

Note that this patch depends on cpu_pm properly handling the errors
returned by notifiers. For omap variants, this is fixed with patch
"ARM: OMAP2+: Handle errors for cpu_pm".

Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

We need to check for errors when calling cpu_pm_enter() and
cpu_cluster_pm_enter(). And we need to bail out on errors as
otherwise we can enter a deeper idle state when not desired.

I'm not aware of the lack of error handling causing issues yet,
but we need this at least for blocking deeper idle states when
a GPIO instance has pending interrupts.

Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-2-tony@atomide.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

This patch adds support for the GPIO controller used by
Mellanox BlueField 2 SOCs.

Signed-off-by: Asmaa Mnebhi <Asmaa@mellanox.com>
Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Merge tag 'gpio-updates-for-v5.7-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel

gpio updates for v5.7 part 2

- replace z zero-length array with flexible-array member in gpio-uniphier
- make naming of variables consistent in uapi line event code
- fix the behavior of line watch/unwatch ioctl()

The optimization to check for requested lines actually optimized for the
uncomon error case, where one of the GPIO lines is still in use.
Hence the error message must be printed when the loop is terminated
early, not when it went through all available GPIO lines.

Fixes: 869233f8 ("gpiolib: Optimize gpiochip_remove() when check for requested line")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.be


Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

When operating on the bits of watched_lines bitmap, we're using
desc_to_gpio() which returns the GPIO number from the global numberspace.
This leads to all sorts of memory corruptions and invalid behavior. We
should switch to using gpio_chip_hwgpio() instead.

Fixes: 51c1064e ("gpiolib: add new ioctl() for monitoring changes in line info")
Reported-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: Kent Gibson <warthog618@gmail.com>

Fix the field having a bit cleared by the unwatch ioctl().

Fixes: 51c1064e ("gpiolib: add new ioctl() for monitoring changes in line info")
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Rename 'event' to 'ge' to be consistent with other use.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21


[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Here are the following optimizations have been done:
 - break the loop after first found requested line
  - due to above, drop redundant boolean variable
 - replace open coded variant of gpiochip_is_requested()
  - due to above, drop redundant pointer to struct gpio_desc
 - use 'unsigned int' instead of 'unsigned' for loop counter

Note, pointer to struct gpio_chip followed by pointer to struct gpio_device
is still valid, back link is not.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

As GPIO hogs are configured at GPIO controller initialization time,
adding/removing GPIO hogs in DT overlays does not work.

Add support for GPIO hogs described in DT overlays by registering an OF
reconfiguration notifier, to handle the addition and removal of GPIO hog
subnodes to/from a GPIO controller device node.

Note that when a GPIO hog device node is being removed, its "gpios"
properties is no longer available, so we have to keep track of which
node a hog belongs to, which is done by adding a pointer to the hog's
device node to struct gpio_desc.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.be


Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Extract the code to add all GPIO hogs of a gpio-hog node into its own
function, so it can be reused.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200220130149.26283-2-geert+renesas@glider.be


Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The existing use of ktime_get_real_ns() in the timestamps from
the GPIO events is dubious.

We have had several discussions about this timestamp, and it is
unclear whether userspace has ever taken into account that a
timestamp from ktime_get_real_ns() can actually move backwards
in time relative the previous timetamp, and userspace is more
likely to expect a monotonic counter.

Background:
https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/
https://marc.info/?l=linux-gpio&m=151661955709074&w=2



The change is ABI incompatible, but incompatible in a way that
is IMO more likely to fix future bugs rather than break current
userspace. To the best of my knowledge all userspace expects
a monotonic timestamp and users are just lucky that they very
seldom move backwards in time.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Whenever retrieving a descriptor from a gpiochip: use the provided
helper which checks for errors.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.pl


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

All the irq related callbacks are called with the (raw) spinlock
desc->lock being held. So the lock here must be raw as well. Also irqs
were already disabled by the caller for the irq chip callbacks, so the
non-irq variants of spin_lock must be used there.

Fixes: be8c8fac ("gpio: new driver to work with a 8x12 siox")
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20200211135121.15752-1-uwe@kleine-koenig.org


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The indentation is wrong in gpio_mockup_apply_pull(). This patch makes
the code more readable.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200210155059.29609-1-brgl@bgdev.pl


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

"Positive" is spelled incorrectly as "Postive" in
comment fix this.

Signed-off-by: Ashish Chavan <ashish.gschavan@gmail.com>
Link: https://lore.kernel.org/r/20200209095600.16394-1-ashish.gschavan@gmail.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Merge tag 'gpio-updates-for-v5.7-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel

gpio updates for v5.7 part 1

- make irqs optional in gpio-pxa
- improve the logic behind the get() and set() callbacks in gpio-wcd934x
- add new kfifo helpers (acked by kfifo maintainer)
- rework the locking mechanism for lineevent kfifo
- implement a new ioctl() for watching changes on GPIO lines

Add a simple program that allows to test the new LINECHANGED_FD ioctl().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Currently there is no way for user-space to be informed about changes
in status of GPIO lines e.g. when someone else requests the line or its
config changes. We can only periodically re-read the line-info. This
is fine for simple one-off user-space tools, but any daemon that provides
a centralized access to GPIO chips would benefit hugely from an event
driven line info synchronization.

This patch adds a new ioctl() that allows user-space processes to reuse
the file descriptor associated with the character device for watching
any changes in line properties. Every such event contains the updated
line information.

Currently the events are generated on three types of status changes: when
a line is requested, when it's released and when its config is changed.
The first two are self-explanatory. For the third one: this will only
happen when another user-space process calls the new SET_CONFIG ioctl()
as any changes that can happen from within the kernel (i.e.
set_transitory() or set_debounce()) are of no interest to user-space.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

We'll soon be filling out the gpioline_info structure in multiple
places. Add a separate function that given a gpio_desc sets all relevant
fields.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Currently if the line-event kfifo is full, we just silently drop any new
events. Add a ratelimited debug message so that we at least have some
trace in the kernel log of event overflow.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The read_lock mutex is supposed to prevent collisions between reading
and writing to the line event kfifo but it's actually only taken when
the events are being read from it.

Drop the mutex entirely and reuse the spinlock made available to us in
the waitqueue struct. Take the lock whenever the fifo is modified or
inspected. Drop the call to kfifo_to_user() and instead first extract
the new element from kfifo when the lock is taken and only then pass
it on to the user after the spinlock is released.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Provide two spinlocked versions of kfifo_is_empty() to be used with
spinlocked variants of kfifo_in() and kfifo_out().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Stefani Seibold <stefani@seibold.net>

Provide variants of spinlocked kfifo_in() and kfifo_out() routines which
don't disable interrupts.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Stefani Seibold <stefani@seibold.net>

Inclusion of kernel.h increases the mess with the header dependencies.
Avoid kernel.h inclusion where it's possible.

Besides that, clean up a bit other inclusions inside GPIO subsystem headers.
It includes:
 - removal pin control bits (forward declaration and header) from linux/gpio.h
 - removal of.h from asm-generic/gpio.h
 - use of explicit headers in gpio/consumer.h
 - add FIXME note with regard to gpio.h inclusion in of_gpio,h

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200205134336.20197-1-andriy.shevchenko@linux.intel.com


Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

The check with register value and mask should be & rather than &&.
While at it, also use "unsigned int" for value variable because
regmap_read() takes unsigned int *val argument.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The .set callback should just set output value.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Not all platforms use those. Let's use
platform_get_irq_byname_optional() instead platform_get_irq_byname() so
that we avoid a useless warning:

  [    1.359455] pxa-gpio d4019000.gpio: IRQ gpio0 not found
  [    1.359583] pxa-gpio d4019000.gpio: IRQ gpio1 not found

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>