summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)Author
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>
2025-02-26gpio: sim: 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-6-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpiolib: introduce gpio_chip setters that return valuesBartosz Golaszewski
Add new variants of the set() and set_multiple() callbacks that have integer return values allowing to indicate failures to users of the GPIO consumer API. Until we convert all GPIO providers treewide to using them, they will live in parallel to the existing ones. Make sure that providers cannot define both. Prefer the new ones and only use the old ones as fallback. 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-5-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpiolib: rework the wrapper around gpio_chip::set_multiple()Bartosz Golaszewski
Make the existing wrapper around gpio_chip::set_multiple() consistent with the one for gpio_chip::set(): make it return int, add a lockdep assertion, warn on missing set callback and move the code a bit for better readability. Add return value checks in all call places. 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-4-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpiolib: wrap gpio_chip::set()Bartosz Golaszewski
We have three places where we dereference the gpio_chip::set() callback. In order to make it easier to incorporate the upcoming new variant of this callback (one returning an integer value), wrap it in a helper so that the dereferencing only happens once. 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-3-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-26gpiolib: make value setters have return valuesBartosz Golaszewski
Change the in-kernel consumer interface for GPIOs: make all variants of value setters that don't have a return value, return a signed integer instead. That will allow these routines to indicate failures to callers. This doesn't change the implementation just yet, we'll do it in subsequent commits. We need to update the gpio-latch module as it passes the address of value setters as a function pointer argument and thus cares about its type. 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-2-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpio: vf610: Switch to gpio-mmioLinus Walleij
After adding a pinctrl flag to gpio-mmio we can use it for driving gpio-vf610. The existing code has the same semantics and the generic gpio-mmio, including reading from the data out register when the direction is set to input, and it can also handle the absence of the direction register better than the current driver: we get the direction from the shadow direction registers in gpio-mmio instead. Since gpio-mmio has an internal spinlock we can drop the direction-protecting spinlock from the driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Tested-by: Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/20250219-vf610-mmio-v3-2-588b64f0b689@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpio: mmio: Add flag for calling pinctrl back-endLinus Walleij
It turns out that with this flag we can switch over an entire driver to use gpio-mmio instead of a bunch of custom code, also providing get/set_multiple() to it in the process, so it seems like a reasonable feature to add. The generic pin control backend requires us to call the gpiochip_generic_request(), gpiochip_generic_free(), pinctrl_gpio_direction_output() and pinctrl_gpio_direction_input() callbacks, so if the new flag for a pin control back-end is set, we make sure these functions get called as expected. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250219-vf610-mmio-v3-1-588b64f0b689@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpio: virtuser: convert to use dev-sync-probe utilitiesKoichiro Den
Update gpio-virtuser to use the new dev-sync-probe helper functions for synchronized platform device creation, reducing code duplication. No functional change. Signed-off-by: Koichiro Den <koichiro.den@canonical.com> Link: https://lore.kernel.org/r/20250221133501.2203897-4-koichiro.den@canonical.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpio: sim: convert to use dev-sync-probe utilitiesKoichiro Den
Update gpio-sim to use the new dev-sync-probe helper functions for synchronized platform device creation, reducing code duplication. No functional change. Signed-off-by: Koichiro Den <koichiro.den@canonical.com> Link: https://lore.kernel.org/r/20250221133501.2203897-3-koichiro.den@canonical.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpio: introduce utilities for synchronous fake device creationKoichiro Den
Both gpio-sim and gpio-virtuser share a mechanism to instantiate a platform device, wait for probe completion, and retrieve the probe success or error status synchronously. With gpio-aggregator planned to adopt this approach for its configfs interface, it's time to factor out the common code. Add dev-sync-probe.[ch] to house helper functions used by all such implementations. No functional change. Signed-off-by: Koichiro Den <koichiro.den@canonical.com> Link: https://lore.kernel.org/r/20250221133501.2203897-2-koichiro.den@canonical.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: read descriptor flags once in gpiolib_dbg_show()Bartosz Golaszewski
For consistency with most other code that can access requested descriptors: read the flags once atomically and then test individual bits from the helper variable. This avoids any potential discrepancies should flags change during the debug print. Link: https://lore.kernel.org/r/20250215100847.30136-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::get_direction()Bartosz Golaszewski
As per the API contract, the get_direction() callback can only return 0, 1 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-8-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::direction_input()Bartosz Golaszewski
The return value of the direction_input() callback may be propagated to user-space. As per the API contract it can only return 0 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-7-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::direction_output()Bartosz Golaszewski
The return value of the direction_output() callback may be propagated to user-space. As per the API contract it can only return 0 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-6-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::get_multiple()Bartosz Golaszewski
As per the API contract, the get_multiple() callback is only allowed to return 0 or a negative error number. Filter out anything else. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-5-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::get()Bartosz Golaszewski
As per the API contract, the get() callback is only allowed to return 0, 1 or a negative error number. Add a wrapper around the callback calls that filters out anything else. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-4-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::set_config()Bartosz Golaszewski
The return value of the set_config() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-3-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24gpiolib: sanitize the return value of gpio_chip::request()Bartosz Golaszewski
The return value of the request() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-2-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-24Merge tag 'v6.14-rc4' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into HEAD Linux 6.14-rc4
2025-02-21gpio: regmap: Allow ngpio to be read from the propertyAndy Shevchenko
GPIOLIB supports the case when number of supported GPIOs can be read from the device property. Enable this for drivers that are using GPIO regmap layer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250213195621.3133406-6-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-21gpio: regmap: Move optional assignments down in the codeAndy Shevchenko
Move optional assignments down in the code, so they may use some values from the (updated) struct gpio_chip later on. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250213195621.3133406-5-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-21gpio: regmap: Group optional assignments together for better understandingAndy Shevchenko
Group ngpio_per_reg, reg_stride, and reg_mask_xlate assignments together with the respective conditional for better understanding what's going on in the code. While at it, mark ngpio_per_reg as (Optional) in the kernel-doc in accordance with what code actually does. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250213195621.3133406-4-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-21gpiolib: Use fwnode instead of device in gpiochip_get_ngpios()Andy Shevchenko
The gpiochip_get_ngpios() can be used in the cases where passed device is not a provider of the certain property. Use fwnode instead. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250213195621.3133406-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-21gpiolib: Extract gpiochip_choose_fwnode() for wider useAndy Shevchenko
Extract gpiochip_choose_fwnode() for the future use in another function. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250213195621.3133406-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-20gpiolib: don't bail out if get_direction() fails in gpiochip_add_data()Bartosz Golaszewski
Since commit 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") we check the return value of the get_direction() callback as per its API contract. Some drivers have been observed to fail to register now as they may call get_direction() in gpiochip_add_data() in contexts where it has always silently failed. Until we audit all drivers, replace the bail-out to a kernel log warning. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/Z7VFB1nST6lbmBIo@finisterre.sirena.org.uk/ Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/dfe03f88-407e-4ef1-ad30-42db53bbd4e4@samsung.com/ Tested-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20250219144356.258635-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-18gpiolib: don't build HTE code with CONFIG_HTE disabledBartosz Golaszewski
Hardware timestamping is only used on tegra186 platforms but we include the code and export the symbols everywhere. Shrink the binary a bit by compiling the relevant functions conditionally. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250217103922.151047-2-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-18gpiolib: protect gpio_chip with SRCU in array_info paths in multi get/setBartosz Golaszewski
During the locking rework in GPIOLIB, we omitted one important use-case, namely: setting and getting values for GPIO descriptor arrays with array_info present. This patch does two things: first it makes struct gpio_array store the address of the underlying GPIO device and not chip. Next: it protects the chip with SRCU from removal in gpiod_get_array_value_complex() and gpiod_set_array_value_complex(). Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250215095655.23152-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>