aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpiolib-sysfs.c
Commit message (Collapse)AuthorAgeFilesLines
* gpio: sysfs: Fix an end of loop test in gpiod_unexport()Dan Carpenter2025-07-191-3/+6
| | | | | | | | | | | | | The test for "if (!desc_data)" does not work correctly because the list iterator in a list_for_each_entry() loop is always non-NULL. If we don't exit via a break, then it points to invalid memory. Instead, use a tmp variable for the list iterator and only set the "desc_data" when we have found a match. Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as class devices") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interfaceBartosz Golaszewski2025-07-161-0/+42
| | | | | | | | | | | | | | Add a Kconfig switch allowing to disable the legacy parts of the GPIO sysfs interface. This means that even though we keep the /sys/class/gpio/ directory, it no longer contains the global export/unexport attribute pair (instead, the user should use the per-chip export/unpexport) nor the gpiochip$BASE entries. This option default to y if GPIO sysfs is enabled but we'll default it to n at some point in the future. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directoryBartosz Golaszewski2025-07-161-1/+50
| | | | | | | | | | | As a way to allow the user-space to stop referring to GPIOs by their global numbers, introduce a parallel group of line attributes for exported GPIO that live inside the GPIO chip class device and are referred to by their HW offset within their parent chip. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: don't look up exported lines as class devicesBartosz Golaszewski2025-07-161-16/+44
| | | | | | | | | | | | In preparation for adding a parallel, per-chip attribute group for exported GPIO lines, stop using class device APIs to refer to it in the code. When unregistering the chip, don't call class_find_device() but instead store exported lines in a linked list inside the GPIO chip data object and look it up there. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: don't use driver data in sysfs callbacks for line attributesBartosz Golaszewski2025-07-161-40/+83
| | | | | | | | | | | | | | | | | | | | Currently each exported GPIO is represented in sysfs as a separate class device. This allows us to simply use dev_get_drvdata() to retrieve the pointer passed to device_create_with_groups() from sysfs ops callbacks. However, we're preparing to add a parallel set of per-line sysfs attributes that will live inside the associated gpiochip group. They are not registered as class devices and so have the parent device passed as argument to their callbacks (the GPIO chip class device). Put the attribute structs inside the GPIO descriptor data and dereference the relevant ones using container_of() in the callbacks. This way, we'll be able to reuse the same code for both the legacy and new GPIO attributes. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: rename the data variable in gpiod_(un)export()Bartosz Golaszewski2025-07-161-18/+18
| | | | | | | | | | | In preparation for future commits which will make use of descriptor AND GPIO-device data in the same functions rename the former from data to desc_data separately which will make future changes smaller and easier to read. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functionsBartosz Golaszewski2025-07-161-12/+9
| | | | | | | | | | | | | | | We don't use any fields from struct device in gpio_sysfs_request_irq(), gpio_sysfs_free_irq() and gpio_sysfs_set_active_low(). We only use the dev argument to get the associated struct gpiod_data pointer with dev_get_drvdata(). To make the transition to not using dev_get_drvdata() across line callbacks for sysfs attributes easier, pass gpiod_data directly to these functions instead of having it wrapped in struct device. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: only get the dirent reference for the value attr onceBartosz Golaszewski2025-07-161-8/+11
| | | | | | | | | | There's no reason to retrieve the reference to the sysfs dirent every time we request an interrupt, we can as well only do it once when exporting the GPIO. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: add a parallel class device for each GPIO chip using device IDsBartosz Golaszewski2025-07-161-48/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to enable moving away from the global GPIO numberspace-based exporting of lines over sysfs: add a parallel, per-chip entry under /sys/class/gpio/ for every registered GPIO chip, denoted by device ID in the file name and not its base GPIO number. Compared to the existing chip group: it does not contain the "base" attribute as the goal of this change is to not refer to GPIOs by their global number from user-space anymore. It also contains its own, per-chip export/unexport attribute pair which allow to export lines by their hardware offset within the chip. Caveat #1: the new device cannot be a link to (or be linked to by) the existing "gpiochip<BASE>" entry as we cannot create links in /sys/class/xyz/. Caveat #2: the new entry cannot be named "gpiochipX" as it could conflict with devices whose base is statically defined to a low number. Let's go with "chipX" instead. While at it: the chip label is unique so update the untrue statement when extending the docs. Acked-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: use gpiod_is_equal() to compare GPIO descriptorsBartosz Golaszewski2025-07-161-1/+1
| | | | | | | | | | | We have a dedicated comparator for GPIO descriptors that performs additional checks and hides the implementation detail of whether the same GPIO can be associated with two separate struct gpio_desc objects. Use it in sysfs code Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: fix use-after-free in error pathAntonio Quartulli2025-06-231-1/+3
| | | | | | | | | | | | | | | | When invoking device_create_with_groups(), its return value is stored in `data->cdev_base`. However, in case of faiure, `data` is first freed and then derefernced in order to return `data->cdev_base`. Fix the use-after-free by extracting the error code before free'ing `data`. Fixes: fd19792851db ("gpio: sysfs: remove the mockdev pointer from struct gpio_device") Addresses-Coverity-ID: 1644512 ("Memory - illegal accesses (USE_AFTER_FREE)") Signed-off-by: Antonio Quartulli <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Bartosz: added Fixes: tag, tweaked commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: remove the mockdev pointer from struct gpio_deviceBartosz Golaszewski2025-06-201-28/+53
| | | | | | | | | | | | | | The usage of the mockdev pointer in struct gpio_device is limited to the GPIO sysfs code. There's no reason to keep it in this top-level structure. Create a separate structure containing the reference to the GPIO device and the dummy class device that will be passed to device_create_with_groups(). The !gdev->mockdev checks can be removed as long as we make sure that all operations on the GPIO class are protected with the sysfs lock. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: remove unneeded headersBartosz Golaszewski2025-06-201-2/+0
| | | | | | | | | | | No symbols from the linux/idr.h or linux/spinlock.h headers are used in this file so remove them. We also don't technically need linux/list.h currently but one of the follow-up commits will start using it so let's leave it. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: refactor the coding styleBartosz Golaszewski2025-06-201-33/+34
| | | | | | | | | | | | Update the code to be more consistent with the rest of the codebase. Mostly correctly align line-breaks, remove unneeded tabs, stray newlines & spaces and tweak the comment style. No functional change. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: call mutex_destroy() in gpiod_unexport()Bartosz Golaszewski2025-06-201-0/+1
| | | | | | | | | | While not critical, it's useful to have the corresponding call to mutex_destroy() whenever we use mutex_init(). Add the call right before kfreeing the GPIO data. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: don't allow setting values on input linesBartosz Golaszewski2025-04-071-5/+3
| | | | | | | | | | | | | Some drivers as well as the character device and sysfs code check whether the line actually is in output mode before allowing the user to set a value. However, GPIO value setters now return integer values and can indicate failures. This allows us to move these checks into the core code. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: emit chardev line-state events on edge storeBartosz Golaszewski2024-11-041-2/+12
| | | | | | | | | | In order to emit line-state events on edge changes in sysfs, update the EDGE flags in the descriptor in gpio_sysfs_request_irq() and emit the event on a successful store. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: emit chardev line-state events on active-low changesBartosz Golaszewski2024-11-041-0/+2
| | | | | | | | | | The sysfs active_low attribute doesn't go through the usual paths so it doesn't emit the line-state event. Add the missing call to gpiod_line_state_notify() to gpio_sysfs_set_active_low(). Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: emit chardev line-state events on GPIO exportBartosz Golaszewski2024-11-041-2/+6
| | | | | | | | | | | We already emit a CONFIG_RELEASED event when a line is unexported over sysfs (this is handled by gpiod_free()) but we don't do the opposite when it's exported. This adds the missing call to gpiod_line_state_notify(). Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: use cleanup guards for the sysfs_lock mutexBartosz Golaszewski2024-11-041-33/+22
| | | | | | | | | Shrink the code and remove some goto labels by using guards around the sysfs_lock mutex. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: use cleanup guards for gpiod_data::mutexBartosz Golaszewski2024-11-041-52/+30
| | | | | | | | | Shrink the code and drop some goto labels by using lock guards around gpiod_data::mutex. Reviewed-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: demote warning messages on invalid user input to debugBartosz Golaszewski2024-10-311-3/+3
| | | | | | | | | We should not emit a non-ratelimited warning everytime a user passes an invalid value to /sys/class/gpio/export as it's an easy way to spam the kernel log. Change the relevant messages to pr_debug_ratelimited(). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: constify gpio classBartosz Golaszewski2024-10-171-3/+2
| | | | | | | | | | | | All class functions used here take a const pointer to the class structure. We can constify gpio_class. While at it: remove a stray newline and use a tab in the struct definition for consistency with the line above. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: make the sysfs export behavior consistentBartosz Golaszewski2024-10-021-8/+2
| | | | | | | | | | | | | | | | | | For drivers or board files that set gpio_chip->names, the links to the GPIO attribute group created on sysfs export will be named after the line's name set in that array. For lines that are named using device properties, the names pointer of the gpio_chip struct is never assigned so they are exported as if they're not named. The ABI documentation does not mention the former behavior and given that the majority of modern systems use device-tree, ACPI or other way of passing GPIO names using device properties - bypassing gc->names - it's better to make the behavior consistent by always exporting lines as "gpioXYZ". Reviewed-by: Linus Walleij <[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-2/+4
| | | | | | | | | | | | | | | $ 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]>
* gpiolib: Get rid of never false gpio_is_valid() callsAndy Shevchenko2024-04-171-1/+1
| | | | | | | | | | | | | | In the cases when gpio_is_valid() is called with unsigned parameter the result is always true in the GPIO library code, hence the check for false won't ever be true. Get rid of such calls. While at it, move GPIO device base to be unsigned to clearly show it won't ever be negative. This requires a new definition for the maximum GPIO number in the system. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: repair export returning -EPERM on 1st attemptAlexander Sverdlin2024-03-081-1/+1
| | | | | | | | | | | | | | It would make sense to return -EPERM if the bit was already set (already used), not if it was cleared. Before this fix pins can only be exported on the 2nd attempt: $ echo 522 > /sys/class/gpio/export sh: write error: Operation not permitted $ echo 522 > /sys/class/gpio/export Fixes: 35b545332b80 ("gpio: remove gpio_lock") Signed-off-by: Alexander Sverdlin <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: sysfs: fix inverted pointer logicBartosz Golaszewski2024-02-151-1/+1
| | | | | | | | | The logic is inverted, we want to return if the chip *IS* NULL. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/linux-gpio/[email protected]/ Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: use srcu_dereference() with SRCU-protected pointersBartosz Golaszewski2024-02-151-2/+3
| | | | | | | | | | | | 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: protect the pointer to gpio_chip in gpio_device with SRCUBartosz Golaszewski2024-02-121-16/+41
| | | | | | | | | | | | | | | | | | | 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: sysfs: don't access gdev->chip if it's not neededBartosz Golaszewski2024-02-121-3/+3
| | | | | | | | | | Don't dereference gdev->chip if the same information can be obtained from struct gpio_device. Suggested-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* gpio: sysfs: pass the GPIO device - not chip - to sysfs callbacksBartosz Golaszewski2024-02-121-7/+7
| | | | | | | | | | | We're working towards protecting the chip pointer in struct gpio_device with SRCU. In order to use it in sysfs callbacks we must pass the pointer to the GPIO device that wraps the chip instead of the address of the chip itself as the user data. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]>
* gpio: sysfs: extend the critical section for unregistering sysfs devicesBartosz Golaszewski2024-02-121-7/+8
| | | | | | | | | Checking the gdev->mockdev pointer for NULL must be part of the critical section. 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-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-23/+23
| | | | | | | | | 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]>
* gpiolib: revert the attempt to protect the GPIO device list with an rwsemBartosz Golaszewski2024-01-171-21/+24
| | | | | | | | | | | | | | | | | | | | | This reverts commits 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") and 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices"). Unfortunately the legacy GPIO API that's still used in older code has to translate numbers from the global GPIO numberspace to descriptors. This results in a GPIO device lookup in every call to legacy functions. Some of those functions - like gpio_set/get_value() - can be called from atomic context so taking a sleeping lock that is an RW semaphore results in an error. We'll probably have to protect this list with SRCU. Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/linux-wireless/[email protected]/ Fixes: 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") Fixes: 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices") Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpiolib: replace the GPIO device mutex with a read-write semaphoreBartosz Golaszewski2024-01-041-1/+1
| | | | | | | | | | There are only two spots where we modify (add to or remove objects from) the GPIO device list. Readers should be able to access it concurrently. Replace the mutex with a read-write semaphore and adjust the locking operations accordingly. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
* gpio: sysfs: drop tabs from local variable declarationsBartosz Golaszewski2023-12-271-33/+32
| | | | | | | | | | Older code has an annoying habit of putting tabs between the type and the name of the variable. This doesn't really add to readability and newer code doesn't do it so make the entire file consistent. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
* Merge tag 'v6.7-rc7' into gpio/for-nextBartosz Golaszewski2023-12-271-6/+9
|\ | | | | | | Linux 6.7-rc7
| * gpiolib: sysfs: Fix error handling on failed exportBoerge Struempfel2023-12-011-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If gpio_set_transitory() fails, we should free the GPIO again. Most notably, the flag FLAG_REQUESTED has previously been set in gpiod_request_commit(), and should be reset on failure. To my knowledge, this does not affect any current users, since the gpio_set_transitory() mainly returns 0 and -ENOTSUPP, which is converted to 0. However the gpio_set_transitory() function calles the .set_config() function of the corresponding GPIO chip and there are some GPIO drivers in which some (unlikely) branches return other values like -EPROBE_DEFER, and -EINVAL. In these cases, the above mentioned FLAG_REQUESTED would not be reset, which results in the pin being blocked until the next reboot. Fixes: e10f72bf4b3e ("gpio: gpiolib: Generalise state persistence beyond sleep") Signed-off-by: Boerge Struempfel <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* | gpiolib: use a mutex to protect the list of GPIO devicesBartosz Golaszewski2023-12-181-24/+21
|/ | | | | | | | | | The global list of GPIO devices is never modified or accessed from atomic context so it's fine to protect it using a mutex. Add a new global lock dedicated to the gpio_devices list and use it whenever accessing or modifying it. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
* gpio: sysfs: drop the mention of gpiochip_find() from sysfs codeBartosz Golaszewski2023-10-041-1/+1
| | | | | | | | We have removed all callers of gpiochip_find() so don't mention it in gpiolib-sysfs.c. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
* gpiolib: sysfs: Do unexport GPIO when user asks for itAndy Shevchenko2023-08-161-2/+5
| | | | | | | | | | | | | | | It seems that sysfs interface implicitly relied on the gpiod_free() to unexport the line. This is logically incorrect as core gpiolib should not deal with sysfs so instead of restoring it, let's call gpiod_unexport() from sysfs code. Fixes: b0ce9ce408b6 ("gpiolib: Do not unexport GPIO on freeing") Reported-by: Marek Behún <[email protected]> Closes: https://lore.kernel.org/r/20230808102828.4a9eac09@dellmb Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Marek Behún <[email protected]> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
* Merge tag 'driver-core-6.4-rc1' of ↵Linus Torvalds2023-04-271-8/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the large set of driver core changes for 6.4-rc1. Once again, a busy development cycle, with lots of changes happening in the driver core in the quest to be able to move "struct bus" and "struct class" into read-only memory, a task now complete with these changes. This will make the future rust interactions with the driver core more "provably correct" as well as providing more obvious lifetime rules for all busses and classes in the kernel. The changes required for this did touch many individual classes and busses as many callbacks were changed to take const * parameters instead. All of these changes have been submitted to the various subsystem maintainers, giving them plenty of time to review, and most of them actually did so. Other than those changes, included in here are a small set of other things: - kobject logging improvements - cacheinfo improvements and updates - obligatory fw_devlink updates and fixes - documentation updates - device property cleanups and const * changes - firwmare loader dependency fixes. All of these have been in linux-next for a while with no reported problems" * tag 'driver-core-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (120 commits) device property: make device_property functions take const device * driver core: update comments in device_rename() driver core: Don't require dynamic_debug for initcall_debug probe timing firmware_loader: rework crypto dependencies firmware_loader: Strip off \n from customized path zram: fix up permission for the hot_add sysfs file cacheinfo: Add use_arch[|_cache]_info field/function arch_topology: Remove early cacheinfo error message if -ENOENT cacheinfo: Check cache properties are present in DT cacheinfo: Check sib_leaf in cache_leaves_are_shared() cacheinfo: Allow early level detection when DT/ACPI info is missing/broken cacheinfo: Add arm64 early level initializer implementation cacheinfo: Add arch specific early level initializer tty: make tty_class a static const structure driver core: class: remove struct class_interface * from callbacks driver core: class: mark the struct class in struct class_interface constant driver core: class: make class_register() take a const * driver core: class: mark class_release() as taking a const * driver core: remove incorrect comment for device_create* MIPS: vpe-cmp: remove module owner pointer from struct class usage. ...
| * driver core: create class_is_registered()Greg Kroah-Hartman2023-03-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some classes (i.e. gpio), want to know if they have been registered or not, and poke around in the class's internal structures to try to figure this out. Because this is not really a good idea, provide a function for classes to call to try to figure this out. Note, this is racy as the state of the class could change at any moment in time after the call is made, but as usually a class only wants to know if it has been registered yet or not, it should be fairly safe to use, and is just as safe as the previous "poke at the class internals" check was. Move the gpiolib code to use this function as proof that it works properly. Cc: Bartosz Golaszewski <[email protected]> Cc: Sebastian Reichel <[email protected]> Cc: Benjamin Tissoires <[email protected]> Cc: [email protected] Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
| * driver core: class: mark the struct class for sysfs callbacks as constantGreg Kroah-Hartman2023-03-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct class should never be modified in a sysfs callback as there is nothing in the structure to modify, and frankly, the structure is almost never used in a sysfs callback, so mark it as constant to allow struct class to be moved to read-only memory. While we are touching all class sysfs callbacks also mark the attribute as constant as it can not be modified. The bonding code still uses this structure so it can not be removed from the function callbacks. Cc: "David S. Miller" <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Bartosz Golaszewski <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Johannes Berg <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Miquel Raynal <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Russ Weight <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Steve French <[email protected]> Cc: Vignesh Raghavendra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Luis Chamberlain <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
| * drivers: remove struct module * setting from struct classGreg Kroah-Hartman2023-03-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to manually set the owner of a struct class, as the registering function does it automatically, so remove all of the explicit settings from various drivers that did so as it is unneeded. This allows us to remove this pointer entirely from this structure going forward. Cc: "Rafael J. Wysocki" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
* | gpiolib: Clean up headersAndy Shevchenko2023-03-061-5/+16
| | | | | | | | | | | | | | | | | | | | | | There is a few things done: - include only the headers we are direct user of - when pointer is in use, provide a forward declaration - add missing headers - group generic headers and subsystem headers - sort each group alphabetically Signed-off-by: Andy Shevchenko <[email protected]>
* | gpiolib: remove legacy gpio_export()Arnd Bergmann2023-03-061-2/+2
|/ | | | | | | | | | | | | | There are only a handful of users of gpio_export() and related functions. As these are just wrappers around the modern gpiod_export() helper, remove the wrappers and open-code the gpio_to_desc in all callers to shrink the legacy API. Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
* gpiolib: Embed iterator variable into for_each_gpio_desc_with_flag()Andy Shevchenko2022-04-091-2/+1
| | | | | | | | | | The iterator loop is used exclusively to get a descriptor, which in its turn is what is being used by the caller. Embed the iterator variable into the loop in the for_each_gpio_desc_with_flag() macro helper. Suggested-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-01 02:11:08 +0000