Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO IRQ controller is able to generate level triggered
interrupts, however, these were handled by handle_simple_irq so far
which did not take care of IRQ masking. This lead to "nobody cared
(try booting with the "irqpoll" option)" stack traces.
Use the generic interrupt handlers depending on the IRQ type.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes error handling in the function max732x_probe by checking
if the calls to the function max732x_readb fail by returning a error
code.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As per CCF documentation (clk.txt) the clk_prepare/unprepare APIs
are not allowed in atomic context. But now OMAP GPIO driver
uses them while applying debounce settings and as part
of PM runtime irqsafe operations:
- omap_gpio_debounce() is holding the lock with IRQs off.
+ omap2_set_gpio_debounce()
+ clk_prepare_enable()
+ clk_prepare() this one might sleep.
- pm_runtime_get_sync() is holding the lock with IRQs off
+ omap_gpio_runtime_suspend()
+ raw_spin_lock_irqsave()
+ omap_gpio_dbck_disable()
+ clk_disable_unprepare()
Hence, fix it by moeving dbclk prepare/unprepare in OMAP GPIO
omap_gpio_probe/omap_gpio_remove. Also, while here, ensure that
debounce functionality is disabled if clk_get() failed,
because otherwise kernel will carsh in omap2_set_gpio_debounce().
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The access to HW registers has to be be protected in
omap_gpio_irq_handler(), as it may race with code executed on
another CPUs.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to TRMs:
Required input line stable =
(the value of the GPIO_DEBOUNCINGTIME[7:0].DEBOUNCETIME + 1) × 31,
where the value of the GPIO_DEBOUNCINGTIME[7:0].DEBOUNCETIME bit field
is from 0 to 255.
But now omap2_set_gpio_debounce() will calculate debounce time and
behave incorrectly in the following cases:
1) requested debounce time is !0 and <32
calculated DEBOUNCETIME = 0x1 == 62 us;
expected value of DEBOUNCETIME = 0x0 == 31us
2) requested debounce time is 0
calculated DEBOUNCETIME = 0x1 == 62 us;
expected: disable debounce and DEBOUNCETIME = 0x0
3) requested debounce time is >32 and <63
calculated DEBOUNCETIME = 0x0 and debounce will be disabled;
expected: enable debounce and DEBOUNCETIME = 0x1 == 62 us
Hence, rework omap2_set_gpio_debounce() to fix above cases:
1) introduce local variable "enable" and use it to identify
when debounce need to be enabled or disabled. Disable debounce
if requested debounce time is 0.
2) use below formula for debounce time calculation:
debounce = (DIV_ROUND_UP(debounce, 31) - 1) & 0xFF;
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Switch OMAP GPIO driver to use platform_get_irq(), because
it is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ, ..)
for requesting IRQ resources any more, as they can be not ready yet
in case of DT-boot.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The bank->chip.irqdomain is uninitialized at the moment when
irq_domain_remove() is called, so remove this call.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.
HW configuration which generates lockdep warning (TI dra7-evm):
[SOC GPIO bankA.gpioX]
<- irq - [pcf875x.gpioY]
<- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
The issue was reported in [1] and discussed [2].
=============================================
[ INFO: possible recursive locking detected ]
4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
---------------------------------------------
sh/63 is trying to acquire lock:
(class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
but task is already holding lock:
(class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(class);
lock(class);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by sh/63:
#0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164
#1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0
#2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0
#3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4
#4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398
#5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94
#6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
stack backtrace:
CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14)
[<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c)
[<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20)
[<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128)
[<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c)
[<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94)
[<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc)
[<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54)
[<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc)
[<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4)
[<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124)
[<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398)
[<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4)
[<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728)
[<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4)
[<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8)
[<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0)
[<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8)
[<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164)
[<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c)
[<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
Lets fix it by using separate lockdep class for each registered GPIO
IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.
The implementation of this patch inspired by solution done by Nicolas
Boichat for regmap [3]
[1] http://www.spinics.net/lists/linux-gpio/msg05844.html
[2] http://www.spinics.net/lists/linux-gpio/msg06021.html
[3] http://www.spinics.net/lists/arm-kernel/msg429834.html
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roger Quadros <rogerq@ti.com>
Reported-by: Roger Quadros <rogerq@ti.com>
Tested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
As reported by Alexey Khoroshilov:
grgpio_irq_unmap() code looks quite suspicious regarding usage of
priv->bgc.lock spinlock.
It locks the spinlock in line 310:
spin_lock_irqsave(&priv->bgc.lock, flags);
and then it can call grgpio_set_imask() in line 317:
grgpio_set_imask(priv, i, 0);
But grgpio_set_imask() unconditionally locks the spinlock by itself.
Fix this by moving the spinlock acquisition outside of
grgpio_set_imask().
Found by Linux Driver Verification project (linuxtesting.org).
Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix the section mismatch warning
WARNING: vmlinux.o(.text+0x2b2788): Section mismatch in reference from the function mxc_gpio_probe() to the function .init.text:mxc_gpio_init_gc()
The function mxc_gpio_probe() references
the function __init mxc_gpio_init_gc().
This is often because mxc_gpio_probe lacks a __init
annotation or the annotation of mxc_gpio_init_gc is wrong.
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently in the FSL platform all GPIO interrupts in a bank are muxed
into two GPIO lines to the GPC interrupt controller. In each GPIO bank
GPIOs 0-15 are OR'ed into one GPC interrupt controller interrupt and 16-31
are OR'ed into another. With the current code, if any of the 0-15 or
16-31 interrupts are marked as wakeup capable, all interrupts belonging
to that sub-bank (either 0-15 or 16-31) will wake up the device. This is
because interrupts are only being masked at the interrupt controller
and not at the GPIO controller.
This patch allows masking of GPIO interrupts at the GPIO controller during
suspend if they have not been labeled wakeup capable. This patch uses
preexisting IRQCHIP_MASK_ON_SUSPEND flag while initializing the GPIO
interrupts to get the desired behavior.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Ulises Brindis <ubrindis56@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix below build warning:
CC drivers/gpio/gpio-omap.o
drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_type':
drivers/gpio/gpio-omap.c:504:3: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:360:29: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
Fixes: commit 4dbada2be4 ("gpio: omap: use raw locks for locking")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For wake from S5, we need to:
- register a reboot handler
- set wakeup capability before requesting IRQ so wakeup count is
incremented
- mask all GPIO IRQs and clear any pending interrupts during driver
probe to since no driver will yet be registered to handle any IRQs
carried over from boot at that time, and it's possible that the
booted kernel does not request the same IRQ anyway.
This means that /sys/.../power/wakeup_count is valid at boot time, and
we can properly account for S5 wakeup stats. e.g.:
### After waking from S5 from a GPIO key
# cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup
enabled
# cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup_count
1
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Uses the gpiolib irqchip helpers. For this to work, the irq setup
function is called once per bank instead of once per device. Note
that all known uses of this block have a BCM7120 L2 interrupt
controller as a parent. Supports interrupts for all GPIOs.
In the IRQ handler, we check for raised IRQs for invalid GPIOs and
warn (ratelimited) if they're encountered.
Also, several drivers (e.g. gpio-keys) allow for GPIOs to be
configured as wakeup sources, and this GPIO controller supports that
through a separate interrupt path.
The de-facto standard DT property "wakeup-source" is checked, since
that indicates whether the GPIO controller hardware can wake. Uses
the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
any of its own wakeup source configuration.
Aside regarding gpiolib irqchip helpers: It wasn't obvious (to me)
that you can have multiple chained irqchips and associated IRQ domains
for a single parent IRQ, and as long as the xlate function is written
correctly, a GPIO IRQ request end up checking the correct domain and
will get associated with the correct IRQ. What helps make this clear
is to read
drivers/gpio/gpiolib-of.c:
- of_gpiochip_find_and_xlate()
- of_get_named_gpiod_flags()
drivers/gpio/gpiolib.c:
- gpiochip_find()
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On ETRAX FS, all pins on the first port (and only the first port) have
interrupt support.
On ARTPEC-3, all pins on all ports have interrupt support. However,
there are only eight interrupts. Each of the interrupts is associated
with a group of pins and for each interrupt the one pin from the group
which will trigger it can be selected.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the driver has specified its own irq_{request/release}_resources()
functions, don't override them. The gpio-etraxfs driver will use this.
Signed-off-by: Rabin Vincent <rabin@rab.in>
[Added a small comment blurb]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
mpc8xxx_gpio_chip.lock needs to be a real spinlock in preempt-rt.
Especially the interrupt related functions can not be converted to a
sleeping lock.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed as most platforms don't use probing.
There appears to be a great deal of blind copy and paste of this code.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add support for the GIO block in the ARTPEC-3 SoC. The basic
functionality is essentialy the same as the version in the ETRAX FS,
except for a different set of ports, including a read-only port.
Cc: devicetree@vger.kernel.org
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Allow chips to indicates that they are input-only and thus cannot set
the output value. This will be used by the gpio-etraxfs driver.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
BGPIO_F_UNREADABLE_REG_SET is incorrect, since the set register _is_
readable. What's really required is BGPIO_F_READ_OUTPUT_REG_SET:
reading the set register reads the set output value.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path is to access this lock is always under a
raw_spin_lock, for instance
- __setup_irq() holds &desc->lock with irq off
+ __irq_set_trigger()
+ omap_gpio_irq_type()
- handle_level_irq() (runs with irqs off therefore raw locks)
+ mask_ack_irq()
+ omap_gpio_mask_irq()
This fixes the obvious backtrace on -RT. However the locking vs context
is not and this is not limited to -RT:
- omap_gpio_irq_type() is called with IRQ off and has an conditional
call to pm_runtime_get_sync() which may sleep. Either it may happen or
it may not happen but pm_runtime_get_sync() should not be called with
irqs off.
- omap_gpio_debounce() is holding the lock with IRQs off.
+ omap2_set_gpio_debounce()
+ clk_prepare_enable()
+ clk_prepare() this one might sleep.
The number of users of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This variable is used as an iterator and initialized in the
list_for_each() loop.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio controller on MPC5125 is identical to the MPC5121 register
wise, the only difference is that the lines 0..3 are input only instead
of 28..31 on MPC5121.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio controllers that are handled by the mpc8xxx driver differ
slightly. Up to now some differences were handled by use of
of_device_is_compatible, others by use of struct of_device_id's data.
To make this consistent and easily extendable handle the differences at
a single place.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This variable is not modified in the driver and all functions it it
passed to don't change it either. So it can and should be marked const.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull irq fixes from Ingo Molnar:
"Misc irq fixes:
- two driver fixes
- a Xen regression fix
- a nested irq thread crash fix"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/gicv3-its: Fix mapping of LPIs to collections
genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD
genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now
gpio/davinci: Fix race in installing chained irq handler
Interrupts for GPIOs 16 through 31 are enabled by bit 1 in the
"binten" register (offset 8). Previous versions of GPIO only
used bit 0, which enables GPIO 0-15 interrupts.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpiod_get* functions mandatory and so allows to remove an ugly cpp hack
introduced in commit 39b2bbe3d7 (gpio: add flags argument to gpiod_get*()
functions) for v3.17-rc1.
The other nine commits fix the last remaining users of these functions that
don't pass flags yet. (Only etraxfs-uart wasn't fixed; this driver's use of the
gpiod functions needs fixing anyhow.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJVmj+OAAoJEMH8FHityuwJHGcH/A5bSLcdaFCMcrYceYD/odzR
X/mer/CcW/uWG0sUha2pZjT172szSrm0/Bk+SaY5Ub0c6ssCpKRGhtqZNVWWz44V
duRQGkYEFODHSed1XnKQyKwr6nLyhjmj8RuP5GokjcsBZyl4onj+NHgmpH5aQBYC
4NyFpIXcSS4jCwj4nsZu4Y2xLAgu/t5oVzqDheqTyZ9imgaR8hbyminKhN+wFfrI
FKukShQ5AQPVs7pGEqeY0wgJp+keOIYLukLwvgZw+S7MxixXaPiSK1Ez9DPY9CFo
f+NkDV6GIe4OAOGFsL9dCxR0sO6mF7C5PpYuDUBtISi3JHNAvW+Ri7FKPeSDikA=
=ixJj
-----END PGP SIGNATURE-----
Merge tag 'gpiod-flags-for-4.3' of git://git.pengutronix.de/git/ukl/linux into devel
The last patch in this series makes the flags parameter for the various
gpiod_get* functions mandatory and so allows to remove an ugly cpp hack
introduced in commit 39b2bbe3d7 (gpio: add flags argument to gpiod_get*()
functions) for v3.17-rc1.
The other nine commits fix the last remaining users of these functions that
don't pass flags yet. (Only etraxfs-uart wasn't fixed; this driver's use of the
gpiod functions needs fixing anyhow.)
Value returned by devm_ioremap_resource() was checked for non-NULL but
devm_ioremap_resource() returns IOMEM_ERR_PTR, not NULL. In case of
error this could lead to dereference of ERR_PTR.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
pca953x interrupt controller functionality is implemented using
nested threaded IRQs which require parent_irq to be configured
properly otherwise below warning can be seen if IRQ core
will try re-schedule nested IRQ:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 12 at kernel/irq/manage.c:696 irq_nested_primary_handler+0x30/0x38()
Primary handler called for nested irq 301
Modules linked in: uinput ipv6 smsc95xx usbnet mii imx2_wdt etnaviv(C) matrix_keypad matrix_keymap ar1021_i2c
CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: G WC 4.1.1 #9
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013298>] (dump_backtrace) from [<c0013488>] (show_stack+0x20/0x24)
[<c0013468>] (show_stack) from [<c05743c4>] (dump_stack+0x70/0xc0)
[<c0574354>] (dump_stack) from [<c002b7b8>] (warn_slowpath_common+0x88/0xc0)
[<c002b730>] (warn_slowpath_common) from [<c002b8ac>] (warn_slowpath_fmt+0x40/0x48)
[<c002b870>] (warn_slowpath_fmt) from [<c0075798>] (irq_nested_primary_handler+0x30/0x38)
[<c0075768>] (irq_nested_primary_handler) from [<c0075200>] (handle_irq_event_percpu+0x70/0x2d0)
[<c0075190>] (handle_irq_event_percpu) from [<c00754ac>] (handle_irq_event+0x4c/0x6c)
[<c0075460>] (handle_irq_event) from [<c0078204>] (handle_simple_irq+0xa4/0xc8)
[<c0078160>] (handle_simple_irq) from [<c0077cd4>] (resend_irqs+0x50/0x7c)
[<c0077c84>] (resend_irqs) from [<c002f99c>] (tasklet_action+0x94/0x140)
[<c002f908>] (tasklet_action) from [<c002eea8>] (__do_softirq+0xa0/0x3c8)
[<c002ee08>] (__do_softirq) from [<c002f208>] (run_ksoftirqd+0x38/0x54)
[<c002f1d0>] (run_ksoftirqd) from [<c004b1e4>] (smpboot_thread_fn+0x1f8/0x2f0)
[<c004afec>] (smpboot_thread_fn) from [<c0047744>] (kthread+0xe8/0x104)
[<c004765c>] (kthread) from [<c000fac8>] (ret_from_fork+0x14/0x2c)
---[ end trace 96052cda48865769 ]---
The issue was reported and described in details by Lothar Waßmann and
Christian Gmeiner in https://lkml.org/lkml/2014/9/9/123.
Fix it by adding missed call of gpiochip_set_chained_irqchip()
so GPIO IRQ chip helpers will set parent_irq for nested IRQs
properly.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
OMAP GPIO driver allowed to be built as loadable module, but it
doesn't set owner field in GPIO chip structure. As result,
module_get/put() API is not working and it's possible to unload
OMAP driver while in use:
omap_gpio 48051000.gpio: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED
Hence, add missing configuration.
Cc: Tony Lindgren <tony@atomide.com>
Fixes: cac089f902 ('gpio: omap: Allow building as a loadable module')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This fixes the build warning , warning: cast from pointer to integer
of different size when building this file on a x86 allmodconfig
configuration. In order for me to fix this build warning I changed
the cast in the function mmio_74xx_gpio_probe from casting the
variable data of the stucture pointer of_id to uintptr_t rather
then unsigned when assigning to the variable flag of the structure
pointer priv of the structure type mmio_74xx_gpio_priv.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In case the gpiochip doesn't have the .dev field set, as is the case
in here, it is not possible to reference this device in DT as a GPIO
controller. A good example of this problem is that gpio-leds can not
be used when connected to this chip, the gpio-leds driver bails out
with -EPROBE_DEFER.
Fix this problem by setting the .dev field of the gpio_chip to the
parent i2c device.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mans Rullgard <mans@mansr.com>
Cc: Olaf Mandel <o.mandel@menlosystems.com>
Cc: Semen Protsenko <semen.protsenko@globallogic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
xgpio_save_regs() is used in this driver to setup the initial
values of the registers in the hardware.
The relevant registers at that time are:
0x0 -> channel 0 data (32 bits, one for each GPIO on this channel).
0x4 -> channel 0 tri, controls in/out status for each GPIO of this channel.
0x8 -> channel 1 data
0xC -> channel 1 tri
gpio-xilinx.c defines these:
XGPIO_DATA_OFFSET (0x0)
XGPIO_TRI_OFFSET (0x4)
XGPIO_CHANNEL_OFFSET 0x8
Before this patch, the "data" register value of channel 1 was written
at 0x4 intead of 0x8 (overwriting the channel 0 "tri" register),
and the "tri" register value for channel 1 was written at 0x8 instead of 0xC.
Signed-off-by: Raphaël Teysseyre <rteysseyre@gmail.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Assign GPIO chip owner field to chip->dev->driver->owner if it was not
configured by GPIO driver.
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Now nothing prevents GPIO driver from being unloaded if its gpios
were requested as GPIO IRQs only (without calling gpio_request()).
Hence, add calls of try_module_get()/module_put() into
gpiochip_irq_reqres/relres() to track such scenario properly.
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The spinlock 'slock' is used now to protect pcf857x_irq() from itself
which is unnecessary (especially after switching to use threaded
IRQs). Hence, remove it and use mutex to protect device data in IRQ
handler.
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently gpio modules are runtime-resumed at probe time. This means the
gpio module will be active all the time (except during system suspend,
if not configured as a wake-up source).
While an R-Car Gen2 gpio module retains pins configured for output at
the requested level while put in standby mode, gpio registercannot be
accessed while suspended. Unfortunately pm_runtime_get_sync() cannot be
called from all contexts where gpio register access is needed. Hence
move the Runtime PM handling from probe/remove time to gpio request/free
time, which is probably the best we can do.
On r8a7791/koelsch, gpio modules 0, 1, 3, and 4 are now suspended during
normal use (gpio2 is used for LEDs and regulators, gpio5 for keys, gpio6
for SD-Card CD & WP, gpio7 for keys and regulators).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
