summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)Author
2025-03-17gpio: bcm-kona: use lock guardsBartosz Golaszewski
Reduce the code complexity by using automatic lock guards with the raw spinlock. Link: https://lore.kernel.org/r/20250310-gpiochip-set-conversion-v1-1-03798bb833eb@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-17Merge tag 'v6.14-rc7' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc7
2025-03-13Merge tag 'intel-gpio-v6.15-1' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next intel-gpio for v6.15-1 * A cleanup to remove unneeded ERR_CAST() in GPIO ACPI library The following is an automated git shortlog grouped by driver: gpiolib-acpi: - Drop unneeded ERR_CAST() in __acpi_find_gpio()
2025-03-13gpio: cdev: use raw notifier for line state eventsBartosz Golaszewski
We use a notifier to implement the mechanism of informing the user-space about changes in GPIO line status. We register with the notifier when the GPIO character device file is opened and unregister when the last reference to the associated file descriptor is dropped. Since commit fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") we use the atomic notifier variant. Atomic notifiers call rcu_synchronize in atomic_notifier_chain_unregister() which caused a significant performance regression in some circumstances, observed by user-space when calling close() on the GPIO device file descriptor. Replace the atomic notifier with the raw variant and provide synchronization with a read-write spinlock. Fixes: fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") Reported-by: David Jander <david@protonic.nl> Closes: https://lore.kernel.org/all/20250311110034.53959031@erd003.prtnl/ Tested-by: David Jander <david@protonic.nl> Tested-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20250311-gpiolib-line-state-raw-notifier-v2-1-138374581e1e@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-13gpiolib: don't check the retval of get_direction() when registering a chipBartosz Golaszewski
During chip registration we should neither check the return value of gc->get_direction() nor hold the SRCU lock when calling it. The former is because pin controllers may have pins set to alternate functions and return errors from their get_direction() callbacks. That's alright - we should default to the safe INPUT state and not bail-out. The latter is not needed because we haven't registered the chip yet so there's nothing to protect against dynamic removal. In fact: we currently hit a lockdep splat. Revert to calling the gc->get_direction() callback directly and *not* checking its value. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/81f890fc-6688-42f0-9756-567efc8bb97a@samsung.com/ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20250226-retval-fixes-v2-1-c8dc57182441@linaro.org Tested-by: Gene C <arch@sapience.com> Link: https://lore.kernel.org/r/20250311175631.83779-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: adnp: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250306-gpiochip-set-conversion-v2-2-a76e72e21425@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: adnp: use lock guards for the I2C lockBartosz Golaszewski
Reduce the code complexity by using automatic lock guards with the I2C mutex. Link: https://lore.kernel.org/r/20250306-gpiochip-set-conversion-v2-1-a76e72e21425@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: aspeed-sgpio: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-15-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: aspeed-sgpio: use lock guardsBartosz Golaszewski
Reduce the code complexity by using automatic lock guards with the raw spinlock. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-14-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: aspeed: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-13-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: aspeed: use lock guardsBartosz Golaszewski
Reduce the code complexity by using automatic lock guards with the raw spinlock. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-12-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: arizona: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-11-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: amd-fch: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-10-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: amd8111: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-9-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: altera: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-8-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: altera-a10sr: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-7-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: adp5585: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-6-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: adp5520: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-5-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: adnp: use devm_mutex_init()Bartosz Golaszewski
The mutex initialized in probe() is never cleaned up. Use devm_mutex_init() to do it automatically. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-3-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-10gpio: 74x164: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250303-gpiochip-set-conversion-v1-1-1d5cceeebf8b@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-06ieee802154: ca8210: Switch to using gpiod APIAndy Shevchenko
This updates the driver to gpiod API, and removes yet another use of of_get_named_gpio(). With this, invert the logic of the reset pin which is active-low and add a quirk for the legacy and incorrect device tree descriptions. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/20250305105656.2133487-4-andriy.shevchenko@linux.intel.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
2025-03-06gpio: rcar: Fix missing of_node_put() callFabrizio Castro
of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: 159f8a0209af ("gpio-rcar: Add DT support") Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250305163753.34913-2-fabrizio.castro.jz@renesas.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: Hide valid_mask from direct assignmentsMatti Vaittinen
The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. Current documentation does not mention this but just says the valid_mask is used if it's not NULL. This lured me to try populating it directly in the GPIO driver probe instead of using the init_valid_mask() callback. It took some retries with different bitmaps and eventually a bit of code-reading to understand why the valid_mask was not obeyed. I could've avoided this trial and error if the valid_mask was hidden in the struct gpio_device instead of being a visible member of the struct gpio_chip. Help the next developer who decides to directly populate the valid_mask in struct gpio_chip by hiding the valid_mask in struct gpio_device and keep it internal to the GPIO core. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/4547ca90d910d60cab3d56d864d59ddde47a5e93.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: gpio-rcar: Drop direct use of valid_maskMatti Vaittinen
The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. It should not be directly populated by the drivers. Hiding the valid_mask in struct gpio_device makes it clear it is not meant to be directly populated by drivers. This means drivers should not access it directly from the struct gpio_chip. The gpio-rcar checks the valid mask in set/get_multiple() operations. This is no longer needed [1]. Drop these checks. Additionally, the valid_mask is needed for enabling the GPIO inputs at probe time. Use the new valid_mask -getter function instead of accessing it directly from the struct gpio_chip. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/e46441ba8a2840e6b48ec8d2ecd5919995a5675f.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: Add a valid_mask getterMatti Vaittinen
The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. It shouldn't be directly populated by drivers. This can be prevented by moving it from the struct gpio_chip to struct gpio_device, which is internal to the GPIO core. As a preparatory step, provide a getter function which can be used by those drivers which need the valid_mask information. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/026f9d78502eca883bfe3faeb684e23d5d6c5e84.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: Respect valid_mask when requesting GPIOsMatti Vaittinen
When GPIOs were requested the validity of GPIOs were checked only when the GPIO-chip had the request -callback populated. This made using masked GPIOs possible. The GPIO chip driver authors may find it difficult to understand the relation of enforsing the GPIO validity and the 'request' -callback because the current documentation for the 'request' callback does not mention this. It only states: * @request: optional hook for chip-specific activation, such as * enabling module power and clock; may sleep The validity of the GPIO line should be checked whether the driver provides the 'request' callback or not. Unconditionally check the GPIO validity when GPIO is being requested. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/cd5e067b80e1bb590027bc3bfa817e7f794f21c3.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: rcar: Use raw_spinlock to protect register accessNiklas Söderlund
Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access. [ 4.239592] ============================= [ 4.239595] [ BUG: Invalid wait context ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 is trying to lock: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] other info that might help us debug this: [ 4.239643] context-{5:5} [ 4.239646] 5 locks held by kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz [ 4.304082] stack backtrace: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 4.304097] Workqueue: async async_run_entry_fn [ 4.304106] Call trace: [ 4.304110] show_stack+0x14/0x20 (C) [ 4.304122] dump_stack_lvl+0x6c/0x90 [ 4.304131] dump_stack+0x14/0x1c [ 4.304138] __lock_acquire+0xdfc/0x1584 [ 4.426274] lock_acquire+0x1c4/0x33c [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: link resume succeeded after 1 retries [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_for_each_drv+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] worker_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_from_fork+0x10/0x20 Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250121135833.3769310-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: aggregator: protect driver attr handlers against module unloadKoichiro Den
Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held. Add try_module_get() in these handlers. For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]--- Fixes: 828546e24280 ("gpio: Add GPIO Aggregator") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den <koichiro.den@canonical.com> Link: https://lore.kernel.org/r/20250224143134.3024598-2-koichiro.den@canonical.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-05gpio: loongson-64bit: Add more gpio chip supportBinbin Zhou
The Loongson-7A2000 and Loongson-3A6000 share the same gpio chip model. Just add them through driver_data. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Acked-by: Huacai Chen <chenhuacai@loongson.cn> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250303074552.3335186-2-zhoubinbin@loongson.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-04gpiolib-acpi: Drop unneeded ERR_CAST() in __acpi_find_gpio()Andy Shevchenko
The checked type by PTR_ERR() is the same as returned by __acpi_find_gpio(). Hence there is no need to cast, drop it. Acked-by: Mika Westerberg <westeri@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-03-04gpiolib: Align FLAG_* definitions in the struct gpio_descAndy Shevchenko
Align FLAG_* definitions in the struct gpio_desc for better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250303160341.1322640-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-04gpiolib: of: Handle threecell GPIO chipsLinus Walleij
When describing GPIO controllers in the device tree, the ambition of device tree to describe the hardware may require a three-cell scheme: gpios = <&gpio instance offset flags>; This implements support for this scheme in the gpiolib OF core. Drivers that want to handle multiple gpiochip instances from one OF node need to implement a callback similar to this to determine if a certain gpio chip is a pointer to the right instance (pseudo-code): struct my_gpio { struct gpio_chip gcs[MAX_CHIPS]; }; static bool my_of_node_instance_match(struct gpio_chip *gc unsigned int instance) { struct my_gpio *mg = gpiochip_get_data(gc); if (instance >= MAX_CHIPS) return false; return (gc == &mg->gcs[instance]); } probe() { struct my_gpio *mg; struct gpio_chip *gc; int i, ret; for (i = 0; i++; i < MAX_CHIPS) { gc = &mg->gcs[i]; /* This tells gpiolib we have several instances per node */ gc->of_gpio_n_cells = 3; gc->of_node_instance_match = my_of_node_instance_match; gc->base = -1; ... ret = devm_gpiochip_add_data(dev, gc, mg); if (ret) return ret; } } Rename the "simple" of_xlate function to "twocell" which is closer to what it actually does. In the device tree bindings, the provide node needs to specify #gpio-cells = <3>; where the first cell is the instance number: gpios = <&gpio instance offset flags>; Conversely ranges need to have four cells: gpio-ranges = <&pinctrl instance gpio_offset pin_offset count>; Reviewed-by: Alex Elder <elder@riscstar.com> Tested-by: Yixun Lan <dlan@gentoo.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250225-gpio-ranges-fourcell-v3-2-860382ba4713@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-04gpiolib: of: Use local variablesLinus Walleij
Instead of modifying the contents of the array of values read in from a phandle, use local variables to store the values. This makes the code easier to read and the array immutable. Reviewed-by: Alex Elder <elder@riscstar.com> Tested-by: Yixun Lan <dlan@gentoo.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250225-gpio-ranges-fourcell-v3-1-860382ba4713@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-03gpiolib: update kerneldocs for value settersBartosz Golaszewski
Value setters now return int and can indicate failure. Update the kerneldocs. Link: https://lore.kernel.org/r/20250227083748.22400-2-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-03gpiolib: remove unneeded WARN_ON() from gpiochip_set_multiple()Bartosz Golaszewski
GPIO drivers are not required to support set_multiple() - the core will fallback to calling set() for each line if it's missing. Remove the offending check from gpiochip_set_multiple(). Fixes: 98ce1eb1fd87 ("gpiolib: introduce gpio_chip setters that return values") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ab3e42c0-70fa-48e0-ac93-ecbffef63507@samsung.com/ Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250227152831.59784-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-03-03Merge tag 'v6.14-rc5' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc5
2025-02-28gpiolib: Fix Oops in gpiod_direction_input_nonotify()Dan Carpenter
The gpiod_direction_input_nonotify() function is supposed to return zero if the direction for the pin is input. But instead it accidentally returns GPIO_LINE_DIRECTION_IN (1) which will be cast into an ERR_PTR() in gpiochip_request_own_desc(). The callers dereference it and it leads to a crash. I changed gpiod_direction_output_raw_commit() just for consistency but returning GPIO_LINE_DIRECTION_OUT (0) is fine. Cc: stable@vger.kernel.org Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/254f3925-3015-4c9d-aac5-bb9b4b2cd2c5@stanley.mountain [Bartosz: moved the variable declarations to the top of the functions] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-27gpiolib: don't double-check the gc->get callback's existenceBartosz Golaszewski
gpiochip_get() is called only in two places: in gpio_chip_get_value() and in gpiochip_get_multiple() where the existence of the gc->get() callback is already checked. It makes sense to unduplicate the check by moving it one level up the stack. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Closes: https://lore.kernel.org/all/Z7yekJ8uRh8dphKn@black.fi.intel.com/ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250226-retval-fixes-v2-3-c8dc57182441@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-27gpiolib: use a more explicit retval logic in gpiochip_get_direction()Bartosz Golaszewski
We have existing macros for direction settings so we don't need to rely on the magic value of 1 in the retval check. Use readable logic that explicitly says we expect INPUT, OUTPUT or a negative errno and nothing else in gpiochip_get_direction(). Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Closes: https://lore.kernel.org/all/Z7yfTggRrk3K6srs@black.fi.intel.com/ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250226-retval-fixes-v2-2-c8dc57182441@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-27gpiolib: don't use gpiochip_get_direction() when registering a chipBartosz Golaszewski
During chip registration we should neither check the return value of gc->get_direction() nor hold the SRCU lock when calling it. The former is because pin controllers may have pins set to alternate functions and return errors from their get_direction() callbacks. That's alright - we should default to the safe INPUT state and not bail-out. The latter is not needed because we haven't registered the chip yet so there's nothing to protect against dynamic removal. In fact: we currently hit a lockdep splat. Revert to calling the gc->get_direction() callback directly and *not* checking its value. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/81f890fc-6688-42f0-9756-567efc8bb97a@samsung.com/ Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20250226-retval-fixes-v2-1-c8dc57182441@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: pcf857x: add support for reset-gpios on (most) PCA967xQuentin Schulz
The PCA9670, PCA9671, PCA9672 and PCA9673 all have a RESETN input pin that is used to reset the I2C GPIO expander. One needs to hold this pin low for at least 4us and the reset should be finished after about 100us according to the datasheet[1]. Once the reset is done, the "registers and I2C-bus state machine will be held in their default state until the RESET input is once again HIGH.". Because the logic is reset, the latch values eventually provided in the Device Tree via lines-initial-states property are inapplicable so they are simply ignored if a reset GPIO is provided. [1] https://www.nxp.com/docs/en/data-sheet/PCA9670.pdf 8.5 and fig 22. Tested-by: Heiko Stuebner <heiko@sntech.de> # RK3588 Tiger Haikou Video Demo Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250224-pca976x-reset-driver-v3-2-58370ef405be@cherry.de Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: mvebu: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-15-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: davinci: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-14-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: latch: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-13-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: latch: use lock guardsBartosz Golaszewski
Use lock guards from linux/cleanup.h. This will make the subsequent commit that switches to using value returning GPIO line setters much simpler as we'll be able to return values without caring about releasing the locks. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-12-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: max77650: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-11-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: aggregator: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-10-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: mockup: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-9-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: pca953x: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-8-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpio: regmap: use value returning settersBartosz Golaszewski
struct gpio_chip now has additional variants of the set(_multiple) driver callbacks that return an integer to indicate success or failure. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Michael Walle <mwalle@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-7-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>