The GG.0 and GG.1 GPIOs serve as CLKREQ and RST pins, respectively, for
PCIe controller 5 on Tegra194. When this controller is configured in
endpoint mode, these pins need to be used as GPIOs by the PCIe endpoint
driver. Typically the mode programming of these pins (GPIO vs. SFIO) is
performed by early boot firmware to ensure that the configuration is
consistent.

However, the GG.0 and GG.1 pins are part of a special power partition
that is not enabled during early boot, and hence the early boot firmware
cannot program these pins to be GPIOs (they are SFIO by default). Adding
them as pin ranges for the pin controller allows the pin controller to
be involved when these pins are requested as GPIOs and allows the proper
programming to take place.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-4-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add support for Tegra SoC generations to specify a list of pin ranges
that map GPIOs to ranges of pins in the pin controller.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-3-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Wake gpiochip_generic_request() call into the pinctrl helpers only if a
GPIO controller had any pin-ranges assigned to it. This allows a driver
to unconditionally use this helper if it supports multiple devices of
which only a subset have pin-ranges assigned to them.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

impd1_probe() fills in the GPIO lookup table by manually populating an
array of gpiod_lookup structures.  Use the existing GPIO_LOOKUP() helper
macro instead, to relax a dependency on the gpiod_lookup structure's
member names.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lore.kernel.org/r/20200324135653.6676-1-geert+renesas@glider.beSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

The default handling of the gpio-line-names property by the
gpiolib-of implementation does not work with the multiple
gpiochip banks per device structure used by the gpio-brcmstb
driver.

This commit adds driver level support for the device tree
property so that GPIO lines can be assigned friendly names.
Signed-off-by: NDoug Berger <opendmb@gmail.com>
Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.comAcked-by: NGregory Fong <gregory.0xf0@gmail.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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

gpio updates for v5.7 part 4

- improve comments in the uapi header
- fix documentation issues
- add a warning to gpio-pl061 when the IRQ line is not configured
- allow building gpio-mxc and gpio-mxs with COMPILE_TEST enabled
- don't print an error message when an optional IRQ is missing in gpio-mvebu
- fix a potential segfault in gpio-hammer
- fix a couple typos and coding style issues in gpio tools
- provide a new flag in gpio-mmio and use it in mt7621 to fix an issue with
  the controller ignoring value setting when a GPIO is in input mode
- slightly refactor gpio_name_to_desc()

Replace COMSUMER with proper CONSUMER
Signed-off-by: NMykyta Poturai <mykyta.poturai@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

"retain good changes" means that I left the help string split up instead
of having this weird thing where it tries to merge together the last three
lines and it looks **really** bad
Signed-off-by: NGabriel Ravier <gabravier@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Since name == NULL can't ever match, move the check out of
IRQ-disabled region.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

There is a spelling mistake in an error message. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

DSET/DCLR registers only works on output pins. Add corresponding
BGPIOF_NO_SET_ON_INPUT flag to bgpio_init call to fix direction_out
behavior.
Signed-off-by: NChuanhong Guo <gch981213@gmail.com>
Tested-by: NRené van Dorst <opensource@vdorst.com>
Reviewed-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

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: NChuanhong Guo <gch981213@gmail.com>
Tested-by: NRené van Dorst <opensource@vdorst.com>
Reviewed-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: NBartosz 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: NGabriel Ravier <gabravier@gmail.com>
Signed-off-by: NBartosz 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: NChris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXS driver for better compile
testing coverage.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add COMPILE_TEST support to GPIO_MXC driver for better compile
testing coverage.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NBartosz 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: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NBartosz 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Character arrays can be considered empty strings (if they are
immediately terminated), but they cannot be NULL.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
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>

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: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-2-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>

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: 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>

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