linux-stable.git/drivers/gpio, branch v5.4.11 Linux kernel stable tree gpio: Handle counting of Freescale chipselects 2020-01-12T11:21:12+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-28T08:37:17+00:00 b8ec95e4b983566d0a03994258489bd560bd51e4 [ 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 <christophe.leroy@c-s.fr> Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <christophe.leroy@c-s.fr>
Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gpiolib: fix up emulated open drain outputs 2020-01-09T09:19:59+00:00 Russell King rmk+kernel@armlinux.org.uk 2019-12-07T16:20:18+00:00 530f7c6df94e2190ae4499633910f36487da4d6c 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: <stable@vger.kernel.org> Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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: <stable@vger.kernel.org>
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gpio: xtensa: fix driver build 2020-01-09T09:19:59+00:00 Max Filippov jcmvbkbc@gmail.com 2019-11-26T19:30:27+00:00 5654d5d25c17782e0a12554483bd345cd25b7bf6 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 <jcmvbkbc@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <jcmvbkbc@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gpio: lynxpoint: Setup correct IRQ handlers 2020-01-04T18:18:20+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2019-11-18T18:02:51+00:00 3a2d6bc5aa9e163b67786310c7b5c8ed669e8f74 [ 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 <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20191118180251.31439-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191118180251.31439-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gpio: mpc8xxx: Don't overwrite default irq_set_type callback 2020-01-04T18:18:20+00:00 Vladimir Oltean vladimir.oltean@nxp.com 2019-11-15T12:55:51+00:00 00ae1761fab3b3fdeb703e5aa85aca0bbeda8e5c [ 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20191115125551.31061-1-olteanv@gmail.com Tested-by: Michael Walle <michael@walle.cc> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20191115125551.31061-1-olteanv@gmail.com
Tested-by: Michael Walle <michael@walle.cc>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gpio/mpc8xxx: fix qoriq GPIO reading 2020-01-04T18:18:18+00:00 Russell King rmk+kernel@armlinux.org.uk 2019-11-19T13:10:38+00:00 3fd185ba5688fbb5191213ab849f03940f3012c6 [ Upstream commit 787b64a43f7acacf8099329ea08872e663f1e74f ] Qoriq requires the IBE register to be set to enable GPIO inputs to be read. Set it. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1iX3HC-00069N-0T@rmk-PC.armlinux.org.uk Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 787b64a43f7acacf8099329ea08872e663f1e74f ]

Qoriq requires the IBE register to be set to enable GPIO inputs to be
read.  Set it.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/E1iX3HC-00069N-0T@rmk-PC.armlinux.org.uk
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gpio: mxc: Only get the second IRQ when there is more than one IRQ 2020-01-04T18:16:27+00:00 Anson Huang Anson.Huang@nxp.com 2019-09-19T09:39:17+00:00 1c85192b4b0a1b8a5f53752e4a60a3b384dc871c [ Upstream commit c8f3d144004dd3f471ffd414690d15a005e4acd6 ] On some of i.MX SoCs like i.MX8QXP, there is ONLY one IRQ for each GPIO bank, so it is better to check the IRQ count before getting second IRQ to avoid below error message during probe: [ 1.070908] gpio-mxc 5d080000.gpio: IRQ index 1 not found [ 1.077420] gpio-mxc 5d090000.gpio: IRQ index 1 not found [ 1.083766] gpio-mxc 5d0a0000.gpio: IRQ index 1 not found [ 1.090122] gpio-mxc 5d0b0000.gpio: IRQ index 1 not found [ 1.096470] gpio-mxc 5d0c0000.gpio: IRQ index 1 not found [ 1.102804] gpio-mxc 5d0d0000.gpio: IRQ index 1 not found [ 1.109144] gpio-mxc 5d0e0000.gpio: IRQ index 1 not found [ 1.115475] gpio-mxc 5d0f0000.gpio: IRQ index 1 not found Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c8f3d144004dd3f471ffd414690d15a005e4acd6 ]

On some of i.MX SoCs like i.MX8QXP, there is ONLY one IRQ for each
GPIO bank, so it is better to check the IRQ count before getting
second IRQ to avoid below error message during probe:

[    1.070908] gpio-mxc 5d080000.gpio: IRQ index 1 not found
[    1.077420] gpio-mxc 5d090000.gpio: IRQ index 1 not found
[    1.083766] gpio-mxc 5d0a0000.gpio: IRQ index 1 not found
[    1.090122] gpio-mxc 5d0b0000.gpio: IRQ index 1 not found
[    1.096470] gpio-mxc 5d0c0000.gpio: IRQ index 1 not found
[    1.102804] gpio-mxc 5d0d0000.gpio: IRQ index 1 not found
[    1.109144] gpio-mxc 5d0e0000.gpio: IRQ index 1 not found
[    1.115475] gpio-mxc 5d0f0000.gpio: IRQ index 1 not found

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'gpio-v5.4-rc8-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes 2019-11-13T21:58:01+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-13T21:58:01+00:00 cbdaa5e7bd90db9980ff6187baea9d49fc4de960 gpio fixes for v5.4-rc8 - fix debounce times in max776520 and bd70528 - fix parallel build of gpio tools 
gpio fixes for v5.4-rc8

- fix debounce times in max776520 and bd70528
- fix parallel build of gpio tools
gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist 2019-11-13T21:57:26+00:00 Hans de Goede hdegoede@redhat.com 2019-11-06T11:51:09+00:00 2727315df3f5ffbebcb174eed3153944a858b66f The Terra Pad 1061 has the usual micro-USB-B id-pin handler, but instead of controlling the actual micro-USB-B it turns the 5V boost for the tablet's USB-A connector and its keyboard-cover connector off. The actual micro-USB-B connector on the tablet is wired for charging only, and its id pin is *not* connected to the GPIO which is used for the (broken) id-pin event handler in the DSDT. While at it not only add a comment why the Terra Pad 1061 is on the blacklist, but also fix the missing comment for the Minix Neo Z83-4 entry. Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The Terra Pad 1061 has the usual micro-USB-B id-pin handler, but instead
of controlling the actual micro-USB-B it turns the 5V boost for the
tablet's USB-A connector and its keyboard-cover connector off.

The actual micro-USB-B connector on the tablet is wired for charging only,
and its id pin is *not* connected to the GPIO which is used for the
(broken) id-pin event handler in the DSDT.

While at it not only add a comment why the Terra Pad 1061 is on the
blacklist, but also fix the missing comment for the Minix Neo Z83-4 entry.

Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: bd70528: Use correct unit for debounce times 2019-11-12T10:18:52+00:00 Thierry Reding treding@nvidia.com 2019-11-08T16:07:47+00:00 f88c117b6d6d7e96557b6ee143b26b550fc51076 The debounce time passed to gpiod_set_debounce() is specified in microseconds, so make sure to use the correct unit when computing the register values, which denote delays in milliseconds. Signed-off-by: Thierry Reding <treding@nvidia.com> Cc: <stable@vger.kernel.org> Fixes: 18bc64b3aebf ("gpio: Initial support for ROHM bd70528 GPIO block") [Bartosz: fixed a typo in commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> 
The debounce time passed to gpiod_set_debounce() is specified in
microseconds, so make sure to use the correct unit when computing the
register values, which denote delays in milliseconds.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Cc: <stable@vger.kernel.org>
Fixes: 18bc64b3aebf ("gpio: Initial support for ROHM bd70528 GPIO block")
[Bartosz: fixed a typo in commit message]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>