linux-stable.git/drivers/gpio, branch v5.4.8 Linux kernel stable tree 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>
gpio: max77620: Fixup debounce delays 2019-11-12T10:13:54+00:00 Thierry Reding treding@nvidia.com 2019-11-08T16:07:46+00:00 b0391479ae04dfcbd208b9571c375064caad9a57 When converting milliseconds to microseconds in commit fffa6af94894 ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps were introduced between the various ranges supported by the controller. Fix this by changing the start of each range to the value immediately following the end of the previous range. This way a debounce time of, say 8250 us will translate into 16 ms instead of returning an -EINVAL error. Typically the debounce delay is only ever set through device tree and specified in milliseconds, so we can never really hit this issue because debounce times are always a multiple of 1000 us. The only notable exception for this is drivers/mmc/host/mmc-spi.c where the CD GPIO is requested, which passes a 1 us debounce time. According to a comment preceeding that code this should actually be 1 ms (i.e. 1000 us). Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Pavel Machek <pavel@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> 
When converting milliseconds to microseconds in commit fffa6af94894
("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps
were introduced between the various ranges supported by the controller.
Fix this by changing the start of each range to the value immediately
following the end of the previous range. This way a debounce time of,
say 8250 us will translate into 16 ms instead of returning an -EINVAL
error.

Typically the debounce delay is only ever set through device tree and
specified in milliseconds, so we can never really hit this issue because
debounce times are always a multiple of 1000 us.

The only notable exception for this is drivers/mmc/host/mmc-spi.c where
the CD GPIO is requested, which passes a 1 us debounce time. According
to a comment preceeding that code this should actually be 1 ms (i.e.
1000 us).

Reported-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Pavel Machek <pavel@denx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Revert "gpio: merrifield: Pass irqchip when adding gpiochip" 2019-11-03T22:41:11+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-03T22:41:11+00:00 1173c3c28abfc3d7b7665db502280ba9322320e6 This reverts commit 8f86a5b4ad679e4836733b47414226074eee4e4d. It has been established that this causes a boot regression on both Baytrail and Cherrytrail SoCs, and we can't have that in the final kernel release, so we need to revert it. Reported-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
This reverts commit 8f86a5b4ad679e4836733b47414226074eee4e4d.

It has been established that this causes a boot regression on
both Baytrail and Cherrytrail SoCs, and we can't have that in
the final kernel release, so we need to revert it.

Reported-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Revert "gpio: merrifield: Restore use of irq_base" 2019-11-03T22:40:48+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-03T22:40:48+00:00 52c75f56703e1c40a2bc3f64a140602112dfa302 This reverts commit 6658f87f219427ee776c498e07c878eb5cad1be2. This revert is a prerequisite for the later revert of commit 8f86a5b4ad679e4836733b47414226074eee4e4d. Reported-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
This reverts commit 6658f87f219427ee776c498e07c878eb5cad1be2.

This revert is a prerequisite for the later revert of commit
8f86a5b4ad679e4836733b47414226074eee4e4d.

Reported-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>