linux-stable.git/drivers/gpio, branch v5.4.13

gpio: mpc8xxx: Add platform device to gpiochip->parent

2020-01-17T18:49:03+00:00

[ Upstream commit 322f6a3182d42df18059a89c53b09d33919f755e ]

Dear Linus Walleij,

In old kernels, some APIs still try to use parent->of_node from struct gpio_chip,
and it could be resulted in kernel panic because parent is NULL. Adding platform
device to gpiochip->parent can fix this problem.

Signed-off-by: Johnson Chen 
Link: https://patchwork.kernel.org/patch/11234609
Link: https://lore.kernel.org/r/HK0PR01MB3521489269F76467DFD7843FFA450@HK0PR01MB3521.apcprd01.prod.exchangelabs.com
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: Fix error message on out-of-range GPIO in lookup table

2020-01-17T18:48:22+00:00

commit d935bd50dd14a7714cbdba9a76435dbb56edb1ae upstream.

When a GPIO offset in a lookup table is out-of-range, the printed error
message (1) does not include the actual out-of-range value, and (2)
contains an off-by-one error in the upper bound.

Avoid user confusion by also printing the actual GPIO offset, and
correcting the upper bound of the range.
While at it, use "%u" for unsigned int.

Sample impact:

    -requested GPIO 0 is out of range [0..32] for chip e6052000.gpio
    +requested GPIO 0 (45) is out of range [0..31] for chip e6052000.gpio

Fixes: 2a3cf6a3599e9015 ("gpiolib: return -ENOENT if no GPIO mapping exists")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20191127095919.4214-1-geert+renesas@glider.be
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: zynq: Fix for bug in zynq_gpio_restore_context API

2020-01-17T18:48:20+00:00

commit 36f2e7207f21a83ca0054116191f119ac64583ab upstream.

This patch writes the inverse value of Interrupt Mask Status
register into the Interrupt Enable register in
zynq_gpio_restore_context API to fix the bug.

Fixes: e11de4de28c0 ("gpio: zynq: Add support for suspend resume")
Signed-off-by: Swapna Manupati 
Signed-off-by: Michal Simek 
Signed-off-by: Srinivas Neeli 
Link: https://lore.kernel.org/r/1577362338-28744-2-git-send-email-srinivas.neeli@xilinx.com
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism

2020-01-14T19:08:28+00:00

commit aa23ca3d98f756d5b1e503fb140665fb24a41a38 upstream.

On some laptops enabling wakeup on the GPIO interrupts used for ACPI _AEI
event handling causes spurious wakeups.

This commit adds a new honor_wakeup option, defaulting to true (our current
behavior), which can be used to disable wakeup on troublesome hardware
to avoid these spurious wakeups.

This is a workaround for an architectural problem with s2idle under Linux
where we do not have any mechanism to immediately go back to sleep after
wakeup events, other then for embedded-controller events using the standard
ACPI EC interface, for details see:
https://lore.kernel.org/linux-acpi/61450f9b-cbc6-0c09-8b3a-aff6bf9a0b3c@redhat.com/

One series of laptops which is not able to suspend without this workaround
is the HP x2 10 Cherry Trail models, this commit adds a DMI based quirk
which makes sets honor_wakeup to false on these models.

Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20200105160357.97154-3-hdegoede@redhat.com
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Turn dmi_system_id table into a generic quirk table

2020-01-14T19:08:28+00:00

commit 1ad1b54099c231aed8f6f257065c1b322583f264 upstream.

Turn the existing run_edge_events_on_boot_blacklist dmi_system_id table
into a generic quirk table, storing the quirks in the driver_data ptr.

This is a preparation patch for adding other types of (DMI based) quirks.

Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20200105160357.97154-2-hdegoede@redhat.com
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: Handle counting of Freescale chipselects

2020-01-12T11:21:12+00:00

[ Upstream commit 71b8f600b034c7f5780f6fb311dabfe331c64feb ]

We have a special quirk to handle the Freescale
nonstandard SPI chipselect GPIOs in the gpiolib-of.c
file, but it currently only handles the case where
the GPIOs are actually requested (gpiod_*get()).

We also need to handle that the SPI core attempts
to count the GPIOs before use, and that needs a
similar quirk in the OF part of the library.

Cc: Christophe Leroy 
Reported-by: Christophe Leroy 
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij 
Tested-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

gpiolib: fix up emulated open drain outputs

2020-01-09T09:19:59+00:00

commit 256efaea1fdc4e38970489197409a26125ee0aaa upstream.

gpiolib has a corner case with open drain outputs that are emulated.
When such outputs are outputting a logic 1, emulation will set the
hardware to input mode, which will cause gpiod_get_direction() to
report that it is in input mode. This is different from the behaviour
with a true open-drain output.

Unify the semantics here.

Cc: 
Suggested-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: xtensa: fix driver build

2020-01-09T09:19:59+00:00

commit 634f0348fe336fce8f6cab1933139115e983ed2f upstream.

Commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") removed
{RSR,WSR}_CPENABLE from xtensa code, but did not fix up all users,
breaking gpio-xtensa driver build. Update gpio-xtensa to use
new xtensa_{get,set}_sr API.

Cc: stable@vger.kernel.org # v5.0+
Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr")
Signed-off-by: Max Filippov 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: lynxpoint: Setup correct IRQ handlers

2020-01-04T18:18:20+00:00

[ Upstream commit e272f7ec070d212b9301d5a465bc8952f8dcf908 ]

When commit 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be
handle_bad_irq()") switched default handler to be handle_bad_irq() the
lp_irq_type() function remained untouched. It means that even request_irq()
can't change the handler and we are not able to handle IRQs properly anymore.
Fix it by setting correct handlers in the lp_irq_type() callback.

Fixes: 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be handle_bad_irq()")
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20191118180251.31439-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: mpc8xxx: Don't overwrite default irq_set_type callback

2020-01-04T18:18:20+00:00

[ Upstream commit 4e50573f39229d5e9c985fa3b4923a8b29619ade ]

The per-SoC devtype structures can contain their own callbacks that
overwrite mpc8xxx_gpio_devtype_default.

The clear intention is that mpc8xxx_irq_set_type is used in case the SoC
does not specify a more specific callback. But what happens is that if
the SoC doesn't specify one, its .irq_set_type is de-facto NULL, and
this overwrites mpc8xxx_irq_set_type to a no-op. This means that the
following SoCs are affected:

- fsl,mpc8572-gpio
- fsl,ls1028a-gpio
- fsl,ls1088a-gpio

On these boards, the irq_set_type does exactly nothing, and the GPIO
controller keeps its GPICR register in the hardware-default state. On
the LS1028A, that is ACTIVE_BOTH, which means 2 interrupts are raised
even if the IRQ client requests LEVEL_HIGH. Another implication is that
the IRQs are not checked (e.g. level-triggered interrupts are not
rejected, although they are not supported).

Fixes: 82e39b0d8566 ("gpio: mpc8xxx: handle differences between incarnations at a single place")
Signed-off-by: Vladimir Oltean 
Link: https://lore.kernel.org/r/20191115125551.31061-1-olteanv@gmail.com
Tested-by: Michael Walle 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin