summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib.h
AgeCommit message (Collapse)AuthorFilesLines
2026-03-16gpio: move hogs into GPIO coreBartosz Golaszewski1-0/+3
Refactor line hogging code by moving the parts duplicated in gpiolib-acpi-core.c and gpiolib-of.c into gpiolib.c, leaving just the OF-specific bits in the latter. This makes fwnode the primary API for setting up hogs and allows to use software nodes in addition to ACPI and OF nodes. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260309-gpio-hog-fwnode-v2-2-4e61f3dbf06a@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-02-23gpiolib: replace snprintf("%s") with strscpyThorsten Blum1-1/+2
Replace snprintf("%s", ...) with strscpy() for direct string copying. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260222170327.281576-2-thorsten.blum@linux.dev Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-21gpio: shared: propagate configuration to pinctrlBartosz Golaszewski1-0/+2
Just toggling the descriptor's "requested" flag is not enough. We need to properly request it in order to potentially propagate any configuration to pinctrl via the .request() callback. We must not take the reference to the device at this point (the device is not ready but we're also requesting the device's own descriptor) so make the _commit() variants of request and free functions available to GPIO core in order to use them instead of their regular counterparts. This fixes an audio issue reported on one of the Qualcomm platforms. Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120154913.61991-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2025-11-17Merge tag 'gpio/shared-gpios-for-v6.19-rc1' of ↵Bartosz Golaszewski1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git into gpio/for-next Immutable branch between the GPIO, ASoC and regulator trees for v6.19-rc1 Add better support for GPIOs shared by multiple consumers.
2025-11-17gpio: provide gpiod_is_shared()Bartosz Golaszewski1-0/+1
Provide an interface allowing consumers to check if a GPIO descriptor represents a GPIO that can potentially be shared by multiple consumers at the same time. This is exposed to allow subsystems that already work around the limitations of the current non-exclusive GPIO handling in some ways, to gradually convert to relying on the new shared GPIO feature of GPIOLIB. Extend the gpiolib-shared module to mark the GPIO shared proxy descriptors with a flag checked by the new interface. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-6-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: define GPIOD_FLAG_SHAREDBartosz Golaszewski1-0/+1
Define a new GPIO descriptor flag for marking pins that are shared by multiple consumer. This flag will be used in several places so we need to do it in advance and separately from other changes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-2-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-21gpio: export gpiod_hwgpio()Bartosz Golaszewski1-8/+0
Reading the GPIO hardware number from a descriptor is a valid use-case outside of the GPIO core. Export the symbol to consumers of GPIO descriptors. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-2-31201c06d124@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-21gpio: rename gpio_chip_hwgpio() to gpiod_hwgpio()Bartosz Golaszewski1-1/+1
This function takes a GPIO descriptor as first argument. Make its naming consistent with the rest of the GPIO codebase and use the gpiod_ prefix. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-1-31201c06d124@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-13gpiolib: reuse macro code in GPIO chip printk helpersBartosz Golaszewski1-8/+9
The arguments passed to dev_$level() macros are duplicated across the gpiochip_$level() macros so put them under an intermediate wrapper. While at it: wrap it in a do-while guard. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-13gpiolib: reuse macro code in GPIO descriptor printk helpersBartosz Golaszewski1-18/+6
A lot of code in gpiod_$level() macros is duplicated across all definitions. Create an intermediate macro which allows us to reuse the low-level code. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-13gpiolib: rename GPIO chip printk macrosBartosz Golaszewski1-4/+4
The chip_$level() macros take struct gpio_chip as argument so make it follow the convention of using the 'gpiochip_' prefix. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-09-12gpiolib: add a common prefix to GPIO descriptor flagsBartosz Golaszewski1-18/+18
While these flags are private within drivers/gpio/, when looking at the code, it's not really clear they are GPIO-specific. Since these are GPIO descriptor flags, prepend their names with a common "GPIOD" prefix. While at it: update the flags' docs: make spelling consistent, correct outdated information, etc. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250909-rename-gpio-flags-v1-1-bda208a40856@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-06-20gpio: sysfs: remove the mockdev pointer from struct gpio_deviceBartosz Golaszewski1-3/+0
The usage of the mockdev pointer in struct gpio_device is limited to the GPIO sysfs code. There's no reason to keep it in this top-level structure. Create a separate structure containing the reference to the GPIO device and the dummy class device that will be passed to device_create_with_groups(). The !gdev->mockdev checks can be removed as long as we make sure that all operations on the GPIO class are protected with the sysfs lock. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250610-gpio-sysfs-chip-export-v1-6-a8c7aa4478b1@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-17Merge tag 'v6.14-rc7' of ↵Bartosz Golaszewski1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc7
2025-03-13gpio: cdev: use raw notifier for line state eventsBartosz Golaszewski1-1/+4
We use a notifier to implement the mechanism of informing the user-space about changes in GPIO line status. We register with the notifier when the GPIO character device file is opened and unregister when the last reference to the associated file descriptor is dropped. Since commit fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") we use the atomic notifier variant. Atomic notifiers call rcu_synchronize in atomic_notifier_chain_unregister() which caused a significant performance regression in some circumstances, observed by user-space when calling close() on the GPIO device file descriptor. Replace the atomic notifier with the raw variant and provide synchronization with a read-write spinlock. Fixes: fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") Reported-by: David Jander <david@protonic.nl> Closes: https://lore.kernel.org/all/20250311110034.53959031@erd003.prtnl/ Tested-by: David Jander <david@protonic.nl> Tested-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20250311-gpiolib-line-state-raw-notifier-v2-1-138374581e1e@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: Hide valid_mask from direct assignmentsMatti Vaittinen1-0/+3
The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. Current documentation does not mention this but just says the valid_mask is used if it's not NULL. This lured me to try populating it directly in the GPIO driver probe instead of using the init_valid_mask() callback. It took some retries with different bitmaps and eventually a bit of code-reading to understand why the valid_mask was not obeyed. I could've avoided this trial and error if the valid_mask was hidden in the struct gpio_device instead of being a visible member of the struct gpio_chip. Help the next developer who decides to directly populate the valid_mask in struct gpio_chip by hiding the valid_mask in struct gpio_device and keep it internal to the GPIO core. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/4547ca90d910d60cab3d56d864d59ddde47a5e93.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-04gpiolib: Align FLAG_* definitions in the struct gpio_descAndy Shevchenko1-18/+18
Align FLAG_* definitions in the struct gpio_desc for better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250303160341.1322640-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-18gpiolib: protect gpio_chip with SRCU in array_info paths in multi get/setBartosz Golaszewski1-2/+2
During the locking rework in GPIOLIB, we omitted one important use-case, namely: setting and getting values for GPIO descriptor arrays with array_info present. This patch does two things: first it makes struct gpio_array store the address of the underlying GPIO device and not chip. Next: it protects the chip with SRCU from removal in gpiod_get_array_value_complex() and gpiod_set_array_value_complex(). Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250215095655.23152-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-22gpiolib: notify user-space about in-kernel line state changesBartosz Golaszewski1-0/+3
We currently only notify user-space about line config changes that are made from user-space. Any kernel config changes are not signalled. Let's improve the situation by emitting the events closer to the source. To that end let's call the relevant notifier chain from the functions setting direction, gpiod_set_config(), gpiod_set_consumer_name() and gpiod_toggle_active_low(). This covers all the options that we can inform the user-space about. We ignore events which don't have corresponding flags exported to user-space on purpose - otherwise the user would see a config-changed event but the associated line-info would remain unchanged. gpiod_direction_output/input() can be called from any context. Fortunately, we now emit line state events using an atomic notifier chain, so it's no longer an issue. Let's also add non-notifying wrappers around the direction setters in order to not emit superfluous reconfigure events when requesting the lines as the initial config should be part of the request notification. Use gpio_do_set_config() instead of gpiod_set_debounce() for configuring debouncing via hardware from the character device code to avoid multiple reconfigure events. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-8-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-22gpiolib: switch the line state notifier to atomicBartosz Golaszewski1-1/+1
With everything else ready, we can now switch to using the atomic notifier for line state events which will allow us to notify user-space about direction changes from atomic context. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-7-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-22gpiolib: add a per-gpio_device line state notification workqueueBartosz Golaszewski1-0/+4
In order to prepare the line state notification mechanism for working in atomic context as well, add a dedicated, high-priority, ordered workqueue to GPIO device which will be used to queue the events fron any context for them to be emitted always in process context. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-5-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-22gpio: cdev: go back to storing debounce period in the GPIO descriptorBartosz Golaszewski1-0/+5
This effectively reverts commits 9344e34e7992 ("gpiolib: cdev: relocate debounce_period_us from struct gpio_desc") and d8543cbaf979 ("gpiolib: remove debounce_period_us from struct gpio_desc") and goes back to storing the debounce period in microseconds in the GPIO descriptor We're doing it in preparation for notifying the user-space about in-kernel line config changes. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-3-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-08-20gpiolib: Replace gpio_suffix_count with NULL-terminated arrayAndy Shevchenko1-6/+5
There is no need to have and export the count variable for the array in question. Instead, make it NULL-terminated. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240819142945.327808-6-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-08-20gpiolib: Introduce for_each_gpio_property_name() helperAndy Shevchenko1-0/+13
Introduce a helper macro for_each_gpio_property_name(). With that in place, update users. This, in particular, will help making the following simplifications easier. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240819142945.327808-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-02gpiolib: unexport gpiochip_get_desc()Bartosz Golaszewski1-0/+1
This function has been deprecated for some time and is now only used within the GPIOLIB core. Remove it from the public header and unexport it as all current users are linked against the compilation unit where it is defined. Link: https://lore.kernel.org/r/20240625073815.12376-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-06-14gpiolib: put gpio_suffixes in a single compilation unitBartosz Golaszewski1-1/+2
The gpio_suffixes array is defined in the gpiolib.h header. This means the array is stored in .rodata of every compilation unit that includes it. Put the definition for the array in gpiolib.c and export just the symbol in the header. We need the size of the array so expose it too. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20240612184821.58053-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-05-15Merge tag 'gpio-updates-for-v6.10-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski "This was a quiet release cycle for the GPIO tree and so this pull-request is relatively small. We have one new driver, some minor improvements to the GPIO core code and across several drivers, some DT and documentation updates but in general nothing stands out or is controversial. All changes have spent time in next with no reported issues (or ones that were quickly fixed). GPIO core: - remove more unused legacy interfaces (after converting the last remaining users to better alternatives) - update kerneldocs - improve error handling and log messages in GPIO ACPI code - remove dead code (always true checks) from GPIOLIB New drivers: - add a driver for Intel Granite Rapids-D vGPIO Driver improvements: - use -ENOTSUPP consistently in gpio-regmap and gpio-pcie-idio-24 - provide an ID table for gpio-cros-ec to avoid a driver name fallback check - add support for gpio-ranges for GPIO drivers supporting multiple GPIO banks - switch to using dynamic GPIO base in gpio-brcmstb - fix irq handling in gpio-npcm-sgpio - switch to memory mapped IO accessors in gpio-sch DT bindings: - add support for gpio-ranges to gpio-brcmstb - add support for a new model and the gpio-line-names property to gpio-mpfs Documentation: - replace leading tabs with spaces in code blocks - fix typos" * tag 'gpio-updates-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (30 commits) gpio: nuvoton: Fix sgpio irq handle error gpiolib: Discourage to use formatting strings in line names gpio: brcmstb: add support for gpio-ranges gpio: of: support gpio-ranges for multiple gpiochip devices dt-bindings: gpio: brcmstb: add gpio-ranges gpio: Add Intel Granite Rapids-D vGPIO driver gpio: brcmstb: Use dynamic GPIO base numbers gpiolib: acpi: Set label for IRQ only lines gpiolib: acpi: Add fwnode name to the GPIO interrupt label gpiolib: Get rid of never false gpio_is_valid() calls gpiolib: acpi: Pass con_id instead of property into acpi_dev_gpio_irq_get_by() gpiolib: acpi: Move acpi_can_fallback_to_crs() out of __acpi_find_gpio() gpiolib: acpi: Simplify error handling in __acpi_find_gpio() gpiolib: acpi: Extract __acpi_find_gpio() helper gpio: sch: Utilise temporary variable for struct device gpio: sch: Switch to memory mapped IO accessors gpio: regmap: Use -ENOTSUPP consistently gpio: pcie-idio-24: Use -ENOTSUPP consistently Documentation: gpio: Replace leading TABs by spaces in code blocks gpiolib: acpi: Check for errors first in acpi_find_gpio() ...
2024-05-09gpiolib: use a single SRCU struct for all GPIO descriptorsBartosz Golaszewski1-5/+5
We used a per-descriptor SRCU struct in order to not impose a wait with synchronize_srcu() for descriptor X on read-only operations of descriptor Y. Now that we no longer call synchronize_srcu() on descriptor label change but only when releasing descriptor resources, we can use a single SRCU structure for all GPIO descriptors in a given chip. Suggested-by: "Paul E. McKenney" <paulmck@kernel.org> Acked-by: "Paul E. McKenney" <paulmck@kernel.org> Link: https://lore.kernel.org/r/20240507172414.28513-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-05-07gpiolib: fix the speed of descriptor label setting with SRCUBartosz Golaszewski1-1/+6
Commit 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") caused a massive drop in performance of requesting GPIO lines due to the call to synchronize_srcu() on each label change. Rework the code to not wait until all read-only users are done with reading the label but instead atomically replace the label pointer and schedule its release after all read-only critical sections are done. To that end wrap the descriptor label in a struct that also contains the rcu_head struct required for deferring tasks using call_srcu() and stop using kstrdup_const() as we're required to allocate memory anyway. Just allocate enough for the label string and rcu_head in one go. Reported-by: Neil Armstrong <neil.armstrong@linaro.org> Closes: https://lore.kernel.org/linux-gpio/CAMRc=Mfig2oooDQYTqo23W3PXSdzhVO4p=G4+P8y1ppBOrkrJQ@mail.gmail.com/ Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Suggested-by: "Paul E. McKenney" <paulmck@kernel.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Acked-by: "Paul E. McKenney" <paulmck@kernel.org> Link: https://lore.kernel.org/r/20240507121346.16969-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-04-17gpiolib: Get rid of never false gpio_is_valid() callsAndy Shevchenko1-1/+1
In the cases when gpio_is_valid() is called with unsigned parameter the result is always true in the GPIO library code, hence the check for false won't ever be true. Get rid of such calls. While at it, move GPIO device base to be unsigned to clearly show it won't ever be negative. This requires a new definition for the maximum GPIO number in the system. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-27gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index()Stephen Boyd1-0/+8
This devm API takes a consumer device as an argument to setup the devm action, but throws it away when calling further into gpiolib. This leads to odd debug messages like this: (NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup Let's pass the consumer device down, by directly calling what fwnode_gpiod_get_index() calls but pass the device used for devm. This changes the message to look like this instead: gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup Note that callers of fwnode_gpiod_get_index() will still see the NULL device pointer debug message, but there's not much we can do about that because the API doesn't take a struct device. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-15gpio: use srcu_dereference() with SRCU-protected pointersBartosz Golaszewski1-1/+2
Lockdep with CONFIG_PROVE_RCU enabled reports false positives about suspicious rcu_dereference() usage. Let's silence it by using srcu_dereference() which is the correct helper with SRCU. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Paul E. McKenney <paulmck@kernel.org>
2024-02-12gpio: remove the RW semaphore from the GPIO deviceBartosz Golaszewski1-5/+0
With all accesses to gdev->chip being protected with SRCU, we can now remove the RW-semaphore specific to the character device which fulfilled the same role up to this point. 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 pointer to gpio_chip in gpio_device with SRCUBartosz Golaszewski1-1/+21
Ensure we cannot crash if the GPIO device gets unregistered (and the chip pointer set to NULL) during any of the API calls. To that end: wait for all users of gdev->chip to exit their read-only SRCU critical sections in gpiochip_remove(). For brevity: add a guard class which can be instantiated at the top of every function requiring read-only access to the chip pointer and use it in all API calls taking a GPIO descriptor as argument. In places where we only deal with the GPIO device - use regular guard() helpers and rcu_dereference() for chip access. Do the same in API calls taking a const pointer to gpio_desc. 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_deviceBartosz Golaszewski1-0/+2
Add the SRCU struct to GPIO device. It will be used to serialize access to the GPIO chip pointer. 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: add the can_sleep flag to struct gpio_deviceBartosz Golaszewski1-0/+3
Duplicating the can_sleep value in GPIO device will allow us to not needlessly dereference the chip pointer in several places and reduce the number of SRCU read-only critical sections. 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: remove gpio_lockBartosz Golaszewski1-2/+0
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 Golaszewski1-1/+0
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 Golaszewski1-10/+24
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 Golaszewski1-0/+3
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: provide and use gpiod_get_label()Bartosz Golaszewski1-0/+1
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: remove unused logging helpersBartosz Golaszewski1-13/+0
The general rule of the kernel is to not provide symbols that have no users upstream. Let's remove logging helpers that are not used anywhere. This will save us work later when we'll be modifying them to use the upcoming SRCU infrastructure. 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-01-17gpiolib: revert the attempt to protect the GPIO device list with an rwsemBartosz Golaszewski1-2/+0
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 Golaszewski1-1/+1
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>
2023-12-19gpiolib: remove debounce_period_us from struct gpio_descKent Gibson1-5/+0
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 Golaszewski1-0/+2
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-10-04gpiolib: make gpio_device_get() and gpio_device_put() publicBartosz Golaszewski1-10/+0
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-09-12gpiolib: make gpiochip_get_desc() publicBartosz Golaszewski1-2/+0
It makes sense for a GPIO driver to want to get its own descriptor without requesting it. After all, the driver knows that it'll still be valid. Let's move this helper to linux/gpio/driver.h. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-09-11gpiolib: unexport gpiod_set_transitory()Bartosz Golaszewski1-0/+2
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-22gpiolib: provide and use gpiod_line_state_notify()Bartosz Golaszewski1-0/+1
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>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-22 04:46:21 +0300