linux-stable.git/drivers/gpio, branch v4.19.37

gpio: pxa: handle corner case of unprobed device

2019-04-20T07:16:00+00:00

[ Upstream commit 9ce3ebe973bf4073426f35f282c6b955ed802765 ]

In the corner case where the gpio driver probe fails, for whatever
reason, the suspend and resume handlers will still be called as they
have to be registered as syscore operations. This applies as well when
no probe was called while the driver has been built in the kernel.

Nicolas tracked this in :
https://bugzilla.kernel.org/show_bug.cgi?id=200905

Therefore, add a failsafe in these function, and test if a proper probe
succeeded and the driver is functional.

Signed-off-by: Robert Jarzmik 
Reported-by: Nicolas Chauvet 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: gpio-omap: fix level interrupt idling

2019-04-05T20:32:56+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:26:27+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:26:27+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:10:05+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: vf610: Mask all GPIO interrupts

2019-03-13T21:02:29+00:00

[ Upstream commit 7ae710f9f8b2cf95297e7bbfe1c09789a7dc43d4 ]

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 
Signed-off-by: Sasha Levin

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

2019-02-27T09:08:49+00:00

commit af14b2c98adb85e9517390bb88309338b9075350 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

gpio: MT7621: use a per instance irq_chip structure

2019-02-27T09:08:49+00:00

commit fa84667b98fd1a191b2465d66b440bda6714b3bf upstream.

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 
Signed-off-by: Greg Kroah-Hartman

gpio: mxc: move gpio noirq suspend/resume to syscore phase

2019-02-20T09:25:44+00:00

commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb upstream.

During noirq suspend/resume phase, GPIO irq could arrive
and its registers like IMR will be changed by irq handle
process, to make the GPIO registers exactly when it is
powered ON after resume, move the GPIO noirq suspend/resume
callback to syscore suspend/resume phase, local irq is
disabled at this phase so GPIO registers are atomic.

Fixes: c19fdaeea0aa ("gpio: mxc: add power management support")
Signed-off-by: Anson Huang 
Signed-off-by: Linus Walleij 
Signed-off-by: Martin Hundebøll 
Cc:  # 4.19.x+
Signed-off-by: Sasha Levin

gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack

2019-02-12T18:47:06+00:00

[ Upstream commit a109c2dbb571b10bb9969285b646f57309c98251 ]

The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
for the dev_err() messages). The probe function should return an error
if one of the banks failed to initialize properly indicated by
not returning non-0.

Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
Signed-off-by: Nicholas Mc Guire 
Acked-by: Sean Wang 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin