aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpiolib.c
Commit message (Collapse)AuthorAgeFilesLines
...
* | 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]>
* | gpiolib: fix the speed of descriptor label setting with SRCUBartosz Golaszewski2024-05-071-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> 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" <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8650-QRD Acked-by: "Paul E. McKenney" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" ↵Hans de Goede2024-04-031-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kobject_get() errors When a gpiochip gets added by loading a module, then another driver may be waiting for that gpiochip to load on the deferred-probe list. If the deferred-probe for the consumer of gpiochip then triggers between the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find() see the chip and the gpiochip_setup_dev() later then gpio_device_find() does a kobject_get() on an uninitialized kobject since the kobject is initialized by gpiochip_setup_dev() calling device_initialize(): arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring ------------[ cut here ]------------ kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called. WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70 Call Trace: kobject_get gpio_device_find gpiod_find_and_request gpiod_get snd_byt_wm5102_mc_probe Not only is the device not initialized yet, but when the gpio-device is added to the list things like the irqchip also have not been initialized yet. So gpio_device_find() should really ignore the gpio-device until gpiochip_add_data_with_key() is fully done. Add a device_is_registered() check to gpio_device_find() to ignore gpio-devices on the list which are not yet fully initialized. Fixes: aab5c6f20023 ("gpio: set device type for GPIO chips") Suggested-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> [Bartosz: fix a typo in commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: Fix debug messaging in gpiod_find_and_request()Andy Shevchenko2024-03-261-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | When consolidating GPIO lookups in ACPI code, the debug messaging had been reworked that the user may see [ 13.401147] (NULL device *): using ACPI '\_SB.LEDS.led-0' for '(null)' GPIO lookup [ 13.401378] gpio gpiochip0: Persistence not supported for GPIO 40 [ 13.401402] gpio-40 (?): no flags found for (null) instead of [ 14.182962] gpio gpiochip0: Persistence not supported for GPIO 40 [ 14.182994] gpio-40 (?): no flags found for gpios The '(null)' parts are less informative and likely scare the users. Replace them by '(default)' which can point out to the default connection IDs, such as 'gpios'. While at it, amend other places where con_id is used in the messages. Reported-by: Ferry Toth <[email protected]> Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Suggested-by: Dmitry Torokhov <[email protected]> Tested-by: Ferry Toth <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: Deduplicate cleanup for-loop in gpiochip_add_data_with_key()Andy Shevchenko2024-03-051-15/+11
| | | | | | | | | | | There is no need to repeat for-loop twice in the error path in gpiochip_add_data_with_key(). Deduplicate it. While at it, rename loop variable to be more specific and avoid ambguity. It also properly unwinds the SRCU, i.e. in reversed order of allocating. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'v6.8-rc7' into gpio/for-nextBartosz Golaszewski2024-03-051-5/+10
|\ | | | | | | Linux 6.8-rc7
| * gpio: fix resource unwinding order in error pathBartosz Golaszewski2024-03-011-4/+4
| | | | | | | | | | | | | | | | Hogs are added *after* ACPI so should be removed *before* in error path. Fixes: a411e81e61df ("gpiolib: add hogs support for machine code") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
| * gpiolib: Fix the error path order in gpiochip_add_data_with_key()Andy Shevchenko2024-03-011-1/+1
| | | | | | | | | | | | | | | | | | After shuffling the code, error path wasn't updated correctly. Fix it here. Fixes: 2f4133bb5f14 ("gpiolib: No need to call gpiochip_remove_pin_ranges() twice") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
| * gpiolib: Handle no pin_ranges in gpiochip_generic_config()Emil Renner Berthing2024-02-201-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to gpiochip_generic_request() and gpiochip_generic_free() the gpiochip_generic_config() function needs to handle the case where there are no pinctrl pins mapped to the GPIOs, usually through the gpio-ranges device tree property. Commit f34fd6ee1be8 ("gpio: dwapb: Use generic request, free and set_config") set the .set_config callback to gpiochip_generic_config() in the dwapb GPIO driver so the GPIO API can set pinctrl configuration for the corresponding pins. Most boards using the dwapb driver do not set the gpio-ranges device tree property though, and in this case gpiochip_generic_config() would return -EPROPE_DEFER rather than the previous -ENOTSUPP return value. This in turn makes gpio_set_config_with_argument_optional() fail and propagate the error to any driver requesting GPIOs. Fixes: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Reported-by: Jisheng Zhang <[email protected]> Closes: https://lore.kernel.org/linux-gpio/ZdC_g3U4l0CJIWzh@xhacker/ Tested-by: Jisheng Zhang <[email protected]> Signed-off-by: Emil Renner Berthing <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: acpi: Make acpi_gpio_count() take firmware node as a parameterAndy Shevchenko2024-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Make acpi_gpio_count() take firmware node as a parameter in order to be aligned with other functions and decouple from unused device pointer. The latter helps to create a common fwnode_gpio_count() in the future. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: of: Make of_gpio_get_count() take firmware node as a parameterAndy Shevchenko2024-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make of_gpio_get_count() take firmware node as a parameter in order to be aligned with other functions and decouple from unused device pointer. The latter helps to create a common fwnode_gpio_count() in the future. While at it, rename to be of_gpio_count() to be aligned with the others. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index()Stephen Boyd2024-02-271-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: don't warn about removing GPIO chips with active users anymoreBartosz Golaszewski2024-02-261-18/+2
| | | | | | | | | | | | | | | | | | | | With SRCU we can now correctly handle the situation when a GPIO provider is removed while having users still holding references to GPIO descriptors. Remove all warnings emitted in this situation. Suggested-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Herve Codina <[email protected]>
* | gpio: fix memory leak in gpiod_request_commit()Xiaolei Wang2024-02-191-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU"), desc_set_label() already allocates memory for the label, so there is no need to allocate it again. If we do, we leak it. unreferenced object 0xffff0000c3e4d0c0 (size 32): comm "kworker/u16:4", pid 60, jiffies 4294894555 hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2d 63 61 6e 32 2d 73 regulator-can2-s 74 62 79 00 00 00 ff ff ff ff ff ff eb db ff ff tby............. backtrace (crc 2c3a0350): [<00000000e93c5cf4>] kmemleak_alloc+0x34/0x40 [<0000000097a2657f>] __kmalloc_node_track_caller+0x2c4/0x524 [<000000000dd1c057>] kstrdup+0x4c/0x98 [<00000000b513a96a>] kstrdup_const+0x34/0x40 [<000000008a7f0feb>] gpiod_request_commit+0xdc/0x358 [<00000000fc71ad64>] gpiod_request+0xd8/0x204 [<00000000fa24b091>] gpiod_find_and_request+0x170/0x780 [<0000000086ecf92d>] gpiod_get_index+0x70/0xe0 [<000000004aef97f9>] gpiod_get_optional+0x18/0x30 [<00000000312f1b25>] reg_fixed_voltage_probe+0x58c/0xad8 [<00000000e6f47635>] platform_probe+0xc4/0x198 [<00000000cf78fbdb>] really_probe+0x204/0x5a8 [<00000000e28d05ec>] __driver_probe_device+0x158/0x2c4 [<00000000e4fe452b>] driver_probe_device+0x60/0x18c [<00000000479fcf5d>] __device_attach_driver+0x168/0x208 [<000000007d389f38>] bus_for_each_drv+0x104/0x190 Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Signed-off-by: Xiaolei Wang <[email protected]> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: constify opaque pointer "data" in gpio_device_find()Krzysztof Kozlowski2024-02-171-1/+1
| | | | | | | | | | | | | | | | | | The opaque pointer "data" in each match function used by gpio_device_find() is a pointer to const, thus the same argument passed to gpio_device_find() can adjusted similarly. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: don't let lockdep complain about inherently dangerous RCU usageBartosz Golaszewski2024-02-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two legacy, deprecated functions - gpiod_to_chip() and gpio_device_get_chip() - that still have users in tree. They return the address of the SRCU-protected chip outside of the read-only critical sections. They are inherently dangerous and the users should convert to safer alternatives. Let's explicitly silence lockdep warnings by using rcu_dereference_check(ptr, 1). While at it: reuse gpio_device_get_chip() in gpiod_to_chip(). Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: use srcu_dereference() with SRCU-protected pointersBartosz Golaszewski2024-02-151-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Paul E. McKenney <[email protected]>
* | gpio: take the SRCU read lock in gpiod_hog()Bartosz Golaszewski2024-02-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | gpiod_hog() may be called without the gpio_device SRCU read lock taken so we need to do it here as well. It's alright if someone else is already holding the lock as SRCU read critical sections can be nested. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Paul E. McKenney <[email protected]>
* | gpio: initialize descriptor SRCU structure before adding OF-based chipsBartosz Golaszewski2024-02-141-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | In certain situations we may end up taking the GPIO descriptor SRCU read lock in of_gpiochip_add() before the SRCU struct is initialized. Move the initialization before the call to of_gpiochip_add(). Fixes: be711caa87c5 ("gpio: add SRCU infrastructure to struct gpio_desc") Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpio: mark unsafe gpio_chip manipulators as deprecatedBartosz Golaszewski2024-02-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | We still have some functions that return the address of the GPIO chip associated with the GPIO device. This is dangerous and the users should find a better solution. Let's add appropriate comments to the kernel docs. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: remove the RW semaphore from the GPIO deviceBartosz Golaszewski2024-02-121-4/+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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: protect the pointer to gpio_chip in gpio_device with SRCUBartosz Golaszewski2024-02-121-84/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: add SRCU infrastructure to struct gpio_deviceBartosz Golaszewski2024-02-121-3/+10
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: add the can_sleep flag to struct gpio_deviceBartosz Golaszewski2024-02-121-5/+6
| | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: remove unnecessary checks from gpiod_to_chip()Bartosz Golaszewski2024-02-121-2/+2
| | | | | | | | | | | | | | | | | | | | We don't need to check the gdev pointer in struct gpio_desc - it's always assigned and never cleared. It's also pointless to check gdev->chip before we actually serialize access to it. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: reduce the functionality of validate_desc()Bartosz Golaszewski2024-02-121-15/+3
| | | | | | | | | | | | | | | | | | | | | | | | Checking desc->gdev->chip for NULL without holding it in place with some serializing mechanism is pointless. Remove this check. Also don't check desc->gdev for NULL as it can never happen. We'll be protecting gdev->chip with SRCU soon but we will provide a dedicated, automatic class for that. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: don't dereference gdev->chip in gpiochip_setup_dev()Bartosz Golaszewski2024-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | We don't need to dereference gdev->chip in gpiochip_setup_dev() as at the time it's called, the label in the associated struct gpio_device is already set. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: remove unneeded code from gpio_device_get_desc()Bartosz Golaszewski2024-02-121-10/+0
| | | | | | | | | | | | | | | | The GPIO chip pointer is unused. Let's remove it. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: reinforce desc->flags handlingBartosz Golaszewski2024-02-121-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | We now removed the gpio_lock spinlock and modified the places previously protected by it to handle desc->flags access in a consistent way. Let's improve other places that were previously unprotected by reading the flags field of gpio_desc once and using the stored value for logic consistency. If we need to modify the field, let's also write it back once with a consistent value resulting from the function's logic. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: remove gpio_lockBartosz Golaszewski2024-02-121-74/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: sysfs: use gpio_device_find() to iterate over existing devicesBartosz Golaszewski2024-02-121-1/+1
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* | gpio: protect the descriptor label with SRCUBartosz Golaszewski2024-02-121-17/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-04 01:27:08 +0000