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

gpiolib: Mark gpio_suffixes array with __maybe_unused

2018-09-26T06:36:39+00:00

[ Upstream commit b23ec59926faf05b0c43680d05671c484e810ac4 ]

Since we put static variable to a header file it's copied to each module
that includes the header. But not all of them are actually used it.

Mark gpio_suffixes array with __maybe_unused to hide a compiler warning:

In file included from
drivers/gpio/gpiolib-legacy.c:6:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~
In file included from drivers/gpio/gpiolib-devprop.c:17:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~

Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: pxa: Fix potential NULL dereference

2018-09-26T06:36:39+00:00

[ Upstream commit 9506755633d0b32ef76f67c345000178e9b0dfc4 ]

platform_get_resource() may fail and return NULL, so we should
better check it's return value to avoid a NULL pointer dereference
a bit later in the code.

This is detected by Coccinelle semantic patch.

@@
expression pdev, res, n, t, e, e1, e2;
@@

res = platform_get_resource(pdev, t, n);
+ if (!res)
+   return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);

Signed-off-by: Wei Yongjun 
Acked-by: Robert Jarzmik 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: ml-ioh: Fix buffer underwrite on probe error path

2018-09-19T20:47:14+00:00

[ Upstream commit 4bf4eed44bfe288f459496eaf38089502ef91a79 ]

If ioh_gpio_probe() fails on devm_irq_alloc_descs() then chip may point
to any element of chip_save array, so reverse iteration from pointer chip
may become chip_save[-1] and gpiochip_remove() will operate with wrong
memory.

The patch fix the error path of ioh_gpio_probe() to correctly bypass
chip_save array.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: tegra: Move driver registration to subsys_init level

2018-09-19T20:47:12+00:00

[ Upstream commit 40b25bce0adbe641a744d1291bc0e51fb7f3c3d8 ]

There is a bug in regards to deferred probing within the drivers core
that causes GPIO-driver to suspend after its users. The bug appears if
GPIO-driver probe is getting deferred, which happens after introducing
dependency on PINCTRL-driver for the GPIO-driver by defining "gpio-ranges"
property in device-tree. The bug in the drivers core is old (more than 4
years now) and is well known, unfortunately there is no easy fix for it.
The good news is that we can workaround the deferred probe issue by
changing GPIO / PINCTRL drivers registration order and hence by moving
PINCTRL driver registration to the arch_init level and GPIO to the
subsys_init.

Signed-off-by: Dmitry Osipenko 
Acked-by: Stefan Agner 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: No NULL owner

2018-06-16T07:52:33+00:00

commit 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 upstream.

Sometimes a GPIO is fetched with NULL as parent device, and
that is just fine. So under these circumstances, avoid using
dev_name() to provide a name for the GPIO line.

Signed-off-by: Linus Walleij 
Cc: Daniel Rosenberg 
Signed-off-by: Greg Kroah-Hartman

gpio: fix error path in lineevent_create

2018-05-16T08:08:42+00:00

commit f001cc351ad3309ec8736c374e90e5a4bc472d41 upstream.

If gpiod_request() fails the cleanup must not call gpiod_free().

Cc: stable@vger.kernel.org
Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: fix aspeed_gpio unmask irq

2018-05-16T08:08:42+00:00

commit f241632fd087d3d9fbd5450f4d8c8604badd8348 upstream.

The unmask function disables all interrupts in a bank when unmasking an
interrupt. Only disable the given interrupt.

Cc: stable@vger.kernel.org
Signed-off-by: Govert Overgaauw 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpioib: do not free unrequested descriptors

2018-05-16T08:08:42+00:00

commit ab3dbcf78f60f46d6a0ad63b1f4b690b7a427140 upstream.

If the main loop in linehandle_create() encounters an error, it
unwinds completely by freeing all previously requested GPIO
descriptors.  However, if the error occurs in the beginning of
the loop before that GPIO is requested, then the exit code
attempts to free a null descriptor.  If extrachecks is enabled,
gpiod_free() triggers a WARN_ON.

Instead, keep a separate count of legitimate GPIOs so that only
those are freed.

Cc: stable@vger.kernel.org
Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
Reviewed-by: Bjorn Andersson 
Signed-off-by: Timur Tabi 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: label descriptors using the device name

2018-04-13T17:48:11+00:00

[ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ]

Some GPIO lines appear named "?" in the lsgpio dump due to their
requesting drivers not passing a reasonable label.

Most typically this happens if a device tree node just defines
gpios = <...> and not foo-gpios = <...>, the former gets named
"foo" and the latter gets named "?".

However the struct device passed in is always valid so let's
just label the GPIO with dev_name() on the device if no proper
label was passed.

Cc: Reported-by: Jason Kridner 
Reported-by: Jason Kridner 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: crystalcove: Do not write regular gpio registers for virtual GPIOs

2018-04-13T17:48:04+00:00

[ Upstream commit 9a752b4c9ab924033bfdb8784c680d50b2bd5684 ]

The Crystal Cove PMIC has 16 real GPIOs but the ACPI code for devices
with this PMIC may address up to 95 GPIOs, these extra GPIOs are
called virtual GPIOs and are used by the ACPI code as a method of
accessing various non GPIO bits of PMIC.

Commit dcdc3018d635 ("gpio: crystalcove: support virtual GPIO") added
dummy support for these to avoid a bunch of ACPI errors, but instead of
ignoring writes / reads to them by doing:

if (gpio >= CRYSTALCOVE_GPIO_NUM)
	return 0;

It accidentally introduced the following wrong check:

if (gpio > CRYSTALCOVE_VGPIO_NUM)
	return 0;

Which means that attempts by the ACPI code to access these gpios
causes some arbitrary gpio to get touched through for example
GPIO1P0CTLO + gpionr % 8.

Since we do support input/output (but not interrupts) on the 0x5e
virtual GPIO, this commit makes to_reg return -ENOTSUPP for unsupported
virtual GPIOs so as to not have to check for (gpio >= CRYSTALCOVE_GPIO_NUM
&& gpio != 0x5e) everywhere and to make it easier to add support for more
virtual GPIOs in the future.

It then adds a check for to_reg returning an error to all callers where
this may happen fixing the ACPI code accessing virtual GPIOs accidentally
causing changes to real GPIOs.

Fixes: dcdc3018d635 ("gpio: crystalcove: support virtual GPIO")
Cc: Aaron Lu 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman