kernel/include/linux/gpio/driver.h, branch linux-5.10.y

gpio: Allow per-parent interrupt data

2023-06-28T08:28:13Z

[ Upstream commit cfe6807d82e97e81c3209dca9448f091e1448a57 ] The core gpiolib code is able to deal with multiple interrupt parents for a single gpio irqchip. It however only allows a single piece of data to be conveyed to all flow handlers (either the gpio_chip or some other, driver-specific data). This means that drivers have to go through some interesting dance to find the correct context, something that isn't great in interrupt context (see aebdc8abc9db86e2bd33070fc2f961012fff74b4 for a prime example). Instead, offer an optional way for a pinctrl/gpio driver to provide an array of pointers which gets used to provide the correct context to the flow handler. Signed-off-by: Marc Zyngier Signed-off-by: Joey Gouly Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20211026175815.52703-2-joey.gouly@arm.com Signed-off-by: Linus Walleij Stable-dep-of: 8c00914e5438 ("gpiolib: Fix GPIO chip IRQ initialization restriction") Signed-off-by: Sasha Levin

gpiolib: of: Introduce hook for missing gpio-ranges

2022-06-09T08:21:15Z

[ Upstream commit 3550bba25d5587a701e6edf20e20984d2ee72c78 ] Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") the device tree nodes of GPIO controller need the gpio-ranges property to handle gpio-hogs. Unfortunately it's impossible to guarantee that every new kernel is shipped with an updated device tree binary. In order to provide backward compatibility with those older DTB, we need a callback within of_gpiochip_add_pin_range() so the relevant platform driver can handle this case. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Stefan Wahren Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Acked-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: Restrict usage of GPIO chip irq members before initialization

2022-04-13T19:01:09Z

commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream. GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized. Signed-off-by: Shreeya Patel Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman

gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP

2021-05-14T07:50:31Z

[ Upstream commit 9c7d24693d864f90b27aad5d15fbfe226c02898b ] The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP isn't enabled. Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Suggested-by: Michael Walle Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Linus Walleij Reviewed-by: Michael Walle Acked-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpiolib: unexport devprop_gpiochip_set_names()

2020-09-14T08:54:42Z

Now that devprop_gpiochip_set_names() is only used in a single place inside drivers/gpio/gpiolib.c, there's no need anymore for it to be exported or to even live in its own source file. Pull this function into the core source file for gpiolib. Signed-off-by: Bartosz Golaszewski Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko

gpiolib: generalize devprop_gpiochip_set_names() for device properties

2020-09-14T08:54:01Z

devprop_gpiochip_set_names() is overly complicated with taking the fwnode argument (which requires using dev_fwnode() & of_fwnode_handle() in ACPI and OF GPIO code respectively). Let's just switch to using the generic device properties. This allows us to pull the code setting line names directly into gpiochip_add_data_with_key() instead of handling it separately for ACPI and OF. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Reviewed-by: Mika Westerberg

gpio: don't use same lockdep class for all devm_gpiochip_add_data users

2020-08-03T23:22:02Z

Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents in its commits message its intention to "create a unique class key for each driver". It does so by having gpiochip_add_data add in-place the definition of two static lockdep classes for LOCKDEP use. That way, every caller of the macro adds their gpiochip with unique lockdep classes. There are many indirect callers of gpiochip_add_data, however, via use of devm_gpiochip_add_data. devm_gpiochip_add_data has external linkage and all its users will share the same lockdep classes, which probably is not intended. Fix this by replicating the gpio_chip_add_data statics-in-macro for the devm_ version as well. Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys") Signed-off-by: Ahmad Fatoum Reviewed-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de Signed-off-by: Linus Walleij

gpio: Correct kernel-doc inconsistency

2020-07-23T13:18:09Z

Fix kernel-doc comment to match parameter name change "chip" to "gc" in gpiochip_add_data function. Signed-off-by: Colton Lewis Link: https://lore.kernel.org/r/20200723095658.234668-1-colton.w.lewis@protonmail.com Signed-off-by: Linus Walleij

Merge tag 'gpio-updates-for-v5.9-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel

2020-06-30T21:53:11Z

gpio updates for v5.9 - use kobj_to_dev() in sysfs interface - kerneldoc and documentation fixes - relax the interrupt flags in gpio-mpc8xxx - support new model in gpio-pca953x - remove a redundant check from gpio-max732x - support a new platform in gpio-zynq (+ some minor fixes) - don't depend on GPIOLIB when already inside the "if GPIOLIB" in Kconfig - support PM ops for suspend in gpio-omap - minor tweaks in gpiolib

gpiolib: Introduce for_each_requested_gpio_in_range() macro

2020-06-20T21:13:26Z

Introduce for_each_requested_gpio_in_range() macro which helps to iterate over requested GPIO in a range. There are already potential users of it, which are going to be converted by the following patches. For most of them for_each_requested_gpio() shortcut has been added. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200615150545.87964-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij