summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib.h
AgeCommit message (Collapse)Author
2024-02-27gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index()Stephen Boyd
This devm API takes a consumer device as an argument to setup the devm action, but throws it away when calling further into gpiolib. This leads to odd debug messages like this: (NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup Let's pass the consumer device down, by directly calling what fwnode_gpiod_get_index() calls but pass the device used for devm. This changes the message to look like this instead: gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup Note that callers of fwnode_gpiod_get_index() will still see the NULL device pointer debug message, but there's not much we can do about that because the API doesn't take a struct device. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-15gpio: use srcu_dereference() with SRCU-protected pointersBartosz Golaszewski
Lockdep with CONFIG_PROVE_RCU enabled reports false positives about suspicious rcu_dereference() usage. Let's silence it by using srcu_dereference() which is the correct helper with SRCU. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Paul E. McKenney <paulmck@kernel.org>
2024-02-12gpio: remove the RW semaphore from the GPIO deviceBartosz Golaszewski
With all accesses to gdev->chip being protected with SRCU, we can now remove the RW-semaphore specific to the character device which fulfilled the same role up to this point. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the pointer to gpio_chip in gpio_device with SRCUBartosz Golaszewski
Ensure we cannot crash if the GPIO device gets unregistered (and the chip pointer set to NULL) during any of the API calls. To that end: wait for all users of gdev->chip to exit their read-only SRCU critical sections in gpiochip_remove(). For brevity: add a guard class which can be instantiated at the top of every function requiring read-only access to the chip pointer and use it in all API calls taking a GPIO descriptor as argument. In places where we only deal with the GPIO device - use regular guard() helpers and rcu_dereference() for chip access. Do the same in API calls taking a const pointer to gpio_desc. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add SRCU infrastructure to struct gpio_deviceBartosz Golaszewski
Add the SRCU struct to GPIO device. It will be used to serialize access to the GPIO chip pointer. Initialize and clean it up where applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add the can_sleep flag to struct gpio_deviceBartosz Golaszewski
Duplicating the can_sleep value in GPIO device will allow us to not needlessly dereference the chip pointer in several places and reduce the number of SRCU read-only critical sections. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove gpio_lockBartosz Golaszewski
The "multi-function" gpio_lock is pretty much useless with how it's used in GPIOLIB currently. Because many GPIO API calls can be called from all contexts but may also call into sleeping driver callbacks, there are many places with utterly broken workarounds like yielding the lock to call a possibly sleeping function and then re-acquiring it again without taking into account that the protected state may have changed. It was also used to protect several unrelated things: like individual descriptors AND the GPIO device list. We now serialize access to these two with SRCU and so can finally remove the spinlock. There is of course the question of consistency of lockless access to GPIO descriptors. Because we only support exclusive access to GPIOs (officially anyway, I'm looking at you broken GPIOD_FLAGS_BIT_NONEXCLUSIVE bit...) and the API contract with providers does not guarantee serialization, it's enough to ensure we cannot accidentally dereference an invalid pointer and that the state we present to both users and providers remains consistent. To achieve that: read the flags field atomically except for a few special cases. Read their current value before executing callback code and use this value for any subsequent logic. Modifying the flags depends on the particular use-case and can differ. For instance: when requesting a GPIO, we need to set the REQUESTED bit immediately so that the next user trying to request the same line sees -EBUSY. While at it: the allocations that used GFP_ATOMIC until this point can now switch to GFP_KERNEL. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: use gpio_device_find() to iterate over existing devicesBartosz Golaszewski
With the list of GPIO devices now protected with SRCU we can use gpio_device_find() to traverse it from sysfs. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the descriptor label with SRCUBartosz Golaszewski
In order to ensure that the label is not freed while it's being accessed, let's protect it with SRCU and synchronize it everytime it's changed. Let's modify desc_set_label() to manage the memory used for the label as it can only be freed once synchronize_srcu() returns. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add SRCU infrastructure to struct gpio_descBartosz Golaszewski
Extend the GPIO descriptor with an SRCU structure in order to serialize the access to the label. Initialize and clean it up where applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: provide and use gpiod_get_label()Bartosz Golaszewski
We will soon serialize access to the descriptor label using SRCU. The write-side of the protection will require calling synchronize_srcu() which must not be called from atomic context. We have two irq helpers: gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label if the GPIO is not requested but is being used as interrupt. They are called with a spinlock held from the interrupt subsystem. They must not do it if we are to use SRCU so instead let's move the special corner case to a dedicated getter. First: let's implement and use the getter where it's applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove unused logging helpersBartosz Golaszewski
The general rule of the kernel is to not provide symbols that have no users upstream. Let's remove logging helpers that are not used anywhere. This will save us work later when we'll be modifying them to use the upcoming SRCU infrastructure. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-01-17gpiolib: revert the attempt to protect the GPIO device list with an rwsemBartosz Golaszewski
This reverts commits 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") and 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices"). Unfortunately the legacy GPIO API that's still used in older code has to translate numbers from the global GPIO numberspace to descriptors. This results in a GPIO device lookup in every call to legacy functions. Some of those functions - like gpio_set/get_value() - can be called from atomic context so taking a sleeping lock that is an RW semaphore results in an error. We'll probably have to protect this list with SRCU. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-wireless/f7b5ff1e-8f34-4d98-a7be-b826cb897dc8@moroto.mountain/ Fixes: 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") Fixes: 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-04gpiolib: replace the GPIO device mutex with a read-write semaphoreBartosz Golaszewski
There are only two spots where we modify (add to or remove objects from) the GPIO device list. Readers should be able to access it concurrently. Replace the mutex with a read-write semaphore and adjust the locking operations accordingly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-12-19gpiolib: remove debounce_period_us from struct gpio_descKent Gibson
cdev is the only user of the debounce_period_us field in struct gpio_desc, and it no longer uses it, so remove it. Signed-off-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-12-18gpiolib: use a mutex to protect the list of GPIO devicesBartosz Golaszewski
The global list of GPIO devices is never modified or accessed from atomic context so it's fine to protect it using a mutex. Add a new global lock dedicated to the gpio_devices list and use it whenever accessing or modifying it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-10-04gpiolib: make gpio_device_get() and gpio_device_put() publicBartosz Golaszewski
In order to start migrating away from accessing struct gpio_chip by users other than their owners, let's first make the reference management functions for the opaque struct gpio_device public in the driver.h header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-09-12gpiolib: make gpiochip_get_desc() publicBartosz Golaszewski
It makes sense for a GPIO driver to want to get its own descriptor without requesting it. After all, the driver knows that it'll still be valid. Let's move this helper to linux/gpio/driver.h. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2023-09-11gpiolib: unexport gpiod_set_transitory()Bartosz Golaszewski
There are no and never have been any users of gpiod_set_transitory() outside the core GPIOLIB code. Make it private. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-22gpiolib: provide and use gpiod_line_state_notify()Bartosz Golaszewski
Wrap the calls to blocking_notifier_call_chain() for the line state notifier with a helper that allows us to use fewer lines of code and simpler syntax. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-08-21gpiolib: add a second blocking notifier to struct gpio_deviceBartosz Golaszewski
Add a new blocking notifier to struct gpio_device and use it to notify subscribers about the GPIO device being unregistered from the device model. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
2023-08-21gpiolib: rename the gpio_device notifierBartosz Golaszewski
Change the generic "notifier" name to "line_state_notifier" in order to reflect its purpose in preparation for adding a second notifier which will be used to notify wait queues about device unregistering. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
2023-07-18gpio: mmio: handle "ngpios" properly in bgpio_init()Asmaa Mnebhi
bgpio_init() uses "sz" argument to populate ngpio, which is not accurate. Instead, read the "ngpios" property from the DT and if it doesn't exist, use the "sz" argument. With this change, drivers no longer need to overwrite the ngpio variable after calling bgpio_init(). If the "ngpios" property is specified, bgpio_bits is calculated as the round up value of ngpio. At the moment, the only requirement specified is that the round up value must be a multiple of 8 but it should also be a power of 2 because we provide accessors based on the bank size in bgpio_setup_accessors(). Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-07-13gpiolib: order includes alphabetically in gpiolib.hBartosz Golaszewski
After adding the missing notifier.h header, let's order all includes alphabetically. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-07-10gpiolib: add missing includeBartosz Golaszewski
gpiolib.h uses notifiers but doesn't include <linux/notifier.h>. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2023-01-30gpiolib: Introduce gpio_device_get() and gpio_device_put()Andy Shevchenko
Introduce gpio_device_get() and gpio_device_put() helpers and convert existing users. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2022-12-07gpiolib: protect the GPIO device against being dropped while in use by ↵Bartosz Golaszewski
user-space While any of the GPIO cdev syscalls is in progress, the kernel can call gpiochip_remove() (for instance, when a USB GPIO expander is disconnected) which will set gdev->chip to NULL after which any subsequent access will cause a crash. To avoid that: use an RW-semaphore in which the syscalls take it for reading (so that we don't needlessly prohibit the user-space from calling syscalls simultaneously) while gpiochip_remove() takes it for writing so that it can only happen once all syscalls return. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL") Fixes: 7b8e00d98168 ("gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> [Nick: fixed a build failure with CDEV_V1 disabled] Co-authored-by: Nick Hainke <vincent@systemli.org> Reviewed-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2022-11-29gpiolib: Provide to_gpio_device() helperAndy Shevchenko
Provide to_gpio_device() helper which can be utilized in the existing and future code. While at it, make sure it becomes no-op at compilation time. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2022-06-05Merge tag 'hte/for-5.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux Pull hardware timestamping subsystem from Thierry Reding: "This contains the new HTE (hardware timestamping engine) subsystem that has been in the works for a couple of months now. The infrastructure provided allows for drivers to register as hardware timestamp providers, while consumers will be able to request events that they are interested in (such as GPIOs and IRQs) to be timestamped by the hardware providers. Note that this currently supports only one provider, but there seems to be enough interest in this functionality and we expect to see more drivers added once this is merged" [ Linus Walleij mentions the Intel PMC in the Elkhart and Tiger Lake platforms as another future timestamp provider ] * tag 'hte/for-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: timestamp: Correct id path dt-bindings: Renamed hte directory to timestamp hte: Uninitialized variable in hte_ts_get() hte: Fix off by one in hte_push_ts_ns() hte: Fix possible use-after-free in tegra_hte_test_remove() hte: Remove unused including <linux/version.h> MAINTAINERS: Add HTE Subsystem hte: Add Tegra HTE test driver tools: gpio: Add new hardware clock type gpiolib: cdev: Add hardware timestamp clock type gpio: tegra186: Add HTE support gpiolib: Add HTE support dt-bindings: Add HTE bindings hte: Add Tegra194 HTE kernel provider drivers: Add hardware timestamp engine (HTE) subsystem Documentation: Add HTE subsystem guide
2022-05-04gpiolib: Add HTE supportDipen Patel
Some GPIO chip can provide hardware timestamp support on its GPIO lines , in order to support that, additional API needs to be added which can talk to both GPIO chip and HTE (hardware timestamping engine) providers if there is any dependencies. This patch introduces optional hooks to enable and disable hardware timestamping related features in the GPIO controller chip. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-04-09gpiolib: Split out for_each_gpio_desc() macroAndy Shevchenko
In some cases we want to traverse all GPIO descriptors for given chip, let's split out for_each_gpio_desc() macro for such cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Embed iterator variable into for_each_gpio_desc_with_flag()Andy Shevchenko
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 <brgl@bgdev.pl> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-03-25Merge tag 'gpio-updates-for-v5.18' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "Relatively few updates for this release cycle. We have a single new driver and some minor changes in drivers, more work on limiting the usage of of_node in drivers and DT updates: - new driver: gpio-en7523 - dt-bindings: convertion of faraday,ftgpio010 to YAML, new compatible string in gpio-vf610 and a bugfix in an example - gpiolib core: several improvements and some code shrink - documentation: convert all public docs into kerneldoc format - set IRQ bus token in gpio-crystalcove (addresses a debugfs issue) - add a missing return value check for kstrdup() in gpio-merrifield - allow gpio-tps68470 to be built as module - more work on limiting usage of of_node in GPIO drivers - several sysfs interface improvements - use SDPX in gpio-ts4900" * tag 'gpio-updates-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: ts4900: Use SPDX header gpiolib: Use list_first_entry()/list_last_entry() gpiolib: sysfs: Simplify edge handling in the code gpiolib: sysfs: Move kstrtox() calls outside of the mutex lock gpiolib: sysfs: Move sysfs_emit() calls outside of the mutex lock gpiolib: make struct comments into real kernel docs dt-bindings: gpio: convert faraday,ftgpio01 to yaml dt-bindings: gpio: gpio-vf610: Add imx93 compatible string gpiolib: Simplify error path in gpiod_get_index() when requesting GPIO gpiolib: Use short form of ternary operator in gpiod_get_index() gpiolib: Introduce for_each_gpio_desc_with_flag() macro gpio: Add support for Airoha EN7523 GPIO controller dt-bindings: arm: airoha: Add binding for Airoha GPIO controller dt-bindings: gpio: fix gpio-hog example gpio: tps68470: Allow building as module gpio: tegra: Get rid of duplicate of_node assignment gpio: altera-a10sr: Switch to use fwnode instead of of_node gpio: merrifield: check the return value of devm_kstrdup() gpio: crystalcove: Set IRQ domain bus token to DOMAIN_BUS_WIRED
2022-02-09gpiolib: make struct comments into real kernel docsBartosz Golaszewski
We have several comments that start with '/**' but don't conform to the kernel doc standard. Add proper detailed descriptions for the affected definitions and move the docs from the forward declarations to the struct definitions where applicable. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2022-02-08gpiolib: Introduce for_each_gpio_desc_with_flag() macroAndy Shevchenko
In a few places we are using a loop against all GPIO descriptors with a given flag for a given device. Replace it with a consolidated for_each type of macro. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-02-08gpiolib: Never return internal error codes to user spaceAndy Shevchenko
Currently it's possible that character device interface may return the error codes which are not supposed to be seen by user space. In this case it's EPROBE_DEFER. Wrap it to return -ENODEV instead as sysfs does. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Reported-by: Suresh Balakrishnan <suresh.balakrishnan@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2020-12-09Merge tag 'gpio-updates-for-v5.11' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.11-rc1 - several refactoring patches of the core gpiolib code - add support for NXP PCAL9554B/C to gpio-pca953x - allow probing mockup devices from device tree - refactoring and improvements to gpio-rcar - improvements to locking in gpio-tegra - code shrink in gpiolib devres - get the irq offset from device tree in gpio-sifive - major refactoring of gpio-exar - convert gpio-mvebu pwm access to regmap - create a new submenu for virtual GPIO drivers - fix clang fall-through warnings treewide - minor driver refactoring and tweaks sprinkled all over
2020-12-05gpiolib: cdev: allow edge event timestamps to be configured as REALTIMEKent Gibson
Using CLOCK_REALTIME as the source for event timestamps is crucial for some specific applications, particularly those requiring timetamps relative to a PTP clock, so provide an option to switch the event timestamp source from the default CLOCK_MONOTONIC to CLOCK_REALTIME. Note that CLOCK_REALTIME was the default source clock for GPIO until Linux 5.7 when it was changed to CLOCK_MONOTONIC due to issues with the shifting of the realtime clock. Providing this option maintains the CLOCK_MONOTONIC as the default, while also providing a path forward for those dependent on the pre-5.7 behaviour. Suggested-by: Jack Winch <sunt.un.morcov@gmail.com> Signed-off-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20201014231158.34117-2-warthog618@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-16gpiolib: Introduce gpio_set_debounce_timeout() for internal useAndy Shevchenko
In some cases we would like to have debounce setter which doesn't fail when a feature is not supported by a controller. Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-10-26gpiolib: Extract gpiod_not_found() helperAndy Shevchenko
Several places in the code are using same idiom, i.e. IS_ERR(desc) && PTR_ERR(desc) == -ENOENT which meaning is GPIO description is not found. For better readability extract gpiod_not_found() helper and use it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-09-30gpiolib: cdev: support setting debounceKent Gibson
Add support for setting debounce on a line via the GPIO uAPI. Where debounce is not supported by hardware, a software debounce is provided. The implementation of the software debouncer waits for the line to be stable for the debounce period before determining if a level change, and a corresponding edge event, has occurred. This provides maximum protection against glitches, but also introduces a debounce_period latency to edge events. The software debouncer is integrated with the edge detection as it utilises the line interrupt, and integration is simpler than getting the two to interwork. Where software debounce AND edge detection is required, the debouncer provides both. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-09-30gpiolib: cdev: support edge detection for uAPI v2Kent Gibson
Add support for edge detection to lines requested using GPIO_V2_GET_LINE_IOCTL. The edge_detector implementation is based on the v1 lineevent implementation. Unlike the v1 implementation, an overflow of the event buffer results in discarding older events, rather than the most recent, so the final event in a burst will correspond to the current state of the line. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-07-12gpiolib: cdev: use blocking notifier call chain instead of atomicKent Gibson
Replace usage of atomic_notifier_call_chain with blocking_notifier_call_chain as the notifier function, lineinfo_changed_notify, calls gpio_desc_to_lineinfo, which calls pinctrl_gpio_can_use_line, which can sleep. The chain isn't being called from an atomic context so the the blocking notifier is a suitable substitute. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-07-12gpiolib: move gpiolib-sysfs function declarations into their own headerKent Gibson
Move gpiolib-sysfs function declarations into their own header. These functions are in gpiolib-sysfs.c, and are only required by gpiolib.c, and so should be in a module header, not gpiolib.h. This brings gpiolib-sysfs into line with gpiolib-cdev, and is another step towards removing the sysfs inferface. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-04-28gpiolib: Rename "chip" variables to "gc" in core header fileGeert Uytterhoeven
Consistently use "gc" for "struct gpio *" variables. This follows the spirit of commit a0b66a73785ccc8f ("gpio: Rename variable in core APIs"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200424141517.11582-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-21gpio: of: Add DT overlay support for GPIO hogsGeert Uytterhoeven
As GPIO hogs are configured at GPIO controller initialization time, adding/removing GPIO hogs in DT overlays does not work. Add support for GPIO hogs described in DT overlays by registering an OF reconfiguration notifier, to handle the addition and removal of GPIO hog subnodes to/from a GPIO controller device node. Note that when a GPIO hog device node is being removed, its "gpios" properties is no longer available, so we have to keep track of which node a hog belongs to, which is done by adding a pointer to the hog's device node to struct gpio_desc. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-02-12gpiolib: add new ioctl() for monitoring changes in line infoBartosz Golaszewski
Currently there is no way for user-space to be informed about changes in status of GPIO lines e.g. when someone else requests the line or its config changes. We can only periodically re-read the line-info. This is fine for simple one-off user-space tools, but any daemon that provides a centralized access to GPIO chips would benefit hugely from an event driven line info synchronization. This patch adds a new ioctl() that allows user-space processes to reuse the file descriptor associated with the character device for watching any changes in line properties. Every such event contains the updated line information. Currently the events are generated on three types of status changes: when a line is requested, when it's released and when its config is changed. The first two are self-explanatory. For the third one: this will only happen when another user-space process calls the new SET_CONFIG ioctl() as any changes that can happen from within the kernel (i.e. set_transitory() or set_debounce()) are of no interest to user-space. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-01-07Merge tag 'gpio-updates-for-v5.6-part1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.6 - improvements in the gpio-pca953x driver - use platform_irq_count() in gpio-mvebu and gpio-bcm-kona - remove unneeded MODULE_VERSION() usage in the gpio directory - irq-related improvements in gpio-tegra driver - several improvements for the core subsystem code: fix confusing indentation, fix int type casting, unduplicate code in several places
2020-01-07gpiolib: convert the type of hwnum to unsigned int in gpiochip_get_desc()Bartosz Golaszewski
gpiochip_get_desc() takes a u16 hwnum, but it turns out most users don't respect that and usually pass an unsigned int. Since implicit casting to a smaller type is dangerous - let's change the type of hwnum to unsigned int in gpiochip_get_desc() and in gpiochip_request_own_desc() where the size of hwnum is not respected either and who's a user of the former. This is safe as we then check the hwnum against the number of lines before proceeding in gpiochip_get_desc(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-12gpiolib: Add GPIOCHIP_NAME definitionGeert Uytterhoeven
The string literal "gpiochip" is used in several places. Add a definition for it, and use it everywhere, to make sure everything stays in sync. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191127084253.16356-2-geert+renesas@glider.be Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>