aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpiolib.c
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | 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: 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]>
* | | | | Merge remote-tracking UNTIL 24. Mar 2025saturneric2025-03-301-41/+78
|\ \ \ \ \ | | |_|_|/ | |/| | |
| * | | | 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]>
| * | | 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 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]>
* / fix: drivers patch make raspberry pi 5 work properlysaturneric2025-01-121-5/+18
|/
* 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]>
* | gpiolib: unify two loops initializing GPIO descriptorsBartosz Golaszewski2024-10-081-3/+2
| | | | | | | | | | | | | | | | | | | | | | We currently iterate over the descriptors owned by the GPIO device we're adding twice with the first loop just setting the gdev pointer. It's not used anywhere between this and the second loop so just drop the first one and move the assignment to the second. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/20241004-gpio-notify-in-kernel-events-v1-2-8ac29e1df4fe@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: use v2 defines for line state change eventsBartosz Golaszewski2024-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | We should only use v2 defines for line state change events. They will get tranlated to v1 if needed by gpio_v2_line_info_changed_to_v1(). This isn't really a functional change as they have the same values but let's do it for consistency. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/20241004-gpio-notify-in-kernel-events-v1-1-8ac29e1df4fe@linaro.org Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: free irqs that are still requested when the chip is being removedBartosz Golaszewski2024-09-301-0/+41
|/ | | | | | | | | | | | | | | | | | If we remove a GPIO chip that is also an interrupt controller with users not having freed some interrupts, we'll end up leaking resources as indicated by the following warning: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'gpio' As there's no way of notifying interrupt users about the irqchip going away and the interrupt subsystem is not plugged into the driver model and so not all cases can be handled by devlinks, we need to make sure to free all interrupts before the complete the removal of the provider. Reviewed-by: Herve Codina <[email protected]> Tested-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: Update the kernel documentation - add Return sectionsAndy Shevchenko2024-09-021-32/+125
| | | | | | | | | | | | | | | $ scripts/kernel-doc -v -none -Wall drivers/gpio/gpiolib* 2>&1 | grep -w warning | wc -l 67 Fix these by adding Return sections. While at it, make sure all of Return sections use the same style. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[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 IS_ERR_OR_NULL() helper functionHongbo Li2024-09-021-2/+2
| | | | | | | | | | | | Use the IS_ERR_OR_NULL() helper instead of open-coding a NULL and an error pointer checks to simplify the code and improve readability. No functional changes are intended. Signed-off-by: Hongbo Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: Replace gpio_suffix_count with NULL-terminated arrayAndy Shevchenko2024-08-201-2/+1
| | | | | | | | | 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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds2024-07-251-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 6.11-rc1. Lots of stuff in here, with not a huge diffstat, but apis are evolving which required lots of files to be touched. Highlights of the changes in here are: - platform remove callback api final fixups (Uwe took many releases to get here, finally!) - Rust bindings for basic firmware apis and initial driver-core interactions. It's not all that useful for a "write a whole driver in rust" type of thing, but the firmware bindings do help out the phy rust drivers, and the driver core bindings give a solid base on which others can start their work. There is still a long way to go here before we have a multitude of rust drivers being added, but it's a great first step. - driver core const api changes. This reached across all bus types, and there are some fix-ups for some not-common bus types that linux-next and 0-day testing shook out. This work is being done to help make the rust bindings more safe, as well as the C code, moving toward the end-goal of allowing us to put driver structures into read-only memory. We aren't there yet, but are getting closer. - minor devres cleanups and fixes found by code inspection - arch_topology minor changes - other minor driver core cleanups All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits) ARM: sa1100: make match function take a const pointer sysfs/cpu: Make crash_hotplug attribute world-readable dio: Have dio_bus_match() callback take a const * zorro: make match function take a const pointer driver core: module: make module_[add|remove]_driver take a const * driver core: make driver_find_device() take a const * driver core: make driver_[create|remove]_file take a const * firmware_loader: fix soundness issue in `request_internal` firmware_loader: annotate doctests as `no_run` devres: Correct code style for functions that return a pointer type devres: Initialize an uninitialized struct member devres: Fix memory leakage caused by driver API devm_free_percpu() devres: Fix devm_krealloc() wasting memory driver core: platform: Switch to use kmemdup_array() driver core: have match() callback in struct bus_type take a const * MAINTAINERS: add Rust device abstractions to DRIVER CORE device: rust: improve safety comments MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER firmware: rust: improve safety comments ...
| * driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman2024-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <[email protected]> Reviewed-by: Alex Elder <[email protected]> Acked-by: Sumit Garg <[email protected]> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
* | gpiolib: unexport gpiochip_get_desc()Bartosz Golaszewski2024-07-021-1/+0
| | | | | | | | | | | | | | | | | | | | 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/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: put gpio_suffixes in a single compilation unitBartosz Golaszewski2024-06-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Show more info for interrupt only lines in debugfsAndy Shevchenko2024-06-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | Show more info for interrupt only lines in debugfs. It's useful to monitor the lines that have been never requested as GPIOs, but IRQs. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Return label, if set, for IRQ only lineAndy Shevchenko2024-06-041-6/+6
| | | | | | | | | | | | | | | | | | If line has been locked as IRQ without requesting, still check its label and return it, if not NULL. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: make gpiochip_set_desc_names() return voidBartosz Golaszewski2024-06-031-8/+4
| | | | | | | | | | | | | | gpiochip_set_desc_names() cannot fail so drop its return value. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: prevent potential speculation leaks in gpio_device_get_desc()Hagar Hemdan2024-05-271-1/+2
|/ | | | | | | | | | | | | | | | | | | Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Signed-off-by: Hagar Hemdan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'gpio-updates-for-v6.10-rc1' of ↵Linus Torvalds2024-05-141-12/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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() ...
| * gpiolib: Get rid of never false gpio_is_valid() callsAndy Shevchenko2024-04-171-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: Do not mention legacy GPIOF_* in the codeAndy Shevchenko2024-04-031-1/+4
| | | | | | | | | | | | | | | | We are going to remove legacy API from kernel, don't mention it in the code that does not use it already for a while. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: use dev_err() when gpiod_configure_flags failedPeng Fan2024-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | When gpio-ranges property was missed to be added in the gpio node, using dev_err() to show an error message will helping to locate issues easier. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: use a single SRCU struct for all GPIO descriptorsBartosz Golaszewski2024-05-091-22/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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" <[email protected]> Acked-by: "Paul E. McKenney" <[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-11-30 23:09:16 +0000