mbox series

[v2,00/13] gpiolib: add gpiod_multi_set_value_cansleep

Message ID 20250206-gpio-set-array-helper-v2-0-1c5f048f79c3@baylibre.com
Headers show
Series gpiolib: add gpiod_multi_set_value_cansleep | expand

Message

David Lechner Feb. 6, 2025, 10:48 p.m. UTC
This series was inspired by some minor annoyance I have experienced a
few times in recent reviews.

Calling gpiod_set_array_value_cansleep() can be quite verbose due to
having so many parameters. In most cases, we already have a struct
gpio_descs that contains the first 3 parameters so we end up with 3 (or
often even 6) pointer indirections at each call site. Also, people have
a tendency to want to hard-code the first argument instead of using
struct gpio_descs.ndescs, often without checking that ndescs >= the
hard-coded value.

So I'm proposing that we add a gpiod_multi_set_value_cansleep()
function that is a wrapper around gpiod_set_array_value_cansleep()
that has struct gpio_descs as the first parameter to make it a bit
easier to read the code and avoid the hard-coding temptation.

I've just done gpiod_multi_set_value_cansleep() for now since there
were over 10 callers of this one. There aren't as many callers of
the get and atomic variants, but we can add those too if this seems
like a useful thing to do.

Maintainers, if you prefer to have this go through the gpio tree, please
give your Acked-by:, otherwise I will resend what is left after the next
kernel release.

---
Changes in v2:
- Renamed new function from gpiods_multi_set_value_cansleep() to
  gpiod_multi_set_value_cansleep()
- Fixed typo in name of replaced function in all commit messages.
- Picked up trailers.
- Link to v1: https://lore.kernel.org/r/20250131-gpio-set-array-helper-v1-0-991c8ccb4d6e@baylibre.com

---
David Lechner (13):
      gpiolib: add gpiod_multi_set_value_cansleep()
      auxdisplay: seg-led-gpio: use gpiod_multi_set_value_cansleep
      bus: ts-nbus: validate ts,data-gpios array size
      bus: ts-nbus: use gpiod_multi_set_value_cansleep
      gpio: max3191x: use gpiod_multi_set_value_cansleep
      iio: adc: ad7606: use gpiod_multi_set_value_cansleep
      iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep
      iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep
      mmc: pwrseq_simple: use gpiod_multi_set_value_cansleep
      mux: gpio: use gpiod_multi_set_value_cansleep
      net: mdio: mux-gpio: use gpiod_multi_set_value_cansleep
      phy: mapphone-mdm6600: use gpiod_multi_set_value_cansleep
      ASoC: adau1701: use gpiod_multi_set_value_cansleep

 drivers/auxdisplay/seg-led-gpio.c           |  3 +--
 drivers/bus/ts-nbus.c                       | 10 ++++++----
 drivers/gpio/gpio-max3191x.c                | 18 +++++++-----------
 drivers/iio/adc/ad7606.c                    |  3 +--
 drivers/iio/adc/ad7606_spi.c                |  3 +--
 drivers/iio/amplifiers/hmc425a.c            |  3 +--
 drivers/iio/resolver/ad2s1210.c             |  8 ++------
 drivers/mmc/core/pwrseq_simple.c            |  3 +--
 drivers/mux/gpio.c                          |  4 +---
 drivers/net/mdio/mdio-mux-gpio.c            |  3 +--
 drivers/phy/motorola/phy-mapphone-mdm6600.c |  4 +---
 include/linux/gpio/consumer.h               |  7 +++++++
 sound/soc/codecs/adau1701.c                 |  4 +---
 13 files changed, 31 insertions(+), 42 deletions(-)
---
base-commit: df4b2bbff898227db0c14264ac7edd634e79f755
change-id: 20250131-gpio-set-array-helper-bd4a328370d3

Best regards,

Comments

Jonathan Cameron Feb. 8, 2025, 1:20 p.m. UTC | #1
On Fri, 7 Feb 2025 14:20:16 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 7, 2025 at 11:48 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Fri, 7 Feb 2025 at 08:49, Bartosz Golaszewski <brgl@bgdev.pl> wrote:  
> > > On Thu, Feb 6, 2025 at 11:48 PM David Lechner <dlechner@baylibre.com> wrote:  
> 
> ...
> 
> > > > Maintainers, if you prefer to have this go through the gpio tree, please
> > > > give your Acked-by:, otherwise I will resend what is left after the next
> > > > kernel release.  
> 
> > > I can provide an immutable branch for the entire series for everyone
> > > to pull or I can apply patch one, provide an immutable branch and
> > > every subsystem can take their respective patches. What do you prefer?  
> >
> > The changes look small and trivial to me. I wouldn't mind if you take
> > them all (at least for mmc). An immutable branch would be good, if it
> > turns out that we need to pull them.  
> 
> +1 here, the potential user for immutable branch/tag is IIO.
> The rest looks trivial and unlikely to have conflicts.

Whilst I'm not sure if we'll need it, definitely good to have immutable
branch just in case.

There is another change to the ad7606 on list, but it's no where near
this code so shouldn't be a problem however this goes in.
My slight preference would be an immutable with a tag on patch 1.
I'll pull that and apply the IIO ones on top.

If you want to grab the lot though that should be fine as well.

Jonathan

>