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: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NBartosz 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.orgReviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus 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: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.comSigned-off-by: NLinus 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: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support for the GPIO controller used by
Mellanox BlueField 2 SOCs.
Signed-off-by: NAsmaa Mnebhi <Asmaa@mellanox.com>
Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.beAcked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus 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: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Tested-by: NKent 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: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Rename 'event' to 'ge' to be consistent with other use.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz 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: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NBartosz 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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus 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: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.beReviewed-by: NFrank Rowand <frank.rowand@sony.com>
Signed-off-by: NLinus 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: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200220130149.26283-2-geert+renesas@glider.beReviewed-by: NFrank Rowand <frank.rowand@sony.com>
Signed-off-by: NLinus 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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Whenever retrieving a descriptor from a gpiochip: use the provided
helper which checks for errors.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.plSigned-off-by: NLinus 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: NUwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20200211135121.15752-1-uwe@kleine-koenig.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The indentation is wrong in gpio_mockup_apply_pull(). This patch makes
the code more readable.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200210155059.29609-1-brgl@bgdev.plSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

"Positive" is spelled incorrectly as "Postive" in
comment fix this.
Signed-off-by: NAshish Chavan <ashish.gschavan@gmail.com>
Link: https://lore.kernel.org/r/20200209095600.16394-1-ashish.gschavan@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NLinus 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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy 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: NBartosz 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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

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: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The .set callback should just set output value.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NBartosz 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: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

'PTR_ERR(p) == -E*' is a stronger condition than IS_ERR(p).
Hence, IS_ERR(p) is unneeded.

The semantic patch that generates this commit is as follows:

// <smpl>
@@
expression ptr;
constant error_code;
@@
-IS_ERR(ptr) && (PTR_ERR(ptr) == - error_code)
+PTR_ERR(ptr) == - error_code
// </smpl>

Link: http://lkml.kernel.org/r/20200106045833.1725-1-masahiroy@kernel.orgSigned-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Stephen Boyd <sboyd@kernel.org> [drivers/clk/clk.c]
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [GPIO]
Acked-by: Wolfram Sang <wsa@the-dreams.de> [drivers/i2c]
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [acpi/scan.c]
Acked-by: NRob Herring <robh@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ROHM BD71828 PMIC contains 4 pins which can be configured by OTP
to be used for general purposes. First 3 can be used as outputs
and 4.th pin can be used as input. Allow them to be controlled
via GPIO framework.

The driver assumes all of the pins are configured as GPIOs and
trusts that the reserved pins in other OTP configurations are
excluded from control using "gpio-reserved-ranges" device tree
property (or left untouched by GPIO users).

Typical use for 4.th pin (input) is to use it as HALL sensor
input so that this pin state is toggled when HALL sensor detects
LID position change (from close to open or open to close). PMIC
HW implements some extra logic which allows PMIC to power-up the
system when this pin is toggled. Please see the data sheet for
details of GPIO options which can be selected by OTP settings.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If a driver consuming the GPIO chip is being probed at the same time as
the GPIO driver is registering the chip, it is possible for the
consuming driver to see the ->descs array in an uninitialised state.
For example, the gpio-keys-polled driver can fail like this:

    kernel: gpiod_request: invalid GPIO (no device)
    kernel: gpio-keys-polled PRP0001:07: failed to get gpio: -22
    kernel: gpio-keys-polled: probe of PRP0001:07 failed with error -22

This patch makes gpiochip_add() hold the lock protecting gpio_devices
until it has finished setting desc->gdev on the newly inserted list
entry.
Signed-off-by: NDan Callaghan <dan.callaghan@opengear.com>
Link: https://lore.kernel.org/r/20200121001216.15964-1-dan.callaghan@opengear.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

This fixes some various typos.
Signed-off-by: NSachin Agarwal <asachin591@gmail.com>
Link: https://lore.kernel.org/r/20200118105319.68637-1-sachinagarwal@sachins-MacBook-2.localSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiochip_set_chained_irqchip() would assign a chained handler
to a GPIO chip. We now populate struct gpio_irq_chip for all
chained GPIO irqchips so drop this function.

Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

When input GPIO set from 0 to 1, the interrupt bit asserted in the GPIO
Interrupt Cause Register (ICR) even if the corresponding interrupt
masked in the GPIO Interrupt Mask Register.

Because interrupt mask register only affects assertion of the interrupt
bits in Main Interrupt Cause Register and it does not affect the
setting of bits in the GPIO ICR.

So, there is problem, when we unmask interrupt with already
asserted bit in the GPIO ICR, then false interrupt immediately occurs
even if GPIO don't change their value since last unmask.
Signed-off-by: NMaxim Kiselev <bigunclemax@gmail.com>
Link: https://lore.kernel.org/r/20200115073811.24438-1-bigunclemax@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

In the current codes, the following 3 lines would be output to
the console for each irq line.
  gpio gpiochip0: (gpio_thunderx): allocate IRQ 10, hwirq 0
  gpio gpiochip0: (gpio_thunderx): found parent hwirq 245784
  gpio gpiochip0: (gpio_thunderx): alloc_irqs_parent for 10 parent hwirq 245784

In general, there are about tens of irq lines for each gpio chip,
and then it would emit so many insignificant log in the boot process.
These infos are more suitable for the dbg purpose. So change these
to the dbg level. With this change, about 200 lines are suppressed
on my Marvell cn96xx board.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20200120095625.25164-1-haokexin@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Adds the GPIO driver for SiFive RISC-V SoCs.
Signed-off-by: NWesley W. Terpstra <wesley@sifive.com>
[Atish: Various fixes and code cleanup]
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Signed-off-by: NYash Shah <yash.shah@sifive.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/1575976274-13487-6-git-send-email-yash.shah@sifive.com

gpio_set_config() simply call gpio_do_set_config(),
so remove the duplicated function.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200116142927.58908-1-yuehaibing@huawei.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch adds support to wcd934x gpio block found in
WCD9340/WC9341 Audio codecs.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200107130844.20763-3-srinivas.kandagatla@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

drivers/gpio/gpiolib.c: In function gpio_set_config:
drivers/gpio/gpiolib.c:3053:16: warning:
 variable config set but not used [-Wunused-but-set-variable]

commit d90f3685 ("gpiolib: have a single place
of calling set_config()") left behind this unused variable.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200108121117.45060-1-yuehaibing@huawei.comReviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

we had written "betwee" rather than "between".
Signed-off-by: NSachin agarwal <asachin591@gmail.com>
Link: https://lore.kernel.org/r/20200112143312.66048-1-sachinagarwal@sachins-MacBook-2.localSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

For consistency and easier maintenance: sort the headers alphabetically.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200114150253.28716-3-brgl@bgdev.plSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The current GPL v2.0 or later SPDX tag is 'GPL-2.0-or-later' as defined
at https://spdx.org/licenses/.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200114150253.28716-2-brgl@bgdev.plSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

drivers/gpio/gpio-grgpio.c: In function ‘grgpio_remove’:
drivers/gpio/gpio-grgpio.c:438:16: warning: unused variable ‘flags’ [-Wunused-variable]
  unsigned long flags;
                 ^
Fixes: 25d071b3 ("gpio: gpio-grgpio: fix possible sleep-in-atomic-context bugs in grgpio_remove()")
Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com>
Link: https://lore.kernel.org/r/1579009062-7154-1-git-send-email-zhangshaokun@hisilicon.com
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com
Reviewed-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>