gpio: of: Make of_gpio_get_count() take firmware node as a parameter

Make of_gpio_get_count() take firmware node as a parameter in order
to be aligned with other functions and decouple from unused device
pointer. The latter helps to create a common fwnode_gpio_count()
in the future.

While at it, rename to be of_gpio_count() to be aligned with the others.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpio: constify of_phandle_args in of_find_gpio_device_by_xlate()

Pointer to the struct of_phandle_args can be made const after
gpio_device_find() arguments got constified. This should be part of
commit 4a92857d6e83 ("gpio: constify opaque pointer "data" in
gpio_device_find()").

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpio: of: assign and read the hog pointer atomically

The device nodes representing GPIO hogs cannot be deleted without
unregistering the GPIO chip so there's no need to serialize their access.
However we must ensure that users can get the right address so write and
read it atomically.

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

gpio: constify opaque pointer in gpio_device_find() match function

The match function used in gpio_device_find() should not modify the
contents of passed opaque pointer, because such modification would not
be necessary for actual matching and it could lead to quite unreadable,
spaghetti code.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[Bartosz: fix coding style in header]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpio: legacy: mark old interfaces as deprecated in kernel docs

We've recently had someone try to use of_get_named_gpio() in new code.
Mark legacy interfaces as deprecated in kernel docs to avoid any
confusion.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

backlight: hx8357: Convert to agnostic GPIO API

The of_gpio.h is going to be removed. In preparation of that convert
the driver to the agnostic API.

Fixes: fbbbcd177a27 ("gpiolib: of: add quirk for locating reset lines with legacy bindings")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231207161513.3195509-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>

gpiolib: of: Add quirk for mt2701-cs42448 ASoC sound

These gpio names are due to old DT bindings not following the
"-gpio"/"-gpios" conventions. Handle it using a quirk so the
driver can just look up the GPIOs.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20231006-descriptors-asoc-mediatek-v1-1-07fe79f337f5@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>

gpio: of: replace gpiochip_find_* with gpio_device_find_*

We're porting all users of gpiochip_find() to using gpio_device_find().
Update the OF GPIO code.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: Allow "trigger-sources" to reference a GPIO

The "trigger-sources" phandle used for LED triggers are special:
the DT bindings mandate that such triggers have the same phandle
references no matter what the trigger is. A GPIO is just another
kind of device that can trigger a LED.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

mtd: rawnand: ingenic: move the GPIO quirk to gpiolib-of.c

We have a special place for OF polarity quirks in gpiolib-of.c. Let's
move this over there so that it doesn't pollute the driver.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy@kernel.org>

gpio: of: correct notifier return codes

According to the comments in linux/notifier.h, the code to return when a
notifications is "not for us" is NOTIFY_DONE, not NOTIFY_OK.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

mmc: atmel-mci: Move card detect gpio polarity quirk to gpiolib

The polarity of the card detection gpio is handled by the "cd-inverted"
property in the device tree. Move this inversion logic to gpiolib to avoid
reading the gpio raw value.

Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230825095157.76073-4-balamanikandan.gunasundar@microchip.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

gpiolib: of: Don't use GPIO chip fwnode in of_gpiochip_*()

GPIO library should rely only on the GPIO device's fwnode.
Hence, replace GPIO chip fwnode usage by respective OF node
of the GPIO device.

JFYI, this is partial revert of 8afe82550240 ("gpiolib: of:
Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode").

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Benjamin Tissoires <bentiss@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: Clean up headers

There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically

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

gpiolib: split of_mm_gpio_chip out of linux/of_gpio.h

This is a rarely used feature that has nothing to do with the
client-side of_gpio.h.

Split it out with a separate header file and Kconfig option
so it can be removed on its own timeline aside from removing
the of_gpio consumer interfaces.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

gpiolib: of: Move enum of_gpio_flags to its only user

GPIO library for OF is the only user for enum of_gpio_flags.
Move it there.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: Get rid of not used of_node member

All new drivers should use fwnode and / or parent to provide the
necessary information to the GPIO library.

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: remove [devm_]gpiod_get_from_of_node() APIs

Now that everyone is using [devm_]fwnode_gpiod_get[_index]() APIs,
remove OF-specific [devm_]gpiod_get_from_of_node().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: remove of_get_gpio[_flags]() and of_get_named_gpio_flags()

There are no more users of these APIs in the mainline kernel, remove
them. This leaves of_get_named_gpio() as the only legacy OF-specific
API.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: remove obsolete comment for of_gpio_get_count()

The function is only being called form the main gpiolib module, so
remove comment saying that it is also used by external callers.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: stop exporting of_gpio_named_count()

The only user of this function is gpiolib-of.c so move it there.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Revert "gpiolib: of: Introduce hook for missing gpio-ranges"

This reverts commit 3550bba25d5587a701e6edf20e20984d2ee72c78.

No users for this one, revert it for good.
The ->add_pin_ranges() can be used instead.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20230113215352.44272-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: Use correct fwnode for DT-probed chips

The OF node store in chip->fwnode is used to explicitly override the FW
node for a GPIO chip. For chips that use the default FW node (i.e. that
of their parent device), this will be NULL and cause the chip not to be
fully registered.

Instead, use the GPIO device's FW node, which is set to either the node
of the parent device or the explicit override in chip->fwnode.

Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Robert Marko <robimarko@gmail.com>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Tested-by: Brian Masney <bmasney@redhat.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: Drop redundant check in of_mm_gpiochip_remove()

The callers never call the function with invalid pointer.
Moreover, compiler quite likely dropped that check anyway
because we use that pointer before the check.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: Prepare of_mm_gpiochip_add_data() for fwnode

GPIO library is getting rid of of_node, fwnode should be utilized instead.
Prepare of_mm_gpiochip_add_data() for fwnode.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: change of_find_gpio() to accept device node

In preparation of switching all OF-based GPIO lookups to go through
of_find_gpio() let's change it to accept device node as its argument as
we do not always have access to device structure.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: Integrate of_gpiochip_init_valid_mask() into gpiochip_init_valid_mask()

In preparation to complete fwnode switch, integrate
of_gpiochip_init_valid_mask() into gpiochip_init_valid_mask().

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode

GPIO library is getting rid of of_node, fwnode should be utilized instead.
Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add polarity quirk for Freescale PCIe controller

Bindings for Freescale PCIe controller use a separate property called
"reset-gpio-active-high" to control polarity of its reset line, add it
to the list of quirks in gpiolib so that gpiod API can be used in the
driver.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: factor out quirk setting polarity via separate property

Several legacy bindings use a separate property to specify polarity of
GPIOs instead of specifying it directly in the GPIO property. Factor
out this code to make it easier to add more such cases.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: Make use of device_match_of_node()

Make use of device_match_of_node() instead of open coding its
functionality.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add a quirk for reset line polarity for Himax LCDs

Existing DTS that use legacy (non-standard) property name for the reset
line "gpios-reset" also specify incorrect polarity (0 which maps to
"active high"). Add a quirk to force polarity to "active low" so that
once driver is converted to gpiod API that pays attention to line
polarity it will work properly.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add quirk for phy reset polarity for Freescale Ethernet

Bindings for Freescale Fast Ethernet Controller use a separate
property "phy-reset-active-high" to specify polarity of its phy
gpio line. To allow converting the driver to gpiod API we need
to add this quirk to gpiolib.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: factor out code overriding gpio line polarity

There are several instances where we use a separate property to
override polarity specified in gpio property. Factor it out into
a separate function.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add a quirk for legacy names in MOXA ART RTC

The driver is using non-standard "gpio-rtc-data", "gpio-rtc-sclk", and
"gpio-rtc-reset" names for properties describing its gpios. In
preparation to converting to the standard naming ("rtc-*-gpios") and
switching the driver to gpiod API add a quirk to gpiolib to keep
compatibility with existing DTSes.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add a quirk for reset line for Cirrus CS42L56 codec

The controller is using non-standard "cirrus,gpio-nreset" name for its
reset gpio property, whereas gpiod API expects "<name>-gpios".
Add a quirk so that gpiod API will still work on unmodified DTSes.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add a quirk for reset line for Marvell NFC controller

The controller is using non-standard "reset-n-io" name for its reset
gpio property, whereas gpiod API expects "<name>-gpios". Add a quirk
so that gpiod API will still work on unmodified DTSes.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add quirk for locating reset lines with legacy bindings

Some legacy mappings used "gpio[s]-reset" instead of "reset-gpios",
add a quirk so that gpiod API will still work on unmodified DTSes.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: tighten selection of gpio renaming quirks

Tighten selection of legacy gpio renaming quirks so that they only
considered on more relevant configurations.

Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: consolidate simple renames into a single quirk

This consolidates all quirks doing simple renames (either allowing
suffix-less names or trivial renames, when index changes are not
required) into a single quirk.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: of: add a quirk for legacy names in Mediatek mt2701-cs42448

The driver is using non-standard "i2s1-in-sel-gpio1" and
"i2s1-in-sel-gpio2" names to describe its gpios. In preparation to
converting to the standard naming (i2s1-in-sel-gpios) and switching the
driver to gpiod API add a quirk to gpiolib to keep compatibility with
existing DTSes.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

gpiolib: fix OOB access in quirk callbacks

Commit a2b5e207cade ("gpiolib: rework quirk handling in of_find_gpio()")
introduced an array of quirk functions which get iterated over. But a
sentinal value is missing. Add it.

Fixes: a2b5e207cade ("gpiolib: rework quirk handling in of_find_gpio()")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: factor out conversion from OF flags

There are several places where we need to convert from OF flags to
"normal" GPIO_* flags, so let's introduce a helper and use it.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: rework quirk handling in of_find_gpio()

Instead of having a string of "if" statements let's put all quirks into
an array and iterate over them.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: make Freescale SPI quirk similar to all others

There is no need for of_find_spi_cs_gpio() to be different from other
quirks: the only variant of property actually used in DTS is "gpios"
(plural) so we can use of_get_named_gpiod_flags() instead of recursing
into of_find_gpio() again.

This will allow us consolidate quirk handling down the road.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: do not ignore requested index when applying quirks

We should not ignore index passed into of_find_gpio() when handling
quirks. While in practice this change will not have any effect, it
will allow consolidate quirk handling.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: support bias pull disable

On top of looking at PULL_UP and PULL_DOWN flags, also look at
PULL_DISABLE and set the appropriate GPIO flag. The GPIO core will then
pass down this to controllers that support it.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpio: gpiolib-of: Fix refcount bugs in of_mm_gpiochip_add_data()

We should use of_node_get() when a new reference of device_node
is created. It is noted that the old reference stored in
'mm_gc->gc.of_node' should also be decreased.

This patch is based on the fact that there is a call site in function
'qe_add_gpiochips()' of src file 'drivers\soc\fsl\qe\gpio.c'. In this
function, of_mm_gpiochip_add_data() is contained in an iteration of
for_each_compatible_node() which will automatically increase and
decrease the refcount. So we need additional of_node_get() for the
reference escape in of_mm_gpiochip_add_data().

Fixes: a19e3da5bc5f ("of/gpio: Kill of_gpio_chip and add members directly to gpio_chip")
Signed-off-by: Liang He <windhl@126.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: Use device_match_of_node() helper

Instead of open coding, use device_match_of_node() helper.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: Introduce hook for missing gpio-ranges

Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.

In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.

Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: Embed iterator variable into for_each_gpio_desc_with_flag()

The iterator loop is used exclusively to get a descriptor, which in its
turn is what is being used by the caller. Embed the iterator variable
into the loop in the for_each_gpio_desc_with_flag() macro helper.

Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: fix bounds check for 'gpio-reserved-ranges'

Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size"
because it clears "size" bits starting from the "start" bit in the according
bitmap. So it has to use "greater" instead of "greater or equal" when performs
bounds check to make sure that GPIOs are in the available range.
Previous implementation skipped ranges that include the last GPIO in
the range.

I wrote the mail to the maintainers
(https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u)
of the questioned DTSes (because I couldn't understand how the maintainers
interpreted this property), but I haven't received a response.
Since the questioned DTSes use "gpio-reserved-ranges = <0 4>"
(i.e., the beginning of the range), this patch doesn't affect these DTSes at all.
TBH this patch doesn't break any existing DTSes because none of them
reserve gpios at the end of range.

Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property")
Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: Introduce for_each_gpio_desc_with_flag() macro

In a few places we are using a loop against all GPIO descriptors
with a given flag for a given device. Replace it with a consolidated
for_each type of macro.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

gpiolib: of: make fwnode take precedence in struct gpio_chip

If the driver sets the fwnode in struct gpio_chip, let it take
precedence over the of_node. This only affects OF-based systems,
ACPI needs to be converted separately.

Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: constify few local device_node variables

gpiolib does not modify struct device_node, so few local pointers can
point to a const data.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpiolib: constify passed device_node pointer

Several gpiolib functions receive pointer to struct device_node which is
later passed to OF functions. These OF functions accept already pointer
to const, so gpiolib can follow similar approach to indicate they are
not modifying the struct device_node.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpiolib: Move of_node operations to gpiolib-of and correct fwnode use

The initial value of the OF node based on presence of parent, but
at the same time this operation somehow appeared separately from others
that handle the OF case. On the other hand there is no need to assign
dev->fwnode in the OF case if code properly retrieves fwnode, i.e.
via dev_fwnode() helper.

Amend gpiolib.c and gpiolib-of.c code in order to group OF operations.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default

There are multiple instances of GPIO device tree nodes of the form:

foo {
compatible = "acme,foo";
...

gpio0: gpio0@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};

gpio1: gpio1@xxxxxxxx {
compatible = "acme,bar";
...
gpio-controller;
};

...
}

bazz {
my-gpios = <&gpio0 ...>;
}

Case 1: The driver for "foo" populates struct device for these gpio*
nodes and then probes them using a driver that binds with "acme,bar".
This driver for "acme,bar" then registers the gpio* nodes with gpiolib.
This lines up with how DT nodes with the "compatible" property are
typically converted to struct devices and then registered with driver
core to probe them. This also allows the gpio* devices to hook into all
the driver core capabilities like runtime PM, probe deferral,
suspend/resume ordering, device links, etc.

Case 2: The driver for "foo" doesn't populate struct devices for these
gpio* nodes before registering them with gpiolib. Instead it just loops
through its child nodes and directly registers the gpio* nodes with
gpiolib.

Drivers that follow case 2 cause problems with fw_devlink=on. This is
because fw_devlink will prevent bazz from probing until there's a struct
device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO
supplier). Once the struct device is available, fw_devlink will create a
device link with gpio0 device as the supplier and bazz device as the
consumer. After this point, since the gpio0 device will never bind to a
driver, the device link will prevent bazz device from ever probing.

Finding and refactoring all the instances of drivers that follow case 2
will cause a lot of code churn and it is not something that can be done
in one shot. In some instances it might not even be possible to refactor
them cleanly. Examples of such instances are [1] [2].

This patch works around this problem and avoids all the code churn by
simply setting the fwnode of the gpio_device and creating a stub driver
to bind to the gpio_device. This allows all the consumers to continue
probing when the driver follows case 2.

[1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
[2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/

Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpiolib: of: Use named item for enum gpiod_flags variable

Use named item instead of plain integer for enum gpiod_flags
to make it clear that even 0 has its own meaning.

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

gpiolib: Extract gpiod_not_found() helper

Several places in the code are using same idiom, i.e.
IS_ERR(desc) && PTR_ERR(desc) == -ENOENT
which meaning is GPIO description is not found.

For better readability extract gpiod_not_found() helper and use it.

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

gpiolib: generalize devprop_gpiochip_set_names() for device properties

devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() & of_fwnode_handle()
in ACPI and OF GPIO code respectively). Let's just switch to using the
generic device properties.

This allows us to pull the code setting line names directly into
gpiochip_add_data_with_key() instead of handling it separately for
ACPI and OF.

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

spi: ppc4xx: Convert to use GPIO descriptors

This converts the PPC4xx SPI driver to use GPIO descriptors.

The driver is already just picking some GPIOs from the device
tree so the conversion is pretty straight forward. However
this driver is looking form a pure "gpios" property rather
than the standard binding "cs-gpios" so we need to add a new
exception to the gpiolib OF parser to allow this for this
driver's compatibles.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20200714072226.26071-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>

gpio: gpiolib-of: Provide documentation for of_gpio_spi_cs_get_count()

Descriptions for of_gpio_spi_cs_get_count()'s 2 arguments are
missing. Document both 'dev' and 'con_id'.

Fixes the following W=1 kernel build warnings:

drivers/gpio/gpiolib-of.c:36: warning: Function parameter or member 'dev' not described in 'of_gpio_spi_cs_get_count'
drivers/gpio/gpiolib-of.c:36: warning: Function parameter or member 'con_id' not described in 'of_gpio_spi_cs_get_count'

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Link: https://lore.kernel.org/r/20200630133345.2232932-2-lee.jones@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

usb: fusb302: Convert to use GPIO descriptors

This converts the FUSB302 driver to use GPIO descriptors.
The conversion to descriptors per se is pretty straight-forward.

In the process I discovered that:

1. The driver uses a completely undocumented device tree binding
for the interrupt GPIO line, "fcs,int_n". Ooops.

2. The undocumented binding, presumably since it has not seen
review, is just "fcs,int_n", lacking the compulsory "-gpios"
suffix and also something that is not a good name because
the "_n" implies the line is inverted which is something we
handle with flags in the device tree. Ooops.

3. Possibly the driver should not be requesting the line as a
GPIO and request the corresponding interrupt line by open
coding, the GPIO chip is very likely doubleing as an IRQ
controller and can probably provide an interrupt directly
for this line with interrupts-extended = <&gpio0 ...>;

4. Possibly the IRQ should just be tagged on the I2C client node
in the device tree like apparently ACPI does, as it overrides
this IRQ with client->irq if that exists.

But now it is too late to do much about that and as I can see
this is used like this in the Pinebook which is a shipping product
so let'a just contain the mess and move on.

The property currently appears in:
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts

Create a quirk in the GPIO OF library to allow this property
specifically to be specified without the "-gpios" suffix, we have
other such bindings already.

Cc: Tobias Schramm <t.schramm@manjaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Yueyao Zhu <yueyao@google.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200415192448.305257-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpiolib: of: improve gpiolib-of support of pull up/down on expanders

When using GPIO expanders attached to I2C ports, their set_config function
needs to be passed a config setting which contains options to enable pull
up or pull down bias feature. In order to set this config properly,
the gpio parser needs to handle GPIO_PULL_UP and GPIO_PULL_DOWN.

This patch enables the flags corresponding to GPIO_PULL_UP and
GPIO_PULL_DOWN.

Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpio: of: Add DT overlay support for GPIO hogs

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>

gpio: of: Extract of_gpiochip_add_hog()

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>

treewide: remove redundant IS_ERR() before error code check

'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.org
Signed-off-by: Masahiro 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: Rob Herring <robh@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mmc: core: Rework cd-gpio handling

There are a few places around the code that invert inverted and possibly
inverted CD line. That's really confusing. Squash them all into one place
in mmc_gpiod_request_cd(). MMC_CAP2_CD_ACTIVE_HIGH is used analogously to
WP line: in GPIO mode it is used only at probe time to switch polarity, for
native mode it is left as is.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/db189b715596d63caf8c6a088bddc71dd69a879b.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: core: Rework wp-gpio handling

Use MMC_CAP2_RO_ACTIVE_HIGH flag as indicator if GPIO line is to be
inverted compared to DT/platform-specified polarity. The flag is not used
after init in GPIO mode anyway. No functional changes intended.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/a60f563f11bbff821da2fa2949ca82922b144860.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

gpiolib: of: Make of_gpio_spi_cs_get_count static

Fix sparse warning:

drivers/gpio/gpiolib-of.c:35:5: warning:
symbol 'of_gpio_spi_cs_get_count' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191130012828.14504-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>

gpio: Handle counting of Freescale chipselects

We have a special quirk to handle the Freescale
nonstandard SPI chipselect GPIOs in the gpiolib-of.c
file, but it currently only handles the case where
the GPIOs are actually requested (gpiod_*get()).

We also need to handle that the SPI core attempts
to count the GPIOs before use, and that needs a
similar quirk in the OF part of the library.

Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>

gpio: of: Fix bogus reference to gpiod_get_count()

The recommended function is called gpiod_count(), not gpiod_get_count().

Fixes: f626d6dfb7098525 ("gpio: of: Break out OF-only code")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191120154521.16273-1-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: No need to call gpiochip_remove_pin_ranges() twice

of_gpiochip_add(), when fails, calls gpiochip_remove_pin_ranges().

ADD:
gpiochip_add_data_with_key() ->
of_gpiochip_add() -> (ERROR path)
gpiochip_remove_pin_ranges()

At the same time of_gpiochip_remove() calls exactly the above mentioned
function unconditionally and so does gpiochip_remove().

REMOVE:
gpiochip_remove() ->
gpiochip_remove_pin_ranges()
of_gpiochip_remove() ->
gpiochip_remove_pin_ranges()

Since gpiochip_remove() calls gpiochip_remove_pin_ranges() unconditionally,
we have duplicate call to the same function when it's not necessary.

Move gpiochip_remove_pin_ranges() from of_gpiochip_add() to gpiochip_add()
to avoid duplicate calls and be consistent with the explicit call in
gpiochip_remove().

Fixes: e93fa3f24353 ("gpiolib: remove duplicate pin range code")
Depends-on: f7299d441a4d ("gpio: of: Fix of_gpiochip_add() error path")
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: don't warn if ignored GPIO flag matches the behavior

Some devicetrees specify the ACTIVE_LOW flag in the fixed regulator GPIO
handle. While this has always been ignored, it's consistent with the
behavior of the regulator binding in the absence of the
"enable-active-high" DT property. It doesn't make much sense to print a
user visible warning for a configuration which is consistent, so only
print the warning if the GPIO flag contradicts the behavior dictated by
by the enable-active-high property.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[Bartosz: coding style tweak]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpio: fix kernel-doc for of_gpio_need_valid_mask()

Fix kernel-doc for of_gpio_need_valid_mask().
Fixes this warning and uses correct Return: format.

../drivers/gpio/gpiolib-of.c:92: warning: Excess function parameter 'dev' description in 'of_gpio_need_valid_mask'

Fixes: f626d6dfb709 ("gpio: of: Break out OF-only code")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: linux-gpio@vger.kernel.org
Link: https://lore.kernel.org/r/6c5d22c8-6e27-3314-9c46-701d932b11a6@infradead.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: fix getting nonexclusive gpiods from DT

Since commit ec757001c818 ("gpio: Enable nonexclusive gpiods from DT
nodes") we are able to get GPIOD_FLAGS_BIT_NONEXCLUSIVE marked gpios.
Currently the gpiolib uses the wrong flags variable for the check. We
need to check the gpiod_flags instead of the of_gpio_flags else we
return -EBUSY for GPIOD_FLAGS_BIT_NONEXCLUSIVE marked and requested
gpiod's.

Fixes: ec757001c818 gpio: Enable nonexclusive gpiods from DT nodes
Cc: stable@vger.kernel.org
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
[Bartosz: the function was moved to gpiolib-of.c so updated the patch]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpiolib: of: add a fallback for wlf,reset GPIO name

The old Arizona binding did not use -gpio or -gpios suffix, so
devm_gpiod_get() does not work for it. As it is the one of a few users
of devm_gpiod_get_from_of_node() API that I want to remove, I'd rather
have a small quirk in the gpiolib OF handler, and switch Arizona
driver to devm_gpiod_get().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190911075215.78047-2-dmitry.torokhov@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Switch to EXPORT_SYMBOL_GPL()

All exported functions provide genuine Linux-specific functionality.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20190906084539.21838-4-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Make of_gpio_simple_xlate() private

Since commit 9a95e8d25a140ba9 ("gpio: remove etraxfs driver"), there are
no more users of of_gpio_simple_xlate() outside gpiolib-of.c.
All GPIO drivers that need it now rely on of_gpiochip_add() setting it
up as the default translate function.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20190906084539.21838-3-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Make of_get_named_gpiod_flags() private

Since commit f626d6dfb7098525 ("gpio: of: Break out OF-only code"),
there are no more users of of_get_named_gpiod_flags() outside
gpiolib-of.c.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20190906084539.21838-2-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: fix fallback quirks handling

We should only try to execute fallback quirks handling when previous
call returned -ENOENT, and not when we did not get -EPROBE_DEFER.
The other errors should be treated as hard errors: we did find the GPIO
description, but for some reason we failed to handle it properly.

The fallbacks should only be executed when previous handlers returned
-ENOENT, which means the mapping/description was not found.

Also let's remove the explicit deferral handling when iterating through
GPIO suffixes: it is not needed anymore as we will not be calling
fallbacks for anything but -ENOENT.

Fixes: df451f83e1fc ("gpio: of: fix Freescale SPI CS quirk handling")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190903231856.GA165165@dtor-ws
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Normalize return code variable name

It is confusing to name return variables mixedly "status",
"err" or "ret". I just changed them all to "ret", by personal
preference, to lower cognitive stress.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190716115854.12098-1-linus.walleij@linaro.org

gpio: of: fix Freescale SPI CS quirk handling

On the gta04 we see:
spi_gpio: probe of spi_lcd failed with error -2

The quirk introduced in
commit e3023bf80639 ("gpio: of: Handle the Freescale SPI CS")
can also be triggered by a temporary -EPROBE_DEFER and
so "convert" it to a hard -ENOENT.

Disable that conversion by checking for -EPROBE_DEFER.

Fixes: e3023bf80639 ("gpio: of: Handle the Freescale SPI CS")
Suggested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20190816165000.32334-1-andreas@kemnade.info
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Fix hard-assigned valid_mask for OF case

The recent refactoring to break out OF code to its own file
contained a bug letting the need_valid_mask
be overridden by the need of the device tree range check,
and if there were no ranges, but device tree was active
and the reserved GPIO used in another way, things likely
crash.

Cc: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Fixes: f626d6dfb709 ("gpio: of: Break out OF-only code")
Reported-by: Mark Brown <broonie@kernel.org>
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Break out OF-only code

The core gpiolib should not contain any OF/device tree-only
code. Try to break out the main part of it and push it down
into the optional gpiolib-of.c part of the library.

Create a local gpiolib-of.h header and move stuff around a
bit to get a clean cut.

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

Revert "gpio/spi: Fix spi-gpio regression on active high CS"

This reverts commit fbbf145a0e0a0177e089c52275fbfa55763e7d1d.

It seems I was misguided in my fixup, which was working at the
time but did not work on the final v5.2.

The patch tried to avoid a quirk the gpiolib code not to treat
"spi-gpio" CS gpios "special" by enforcing them to be active
low, in the belief that since the "spi-gpio" driver was
parsing the device tree on its own, it did not care to inspect
the "spi-cs-high" attribute on the device nodes.

That's wrong. The SPI core was inspecting them inside the
of_spi_parse_dt() funtion and setting SPI_CS_HIGH on the
nodes, and the driver inspected this flag when driving the
line.

As of now, the core handles the GPIO and it will consistently
set the GPIO descriptor to 1 to enable CS, strictly requireing
the gpiolib to invert it. And the gpiolib should indeed
enforce active low on the CS line.

Device trees should of course put the right flag on the GPIO
handles, but it used to not matter. If we don't enforce active
low on "gpio-gpio" we may run into ABI backward compatibility
issues, so revert this.

Cc: linux-spi@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190715204529.9539-1-linus.walleij@linaro.org

gpiolib: of: fix a memory leak in of_gpio_flags_quirks()

Each iteration of for_each_child_of_node puts the previous node, but in
the case of a break from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the break.
Issue found with Coccinelle.

Cc: <stable@vger.kernel.org>
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

gpio/spi: Fix spi-gpio regression on active high CS

I ran into an intriguing bug caused by
commit ""spi: gpio: Don't request CS GPIO in DT use-case"
affecting all SPI GPIO devices with an active high
chip select line.

The commit switches the CS gpio handling over to the GPIO
core, which will parse and handle "cs-gpios" from the OF
node without even calling down to the driver to get the
job done.

However the GPIO core handles the standard bindings in
Documentation/devicetree/bindings/spi/spi-controller.yaml
that specifies that active high CS needs to be specified
using "spi-cs-high" in the DT node.

The code in drivers/spi/spi-gpio.c never respected this
and never tried to inspect subnodes to see if they contained
"spi-cs-high" like the gpiolib OF quirks does. Instead the
only way to get an active high CS was to tag it in the
device tree using the flags cell such as
cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;

This alters the quirks to not inspect the subnodes of SPI
masters on "spi-gpio" for the standard attribute "spi-cs-high",
making old device trees work as expected.

This semantic is a bit ambigous, but just allowing the
flags on the GPIO descriptor to modify polarity is what
the kernel at large mostly uses so let's encourage that.

Fixes: 249e2632dcd0 ("spi: gpio: Don't request CS GPIO in DT use-case")
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: parse stmmac PHY reset line specific active-low property

The stmmac driver currently ignores the GPIO flags which are passed via
devicetree because it operates with legacy GPIO numbers instead of GPIO
descriptors. stmmac assumes that the GPIO is "active HIGH" by default.
This can be overwritten by setting "snps,reset-active-low" to make the
reset line "active LOW".

Recent Amlogic SoCs (G12A which includes S905X2 and S905D2 as well as
G12B which includes S922X) use GPIOZ_14 or GPIOZ_15 for the PHY reset
line. These GPIOs are special because they are marked as "3.3V input
tolerant open drain" pins which means they can only drive the pin output
LOW (to reset the PHY) or to switch to input mode (to take the PHY out
of reset).
The GPIO subsystem already supports this with the GPIO_OPEN_DRAIN and
GPIO_OPEN_SOURCE flags in the devicetree bindings.

Add the stmmac PHY reset line specific active low parsing to gpiolib-of
so stmmac can be ported to GPIO descriptors while being backwards
compatible with device trees which use the "old" way of specifying the
polarity.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Handle the Freescale SPI CS

The Freescale SPI chipselects are special: while everyone else
is using "cs-gpios" the Freescale platforms just use "gpios".
Fix this by responding with "gpios" when asking for "cs-gpios"
in a freescale device node, so we hide this pecularity from
the SPI core.

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

gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT

Since GPIO library operates with enumerator when it's subject to handle
the GPIO lookup flags, it will be better to clearly see what default means.

Thus, introduce GPIO_LOOKUP_FLAGS_DEFAULT entry to describe
the default assumptions.

While here, replace 0 by newly introduced constant.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: Make use of enum gpio_lookup_flags consistent

The library uses enum gpio_lookup_flags to define the possible
characteristics of GPIO pin. Since enumerator listed only individual
bits the common use of it is in a form of a bitmask of
gpio_lookup_flags GPIO_* values. The more correct type for this is
unsigned long.

Due to above convert all users to use unsigned long instead of
enum gpio_lookup_flags except enumerator definition.

While here, make field and parameter descriptions consistent as well.

Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Optimize quirk checks

Simple string comparisons are cheaper than DT lookups, as the latter
involve taking a spinlock and traversing properties.
Hence optimize quirk checks by postponing DT lookups after string
comparisons.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Fix of_gpiochip_add() error path

If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no
error handling is performed. This lead to the need of callers to call
of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..."
if the failure happened before the call to of_node_get().

Fix this by adding proper error handling.

Note that calling gpiochip_remove_pin_ranges() multiple times causes no
harm: subsequent calls are a no-op.

Fixes: dfbd379ba9b7431e ("gpio: of: Return error if gpio hog configuration failed")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Check for "spi-cs-high" in child instead of parent node

"spi-cs-high" is going to be specified in child node of an SPI
controller's representing attached SPI device, so change the code to
look for it there, instead of checking parent node.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Check propname before applying "cs-gpios" quirks

SPI GPIO device has more than just "cs-gpio" property in its node and
would request those GPIOs as a part of its initialization. To avoid
applying CS-specific quirk to all of them add a check to make sure
that propname is "cs-gpios".

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Handle both enable-gpio{,s}

Handle both enable-gpio and enable-gpios properties of the GPIO
regulator in the quirk. The later is the preferred modern name
of the property.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Restrict enable-gpio quirk to regulator-gpio

Commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to
enable-gpios") breaks the device tree ABI specified in the device tree
bindings for fixed regulators (compatible "regulator-fixed"). According
to these bindings the polarity of the GPIO is exclusively controlled by
the presence or absence of the enable-active-high property. As such the
polarity quirk implemented in of_gpio_flags_quirks() must be applied to
the GPIO specified for fixed regulators.

However, commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only
to enable-gpios") restricted the quirk to the enable-gpios property for
fixed regulators as well, whereas according to the commit message itself
it should only apply to "regulator-gpio" compatible device tree nodes.

Fix this by actually implementing what the offending commit intended,
which is to ensure that the quirk is applied to the GPIO specified by
the "enable-gpio" property for the "regulator-gpio" bindings only.

This fixes a regression on Jetson TX1 where the fixed regulator for the
HDMI +5V pin relies on the flags quirk for the proper polarity.

Fixes: 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Apply regulator-gpio quirk only to enable-gpios

Since commit d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
the GPIO regulator had inverted the polarity of the control GPIO. This
problem manifested itself on systems with DT containing the following
description (snippet from salvator-common.dtsi):

gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
gpios-states = <1>;
states = <3300000 1
1800000 0>;

Prior to the aforementioned commit, the gpio-regulator code used
gpio_request_array() to claim the GPIO(s) specified in the "gpios"
DT node, while the commit changed that to devm_gpiod_get_index().

The legacy gpio_request_array() calls gpio_request_one() and then
gpiod_request(), which parses the DT flags of the "gpios" node and
populates the GPIO descriptor flags field accordingly.

The new devm_gpiod_get_index() calls gpiod_get_index(), then
of_find_gpio(), of_get_named_gpiod_flags() with flags != NULL,
and then of_gpio_flags_quirks(). Since commit a603a2b8d86e
("gpio: of: Add special quirk to parse regulator flags"),
of_gpio_flags_quirks() contains a quirk for regulator-gpio
which was never triggered by the legacy gpio_request_array()
code path, but is triggered by devm_gpiod_get_index() code
path.

This quirk checks whether a GPIO is associated with a fixed
or gpio-regulator and if so, checks two additional conditions.
First, whether such GPIO is active-low, and if so, ignores the
active-low flag. Second, whether the regulator DT node does
have an "enable-active-high" property and if the property is
NOT present, sets the GPIO flags as active-low.

The second check triggers a problem, since it is applied to all
GPIOs associated with a gpio-regulator, rather than only on the
"enable" GPIOs, as the old code did. This changes the way the
gpio-regulator interprets the DT description of the control
GPIOs.

The old code using gpio_request_array() explicitly parsed the
"enable-active-high" DT property and only applied it to the
GPIOs described in the "enable-gpios" DT node, and only if
those were present.

This patch fixes the quirk code by only applying the quirk
to "enable-gpios", thus restoring the old behavior.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: add core support for pull-up/pull-down configuration

This commit adds support for configuring the pull-up and pull-down
resistors available in some GPIO controllers. While configuring
pull-up/pull-down is already possible through the pinctrl subsystem,
some GPIO controllers, especially simple ones such as GPIO expanders
on I2C, don't have any pinmuxing capability and therefore do not use
the pinctrl subsystem.

This commit implements the GPIO_PULL_UP and GPIO_PULL_DOWN flags,
which can be used from the Device Tree, to enable a pull-up or
pull-down resistor on a given GPIO.

The flag is simply propagated all the way to the core GPIO subsystem,
where it is used to call the gpio_chip ->set_config callback with the
appropriate existing PIN_CONFIG_BIAS_* values.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Fix logic inversion

The SPI chip selects were not properly inspected due to
a logic inversion. This made SPI GPIOs not work.

Cc: Jan Kotas <jank@cadence.com>
Reported-by: Jan Kotas <jank@cadence.com>
Tested-by: Jan Kotas <jank@cadence.com>
Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

gpio/mmc/of: Respect polarity in the device tree

The device tree bindings for the MMC card detect and
write protect lines specify that these should be active
low unless "cd-inverted" or "wp-inverted" has been
specified.

However that is not how the kernel code has worked. It
has always respected the flags passed to the phandle in
the device tree, but respected the "cd-inverted" and
"wp-inverted" flags such that if those are set, the
polarity will be the inverse of that specified in the
device tree.

Switch to behaving like the old code did and fix the
regression.

Fixes: 81c85ec15a19 ("gpio: OF: Parse MMC-specific CD and WP properties")
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: OF: Parse MMC-specific CD and WP properties

When retrieveing CD (card detect) and WP (write protect)
GPIO handles from the device tree, make sure to assign
them active low by default unless the "cd-inverted" or
"wp-inverted" properties are set. These properties mean
that respective signal is active HIGH since the SDHCI
specification stipulates that this kind of signals
should be treated as active LOW.

If the twocell GPIO flag is also specified as active
low, well that's nice and we will silently ignore the
tautological specification.

If however the GPIO line is specified as active low
in the GPIO flasg cell and "cd-inverted" or "wp-inverted"
is also specified, the latter takes precedence and we
print a warning.

The current effect on the MMC slot-gpio core are as
follows:

For CD GPIOs: no effect. The current code in
mmc/core/host.c calls mmc_gpiod_request_cd() with
the "override_active_level" argument set to true,
which means that whatever the GPIO descriptor
thinks about active low/high will be ignored, the
core will use the MMC_CAP2_CD_ACTIVE_HIGH to keep
track of this and reads the raw value from the
GPIO descriptor, totally bypassing gpiolibs inversion
semantics. I plan to clean this up at a later point
passing the handling of inversion semantics over
to gpiolib, so this patch prepares the ground for
that.

Fow WP GPIOs: this is probably fixing a bug, because
the code in mmc/core/host.c calls mmc_gpiod_request_ro()
with the "override_active_level" argument set to false,
which means it will respect the inversion semantics of
the gpiolib and ignore the MMC_CAP2_RO_ACTIVE_HIGH
flag for everyone using this through device tree.
However the code in host.c confusingly goes to great
lengths setting up the MMC_CAP2_RO_ACTIVE_HIGH flag
from the GPIO descriptor and by reading the "wp-inverted"
property of the node. As far as I can tell this is all
in vain and the inversion is broken: device trees that
use "wp-inverted" do not work as intended, instead the
only way to actually get inversion on a line is by
setting the second cell flag to GPIO_ACTIVE_HIGH (which
will be the default) or GPIO_ACTIVE_LOW if they want
the proper MMC semantics. Presumably all device trees do
this right but we need to parse and handle this properly.

Cc: linux-mmc@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: restore original GPLv2+ license of gpiolib-of.c sources

It's easy to verify that the change of drivers/gpio/gpiolib-of.c license
header to SPDX standard changes the license from GPLv2+ to GPLv2, and
this change corrects it.

Fixes: dae5f0afcfc3 ("gpio: Use SPDX header for core library")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Use SPDX header for core library

Use the SPDX headers and cut down on boilerplate to indicate the
license in the core gpiolib implementation.

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

gpio: of: Handle SPI chipselect legacy bindings

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: Linus Walleij <linus.walleij@linaro.org>

gpio: Fix crash due to registration race

gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list
before of_gpiochip_add() is called, but it's only the latter which sets
the ->of_xlate function pointer. gpiochip_find() can be called by
someone else between these two actions, and it can find the chip and
call of_gpiochip_match_node_and_xlate() which leads to the following
crash due to a NULL ->of_xlate().

Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000
Modules linked in: leds_gpio(+) gpio_generic(+)
CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43
Hardware name: ARM-Versatile Express
PC is at (null)
LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38
Process insmod (pid: 830, stack limit = 0x(ptrval))
(of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84)
(gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238)
(of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8)
(gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144)
(devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio])
(gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c)
(platform_drv_probe) from (really_probe+0x1d0/0x3d4)
(really_probe) from (driver_probe_device+0x78/0x1c0)
(driver_probe_device) from (__driver_attach+0x120/0x13c)
(__driver_attach) from (bus_for_each_dev+0x68/0xb4)
(bus_for_each_dev) from (bus_add_driver+0x1a8/0x268)
(bus_add_driver) from (driver_register+0x78/0x10c)
(driver_register) from (do_one_initcall+0x54/0x1fc)
(do_one_initcall) from (do_init_module+0x64/0x1f4)
(do_init_module) from (load_module+0x2198/0x26ac)
(load_module) from (sys_finit_module+0xe0/0x110)
(sys_finit_module) from (ret_fast_syscall+0x0/0x54)

One way to fix this would be to rework the hairy registration sequence
in gpiochip_add_data_with_key(), but since I'd probably introduce a
couple of new bugs if I attempted that, simply add a check for a
non-NULL of_xlate function pointer in
of_gpiochip_match_node_and_xlate(). This works since the driver looking
for the gpio will simply fail to find the gpio and defer its probe and
be reprobed when the driver which is registering the gpiochip has fully
completed its probe.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Convert to using %pOFn instead of device_node.name

In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: Fix of_node inconsistency

Some platforms are not setting of_node in the driver. On these platforms
defining gpio-reserved-ranges on device tree leads to kernel crash.

It is due to some parts of the gpio core relying on the driver to set up
of_node,while other parts do themselves.This inconsistent behaviour leads
to a crash.

gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node
as NULL. of_gpiochip_add() fills "of_node" and calls
of_gpiochip_init_valid_mask().

The fix is to move the assignment to chip->of_node from of_gpiochip_add()
to gpiochip_add_data_with_key().

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Handle fixed regulator flags properly

This fixes up the handling of fixed regulator polarity
inversion flags: while I remembered to fix it for the
undocumented "reg-fixed-voltage" I forgot about the
official "regulator-fixed" binding, there are two ways
to do a fixed regulator.

The error was noticed and fixed.

Fixes: a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags")
Cc: Mark Brown <broonie@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Convert to use match_string() helper

The new helper returns index of the matching string in an array.
We are going to use it here.

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

gpiolib: Support 'gpio-reserved-ranges' property

Some qcom platforms make some GPIOs or pins unavailable for use by
non-secure operating systems, and thus reading or writing the registers
for those pins will cause access control issues. Add support for a DT
property to describe the set of GPIOs that are available for use so that
higher level OSes are able to know what pins to avoid reading/writing.
Non-DT platforms can add support by directly updating the
chip->valid_mask.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Handle deferred probing in of_find_gpio() properly

of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly
through of_find_spi_gpio() or of_find_regulator_gpio() can return
-EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio()
calls.

This patch fixes this by trying of_find_spi_gpio() or
of_find_regulator_gpio() only if deferred probing was not requested by
the previous of_get_named_gpiod_flags() call.

Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties")
Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
[Augmented to fit with Maxime's patch]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: Keep returning EPROBE_DEFER when we should

Commits c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties")
and 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO
properties") have introduced a regression in the way error codes from
of_get_named_gpiod_flags are handled.

Previously, those errors codes were returned immediately, but the two
commits mentioned above are now overwriting the error pointer, meaning that
whatever value has been returned will be dropped in favor of whatever the
two new functions will return.

This might not be a big deal except for EPROBE_DEFER, on which GPIOlib
customers will depend on, and that will now be returned as an hard error
which means that they will not probe anymore, instead of gently deferring
their probe.

Since EPROBE_DEFER basically means that we have found a valid property but
there was no GPIO controller registered to handle it, fix this issues by
returning it as soon as we encounter it.

Fixes: c85823390215 ("gpio: of: Support SPI nonstandard GPIO properties")
Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[Fold in fix to the fix]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Support gpio nexus dt bindings

Platforms like 96boards have a standardized connector/expansion
slot that exposes signals like GPIOs to expansion boards in an
SoC agnostic way. We'd like the DT overlays for the expansion
boards to be written once without knowledge of the SoC on the
other side of the connector. This avoids the unscalable
combinatorial explosion of a different DT overlay for each
expansion board and SoC pair.

Now that we have nexus support in the OF core let's change the
function call here that parses the phandle lists of gpios to use
the nexus variant. This allows us to remap phandles and their
arguments through any number of nexus nodes and end up with the
actual gpio provider being used.

Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>

gpio: of: Fix NPE from OF flags

Some calls to of_get_named_gpio() calls sets the flags
argument to NULL because they are not interested in the
flags. This caused a null pointer exception since we were
unconditionally using these flags. Fix it.

Fixes: 6a537d48461d ("gpio: of: Support regulator nonstandard GPIO properties")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Add special quirk to parse regulator flags

While most GPIOs are indicated to be active low or open drain using
their twocell flags, we have legacy regulator bindings to take into
account.

Add a quirk respecting the special boolean active-high and open
drain flags when parsing regulator nodes for GPIOs.

This makes it possible to get rid of duplicated inversion semantics
handling in the regulator core and any regulator drivers parsing
and handling this separately.

Unfortunately the old regulator inversion semantics are specified
such that the presence or absence of "enable-active-high" solely
controls the semantics, so we cannot deprecate this in favor
of the phandle-provided inversion flag, instead any such phandle
inversion flag provided in the second cell of a GPIO handle must be
actively ignored, so we print a warning to contain the situation
and make things easy for the users.

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

gpio: of: Support regulator nonstandard GPIO properties

Before it was clearly established that all GPIO properties in the
device tree shall be named "foo-gpios" (with the deprecated variant
"foo-gpio" for single lines) we unfortunately merged a few bindings
for regulators with random phandle names.

As we want to switch the GPIO regulator driver to using descriptors,
we need devm_gpiod_get() to return something reasonable when looking
up these in the device tree.

Put in a special #ifdef:ed kludge to do this special lookup only
for the regulator case and gets compiled out if we're not enabling
regulators. Supply a whitelist with properties we accept.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Support SPI nonstandard GPIO properties

Before it was clearly established that all GPIO properties in the
device tree shall be named "foo-gpios" (with the deprecated variant
"foo-gpio" for single lines) we unfortunately merged a few bindings
which named the lines "gpio-foo" instead.

This is most prominent in the GPIO SPI driver in Linux which names
the lines "gpio-sck", "gpio-mosi" and "gpio-miso".

As we want to switch the GPIO SPI driver to using descriptors, we
need devm_gpiod_get() to return something reasonable when looking
up these in the device tree.

Put in a special #ifdef:ed kludge to do this special lookup only
for the SPI case and gets compiled out if we're not enabling SPI.
If we have more oddly defined legacy GPIOs like this, they can be
handled in a similar manner.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: fix "gpio-line-names" property retrieval

Following commit 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names()
to use device property accessors"), "gpio-line-names" DT property is
not retrieved anymore when chip->parent is not set by the driver.
This is due to OF based property reads having been replaced by device
based property reads.

This patch fixes that by making use of
fwnode_property_read_string_array() instead of
device_property_read_string_array() and handing over either
of_fwnode_handle(chip->of_node) or dev_fwnode(chip->parent)
to that function.

Fixes: 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device property accessors")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: gpiolib: Generalise state persistence beyond sleep

General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.

The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.

The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Fix loose spelling

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: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Improve kerneldoc

Add descriptions for missing fields and fix up some parameter references
to match the code.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Convert to using %pOF instead of full_name

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: Rob 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: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Spelling: s/retures/returns/

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

gpio: Add new flags to control sleep status of GPIOs

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: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: core: Decouple open drain/source flag with active low/high

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: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Add support for multiple GPIOs in a single GPIO hog

When listing multiple GPIOs in the "gpios" property of a GPIO hog, only
the first GPIO is affected. The user is left clueless about the
dysfunctioning of the other GPIOs specified.

Fix this by adding and documenting support for specifying multiple
GPIOs in a single GPIO hog.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: fix GPIO drivers with multiple gpio_chip for a single node

Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are
broken too.

Those drivers register multiple gpio_chip that are associated to a
single OF node, and their own .of_xlate() checks if the passed
gpio_chip is valid.

Now, the problem is of_find_gpiochip_by_node() returns the first
gpio_chip found to match the given node. So, .of_xlate() fails,
except for the first GPIO bank.

Reverting the commit could be a solution, but I do not want to go
back to the mess of struct gg_data. Another solution here is to
take the match by a node pointer and the success of .of_xlate().
It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
and for really getting the gpio_desc index. Perhaps, our long-term
goal might be to convert the drivers to single chip registration,
but this commit will solve the problem until then.

Fixes: 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: add missing of_node_put() in of_gpiochip_scan_gpios()

When terminating for_each_available_child_of_node() iteration
with break or return, of_node_put() should be used to prevent
stale device node references from being left behind.

This is detected by Coccinelle semantic patch.

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Rework of_gpiochip_set_names() to use device property accessors

In order to use "gpio-line-names" property in systems not having DT as
their boot firmware, rework of_gpiochip_set_names() to use device property
accessors. This reworked function is placed in a separate file making it
clear it deals with universal device properties.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: OF: separation of concerns

The generic GPIO library directly implement code for of_find_gpio()
which is only used with CONFIG_OF and causes compilation problems
on archs that do not even have stubs for OF functions, especially
on UM that does not implement any IO remap functions.

Move the function to gpiolib-of.c, implement a static inline stub
in gpiolib.h returning PTR_ERR(-ENOENT) if CONFIG_OF_GPIO is not
set and be done with it.

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

Revert "gpio: include <linux/io-mapping.h> in gpiolib-of"

This reverts commit 7d4defe21c682c934a19fce1ba8b54b7bde61b08.

The commit was pointless, manically trembling in the dark for
a solution. The real fixes are:

commit 048c28c91e56
("gpio: make any OF dependent driver depend on OF_GPIO")
commit 2527ecc9195e
("gpio: Fix OF build problem on UM")

Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: factor out common code to a new helper function

The conversion from a DT spec to struct gpio_desc is common between
of_get_named_gpiod_flags() and of_parse_own_gpio(). Factor out the
common code to a new helper, of_xlate_and_get_gpiod_flags().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: remove of_gpiochip_and_xlate() and struct gg_data

The usage of gpiochip_find(&gg_data, of_gpiochip_and_xlate) is odd.

Usually gpiochip_find() is used to find a gpio_chip. Here, however,
the return value from gpiochip_find() is just discarded. Instead,
gpiochip_find(&gg_data, of_gpiochip_and_xlate) is called for the
side-effect of the match function.

The match function, of_gpiochip_find_and_xlate(), fills the given
struct gg_data, but a match function should be simply called to
judge the matching.

This commit fixes this distortion and makes the code more readable.
Remove of_gpiochip_find_and_xlate() and struct gg_data. Instead,
this adds a very simple helper function of_find_gpiochip_by_node().
Now, of_get_named_gpiod_flags() is implemented more straight-forward.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: move chip->of_gpio_n_cells checking to of_gpiochip_add()

Do this sanity check only once when the gpio_chip is added
rather than every time gpio-hog is handled.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: drop needless gpio_chip look-up in of_parse_own_gpio()

This function is doing more complicated than needed. The caller of
this function, of_gpiochip_scan_gpios() already knows the pointer to
the gpio_chip. It can pass it to of_parse_own_gpio() instead of
looking up the gpio_chip by gpiochip_find().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: optimize "gpios" property parsing of of_parse_own_gpio()

Call of_property_read_u32_array() only once rather than iterating
of_property_read_u32_index().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: include <linux/io-mapping.h> in gpiolib-of

When enabling the gpiolib for all archs a build robot came
up with this:

All errors (new ones prefixed by >>):

drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data':
>> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of
function 'iounmap' [-Werror=implicit-function-declaration]
iounmap(mm_gc->regs);
^~~~~~~
cc1: some warnings being treated as errors

Fix this by including <linux/io-mapping.h> explicitly.

Fixes: 296ad4acb8ef ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: add missing of_node_put() to of_gpiochip_add_pin_range()

As the comment block of of_parse_phandle_with_fixed_args() says,
the caller is responsible to call of_node_put() on the returned
node when done.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: make it possible to name GPIO lines

Make it possible to name the producer side of a GPIO line using
a "gpio-line-names" property array, modeled on the
"clock-output-names" property from the clock bindings.

This naming is especially useful for:

- Debugging: lines are named after function, not just opaque
offset numbers.

- Exploration: systems where some or all GPIO lines are available
to end users, such as prototyping, one-off's "makerspace usecases"
users are helped by the names of the GPIO lines when tinkering.
This usecase has been surfacing recently.

The gpio-line-names attribute is completely optional.

Example output from lsgpio on a patched Snowball tree:

GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines
line 0: unnamed unused
line 1: "AP_GPIO161" "extkb3" [kernel]
line 2: "AP_GPIO162" "extkb4" [kernel]
line 3: "ACCELEROMETER_INT1_RDY" unused [kernel]
line 4: "ACCELEROMETER_INT2" unused
line 5: "MAG_DRDY" unused [kernel]
line 6: "GYRO_DRDY" unused [kernel]
line 7: "RSTn_MLC" unused
line 8: "RSTn_SLC" unused
line 9: "GYRO_INT" unused
line 10: "UART_WAKE" unused
line 11: "GBF_RESET" unused
line 12: unnamed unused

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: David Mandala <david.mandala@linaro.org>
Cc: Lee Campbell <leecam@google.com>
Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Scan available child node for gpio-hog

Look for child node which are available when iterating for
gpio hog node for request/set GPIO initial configuration
during OF gpio chip registration.

All it really does is make it possible to set
status = "disabled"; in the hog nodes, and then they will
not be applied.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: Return error if gpio hog configuration failed

If GPIO hog configuration failed while adding OF based
gpiochip() then return the error instead of ignoring it.

This helps of properly handling the gpio driver dependency.

When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
ready at this time and gpio_request() for Tegra GPIO driver
returns error. The error was not causing the Tegra GPIO driver
to fail as the error was getting ignored.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: provide optional of_mm_gpiochip_add_data() function

In the same spirit as we add an optional void *data argument
to the gpiochip_add_data() call, we need this also for
of_mm_gpiochip_add().

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

gpio: change member .dev to .parent

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib-of: Rename gpio_hog functions to be generic

The gpio hogging functions are currently only used for gpio-hogging. But
these functions are widely generic ones which parse gpio device nodes in
the DT.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: defer probe if pinctrl cannot be found

When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
the pin controller isn't available.

Otherwise, the GPIO range wouldn't be set at all unless the pin
controller probed always before the GPIO chip.

With this change, the probe of the GPIO chip will be deferred and will
be retried at a later point, hopefully once the pin controller has been
registered and probed already.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: remove unneeded assignation

ret is assigned value from of_property_read_string_index but is
overwritten before being used so remove it.
Also fix coverity CID 1309759

Reported-by: coverity (CID 1309759)
Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of: remove unnecessary variable in of_get_gpio_hog()

The variable "desc" is only used for storing the return value at the
end of the function. It is unneeded.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Drivers: gpio: Fix spelling errors

Fixed several spelling errors in gpio-lynxpoint, gpio-pca953x,
gpio-tegra, gpio-zynq, gpiolib-of, gpiolib.

Signed-off-by: Colin Cronin <colinpatrickcronin@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: add GPIO hogging mechanism

Based on Boris Brezillion's work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initially configure specific GPIO
when the GPIO controller is probed.

The actual DT scanning to collect the GPIO specific data is performed
as part of gpiochip_add().

The purpose of this is to allow specific GPIOs to be configured
without any driver specific code.
This is particularly useful because board design are getting
increasingly complex and given SoC pins can now have more
than 10 mux values, a lot of connections are now dependent on
external IO muxes to switch various modes.

Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
"description" should be best kept as part of the dts file.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node

The change:

7b8792bbdffdff3abda704f89c6a45ea97afdc62
gpiolib: of: Correct error handling in of_get_named_gpiod_flags

assumed that only one gpio-chip is registred per of-node.
Some drivers register more than one chip per of-node, so
adjust the matching function of_gpiochip_find_and_xlate to
not stop looking for chips if a node-match is found and
the translation fails.

Cc: Stable <stable@vger.kernel.org>
Fixes: 7b8792bbdffd ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags")
Signed-off-by: Hans Holmberg <hans.holmberg@intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: Correct error handling in of_get_named_gpiod_flags

of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases
where the gpio chip is available and the GPIO translation fails.

This causes drivers to be re-probed erroneusly, and hides the
real problem(i.e. the GPIO number being out of range).

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Hans Holmberg <hans.holmberg@intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/gpiolib-of: Create of_mm_gpiochip_remove

Create counterpart of of_mm_gpiochip_add(). This way the modules that
can be removable do not duplicate the cleanup code.

Suggested-by: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: delete unneeded test before of_node_put

Of_node_put supports NULL as its argument, so the initial test is not
necessary.

Suggested by Uwe Kleine-König.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e;
@@

-if (e)
of_node_put(e);
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: make gpiochip_get_desc() gpiolib-private

As GPIO descriptors are not going to remain unique anymore, having this
function public is not safe. Restrain its use to gpiolib since we have
no user outside of it.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: remove export of private of_get_named_gpio_flags()

of_get_named_gpio_flags() has been made gpiolib-private by commit
f01d907582, but its EXPORT statement has not been removed. Fix this.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: Update debug messages for of_get_named_gpiod_flags

Following is the debug output (only a few examples) before and after
the patch.

$ dmesg | grep of_get_named_gpiod_flags

Before:
of_get_named_gpiod_flags: can't parse gpios property
of node '/mmc@12220000[0]'
of_get_named_gpiod_flags exited with status 0

After:
of_get_named_gpiod_flags: can't parse 'wp-gpios' property
of node '/mmc@12220000[0]'
of_get_named_gpiod_flags: parsed 'gpios' property of node
'/gpio-keys/power[0]' - status (0)

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: make of_get_named_gpiod_flags() private

of_get_named_gpiod_flags() is visible and directly usable by GPIO
consumers, but it really should not as the gpiod interface relies
on the simpler gpiod_get() to provide properly-configured GPIOs.

of_get_named_gpiod_flags() is just used internally by gpiolib to
implement gpiod_get(), and by the old of_get_named_gpio_flags()
function, therefore it makes sense to make it gpiolib-private.

As a side-effect, the unused (and unneeded) of_get_gpiod_flags()
inline function is also removed, and of_get_named_gpio_flags() is moved
from a static inline function to a regular one in gpiolib-of.c

This results in all references to gpiod_* functions in of_gpio.h being
gone, which is the way it should be since this file is part of the old
integer GPIO interface.

Changes since v1:
- Fixed compilation error when CONFIG_OF_GPIO is not defined
- Fixed warning due to of_gpio_flags enum not being declared
in private gpiolib.h header

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: of: remove gpio_to_desc() usage

As demonstrated by commit
390d82e312c56b75407a3606cbcde8c4bc7f10ae
"gpiolib: ACPI: remove gpio_to_desc() usage"

gpio_to_desc() must die. Replace one of its usage by the
newly-introduced gpiochip_get_desc() function.

Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: gpiolib-of: Use PTR_ERR_OR_ZERO

PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
also include missing err.h header.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: port of_ functions to use gpiod

Refactor the of_ functions of gpiolib to use the now public gpiod
interface, and export of_get_named_gpiod_flags() and
of_get_gpiod_flags() functions.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl/gpio: non-linear GPIO ranges accesible from gpiolib

This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.

Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: implement gpio-ranges binding document fix

Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

gpio: gpiolib-of.c: make error message more meaningful by adding the node name and index

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: gpiolib-of.c: fix checkpatch error

Fix :
gpio/gpiolib-of.c:64: ERROR: code indent should use tabs where possible

Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: add gpio offset in gpio range cells property

Add gpio offset into "gpio-range-cells" property. It's used to support
sparse pinctrl range in gpio chip.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: fix wrong checking condition for gpio range

If index++ calculates from 0, the checking condition of "while
(index++)" fails & it doesn't check any more. It doesn't follow
the loop that used at here.

Replace it by endless loop at here. Then it keeps parsing
"gpio-ranges" property until it ends.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Make of_count_named_gpios() use new of_count_phandle_with_args()

This patch replaces the horribly coded of_count_named_gpios() with a
call to of_count_phandle_with_args() which is far more efficient. This
also changes the return value of of_gpio_count() & of_gpio_named_count()
from 'unsigned int' to 'int' so that it can return an error code. All
the users of that function are fixed up to correctly handle a negative
return value.

v2: Split GPIO portion into a separate patch

Tested-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>

gpio: use pinctrl device name for add range

gpiochip_add_pin_range() needs pinctrl device name as parameter.
Currently the parameter is pinctrl description name. So fix it.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: let gpiochip_add_pin_range() specify offset

Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76
it is not always enough to specify all the pins of a gpio_chip
from offset zero to be added to a pin map range, since the
mapping from GPIO to pin controller may not be linear at all,
but need to be broken into a few consecutive sub-ranges or
1-pin entries for complicated cases. The ranges may also be
sparse.

This alters the signature of the function to accept offsets
into both the GPIO-chip local pinspace and the pin controller
local pinspace.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: separation of pin concerns

The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.

So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.

This is done by:

- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.

- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.

- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().

Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.

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

gpiolib: remove duplicate pin range code

Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Introduced both of_gpiochip_remove_pin_range() and
gpiochip_remove_pin_ranges(). But the contents are exactly
the same so remove the OF one and rely on the range deletion
in the core.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib-of: staticize the pin range calls

Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Declared the of_gpiochip_[add|remove]_pin_range() global
while they should be static as they are only ever used in
this file. Let's convert them to static.

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: provide provision to register pin ranges

pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.

As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.

After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: Fix debug message in of_get_named_gpio_flags()

This was probably missed in the conversion done in commit 3d0f7cf
("gpio: Adjust of_xlate API to support multiple GPIO chips").

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not yet available

of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
respective GPIO is not (yet) available. This is useful if driver's probe()
functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
can be probed again later on.

The function still returns -EINVAL on other errors (parse error or node doesn't
exist). This way, the case of an optional/intentionally missing GPIO is handled
appropriately.

Signed-off-by: Roland Stigge <stigge@antcom.de>
Acked-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: propagate of_parse_phandle_with_args errors

Make of_get_named_gpio_flags propagate any error it receives from
of_parse_phandle_with_args instead of inconditionally returning -EINVAL.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/of: fix a typo of comment message

Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

gpio: Adjust of_xlate API to support multiple GPIO chips

This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node. This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device. With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.

Tested-by: Roland Stigge <stigge@antcom.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

gpio: Move DT support code into drivers/gpio

The code in drivers/of/gpio.c isn't shared by any other subsystem since it
is all gpiolib specific. drivers/gpio is a better place to maintain these
functions.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>