linux-stable.git/drivers/gpio, branch v3.12.64

gpio: Fix OF build problem on UM

2016-09-21T11:40:09+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: Jiri Slaby

gpio: pca953x: Fix NBANK calculation for PCA9536

2016-08-19T07:51:12+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: Jiri Slaby

gpio/omap: raw read and write endian fix

2016-01-05T17:38:56+00:00

commit 661553b9c67c1c7496de5f603ee3d338ecad6850 upstream.

All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.

Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.

Signed-off-by: Victor Kamensky 
Signed-off-by: Taras Kondratiuk 
Acked-by: Tony Lindgren 
Acked-by: Kevin Hilman 
Acked-by: Santosh Shilimkar 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Linus Walleij 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

gpio/lynxpoint: add new ACPI ID

2015-08-04T14:51:55+00:00

commit 4edd7901eee13f878e7b5fd5efba610e70b09313 upstream.

Newer Intel PCHs have the same GPIO controller than Haswell but the ACPI ID
is different. Add this ID to the driver supported IDs list.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: gpio-kempld: Fix get_direction return value

2015-06-03T09:33:12+00:00

commit f230e8ffc03f17bd9d6b90ea890b8252a8cc1821 upstream.

This patch fixes an inverted return value of the gpio get_direction
function.

The wrong value causes the direction sysfs entry and GPIO debugfs file
to indicate incorrect GPIO direction settings. In some cases it also
prevents setting GPIO output values.

The problem is also present in all other stable kernel versions since
linux-3.12.

Reported-by: Jochen Henneberg 
Signed-off-by: Michael Brunner 
Reviewed-by: Guenter Roeck 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: squelch a compiler warning

2015-05-21T11:25:48+00:00

drivers/gpio/gpiolib-of.c: In function 'of_gpiochip_find_and_xlate':
drivers/gpio/gpiolib-of.c:52:21: warning: assignment makes integer from pointer without a cast [enabled by default]
   gg_data->out_gpio = ERR_PTR(ret);
                     ^
This was introduced in 72464765733575dc89c509f16caabc2af47fda79, a
backport of upstream commit 7b8792bbdffdff3abda704f89c6a45ea97afdc62.

The upstream kernel changed the type of out_gpio from int to struct gpio_desc *
as part of a larger refactoring that wasn't backported

Signed-off-by: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

gpio: sysfs: fix memory leaks and device hotplug

2015-05-16T07:12:43+00:00

commit 483d821108791092798f5d230686868112927044 upstream.

Unregister GPIOs requested through sysfs at chip remove to avoid leaking
the associated memory and sysfs entries.

The stale sysfs entries prevented the gpio numbers from being exported
when the gpio range was later reused (e.g. at device reconnect).

This also fixes the related module-reference leak.

Note that kernfs makes sure that any on-going sysfs operations finish
before the class devices are unregistered and that further accesses
fail.

The chip exported flag is used to prevent gpiod exports during removal.
This also makes it harder to trigger, but does not fix, the related race
between gpiochip_remove and export_store, which is really a race with
gpiod_request that needs to be addressed separately.

Also note that this would prevent the crashes (e.g. NULL-dereferences)
at reconnect that affects pre-3.18 kernels, as well as use-after-free on
operations on open attribute files on pre-3.14 kernels (prior to
kernfs).

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: unregister gpiochip device before removing it

2015-05-16T07:12:43+00:00

commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream.

Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.

Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: mvebu: Fix mask/unmask managment per irq chip type

2015-05-04T09:50:14+00:00

commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream.

Level IRQ handlers and edge IRQ handler are managed by tow different
sets of registers. But currently the driver uses the same mask for the
both registers. It lead to issues with the following scenario:

First, an IRQ is requested on a GPIO to be triggered on front. After,
this an other IRQ is requested for a GPIO of the same bank but
triggered on level. Then the first one will be also setup to be
triggered on level. It leads to an interrupt storm.

The different kind of handler are already associated with two
different irq chip type. With this patch the driver uses a private
mask for each one which solves this issue.

It has been tested on an Armada XP based board and on an Armada 375
board. For the both boards, with this patch is applied, there is no
such interrupt storm when running the previous scenario.

This bug was already fixed but in a different way in the legacy
version of this driver by Evgeniy Dushistov:
9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain
sequence of request_irq can cause irq storm". The fact the new version
of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012

Reported-by: Evgeniy A. Dushistov 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby

gpio: tps65912: fix wrong container_of arguments

2015-03-05T14:37:03+00:00

commit 2f97c20e5f7c3582c7310f65a04465bfb0fd0e85 upstream.

The gpio_chip operations receive a pointer the gpio_chip struct which is
contained in the driver's private struct, yet the container_of call in those
functions point to the mfd struct defined in include/linux/mfd/tps65912.h.

Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Slaby