linux-stable.git/drivers/gpio, branch v5.0.7

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

gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input

2019-04-03T04:27:35+00:00

commit c5bc6e526d3f217ed2cc3681d256dc4a2af4cc2b upstream.

Current code test wrong value so it does not verify if the written
data is correctly read back. Fix it.
Also make it return -EPERM if read value does not match written bit,
just like it done for adnp_gpio_direction_output().

Fixes: 5e969a401a01 ("gpio: Add Avionic Design N-bit GPIO expander support")
Cc: 
Signed-off-by: Axel Lin 
Reviewed-by: Thierry Reding 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: exar: add a check for the return value of ida_simple_get fails

2019-04-03T04:27:35+00:00

commit 7ecced0934e574b528a1ba6c237731e682216a74 upstream.

ida_simple_get may fail and return a negative error number.
The fix checks its return value; if it fails, go to err_destroy.

Cc: 
Signed-off-by: Kangjie Lu 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: pca953x: Fix dereference of irq data in shutdown

2019-03-23T19:11:25+00:00

commit c378b3aa015931a46c91d6ccc2fe04d97801d060 upstream.

If a PCA953x gpio was used as an interrupt and then released,
the shutdown function was trying to extract the pca953x_chip
pointer directly from the irq_data, but in reality was getting
the gpio_chip structure.

The net effect was that the subsequent writes to the data
structure corrupted data in the gpio_chip structure, which wasn't
immediately obvious until attempting to use the GPIO again in the
future, at which point the kernel panics.

This fix correctly extracts the pca953x_chip structure via the
gpio_chip structure, as is correctly done in the other irq
functions.

Fixes: 0a70fe00efea ("gpio: pca953x: Clear irq trigger type on irq shutdown")
Cc: stable@vger.kernel.org
Signed-off-by: Mark Walton 
Reviewed-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2

2019-02-14T09:06:03+00:00

Similarly to PXA3xx, pinctrl-single can't set pin direction on MMP2 either.
See also: commit 9dabfdd84bdfa ("gpio: pxa: disable pinctrl calls for
PXA3xx")

Cc: stable@vger.kernel.org
Fixes: a770d946371e ("gpio: pxa: add pin control gpio direction and request")
Signed-off-by: Lubomir Rintel 
Acked-by: Pavel Machek 
Signed-off-by: Linus Walleij

gpio: MT7621: use a per instance irq_chip structure

2019-02-08T11:30:15+00:00

This fixes the kernel complains:
gpio gpiochip1: (1e000600.gpio-bank1): detected irqchip that is shared
	    with multiple gpiochips: please fix the driver.
gpio gpiochip2: (1e000600.gpio-bank2): detected irqchip that is shared
	    with multiple gpiochips: please fix the driver.

Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
Cc: stable@vger.kernel.org
Signed-off-by: René van Dorst 
Cc: linux-gpio@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Tested-by: Greg Ungerer 
Signed-off-by: Linus Walleij

gpio: vf610: Mask all GPIO interrupts

2019-01-28T14:28:43+00:00

On SoC reset all GPIO interrupts are disable. However, if kexec is
used to boot into a new kernel, the SoC does not experience a
reset. Hence GPIO interrupts can be left enabled from the previous
kernel. It is then possible for the interrupt to fire before an
interrupt handler is registered, resulting in the kernel complaining
of an "unexpected IRQ trap", the interrupt is never cleared, and so
fires again, resulting in an interrupt storm.

Disable all GPIO interrupts before registering the GPIO IRQ chip.

Fixes: 7f2691a19627 ("gpio: vf610: add gpiolib/IRQ chip driver for Vybrid")
Signed-off-by: Andrew Lunn 
Acked-by: Stefan Agner 
Signed-off-by: Linus Walleij

gpio: altera-a10sr: Set proper output level for direction_output

2019-01-23T16:24:02+00:00

The altr_a10sr_gpio_direction_output should set proper output level
based on the value argument.

Fixes: 26a48c4cc2f1 ("gpio: altera-a10sr: Add A10 System Resource Chip GPIO support.")
Cc: 
Signed-off-by: Axel Lin 
Tested by: Thor Thayer 
Reviewed by: Thor Thayer 
Signed-off-by: Bartosz Golaszewski