linux-toradex.git/drivers/gpio, branch v4.4.93

gpio: mpc8xxx: Correct irq handler function

2016-10-28T07:01:25+00:00

commit d71cf15b865bdd45925f7b094d169aaabd705145 upstream.

From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq"
has being used to handle GPIO interrupts in the PowerPC/Layerscape
platforms. But actually, almost all PowerPC/Layerscape platforms
assert an interrupt request upon either a high-to-low change or
any change on the state of the signal.

So the "handle_level_irq" is not reasonable for PowerPC/Layerscape
GPIO interrupt, it should be "handle_edge_irq". Otherwise the system
may lost some interrupts from the PIN's state changes.

Signed-off-by: Liu Gang 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: sa1100: fix irq probing for ucb1x00

2016-10-07T13:23:42+00:00

commit 56beac95cb88c188d2a885825a5da131edb41fe3 upstream.

ucb1x00 has used IRQ probing since it's dawn to find the GPIO interrupt
that it's connected to.  However, commit 23393d49fb75 ("gpio: kill off
set_irq_flags usage") broke this by disabling IRQ probing on GPIO
interrupts.  Fix this.

Fixes: 23393d49fb75 ("gpio: kill off set_irq_flags usage")
Signed-off-by: Russell King 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: Fix OF build problem on UM

2016-09-07T06:32:43+00:00

commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 upstream.

The UserMode (UM) Linux build was failing in gpiolib-of as it requires
ioremap()/iounmap() to exist, which is absent from UM. The non-existence
of IO memory is negatively defined as CONFIG_NO_IOMEM which means we
need to depend on HAS_IOMEM.

Cc: Geert Uytterhoeven 
Reported-by: kbuild test robot 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: intel-mid: Remove potentially harmful code

2016-08-20T16:09:17+00:00

commit 3dbd3212f81b2b410a34a922055e2da792864829 upstream.

The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
doesn't look at all as a proper support for Intel Merrifield and I dare to say
that it distorts the behaviour of the hardware.

The register map is different on Intel Merrifield, i.e. only 6 out of 8
register have the same purpose but none of them has same location in the
address space. The current case potentially harmful to existing hardware since
it's poking registers on wrong offsets and may set some pin to be GPIO output
when connected hardware doesn't expect such.

Besides the above GPIO and pinctrl on Intel Merrifield have been located in
different IP blocks. The functionality has been extended as well, i.e. added
support of level interrupts, special registers for wake capable sources and
thus, in my opinion, requires a completele separate driver.

If someone wondering the existing gpio-intel-mid.c would be converted to actual
pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
that.

Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: pca953x: Fix NBANK calculation for PCA9536

2016-08-20T16:09:17+00:00

commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 upstream.

NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().

Signed-off-by: Vignesh R 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

Revert "gpiolib: Split GPIO flags parsing and GPIO configuration"

2016-07-27T16:47:29+00:00

commit 85b03b3033fd4eba82665b3b9902c095a08cc52f upstream.

This reverts commit 923b93e451db876d1479d3e4458fce14fec31d1c.

Make sure consumers do not overwrite gpio flags for pins that have
already been claimed.

While adding support for gpio drivers to refuse a request using
unsupported flags, the order of when the requested flag was checked and
the new flags were applied was reversed to that consumers could
overwrite flags for already requested gpios.

This not only affects device-tree setups where two drivers could request
the same gpio using conflicting configurations, but also allowed user
space to clear gpio flags for already claimed pins simply by attempting
to export them through the sysfs interface. By for example clearing the
FLAG_ACTIVE_LOW flag this way, user space could effectively change the
polarity of a signal.

Reverting this change obviously prevents gpio drivers from doing sanity
checks on the flags in their request callbacks. Fortunately only one
recently added driver (gpio-tps65218 in v4.6) appears to do this, and a
follow up patch could restore this functionality through a different
interface.

Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-24T17:18:19+00:00

commit b66b2a0adf0e48973b582e055758b9907a7eee7c upstream.

The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs()
with what looks like the wrong parameter. The write_lock_regs
function takes a pointer to the registers, not the bcm_kona_gpio
structure.

Fix the warning, and probably bug by changing the function to
pass reg_base instead of kona_gpio, fixing the following warning:

drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1
  (different address spaces)
  expected void [noderef] *reg_base
  got struct bcm_kona_gpio *kona_gpio
  warning: incorrect type in argument 1 (different address spaces)
  expected void [noderef] *reg_base
  got struct bcm_kona_gpio *kona_gpio

Signed-off-by: Ben Dooks 
Acked-by: Ray Jui 
Reviewed-by: Markus Mayer 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: revert get() to non-errorprogating behaviour

2015-12-17T14:48:29+00:00

commit e20538b82f1f
("gpio: Propagate errors from chip->get()")
started to propagate errors from the .get() functions since
we can get errors from the infrastructure of e.g. slowbus
GPIO expanders.

However it turns out a bunch of drivers relied on the core
to clamp the value, so we need to revert to the old behaviour
and go over all drivers and fix them to conform to the
expectations of the core before we go back to propagating
the error code.

Cc: stable@vger.kernel.org # 4.3+
Cc: Bjorn Andersson 
Cc: Vladimir Zapolskiy 
Fixes: e20538b82f1f ("gpio: Propagate errors from chip->get()")
Reported-by: Michael Trimarchi 
Signed-off-by: Linus Walleij

gpio: generic: clamp values from bgpio_get_set()

2015-12-17T14:47:38+00:00

The bgpio_get_set() call should return a value clamped to [0,1],
the current code will return a negative value if reading
bit 31, which turns the value negative as this is a signed value
and thus gets interpreted as an error by the gpiolib core.
Found on the gpio-mxc but applies to any MMIO driver.

Cc: stable@vger.kernel.org # 4.3+
Cc: kernel@pengutronix.de
Cc: Vladimir Zapolskiy 
Fixes:  e20538b82f1f ("gpio: Propagate errors from chip->get()")
Reported-by: Clemens Gruber 
Signed-off-by: Linus Walleij

gpio: ath79: Fix the logic to clear offset bit of AR71XX_GPIO_REG_OE register

2015-12-11T18:12:57+00:00

Signed-off-by: Axel Lin 
Acked-by: Alban Bedel 
Signed-off-by: Linus Walleij