summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib.c
AgeCommit message (Collapse)Author
2024-02-12gpio: remove gpio_lockBartosz Golaszewski
The "multi-function" gpio_lock is pretty much useless with how it's used in GPIOLIB currently. Because many GPIO API calls can be called from all contexts but may also call into sleeping driver callbacks, there are many places with utterly broken workarounds like yielding the lock to call a possibly sleeping function and then re-acquiring it again without taking into account that the protected state may have changed. It was also used to protect several unrelated things: like individual descriptors AND the GPIO device list. We now serialize access to these two with SRCU and so can finally remove the spinlock. There is of course the question of consistency of lockless access to GPIO descriptors. Because we only support exclusive access to GPIOs (officially anyway, I'm looking at you broken GPIOD_FLAGS_BIT_NONEXCLUSIVE bit...) and the API contract with providers does not guarantee serialization, it's enough to ensure we cannot accidentally dereference an invalid pointer and that the state we present to both users and providers remains consistent. To achieve that: read the flags field atomically except for a few special cases. Read their current value before executing callback code and use this value for any subsequent logic. Modifying the flags depends on the particular use-case and can differ. For instance: when requesting a GPIO, we need to set the REQUESTED bit immediately so that the next user trying to request the same line sees -EBUSY. While at it: the allocations that used GFP_ATOMIC until this point can now switch to GFP_KERNEL. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: use gpio_device_find() to iterate over existing devicesBartosz Golaszewski
With the list of GPIO devices now protected with SRCU we can use gpio_device_find() to traverse it from sysfs. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the descriptor label with SRCUBartosz Golaszewski
In order to ensure that the label is not freed while it's being accessed, let's protect it with SRCU and synchronize it everytime it's changed. Let's modify desc_set_label() to manage the memory used for the label as it can only be freed once synchronize_srcu() returns. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add SRCU infrastructure to struct gpio_descBartosz Golaszewski
Extend the GPIO descriptor with an SRCU structure in order to serialize the access to the label. Initialize and clean it up where applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: don't set label from irq helpersBartosz Golaszewski
We will soon serialize access to the descriptor label using SRCU. The write-side of the protection will require calling synchronize_srcu() which must not be called from atomic context. We have two irq helpers: gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label if the GPIO is not requested but is being used as interrupt. They are called with a spinlock held from the interrupt subsystem. They must not do it if we are to use SRCU so instead let's move the special corner case to a dedicated getter. Don't actually set the label to "interrupt" in the above case but rather use the newly added gpiod_get_label() helper to hide the logic that atomically checks the descriptor flags and returns the address of a static "interrupt" string. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: provide and use gpiod_get_label()Bartosz Golaszewski
We will soon serialize access to the descriptor label using SRCU. The write-side of the protection will require calling synchronize_srcu() which must not be called from atomic context. We have two irq helpers: gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label if the GPIO is not requested but is being used as interrupt. They are called with a spinlock held from the interrupt subsystem. They must not do it if we are to use SRCU so instead let's move the special corner case to a dedicated getter. First: let's implement and use the getter where it's applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: of: assign and read the hog pointer atomicallyBartosz Golaszewski
The device nodes representing GPIO hogs cannot be deleted without unregistering the GPIO chip so there's no need to serialize their access. However we must ensure that users can get the right address so write and read it atomically. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the list of GPIO devices with SRCUBartosz Golaszewski
We're working towards removing the "multi-function" GPIO spinlock that's implemented terribly wrong. We tried using an RW-semaphore to protect the list of GPIO devices but it turned out that we still have old code using legacy GPIO calls that need to translate the global GPIO number to the address of the associated descriptor and - to that end - traverse the list while holding the lock. If we change the spinlock to a sleeping lock then we'll end up with "scheduling while atomic" bugs. Let's allow lockless traversal of the list using SRCU and only use the mutex when modyfing the list. While at it: let's protect the period between when we start the lookup and when we finally request the descriptor (increasing the reference count of the GPIO device) with the SRCU read lock. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: constify opaque pointer in gpio_device_find() match functionKrzysztof Kozlowski
The match function used in gpio_device_find() should not modify the contents of passed opaque pointer, because such modification would not be necessary for actual matching and it could lead to quite unreadable, spaghetti code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: fix coding style in header] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-12Merge tag 'v6.8-rc4' into gpio/for-nextBartosz Golaszewski
Linux 6.8-rc4 Pulling this for a bugfix upstream with which the gpio/for-next branch conflicts.
2024-02-08gpio: set device type for GPIO chipsBartosz Golaszewski
It's useful to have the device type information for those sub-devices that are actually GPIO chips registered with GPIOLIB. While at it: use the device type struct to setup the release callback which is the preferred way to use the device API. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-08gpio: remove GPIO device from the list unconditionally in error pathBartosz Golaszewski
Since commit 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered") we remove the GPIO device entry from the global list (used to order devices by their GPIO ranges) when unregistering the chip, not when releasing the device. It will not happen when the last reference is put anymore. This means, we need to remove it in error path in gpiochip_add_data_with_key() unconditionally, without checking if the device's .release() callback is set. Fixes: 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-05gpio: gpiolib: make gpio_bus_type constRicardo B. Marliere
Now that the driver core can properly handle constant struct bus_type, move the gpio_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-29gpio: unexport GPIO irq domain functions only used internallyBartosz Golaszewski
There are no external users for the irq domain helpers so unexport them and remove the prototypes from the driver header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-17gpiolib: revert the attempt to protect the GPIO device list with an rwsemBartosz Golaszewski
This reverts commits 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") and 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices"). Unfortunately the legacy GPIO API that's still used in older code has to translate numbers from the global GPIO numberspace to descriptors. This results in a GPIO device lookup in every call to legacy functions. Some of those functions - like gpio_set/get_value() - can be called from atomic context so taking a sleeping lock that is an RW semaphore results in an error. We'll probably have to protect this list with SRCU. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-wireless/f7b5ff1e-8f34-4d98-a7be-b826cb897dc8@moroto.mountain/ Fixes: 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") Fixes: 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-04gpiolib: replace the GPIO device mutex with a read-write semaphoreBartosz Golaszewski
There are only two spots where we modify (add to or remove objects from) the GPIO device list. Readers should be able to access it concurrently. Replace the mutex with a read-write semaphore and adjust the locking operations accordingly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2024-01-04gpiolib: remove the GPIO device from the list when it's unregisteredBartosz Golaszewski
If we wait until the GPIO device's .release() callback gets invoked before we remove it from the global device list, then we risk that someone will look it up using gpio_device_find() between where we dropped the last reference and before .release() is done taking a reference again to an object that's being released. The device must be removed when it's being unregistered - just like how we remove it from the GPIO bus. Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-12-27gpiolib: drop tabs from local variable declarationsBartosz Golaszewski
Older code has an annoying habit of putting tabs between the type and the name of the variable. This doesn't really add to readability and newer code doesn't do it so make the entire file consistent. While at it: convert 'unsigned' to 'unsigned int'. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-12-27gpiolib: remove extra_checksBartosz Golaszewski
extra_checks is only used in a few places. It also depends on a non-standard DEBUG define one needs to add to the source file. The overhead of removing it should be minimal (we already use pure might_sleep() in the code anyway) so drop it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-12-19gpiolib: remove debounce_period_us from struct gpio_descKent Gibson
cdev is the only user of the debounce_period_us field in struct gpio_desc, and it no longer uses it, so remove it. Signed-off-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-12-18gpiolib: use a mutex to protect the list of GPIO devicesBartosz Golaszewski
The global list of GPIO devices is never modified or accessed from atomic context so it's fine to protect it using a mutex. Add a new global lock dedicated to the gpio_devices list and use it whenever accessing or modifying it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-12-18gpiolib: rename static functions that are called with the lock takenBartosz Golaszewski
Rename two functions that read or modify the global GPIO device list but don't take the lock themselves (and need to be called with it already acquired). Use the _unlocked() suffix which seems to be used quite consistently across the kernel despite there also existing the _locked() suffix for the same purpose. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-12-15gpiolib: allocate memory atomically with a spinlock heldBartosz Golaszewski
We will eventually switch to protecting the GPIO descriptors with a mutex but until then, we need to allocate memory for the label copy atomically while we're holding the global spinlock. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-gpio/62588146-eed6-42f7-ba26-160226b109fe@moroto.mountain/T/#u Fixes: f8d05e276b45 ("gpiolib: remove gpiochip_is_requested()") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-12-08Merge tag 'gpio-remove-gpiochip_is_requested-for-v6.8-rc1' into gpio/for-nextBartosz Golaszewski
gpio: remove gpiochip_is_requested() - provide a safer alternative to gpiochip_is_requested() - convert all existing users - remove gpiochip_is_requested()
2023-12-08gpiolib: remove gpiochip_is_requested()Bartosz Golaszewski
We have no external users of gpiochip_is_requested(). Let's remove it and replace its internal calls with direct testing of the REQUESTED flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-12-08gpiolib: provide gpiochip_dup_line_label()Bartosz Golaszewski
gpiochip_is_requested() not only has a misleading name but it returns a pointer to a string that is freed when the descriptor is released. Provide a new helper meant to replace it, which returns a copy of the label string instead. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-11-24gpiolib: provide gpio_device_get_label()Bartosz Golaszewski
Provide a getter for the GPIO device label string so that users don't have to dereference struct gpio_chip directly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-11-04treewide: rename pinctrl_gpio_set_config_new()Bartosz Golaszewski
Now that pinctrl_gpio_set_config() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-11-04treewide: rename pinctrl_gpio_free_new()Bartosz Golaszewski
Now that pinctrl_gpio_free()() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-11-04treewide: rename pinctrl_gpio_request_new()Bartosz Golaszewski
Now that pinctrl_gpio_request() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-11-04gpiolib: generic: use new pinctrl GPIO helpersBartosz Golaszewski
Replace the pinctrl helpers taking the global GPIO number as argument with the improved variants that instead take a pointer to the GPIO chip and the controller-relative offset. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-11-04gpiolib: remove gpiochip_find()Bartosz Golaszewski
With all users of gpiochip_find() converted to using gpio_device_find(), we can now remove this function from the kernel. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-13gpiolib: provide gpio_device_get_base()Bartosz Golaszewski
Let's start adding getters for the opaque struct gpio_device. Start with a function allowing to retrieve the base GPIO number. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-13gpiolib: provide gpiod_to_gpio_device()Bartosz Golaszewski
Accessing struct gpio_chip backing a GPIO device is only allowed for the actual providers of that chip. Similarly to how we introduced gpio_device_find() in order to replace the abused gpiochip_find(), let's introduce a counterpart to gpiod_to_chip() that returns a reference to the GPIO device owning the descriptor. This is done in order to later remove gpiod_to_chip() entirely. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-13gpiolib: provide gpio_device_to_device()Bartosz Golaszewski
There are users in the kernel who need to retrieve the address of the struct device backing the GPIO device. Currently they needlessly poke in the internals of GPIOLIB. Add a dedicated getter function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-12gpiolib: provide gpio_device_find_by_fwnode()Andy Shevchenko
One of the ways of looking up GPIO devices is using their fwnode. Provide a helper for that to avoid every user implementing their own matching function. Reviewed-by: Dipen Patel <dipenp@nvidia.com> Tested-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231010151709.4104747-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-10-04gpiolib: replace find_chip_by_name() with gpio_device_find_by_label()Bartosz Golaszewski
Remove all remaining uses of find_chip_by_name() (and subsequently: gpiochip_find()) from gpiolib.c and use the new gpio_device_find_by_label() instead. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-04gpiolib: reluctantly provide gpio_device_get_chip()Bartosz Golaszewski
The process of converting all unauthorized users of struct gpio_chip to using dedicated struct gpio_device function will be long so in the meantime we must provide a way of retrieving the pointer to struct gpio_chip from a GPIO device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-04gpiolib: provide gpio_device_get_desc()Bartosz Golaszewski
Getting the GPIO descriptor directly from the gpio_chip struct is dangerous as we don't take the reference to the underlying GPIO device. In order to start working towards removing gpiochip_get_desc(), let's provide a safer variant that works with an existing reference to struct gpio_device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-04gpiolib: provide gpio_device_find_by_label()Bartosz Golaszewski
By far the most common way of looking up GPIO devices is using their label. Provide a helpers for that to avoid every user implementing their own matching function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-04gpiolib: provide gpio_device_find()Bartosz Golaszewski
gpiochip_find() is wrong and its kernel doc is misleading as the function doesn't return a reference to the gpio_chip but just a raw pointer. The chip itself is not guaranteed to stay alive, in fact it can be deleted at any point. Also: other than GPIO drivers themselves, nobody else has any business accessing gpio_chip structs. Provide a new gpio_device_find() function that returns a real reference to the opaque gpio_device structure that is guaranteed to stay alive for as long as there are active users of it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-10-04gpiolib: make gpio_device_get() and gpio_device_put() publicBartosz Golaszewski
In order to start migrating away from accessing struct gpio_chip by users other than their owners, let's first make the reference management functions for the opaque struct gpio_device public in the driver.h header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-10-02gpiolib: extend the critical sections of lookup tablesBartosz Golaszewski
There are two places in the code where we retrieve a lookup table using gpiod_find_lookup_table() (which protects the table list with the lookup table lock) and then use it after the lock is released. We need to keep the lookup table mutex locked the entire time we're using the tables. Remove the locking from gpiod_find_lookup_table() and use guards to protect the code actually using the table objects. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-09-11gpiolib: unexport gpiod_set_transitory()Bartosz Golaszewski
There are no and never have been any users of gpiod_set_transitory() outside the core GPIOLIB code. Make it private. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-29Merge tag 'gpio-updates-for-v6.6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "We have a lot of code refactoring using common helpers and ended up removing more lines then we're adding this release cycle. Nothing really stands out, just small updates all over the place. Core GPIOLIB updates: - wake-up poll() in user-space on device unbind - improve fwnode usage - interrupt domain handling improvements - correctly handle the ngpios property in gpio-mmio Driver cleanups: - remove unneeded calls to platform_set_drvdata() all around the place - remove unneeded of_match_ptr() expansions whenever a driver depends on CONFIG_OF - remove redundant calls to dev_err_probe() from gpio-omap and gpio-davinci Driver improvements: - use autopointers and guards from cleanup.h in gpio-sim - shrink code in gpio-sim using some common helpers - convert the idio family of drivers to using gpio-regmap - convert gpio-ws16c48 to using gpio-regmap - use devres to simplify code in gpio-pisosr and gpio-mxc - update gpio-sifive: support IRQ wake, improve interrupt handling, allow building as module - make gpio-ge and gpio-bcm-kona OF-independent (plus some minor tweaks) - add support for new models in gpio-pca953x and gpio-ds4520 - add runtime PM support to gpio-mxc - fix a build warning in gpio-mxs - add support for adding pin ranges to gpio-mlxbf3 - add counter/timer support to gpio-104-dio-48e - switch to dynamic GPIO base allocation in gpio-vf610 - minor oneliners here and there Device-tree bindings updates: - enable the gpio-line-names property in snps,dw-apb and STMPE GPIO - document new models in fsl-imx-gpio, ds4520 and pca95xx - convert the bindings for brcm,kona-gpio to YAML" * tag 'gpio-updates-for-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (94 commits) gpio: pca953x: add support for TCA9538 dt-bindings: gpio: pca95xx: document new tca9538 chip gpio: pca953x: Use i2c_get_match_data() gpio: mlxbf3: use capital "OR" for multiple licenses in SPDX gpio: pcf857x: Extend match data support for OF tables gpio: vf610: switch to dynamic allocat GPIO base gpiolib: provide and use gpiod_line_state_notify() gpio: cdev: wake up lineevent poll() on device unbind gpio: cdev: wake up linereq poll() on device unbind gpio: cdev: wake up chardev poll() on device unbind gpiolib: add a second blocking notifier to struct gpio_device gpio: cdev: open-code to_gpio_chardev_data() gpiolib: rename the gpio_device notifier gpio: mlxbf3: Support add_pin_ranges() gpio: mxc: Use helper function devm_clk_get_optional_enabled() gpio: pca9570: fix kerneldoc gpio: sim: simplify code with cleanup helpers gpio: sim: replace memmove() + strstrip() with skip_spaces() + strim() gpio: sim: simplify gpio_sim_device_config_live_store() gpio: mxc: release the parent IRQ in runtime suspend ...
2023-08-22gpiolib: provide and use gpiod_line_state_notify()Bartosz Golaszewski
Wrap the calls to blocking_notifier_call_chain() for the line state notifier with a helper that allows us to use fewer lines of code and simpler syntax. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-08-21gpiolib: add a second blocking notifier to struct gpio_deviceBartosz Golaszewski
Add a new blocking notifier to struct gpio_device and use it to notify subscribers about the GPIO device being unregistered from the device model. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
2023-08-21gpiolib: rename the gpio_device notifierBartosz Golaszewski
Change the generic "notifier" name to "line_state_notifier" in order to reflect its purpose in preparation for adding a second notifier which will be used to notify wait queues about device unregistering. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
2023-08-16gpiolib: fix reference leaks when removing GPIO chips still in useBartosz Golaszewski
After we remove a GPIO chip that still has some requested descriptors, gpiod_free_commit() will fail and we will never put the references to the GPIO device and the owning module in gpiod_free(). Rework this function to: - not warn on desc == NULL as this is a use-case on which most free functions silently return - put the references to desc->gdev and desc->gdev->owner unconditionally so that the release callback actually gets called when the remaining references are dropped by external GPIO users Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-07-18gpio: mmio: handle "ngpios" properly in bgpio_init()Asmaa Mnebhi
bgpio_init() uses "sz" argument to populate ngpio, which is not accurate. Instead, read the "ngpios" property from the DT and if it doesn't exist, use the "sz" argument. With this change, drivers no longer need to overwrite the ngpio variable after calling bgpio_init(). If the "ngpios" property is specified, bgpio_bits is calculated as the round up value of ngpio. At the moment, the only requirement specified is that the round up value must be a multiple of 8 but it should also be a power of 2 because we provide accessors based on the bank size in bgpio_setup_accessors(). Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>