The value setter callbacks (both for single and multiple lines) return void even though we have many types of controllers that can fail to set a line's value: i2c, SPI, USB, etc. For the consumer API: single line setters return void. Multiple line setters do have an integer return value but due to the above, they still cannot be used to indicate problems within the driver. This series proposes to start the process of converting the setters to returning int thus making it possible to propagate any errors to the user. The first patch addresses an existing issue in one of the leds drivers that will break after we change the GPIO consumer API. The second changes the consumer interfaces. This has no impact on any user (even though they don't currently check the retval) except for places where any of the functions are passed as function pointer arguments in which case we need to update the affected callers. I only identified one such place - the gpio-latch module. The third patch adds a wrapper around gpio_chip::set() to limit the number of places where this pointer is dereferenced to one making further work easier. Next we make the existing wrapper around gpio_chip::set_multiple() consistent with the one for set() in terms of the return value as well as SRCU and callback checks. Finally in patch 5 we add new variants of the set callbacks suffixed with "_rv" indicating that they return a value. We privilege them in the code only falling back to the old ones if the new ones aren't present. Patches that follow convert several drivers to using the new callbacks to start the process. My long term plan for this rework is the following: 1. Get this intitial series into the GPIO tree and next. Make sure it doesn't cause problems. 2. Start to convert drivers under drivers/gpio/ until the end of this cycle. 3. After v6.15-rc1 is tagged and the new callbacks are available upstream, start converting drivers outside of drivers/gpio/. For most part, this concerns drivers/pinctrl/ but we also have GPIO drivers scattered in media, sound, iio and old board files. 4. Once all GPIO chips are converted to using the new setters, remove the old callbacks and rename the new ones to the old name in one swift move across the tree (similarly to how the remove_new() was changed back to remove(). Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> --- Changes in v2: - add a leds patch that addresses an issue that would become visible after the consumer API change (reported by build bot after v1) - check the return values of reg_mask_xlate() in gpio-regmap - Link to v1: https://lore.kernel.org/r/20250211-gpio-set-retval-v1-0-52d3d613d7d3@xxxxxxxxxx --- Bartosz Golaszewski (15): leds: aw200xx: don't use return with gpiod_set_value() variants gpiolib: make value setters have return values gpiolib: wrap gpio_chip::set() gpiolib: rework the wrapper around gpio_chip::set_multiple() gpiolib: introduce gpio_chip setters that return values gpio: sim: use value returning setters gpio: regmap: use value returning setters gpio: pca953x: use value returning setters gpio: mockup: use value returning setters gpio: aggregator: use value returning setters gpio: max77650: use value returning setters gpio: latch: use lock guards gpio: latch: use value returning setters gpio: davinci: use value returning setters gpio: mvebu: use value returning setters drivers/gpio/gpio-aggregator.c | 38 +++++++----- drivers/gpio/gpio-davinci.c | 6 +- drivers/gpio/gpio-latch.c | 53 ++++++++-------- drivers/gpio/gpio-max77650.c | 14 ++--- drivers/gpio/gpio-mockup.c | 14 +++-- drivers/gpio/gpio-mvebu.c | 8 +-- drivers/gpio/gpio-pca953x.c | 17 +++--- drivers/gpio/gpio-regmap.c | 32 ++++++---- drivers/gpio/gpio-sim.c | 14 +++-- drivers/gpio/gpiolib.c | 133 +++++++++++++++++++++++++++++------------ drivers/leds/leds-aw200xx.c | 2 +- include/linux/gpio.h | 4 +- include/linux/gpio/consumer.h | 22 ++++--- include/linux/gpio/driver.h | 10 ++++ 14 files changed, 235 insertions(+), 132 deletions(-) --- base-commit: 50a0c754714aa3ea0b0e62f3765eb666a1579f24 change-id: 20250210-gpio-set-retval-41cd6baeead3 Best regards, -- Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
