linux-toradex.git/drivers/gpio, branch v3.14.57

gpio: gpio-kempld: Fix get_direction return value

2015-06-06T15:19:37+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: Greg Kroah-Hartman

gpio: sysfs: fix memory leaks and device hotplug

2015-05-17T16:53:49+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: Greg Kroah-Hartman

gpio: unregister gpiochip device before removing it

2015-05-17T16:53:49+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: Greg Kroah-Hartman

gpio: clamp returned values to the boolean range

2015-05-06T19:59:18+00:00

commit 23600969ff137cf4c3bc9098f77e381de334e3f7 upstream.

Nothing prevents GPIO drivers from returning values outside the
boolean range, and as it turns out a few drivers are actually doing so.
These values were passed as-is to unsuspecting consumers and created
confusion.

This patch makes the internal _gpiod_get_raw_value() function return a
bool, effectively clamping the GPIO value to the boolean range no
matter what the driver does.

While we are at it, we also change the value parameter of
_gpiod_set_raw_value() to bool type before drivers start doing funny
things with it as well.

Another way to fix this would be to change the prototypes of the driver
interface to use bool directly, but this would require a huge
cross-systems patch so this simpler solution is preferred.

Changes since v1:
- Change local variable type to bool as well, use boolean values in
  code
- Also change prototype of open drain/open source setting functions
  since they are only called from _gpiod_set_raw_value()

This probably calls for a larger booleanization of gpiolib, but let's
keep that for a latter change - right now we need to address the issue
of non-boolean values returned by drivers.

Signed-off-by: Alexandre Courbot 
Signed-off-by: Linus Walleij 
Cc: Vladimir Zapolskiy 
Signed-off-by: Greg Kroah-Hartman

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

2015-05-06T19:59:18+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: Greg Kroah-Hartman

gpio: tps65912: fix wrong container_of arguments

2015-03-06T22:43:31+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: Greg Kroah-Hartman

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

2015-03-06T22:43:31+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: Greg Kroah-Hartman

gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

2015-02-11T06:54:45+00:00

commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.

Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in sysfs")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: sysfs: fix memory leak in gpiod_export_link

2015-02-11T06:54:45+00:00

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: sysfs: fix gpio device-attribute leak

2015-01-30T01:40:48+00:00

commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.

The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).

Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.

Remove contingent attributes in export error path and on unexport.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman