linux-stable.git/drivers/gpio, branch v4.6.7

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

2016-07-27T15:42:10+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: sch: Fix Oops on module load on Asus Eee PC 1201

2016-07-27T15:42:10+00:00

commit 87041a58d3b19455d39baed2a5e5bb43b58fb915 upstream.

This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.

The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.

The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.

Thanks Mika for your patience with me :-)

Signed-off-by: Colin Pitrat 
Acked-by: Alexandre Courbot 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: make library immune to error pointers

2016-07-27T15:42:10+00:00

commit c0a1ecb9f4e208f4b75d88fa9669748e3fd705ab upstream.

Most functions that take a GPIO descriptor in need to check the
descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC()
macro except for the gpiod_to_irq() function which needs special
handling.

Reported-by: Grygorii Strashko 
Reviewed-by: Grygorii Strashko 
Acked-by: Alexandre Courbot 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: make sure gpiod_to_irq() returns negative on NULL desc

2016-06-24T17:22:06+00:00

commit 79bb71bd1d93197ce227fa167b450b633f30a52b upstream.

commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264
("gpio: bail out silently on NULL descriptors")
doesn't work for gpiod_to_irq(): drivers assume that NULL
descriptors will give negative IRQ numbers in return.

It has been pointed out that returning 0 is NO_IRQ and that
drivers should be amended to treat this as an error, but that
is for the longer term: now let us repair the semantics.

Cc: Maxime Ripard 
Reported-by: Hans de Goede 
Tested-by: Hans de Goede 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: zynq: initialize clock even without CONFIG_PM

2016-06-24T17:22:04+00:00

commit 0f84f29ff30bdb1bca23017b118b4ea3999cac32 upstream.

When the PM initialization was moved in the commit referenced below, the
code enabling the clock was removed from the probe function. On
CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables
the clock, but when power management is disabled, all those pm_*
functions are noops and the clock is never enabled resulting in a
dysfunctional gpio controller.

Put the clock initialization back to support CONFIG_PM=n.

Signed-off-by: Helmut Grohne 
Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: zynq: Fix the error path

2016-06-24T17:22:04+00:00

commit 615d23f80efc60f8c5146223f305d19207c742e4 upstream.

pm_runtime_disable is called only in remove it is missed
out in the error path.
Fix the same.

Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Linus Walleij 
Cc: Helmut Grohne 
Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix unaligned used of reference counters

2016-06-24T17:22:02+00:00

commit f4833b8cc7edab57d3f3033e549111a546c2e02b upstream.

gpiolib relies on the reference counters to clean up the gpio_device
structure.

Although the number of get/put is properly aligned on gpiolib.c
itself, it does not take into consideration how the referece counters
are affected by other external functions such as cdev_add and device_add.

Because of this, after the last call to put_device, the reference counter
has a value of +3, therefore never calling gpiodevice_release.

Due to the fact that some of the device  has already been cleaned on
gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call
to of_gpiochip_find_and_xlate).

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix NULL pointer deference

2016-06-24T17:22:02+00:00

commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f upstream.

Under some circumstances, a gpiochip might be half cleaned from the
gpio_device list.

This patch makes sure that the chip pointer is still valid, before
calling the match function.

[  104.088296] BUG: unable to handle kernel NULL pointer dereference at
0000000000000090
[  104.089772] IP: [] of_gpiochip_find_and_xlate+0x15/0x80
[  104.128273] Call Trace:
[  104.129802]  [] ? of_parse_own_gpio+0x1f0/0x1f0
[  104.131353]  [] gpiochip_find+0x60/0x90
[  104.132868]  [] of_get_named_gpiod_flags+0x9a/0x120
...
[  104.141586]  [] gpio_led_probe+0x11b/0x360

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-24T17:22:02+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: bail out silently on NULL descriptors

2016-06-24T17:22:02+00:00

commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 upstream.

In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e
("gpio: reflect base and ngpio into gpio_device")
assumed that GPIO descriptors are either valid or error
pointers, but gpiod_get_[index_]optional() actually return
NULL descriptors and then all subsequent calls should just
bail out.

Cc: Sergei Shtylyov 
Cc: Florian Fainelli 
Cc: Andrew Lunn 
Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device")
Reported-by: Uwe Kleine-König 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman