aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpiolib.c
Commit message (Collapse)AuthorAgeFilesLines
* gpiolib: Allow to use setters with return value for output-only gpiosMathieu Dubois-Briand2025-04-141-1/+1
| | | | | | | | | | | | The gpiod_direction_output_raw_commit() function checks if any setter callback is present before doing anything. As the new GPIO setters with return values were introduced, make this check also succeed if one is present. Fixes: 98ce1eb1fd87 ("gpiolib: introduce gpio_chip setters that return values") Signed-off-by: Mathieu Dubois-Briand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'v6.14-rc7' of ↵Bartosz Golaszewski2025-03-171-3/+5
|\ | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc7
| * gpio: cdev: use raw notifier for line state eventsBartosz Golaszewski2025-03-131-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Tested-by: David Jander <[email protected]> Tested-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/20250311-gpiolib-line-state-raw-notifier-v2-1-138374581e1e@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: don't check the retval of get_direction() when registering a chipBartosz Golaszewski2025-03-131-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During chip registration we should neither check the return value of gc->get_direction() nor hold the SRCU lock when calling it. The former is because pin controllers may have pins set to alternate functions and return errors from their get_direction() callbacks. That's alright - we should default to the safe INPUT state and not bail-out. The latter is not needed because we haven't registered the chip yet so there's nothing to protect against dynamic removal. In fact: we currently hit a lockdep splat. Revert to calling the gc->get_direction() callback directly and *not* checking its value. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Marek Szyprowski <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Andy Shevchenko <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Gene C <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: Hide valid_mask from direct assignmentsMatti Vaittinen2025-03-051-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/4547ca90d910d60cab3d56d864d59ddde47a5e93.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: Add a valid_mask getterMatti Vaittinen2025-03-051-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. It shouldn't be directly populated by drivers. This can be prevented by moving it from the struct gpio_chip to struct gpio_device, which is internal to the GPIO core. As a preparatory step, provide a getter function which can be used by those drivers which need the valid_mask information. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/026f9d78502eca883bfe3faeb684e23d5d6c5e84.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: Respect valid_mask when requesting GPIOsMatti Vaittinen2025-03-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When GPIOs were requested the validity of GPIOs were checked only when the GPIO-chip had the request -callback populated. This made using masked GPIOs possible. The GPIO chip driver authors may find it difficult to understand the relation of enforsing the GPIO validity and the 'request' -callback because the current documentation for the 'request' callback does not mention this. It only states: * @request: optional hook for chip-specific activation, such as * enabling module power and clock; may sleep The validity of the GPIO line should be checked whether the driver provides the 'request' callback or not. Unconditionally check the GPIO validity when GPIO is being requested. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/cd5e067b80e1bb590027bc3bfa817e7f794f21c3.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: update kerneldocs for value settersBartosz Golaszewski2025-03-031-0/+15
| | | | | | | | | | | | | | | | Value setters now return int and can indicate failure. Update the kerneldocs. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: remove unneeded WARN_ON() from gpiochip_set_multiple()Bartosz Golaszewski2025-03-031-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | GPIO drivers are not required to support set_multiple() - the core will fallback to calling set() for each line if it's missing. Remove the offending check from gpiochip_set_multiple(). Fixes: 98ce1eb1fd87 ("gpiolib: introduce gpio_chip setters that return values") Reported-by: Marek Szyprowski <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | Merge tag 'v6.14-rc5' of ↵Bartosz Golaszewski2025-03-031-10/+10
|\| | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc5
| * gpiolib: Fix Oops in gpiod_direction_input_nonotify()Dan Carpenter2025-02-281-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpiod_direction_input_nonotify() function is supposed to return zero if the direction for the pin is input. But instead it accidentally returns GPIO_LINE_DIRECTION_IN (1) which will be cast into an ERR_PTR() in gpiochip_request_own_desc(). The callers dereference it and it leads to a crash. I changed gpiod_direction_output_raw_commit() just for consistency but returning GPIO_LINE_DIRECTION_OUT (0) is fine. Cc: [email protected] Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Bartosz: moved the variable declarations to the top of the functions] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: don't double-check the gc->get callback's existenceBartosz Golaszewski2025-02-271-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | gpiochip_get() is called only in two places: in gpio_chip_get_value() and in gpiochip_get_multiple() where the existence of the gc->get() callback is already checked. It makes sense to unduplicate the check by moving it one level up the stack. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Suggested-by: Andy Shevchenko <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: use a more explicit retval logic in gpiochip_get_direction()Bartosz Golaszewski2025-02-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have existing macros for direction settings so we don't need to rely on the magic value of 1 in the retval check. Use readable logic that explicitly says we expect INPUT, OUTPUT or a negative errno and nothing else in gpiochip_get_direction(). Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Suggested-by: Andy Shevchenko <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: don't use gpiochip_get_direction() when registering a chipBartosz Golaszewski2025-02-271-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During chip registration we should neither check the return value of gc->get_direction() nor hold the SRCU lock when calling it. The former is because pin controllers may have pins set to alternate functions and return errors from their get_direction() callbacks. That's alright - we should default to the safe INPUT state and not bail-out. The latter is not needed because we haven't registered the chip yet so there's nothing to protect against dynamic removal. In fact: we currently hit a lockdep splat. Revert to calling the gc->get_direction() callback directly and *not* checking its value. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Reported-by: Marek Szyprowski <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Andy Shevchenko <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: introduce gpio_chip setters that return valuesBartosz Golaszewski2025-02-261-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new variants of the set() and set_multiple() callbacks that have integer return values allowing to indicate failures to users of the GPIO consumer API. Until we convert all GPIO providers treewide to using them, they will live in parallel to the existing ones. Make sure that providers cannot define both. Prefer the new ones and only use the old ones as fallback. Reviewed-by: Linus Walleij <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: rework the wrapper around gpio_chip::set_multiple()Bartosz Golaszewski2025-02-261-11/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the existing wrapper around gpio_chip::set_multiple() consistent with the one for gpio_chip::set(): make it return int, add a lockdep assertion, warn on missing set callback and move the code a bit for better readability. Add return value checks in all call places. Reviewed-by: Linus Walleij <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: wrap gpio_chip::set()Bartosz Golaszewski2025-02-261-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | We have three places where we dereference the gpio_chip::set() callback. In order to make it easier to incorporate the upcoming new variant of this callback (one returning an integer value), wrap it in a helper so that the dereferencing only happens once. Reviewed-by: Linus Walleij <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: make value setters have return valuesBartosz Golaszewski2025-02-261-23/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the in-kernel consumer interface for GPIOs: make all variants of value setters that don't have a return value, return a signed integer instead. That will allow these routines to indicate failures to callers. This doesn't change the implementation just yet, we'll do it in subsequent commits. We need to update the gpio-latch module as it passes the address of value setters as a function pointer argument and thus cares about its type. Reviewed-by: Linus Walleij <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: read descriptor flags once in gpiolib_dbg_show()Bartosz Golaszewski2025-02-241-4/+6
| | | | | | | | | | | | | | | | | | | | For consistency with most other code that can access requested descriptors: read the flags once atomically and then test individual bits from the helper variable. This avoids any potential discrepancies should flags change during the debug print. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::get_direction()Bartosz Golaszewski2025-02-241-6/+21
| | | | | | | | | | | | | | | | | | | | As per the API contract, the get_direction() callback can only return 0, 1 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::direction_input()Bartosz Golaszewski2025-02-241-4/+20
| | | | | | | | | | | | | | | | | | | | | | The return value of the direction_input() callback may be propagated to user-space. As per the API contract it can only return 0 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::direction_output()Bartosz Golaszewski2025-02-241-4/+21
| | | | | | | | | | | | | | | | | | | | | | The return value of the direction_output() callback may be propagated to user-space. As per the API contract it can only return 0 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::get_multiple()Bartosz Golaszewski2025-02-241-2/+8
| | | | | | | | | | | | | | | | | | As per the API contract, the get_multiple() callback is only allowed to return 0 or a negative error number. Filter out anything else. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::get()Bartosz Golaszewski2025-02-241-2/+18
| | | | | | | | | | | | | | | | | | | | As per the API contract, the get() callback is only allowed to return 0, 1 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::set_config()Bartosz Golaszewski2025-02-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | The return value of the set_config() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: sanitize the return value of gpio_chip::request()Bartosz Golaszewski2025-02-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | The return value of the request() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | Merge tag 'v6.14-rc4' of ↵Bartosz Golaszewski2025-02-241-33/+73
|\| | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into HEAD Linux 6.14-rc4
| * gpiolib: don't bail out if get_direction() fails in gpiochip_add_data()Bartosz Golaszewski2025-02-201-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") we check the return value of the get_direction() callback as per its API contract. Some drivers have been observed to fail to register now as they may call get_direction() in gpiochip_add_data() in contexts where it has always silently failed. Until we audit all drivers, replace the bail-out to a kernel log warning. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Mark Brown <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reported-by: Marek Szyprowski <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Tested-by: Mark Brown <[email protected]> Reviewed-by: Mark Brown <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: protect gpio_chip with SRCU in array_info paths in multi get/setBartosz Golaszewski2025-02-181-15/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: check the return value of gpio_chip::get_direction()Bartosz Golaszewski2025-02-171-15/+29
| | | | | | | | | | | | | | | | | | | | | | | | As per the API contract - gpio_chip::get_direction() may fail and return a negative error number. However, we treat it as if it always returned 0 or 1. Check the return value of the callback and propagate the error number up the stack. Cc: [email protected] Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: Fix crash on error in gpiochip_get_ngpios()Andy Shevchenko2025-02-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpiochip_get_ngpios() uses chip_*() macros to print messages. However these macros rely on gpiodev to be initialised and set, which is not the case when called via bgpio_init(). In such a case the printing messages will crash on NULL pointer dereference. Replace chip_*() macros by the respective dev_*() ones to avoid such crash. Fixes: 55b2395e4e92 ("gpio: mmio: handle "ngpios" properly in bgpio_init()") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Use fwnode instead of device in gpiochip_get_ngpios()Andy Shevchenko2025-02-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The gpiochip_get_ngpios() can be used in the cases where passed device is not a provider of the certain property. Use fwnode instead. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Tested-by: Mathieu Dubois-Briand <[email protected]> Reviewed-by: Mathieu Dubois-Briand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Extract gpiochip_choose_fwnode() for wider useAndy Shevchenko2025-02-211-8/+16
| | | | | | | | | | | | | | | | | | | | | | Extract gpiochip_choose_fwnode() for the future use in another function. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Tested-by: Mathieu Dubois-Briand <[email protected]> Reviewed-by: Mathieu Dubois-Briand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: don't build HTE code with CONFIG_HTE disabledBartosz Golaszewski2025-02-181-0/+2
| | | | | | | | | | | | | | | | | | | | Hardware timestamping is only used on tegra186 platforms but we include the code and export the symbols everywhere. Shrink the binary a bit by compiling the relevant functions conditionally. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Deduplicate gpiod_direction_input_nonotify() callAndy Shevchenko2025-02-121-9/+7
| | | | | | | | | | | | | | | | | | | | | | Deduplicate gpiod_direction_input_nonotify() call in gpiod_direction_output_nonotify() when emulating open-drain or open-source behaviour. It also aligns the error check approaches in set_output_value and set_output_flag labels. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Even more opportunities to use str_high_low() helperAndy Shevchenko2025-02-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | The one of previous changes modified the library code to use helpers from string_choices.h. Nevertheless it misses more opportunities to convert the code. Here is the second part of the conversion. Cc: Krzysztof Kozlowski <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: Use str_enable_disable-like helpersKrzysztof Kozlowski2025-02-031-1/+2
|/ | | | | | | | | | | | | | | | | | | | Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Doug Berger <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: clean up debugfs separator handlingJohan Hovold2024-11-041-6/+6
| | | | | | | | | Add the newline separator before generating the gpio chip entry to make the code easier to read. Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'v6.12-rc6' of ↵Bartosz Golaszewski2024-11-041-1/+3
|\ | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.12-rc6
| * gpiolib: fix debugfs dangling chip separatorJohan Hovold2024-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add the missing newline after entries for recently removed gpio chips so that the chip sections are separated by a newline as intended. Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU") Cc: [email protected] # 6.9 Cc: Bartosz Golaszewski <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: fix debugfs newline separatorsJohan Hovold2024-10-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpiolib debugfs interface exports a list of all gpio chips in a system and the state of their pins. The gpio chip sections are supposed to be separated by a newline character, but a long-standing bug prevents the separator from being included when output is generated in multiple sessions, making the output inconsistent and hard to read. Make sure to only suppress the newline separator at the beginning of the file as intended. Fixes: f9c4a31f6150 ("gpiolib: Use seq_file's iterator interface") Cc: [email protected] # 3.7 Cc: Thierry Reding <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: remove leftover spinlock bitsBartosz Golaszewski2024-10-311-6/+0
| | | | | | | | | | | | | | | | We no longer use any spinlocks in gpiolib.c. Stop including linux/spinlock.h and remove an outdated comment. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: fix a NULL-pointer dereference when setting directionBartosz Golaszewski2024-10-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For optional GPIOs we may pass NULL to gpiod_direction_(input|output)(). With the call to the notifier chain added by commit 07c61d4da43f ("gpiolib: notify user-space about in-kernel line state changes") we will now dereference a NULL pointer in this case. The reason for that is the fact that the expansion of the VALIDATE_DESC() macro (which returns 0 for NULL descriptors) was moved into the nonotify variants of the direction setters. Move them back to the top-level interfaces as the nonotify ones are only ever called from inside the GPIO core and are always passed valid GPIO descriptors. This way we'll never call the line_state notifier chain with non-valid descs. Fixes: 07c61d4da43f ("gpiolib: notify user-space about in-kernel line state changes") Reported-by: Mark Brown <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Tested-by: Klara Modin <[email protected]> Tested-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: notify user-space about in-kernel line state changesBartosz Golaszewski2024-10-221-13/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-8-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: switch the line state notifier to atomicBartosz Golaszewski2024-10-221-3/+3
| | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-7-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: cdev: go back to storing debounce period in the GPIO descriptorBartosz Golaszewski2024-10-221-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-3-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: unduplicate chip guard in set_config pathBartosz Golaszewski2024-10-221-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need to guard the GPIO chip until its first dereference in gpio_do_set_config(). First: change the prototype of gpio_do_set_config() to take the GPIO line descriptor as argument, then move the gpio_chip protection into it and drop it in two places where it's done too early. This has the added benefit of making gpio_go_set_config() safe to use from outside of this compilation unit without taking the gdev SRCU read lock and will come in handy when we'll want to make it available to the character device code. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-2-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: notify user-space when a driver requests its own descBartosz Golaszewski2024-10-221-0/+2
| | | | | | | | | | | | | | | | | | | | We notify user-space about lines being requested from user-space or by drivers calling gpiod_get() but not when drivers request their own lines so add the missing call to gpiod_line_state_notify(). Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-1-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | Merge tag 'v6.12-rc3' of ↵Bartosz Golaszewski2024-10-141-2/+2
|\| | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.12-rc3
| * gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()Lad Prabhakar2024-10-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`. Fixes: 5a646e03e956 ("gpiolib: Return label, if set, for IRQ only line") Fixes: a86d27693066 ("gpiolib: fix the speed of descriptor label setting with SRCU") Signed-off-by: Lad Prabhakar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-03 11:20:38 +0000