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

gpio: pca953x: Use correct u16 value for register word write

2016-04-30T22:06:09+00:00

commit 9b8e3ec34318663affced3c14d960e78d760dd9a upstream.

The current implementation only uses the first byte in val,
the second byte is always 0. Change it to use cpu_to_le16
to write the two bytes into the register

Signed-off-by: Yong Li 
Reviewed-by: Phil Reid 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

gpiolib: Fix comment referring to gpio_() in gpiod_()

2016-04-30T22:06:00+00:00

commit 1cfab8f8b397f7d95ad43f72ed9a1fa7d26e210e upstream.

Fixes: 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

gpio: rcar: Add Runtime PM handling for interrupts

2016-03-24T10:01:05+00:00

commit b26a719bdba9aa926ceaadecc66e07623d2b8a53 upstream.

The R-Car GPIO driver handles Runtime PM for requested GPIOs only.

When using a GPIO purely as an interrupt source, no Runtime PM handling
is done, and the GPIO module's clock may not be enabled.

To fix this:
  - Add .irq_request_resources() and .irq_release_resources() callbacks
    to handle Runtime PM when an interrupt is requested,
  - Add irq_bus_lock() and sync_unlock() callbacks to handle Runtime PM
    when e.g. disabling/enabling an interrupt, or configuring the
    interrupt type.

Fixes: d5c3d84657db57bd "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
[ luis: backported to 3.16:
  - use gpio_to_priv() instead of gpiochip_get_data()
  - adjusted context ]
Signed-off-by: Luis Henriques

gpio: gpio-kempld: Fix get_direction return value

2015-06-03T12:27:19+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: Luis Henriques

gpio: sysfs: fix memory leaks and device hotplug

2015-05-20T12:26:01+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 
[ luis: backported to 3.16:
  - file rename: drivers/gpio/gpiolib-sysfs.c -> drivers/gpio/gpiolib.c ]
Signed-off-by: Luis Henriques

gpio: unregister gpiochip device before removing it

2015-05-20T12:26:00+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 
[ luis: backported to 3.16: used Johan's backport to 3.14 ]
Signed-off-by: Luis Henriques

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

2015-05-05T10:09:52+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: Luis Henriques

gpio: tps65912: fix wrong container_of arguments

2015-03-18T09:58:52+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: Luis Henriques

gpiolib: of: allow of_gpiochip_find_and_xlate to find more than one chip per node

2015-03-18T09:58:50+00:00

commit 9cf75e9e4ddd587ac12e88e8751c358b7b27e95f upstream.

The change:

7b8792bbdffdff3abda704f89c6a45ea97afdc62
gpiolib: of: Correct error handling in of_get_named_gpiod_flags

assumed that only one gpio-chip is registred per of-node.
Some drivers register more than one chip per of-node, so
adjust the matching function of_gpiochip_find_and_xlate to
not stop looking for chips if a node-match is found and
the translation fails.

Fixes: 7b8792bbdffd ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags")
Signed-off-by: Hans Holmberg 
Acked-by: Alexandre Courbot 
Tested-by: Robert Jarzmik 
Tested-by: Tyler Hall 
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques

gpio: sysfs: fix gpio attribute-creation race

2015-03-02T15:04:44+00:00

commit ebbeba120ab2ec6ac5f3afc1425ec6ff0b77ad6f upstream.

Fix attribute-creation race with userspace by using the default group
to create also the contingent gpio device attributes.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[ luis: backported to 3.16:
  - all changes in drivers/gpio/gpiolib.c
  - adjusted context ]
Signed-off-by: Luis Henriques