linux-stable.git/drivers/gpio, branch linux-5.0.y

gpio: Fix gpiochip_add_data_with_key() error path

2019-05-16T17:40:26+00:00

[ Upstream commit 357798909164bf423eac6a78ff7da7e98d2d7f7f ]

The err_remove_chip block is too coarse, and may perform cleanup that
must not be done.  E.g. if of_gpiochip_add() fails, of_gpiochip_remove()
is still called, causing:

    OF: ERROR: Bad of_node_put() on /soc/gpio@e6050000
    CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.1.0-rc2-koelsch+ #407
    Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
    Workqueue: events deferred_probe_work_func
    [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
    [] (show_stack) from [] (dump_stack+0x7c/0x9c)
    [] (dump_stack) from [] (kobject_put+0x94/0xbc)
    [] (kobject_put) from [] (gpiochip_add_data_with_key+0x8d8/0xa3c)
    [] (gpiochip_add_data_with_key) from [] (gpio_rcar_probe+0x1d4/0x314)
    [] (gpio_rcar_probe) from [] (platform_drv_probe+0x48/0x94)

and later, if a GPIO consumer tries to use a GPIO from a failed
controller:

    WARNING: CPU: 0 PID: 1 at lib/refcount.c:156 kobject_get+0x38/0x4c
    refcount_t: increment on 0; use-after-free.
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc2-koelsch+ #407
    Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
    [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
    [] (show_stack) from [] (dump_stack+0x7c/0x9c)
    [] (dump_stack) from [] (__warn+0xd0/0xec)
    [] (__warn) from [] (warn_slowpath_fmt+0x44/0x6c)
    [] (warn_slowpath_fmt) from [] (kobject_get+0x38/0x4c)
    [] (kobject_get) from [] (of_node_get+0x14/0x1c)
    [] (of_node_get) from [] (of_find_node_by_phandle+0xc0/0xf0)
    [] (of_find_node_by_phandle) from [] (of_phandle_iterator_next+0x68/0x154)
    [] (of_phandle_iterator_next) from [] (__of_parse_phandle_with_args+0x40/0xd0)
    [] (__of_parse_phandle_with_args) from [] (of_parse_phandle_with_args_map+0x100/0x3ac)
    [] (of_parse_phandle_with_args_map) from [] (of_get_named_gpiod_flags+0x38/0x380)
    [] (of_get_named_gpiod_flags) from [] (gpiod_get_from_of_node+0x24/0xd8)
    [] (gpiod_get_from_of_node) from [] (devm_fwnode_get_index_gpiod_from_child+0xa0/0x144)
    [] (devm_fwnode_get_index_gpiod_from_child) from [] (gpio_keys_probe+0x418/0x7bc)
    [] (gpio_keys_probe) from [] (platform_drv_probe+0x48/0x94)

Fix this by splitting the cleanup block, and adding a missing call to
gpiochip_irqchip_remove().

Fixes: 28355f81969962cf ("gpio: defer probe if pinctrl cannot be found")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mukesh Ojha 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: mxc: add check to return defer probe if clock tree NOT ready

2019-05-08T05:22:58+00:00

commit a329bbe707cee2cf8c660890ef2ad0d00ec7e8a3 upstream.

On i.MX8MQ platform, clock driver uses platform driver
model and it is probed after GPIO driver, so when GPIO
driver fails to get clock, it should check the error type
to decide whether to return defer probe or just ignore
the clock operation.

Fixes: 2808801aab8a ("gpio: mxc: add clock operation")
Signed-off-by: Anson Huang 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: of: Fix of_gpiochip_add() error path

2019-05-04T07:21:21+00:00

[ Upstream commit f7299d441a4da8a5088e651ea55023525a793a13 ]

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 
Reviewed-by: Mukesh Ojha 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin (Microsoft)

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

2019-05-04T07:21:20+00:00

[ Upstream commit 7ce40277bf848391705011ba37eac2e377cbd9e6 ]

"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 
Cc: Linus Walleij 
Cc: Bartosz Golaszewski 
Cc: Chris Healy 
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin (Microsoft)

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

2019-05-04T07:21:20+00:00

[ Upstream commit e5545c94e43b8f6599ffc01df8d1aedf18ee912a ]

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 
Cc: Linus Walleij 
Cc: Bartosz Golaszewski 
Cc: Chris Healy 
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin (Microsoft)

gpio: aspeed: fix a potential NULL pointer dereference

2019-05-04T07:21:18+00:00

[ Upstream commit 6cf4511e9729c00a7306cf94085f9cc3c52ee723 ]

In case devm_kzalloc, the patch returns ENOMEM to avoid potential
NULL pointer dereference.

Signed-off-by: Kangjie Lu 
Reviewed-by: Andrew Jeffery 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Sasha Levin (Microsoft)

gpio: eic: sprd: Fix incorrect irq type setting for the sync EIC

2019-05-02T08:02:44+00:00

commit 102bbe34b31c9159e714432afd64458f6f3876d7 upstream.

When setting sync EIC as IRQ_TYPE_EDGE_BOTH type, we missed to set the
SPRD_EIC_SYNC_INTMODE register to 0, which means detecting edge signals.

Thus this patch fixes the issue.

Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc: 
Signed-off-by: Baolin Wang 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

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

2019-04-05T20:34:53+00:00

[ Upstream commit 692ef26e72fcce0c1e73c41683fd3512f3719d55 ]

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 
Tested-by: Marek Vasut 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

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

2019-04-05T20:34:36+00:00

[ Upstream commit 0e7d6f94016407fd7e1ae472e254d64d4454e9c8 ]

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 
Cc: Geert Uytterhoeven 
Cc: Jan Kotas 
Cc: Linus Walleij 
Cc: Mark Brown 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: gpio-omap: fix level interrupt idling

2019-04-05T20:34:20+00:00

[ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ]

Tony notes that the GPIO module does not idle when level interrupts are
in use, as the wakeup appears to get stuck.

After extensive investigation, it appears that the wakeup will only be
cleared if the interrupt status register is cleared while the interrupt
is enabled. However, we are currently clearing it with the interrupt
disabled for level-based interrupts.

It is acknowledged that this observed behaviour conflicts with a
statement in the TRM:

CAUTION
  After servicing the interrupt, the status bit in the interrupt status
  register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be
  reset and the interrupt line released (by setting the corresponding
  bit of the interrupt status register to 1) before enabling an
  interrupt for the GPIO channel in the interrupt-enable register
  (GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent
  the occurrence of unexpected interrupts when enabling an interrupt
  for the GPIO channel.

However, this does not appear to be a practical problem.

Further, as reported by Grygorii Strashko ,
the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP:
Fix the sequence to clear the IRQ status" saying:

 if the status is cleared after disabling the IRQ then sWAKEUP will not
 be cleared and gates the module transition

When we unmask the level interrupt after the interrupt has been handled,
enable the interrupt and only then clear the interrupt. If the interrupt
is still pending, the hardware will re-assert the interrupt status.

Should the caution note in the TRM prove to be a problem, we could
use a clear-enable-clear sequence instead.

Cc: Aaro Koskinen 
Cc: Keerthy 
Cc: Peter Ujfalusi 
Signed-off-by: Russell King 
[tony@atomide.com: updated comments based on an earlier TI patch]
Signed-off-by: Tony Lindgren 
Acked-by: Grygorii Strashko 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin