| Message ID | 20250131-gpio-set-array-helper-v1-0-991c8ccb4d6e@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gpiolib: add gpiods_set_array_value_cansleep | expand |
> So I'm proposing that we add a gpiods_set_array_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. This looks reasonable. How do you plan to get it merged, since you cross a lot of subsystems here. Andrew
On 1/31/25 2:38 PM, Andrew Lunn wrote: >> So I'm proposing that we add a gpiods_set_array_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. > > This looks reasonable. > > How do you plan to get it merged, since you cross a lot of subsystems > here. > > Andrew Since these are mostly small changes and most of the touched drivers aren't seeing much action, I think it would be OK for as much as possible to go through the GPIO tree. We might need an immutable branch from that though since I know that iio: adc: ad7606 is currently being actively worked on. If there are any patches leftover that don't get acked to go through the GPIO tree, I can resubmit them after the next kernel release cycle since none of this is urgent anyway.
Hi David, On Fri, Jan 31, 2025 at 9:24 PM David Lechner <dlechner@baylibre.com> wrote: > 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 gpiods_set_array_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 gpiods_set_array_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. I like it. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> for the series. Yours, Linus Walleij
On Fri, 31 Jan 2025 21:24:40 +0100, David Lechner <dlechner@baylibre.com> said: > 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 gpiods_set_array_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 gpiods_set_array_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. > > --- > David Lechner (13): > gpiolib: add gpiods_set_array_value_cansleep() > auxdisplay: seg-led-gpio: use gpiods_set_array_value_cansleep > bus: ts-nbus: validate ts,data-gpios array size > bus: ts-nbus: use gpiods_set_array_value_cansleep > gpio: max3191x: use gpiods_set_array_value_cansleep > iio: adc: ad7606: use gpiods_set_array_value_cansleep > iio: amplifiers: hmc425a: use gpiods_set_array_value_cansleep > iio: resolver: ad2s1210: use gpiods_set_array_value_cansleep > mmc: pwrseq_simple: use gpiods_set_array_value_cansleep > mux: gpio: use gpiods_set_array_value_cansleep > net: mdio: mux-gpio: use gpiods_set_array_value_cansleep > phy: mapphone-mdm6600: use gpiods_set_array_value_cansleep > ASoC: adau1701: use gpiods_set_array_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, > -- > David Lechner <dlechner@baylibre.com> > > This looks good to me except for one thing: the function prefix. I would really appreciate it if we could stay within the existing gpiod_ namespace and not add a new one in the form of gpiods_. Maybe: gpiod_multiple_set_ or gpiod_collected_set...? Bartosz
On Fri, 31 Jan 2025 14:51:52 -0600 David Lechner <dlechner@baylibre.com> wrote: > On 1/31/25 2:38 PM, Andrew Lunn wrote: > >> So I'm proposing that we add a gpiods_set_array_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. > > > > This looks reasonable. > > > > How do you plan to get it merged, since you cross a lot of subsystems > > here. > > > > Andrew > > Since these are mostly small changes and most of the touched drivers aren't > seeing much action, I think it would be OK for as much as possible to go through > the GPIO tree. > > We might need an immutable branch from that though since I know that iio: adc: > ad7606 is currently being actively worked on. Looks good to me (subject to requested name change from Bartosz) I'd suggest an immutable with patch 1 then up to each subsystem maintainer to pick that up or wait for next cycle. Always hard to predict what else will get worked on at this stage of a cycle. Jonathan > > If there are any patches leftover that don't get acked to go through the GPIO > tree, I can resubmit them after the next kernel release cycle since none of > this is urgent anyway. >
On Sat, Feb 1, 2025 at 12:36 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Fri, 31 Jan 2025 21:24:40 +0100, David Lechner <dlechner@baylibre.com> said: > > 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 gpiods_set_array_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 gpiods_set_array_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. > This looks good to me except for one thing: the function prefix. I would > really appreciate it if we could stay within the existing gpiod_ namespace and > not add a new one in the form of gpiods_. > > Maybe: gpiod_multiple_set_ or gpiod_collected_set...? +1 here, i.e. I like the idea, but the naming needs to be amended.
On 2/1/25 4:36 AM, Bartosz Golaszewski wrote: > On Fri, 31 Jan 2025 21:24:40 +0100, David Lechner <dlechner@baylibre.com> said: >> 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 gpiods_set_array_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 gpiods_set_array_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. >> >> --- >> David Lechner (13): >> gpiolib: add gpiods_set_array_value_cansleep() >> auxdisplay: seg-led-gpio: use gpiods_set_array_value_cansleep >> bus: ts-nbus: validate ts,data-gpios array size >> bus: ts-nbus: use gpiods_set_array_value_cansleep >> gpio: max3191x: use gpiods_set_array_value_cansleep >> iio: adc: ad7606: use gpiods_set_array_value_cansleep >> iio: amplifiers: hmc425a: use gpiods_set_array_value_cansleep >> iio: resolver: ad2s1210: use gpiods_set_array_value_cansleep >> mmc: pwrseq_simple: use gpiods_set_array_value_cansleep >> mux: gpio: use gpiods_set_array_value_cansleep >> net: mdio: mux-gpio: use gpiods_set_array_value_cansleep >> phy: mapphone-mdm6600: use gpiods_set_array_value_cansleep >> ASoC: adau1701: use gpiods_set_array_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, >> -- >> David Lechner <dlechner@baylibre.com> >> >> > > This looks good to me except for one thing: the function prefix. I would > really appreciate it if we could stay within the existing gpiod_ namespace and > not add a new one in the form of gpiods_. > > Maybe: gpiod_multiple_set_ or gpiod_collected_set...? > > Bartosz I was waiting for someone to complain about the naming. ;-) I was going for as short as possible, but OK, the most obvious prefix to me would be `gpio_descs_...` (to match the first parameter). Any objections to that?
On Sat, Feb 1, 2025 at 5:09 PM David Lechner <dlechner@baylibre.com> wrote: > > On 2/1/25 4:36 AM, Bartosz Golaszewski wrote: > > > > This looks good to me except for one thing: the function prefix. I would > > really appreciate it if we could stay within the existing gpiod_ namespace and > > not add a new one in the form of gpiods_. > > > > Maybe: gpiod_multiple_set_ or gpiod_collected_set...? > > > > Bartosz > > I was waiting for someone to complain about the naming. ;-) > > I was going for as short as possible, but OK, the most obvious prefix to me > would be `gpio_descs_...` (to match the first parameter). Any objections to > that? > Yes, objection! As far as any exported interfaces go: in my book "gpio_" is the prefix for legacy symbols we want to go away and "gpiod_" is the prefix for current, descriptor-based API. Anything else is a no-go. I prefer a longer name that starts with gpiod_ over anything that's shorter but doesn't. Bartosz
On 2/1/25 10:14 AM, Bartosz Golaszewski wrote: > On Sat, Feb 1, 2025 at 5:09 PM David Lechner <dlechner@baylibre.com> wrote: >> >> On 2/1/25 4:36 AM, Bartosz Golaszewski wrote: >>> >>> This looks good to me except for one thing: the function prefix. I would >>> really appreciate it if we could stay within the existing gpiod_ namespace and >>> not add a new one in the form of gpiods_. >>> >>> Maybe: gpiod_multiple_set_ or gpiod_collected_set...? >>> >>> Bartosz >> >> I was waiting for someone to complain about the naming. ;-) >> >> I was going for as short as possible, but OK, the most obvious prefix to me >> would be `gpio_descs_...` (to match the first parameter). Any objections to >> that? >> > > Yes, objection! As far as any exported interfaces go: in my book > "gpio_" is the prefix for legacy symbols we want to go away and > "gpiod_" is the prefix for current, descriptor-based API. Anything > else is a no-go. I prefer a longer name that starts with gpiod_ over > anything that's shorter but doesn't. > > Bartosz Oops, that was a typo. I meant to write gpiod_descs_.
On Sat, Feb 1, 2025 at 5:17 PM David Lechner <dlechner@baylibre.com> wrote: > > On 2/1/25 10:14 AM, Bartosz Golaszewski wrote: > > On Sat, Feb 1, 2025 at 5:09 PM David Lechner <dlechner@baylibre.com> wrote: > >> > >> On 2/1/25 4:36 AM, Bartosz Golaszewski wrote: > >>> > >>> This looks good to me except for one thing: the function prefix. I would > >>> really appreciate it if we could stay within the existing gpiod_ namespace and > >>> not add a new one in the form of gpiods_. > >>> > >>> Maybe: gpiod_multiple_set_ or gpiod_collected_set...? > >>> > >>> Bartosz > >> > >> I was waiting for someone to complain about the naming. ;-) > >> > >> I was going for as short as possible, but OK, the most obvious prefix to me > >> would be `gpio_descs_...` (to match the first parameter). Any objections to > >> that? > >> > > > > Yes, objection! As far as any exported interfaces go: in my book > > "gpio_" is the prefix for legacy symbols we want to go away and > > "gpiod_" is the prefix for current, descriptor-based API. Anything > > else is a no-go. I prefer a longer name that starts with gpiod_ over > > anything that's shorter but doesn't. > > > > Bartosz > > Oops, that was a typo. I meant to write gpiod_descs_. Eh... the D in gpioD already stands for "GPIO Descriptor" but if there's no better option in your opinion than I guess I can live with that. Bart
On Sat, Feb 1, 2025 at 6:22 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > On Sat, Feb 1, 2025 at 5:17 PM David Lechner <dlechner@baylibre.com> wrote: > > On 2/1/25 10:14 AM, Bartosz Golaszewski wrote: > > > On Sat, Feb 1, 2025 at 5:09 PM David Lechner <dlechner@baylibre.com> wrote: > > >> On 2/1/25 4:36 AM, Bartosz Golaszewski wrote: ... > > >>> This looks good to me except for one thing: the function prefix. I would > > >>> really appreciate it if we could stay within the existing gpiod_ namespace and > > >>> not add a new one in the form of gpiods_. > > >>> > > >>> Maybe: gpiod_multiple_set_ or gpiod_collected_set...? > > >> > > >> I was waiting for someone to complain about the naming. ;-) > > >> > > >> I was going for as short as possible, but OK, the most obvious prefix to me > > >> would be `gpio_descs_...` (to match the first parameter). Any objections to > > >> that? > > > > > > Yes, objection! As far as any exported interfaces go: in my book > > > "gpio_" is the prefix for legacy symbols we want to go away and > > > "gpiod_" is the prefix for current, descriptor-based API. Anything > > > else is a no-go. I prefer a longer name that starts with gpiod_ over > > > anything that's shorter but doesn't. > > > > Oops, that was a typo. I meant to write gpiod_descs_. > > Eh... the D in gpioD already stands for "GPIO Descriptor" but if > there's no better option in your opinion than I guess I can live with > that. gpiod_set_many_value_cansleep() ?
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 gpiods_set_array_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 gpiods_set_array_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. --- David Lechner (13): gpiolib: add gpiods_set_array_value_cansleep() auxdisplay: seg-led-gpio: use gpiods_set_array_value_cansleep bus: ts-nbus: validate ts,data-gpios array size bus: ts-nbus: use gpiods_set_array_value_cansleep gpio: max3191x: use gpiods_set_array_value_cansleep iio: adc: ad7606: use gpiods_set_array_value_cansleep iio: amplifiers: hmc425a: use gpiods_set_array_value_cansleep iio: resolver: ad2s1210: use gpiods_set_array_value_cansleep mmc: pwrseq_simple: use gpiods_set_array_value_cansleep mux: gpio: use gpiods_set_array_value_cansleep net: mdio: mux-gpio: use gpiods_set_array_value_cansleep phy: mapphone-mdm6600: use gpiods_set_array_value_cansleep ASoC: adau1701: use gpiods_set_array_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,