kernel/linux.git/drivers/gpio, branch linux-5.11.y

gpio: omap: Save and restore sysconfig

2021-04-28T11:41:47+00:00

[ Upstream commit ddd8d94ca31e768c76cf8bfe34ba7b10136b3694 ] As we are using cpu_pm to save and restore context, we must also save and restore the GPIO sysconfig register. This is needed because we are not calling PM runtime functions at all with cpu_pm. We need to save the sysconfig on idle as it's value can get reconfigured by PM runtime and can be different from the init time value. Device specific flags like "ti,no-idle-on-init" can affect the init value. Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead") Cc: Aaro Koskinen Cc: Adam Ford Cc: Andreas Kemnade Cc: Grygorii Strashko Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Acked-by: Grygorii Strashko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: sysfs: Obey valid_mask

2021-04-21T11:13:17+00:00

[ Upstream commit 23cf00ddd2e1aacf1873e43f5e0c519c120daf7a ] Do not allow exporting GPIOs which are set invalid by the driver's valid mask. Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") Signed-off-by: Matti Vaittinen Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: Read "gpio-line-names" from a firmware node

2021-04-14T06:47:25+00:00

commit b41ba2ec54a70908067034f139aa23d0dd2985ce upstream. On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000, see arch/arm/boot/dts/stm32mp151.dtsi. The driver for pin-controller@50002000 is in drivers/pinctrl/stm32/pinctrl-stm32.c and iterates over all of its DT subnodes when registering each GPIO bank gpiochip. Each gpiochip has: - gpio_chip.parent = dev, where dev is the device node of the pin controller - gpio_chip.of_node = np, which is the OF node of the GPIO bank Therefore, dev_fwnode(chip->parent) != of_fwnode_handle(chip.of_node), i.e. pin-controller@50002000 != pin-controller@50002000/gpio@5000*000. The original code behaved correctly, as it extracted the "gpio-line-names" from of_fwnode_handle(chip.of_node) = pin-controller@50002000/gpio@5000*000. To achieve the same behaviour, read property from the firmware node. Fixes: 7cba1a4d5e162 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Reported-by: Marek Vasut Reported-by: Roman Guskov Signed-off-by: Andy Shevchenko Tested-by: Marek Vasut Reviewed-by: Marek Vasut Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Add missing IRQF_ONESHOT

2021-03-30T12:30:08+00:00

[ Upstream commit 6e5d5791730b55a1f987e1db84b078b91eb49e99 ] fixed the following coccicheck: ./drivers/gpio/gpiolib-acpi.c:176:7-27: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Make sure threaded IRQs without a primary handler are always request with IRQF_ONESHOT Reported-by: Abaci Robot Signed-off-by: Yang Li Acked-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin

gpiolib: Assign fwnode to parent's if no primary one provided

2021-03-24T10:54:10+00:00

[ Upstream commit 6cb59afe9e5b45a035bd6b97da6593743feefc72 ] In case when the properties are supplied in the secondary fwnode (for example, built-in device properties) the fwnode pointer left unassigned. This makes unable to retrieve them. Assign fwnode to parent's if no primary one provided. Fixes: 7cba1a4d5e16 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Fixes: 2afa97e9868f ("gpiolib: Read "gpio-line-names" from a firmware node") Reported-by: Bartosz Golaszewski Tested-by: Bartosz Golaszewski Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: fix gpio-device list corruption

2021-03-17T16:11:21+00:00

commit cf25ef6b631c6fc6c0435fc91eba8734cca20511 upstream. Make sure to hold the gpio_lock when removing the gpio device from the gpio_devices list (when dropping the last reference) to avoid corrupting the list when there are concurrent accesses. Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Cc: stable@vger.kernel.org # 4.6 Reviewed-by: Saravana Kannan Signed-off-by: Johan Hovold Signed-off-by: Bartosz Golaszewski [ johan: adjust context to 5.11 ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

gpio: pca953x: Set IRQ type when handle Intel Galileo Gen 2

2021-03-17T16:11:20+00:00

commit eb441337c7147514ab45036cadf09c3a71e4ce31 upstream. The commit 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") indeliberately made a regression on how IRQ line from GPIO I²C expander is handled. I.e. it reveals that the quirk for Intel Galileo Gen 2 misses the part of setting IRQ type which previously was predefined by gpio-dwapb driver. Now, we have to reorganize the approach to call necessary parts, which can be done via ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk. Without this fix and with above mentioned change the kernel hangs on the first IRQ event with: gpio gpiochip3: Persistence not supported for GPIO 1 irq 32, desc: 62f8fb50, depth: 0, count: 0, unhandled: 0 ->handle_irq(): 41c7b0ab, handle_bad_irq+0x0/0x40 ->irq_data.chip(): e03f1e72, 0xc2539218 ->action(): 0ecc7e6f ->action->handler(): 8a3db21e, irq_default_primary_handler+0x0/0x10 IRQ_NOPROBE set unexpected IRQ trap at vector 20 Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Reviewed-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Allow to find GpioInt() resource by name and index

2021-03-17T16:11:19+00:00

commit 809390219fb9c2421239afe5c9eb862d73978ba0 upstream. Currently only search by index is supported. However, in some cases we might need to pass the quirks to the acpi_dev_gpio_irq_get(). For this, split out acpi_dev_gpio_irq_get_by() and replace acpi_dev_gpio_irq_get() by calling above with NULL for name parameter. Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Acked-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk

2021-03-17T16:11:19+00:00

commit 62d5247d239d4b48762192a251c647d7c997616a upstream. On some systems the ACPI tables has wrong pin number and instead of having a relative one it provides an absolute one in the global GPIO number space. Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk to cope with such cases. Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip") Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Acked-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: pcf857x: Fix missing first interrupt

2021-03-04T11:15:37+00:00

commit a8002a35935aaefcd6a42ad3289f62bab947f2ca upstream. If no n_latch value will be provided at driver probe then all pins will be used as an input: gpio->out = ~n_latch; In that case initial state for all pins is "one": gpio->status = gpio->out; So if pcf857x IRQ happens with change pin value from "zero" to "one" then we miss it, because of "one" from IRQ and "one" from initial state leaves corresponding pin unchanged: change = (gpio->status ^ status) & gpio->irq_enabled; The right solution will be to read actual state at driver probe. Cc: stable@vger.kernel.org Fixes: 6e20a0a429bd ("gpio: pcf857x: enable gpio_to_irq() support") Signed-off-by: Maxim Kiselev Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman