| Message ID | 20250210-gpio-set-array-helper-v3-0-d6a673674da8@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gpiolib: add gpiod_multi_set_value_cansleep | expand |
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. > > [...] Applied, thanks! [01/15] gpiolib: add gpiod_multi_set_value_cansleep() commit: 91931af18bd22437e08e2471f5484d6fbdd8ab93 Best regards,
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. > > [...] Applied, thanks! [06/15] gpio: max3191x: use gpiod_multi_set_value_cansleep commit: eb2e9c308d2882d9d364af048eb3d8336d41c4bb Best regards,
On 2/12/25 3:36 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. >> >> [...] > > Applied, thanks! > > [06/15] gpio: max3191x: use gpiod_multi_set_value_cansleep > commit: eb2e9c308d2882d9d364af048eb3d8336d41c4bb > > Best regards, Hi Bartosz, Do you plan to pick up the other patches that have been acked as well? It seems like most folks were OK with everything going though the gpio tree since the changes are small.
On Thu, Feb 13, 2025 at 11:25:21AM -0600, David Lechner wrote: > On 2/12/25 3:36 AM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> [...] > > Applied, thanks! > > > > [06/15] gpio: max3191x: use gpiod_multi_set_value_cansleep > > commit: eb2e9c308d2882d9d364af048eb3d8336d41c4bb > > Do you plan to pick up the other patches that have been acked > as well? It seems like most folks were OK with everything going > though the gpio tree since the changes are small. FWIW, I took auxdisplay one via the respective tree. But please tell me, if you are going to take them all, I will drop that in my tree.
On Thu, Feb 13, 2025 at 6:25 PM David Lechner <dlechner@baylibre.com> wrote: > > On 2/12/25 3:36 AM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. > >> > >> [...] > > > > Applied, thanks! > > > > [06/15] gpio: max3191x: use gpiod_multi_set_value_cansleep > > commit: eb2e9c308d2882d9d364af048eb3d8336d41c4bb > > > > Best regards, > > Hi Bartosz, > > Do you plan to pick up the other patches that have been acked > as well? It seems like most folks were OK with everything going > though the gpio tree since the changes are small. > Jonathan requested a branch so I made one and sent out a PR. I figured people would just pick the relevant patches into their respective trees? For patches that won't be in next by rc5 - I will take them if Acked - just remind me. Bart
On Thu, Feb 13, 2025 at 06:42:19PM +0100, Bartosz Golaszewski wrote: > On Thu, Feb 13, 2025 at 6:25 PM David Lechner <dlechner@baylibre.com> wrote: > > Do you plan to pick up the other patches that have been acked > > as well? It seems like most folks were OK with everything going > > though the gpio tree since the changes are small. > Jonathan requested a branch so I made one and sent out a PR. I figured > people would just pick the relevant patches into their respective > trees? For patches that won't be in next by rc5 - I will take them if > Acked - just remind me. If people are acking things that generally means they're expecting them to go along with the rest of the series. When you didn't apply the ASoC patch I did actually put into CI but it was a bit surprising that you seemed to be expecting that.
On Thu, Feb 13, 2025 at 6:53 PM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Feb 13, 2025 at 06:42:19PM +0100, Bartosz Golaszewski wrote: > > On Thu, Feb 13, 2025 at 6:25 PM David Lechner <dlechner@baylibre.com> wrote: > > > > Do you plan to pick up the other patches that have been acked > > > as well? It seems like most folks were OK with everything going > > > though the gpio tree since the changes are small. > > > Jonathan requested a branch so I made one and sent out a PR. I figured > > people would just pick the relevant patches into their respective > > trees? For patches that won't be in next by rc5 - I will take them if > > Acked - just remind me. > > If people are acking things that generally means they're expecting them > to go along with the rest of the series. When you didn't apply the ASoC > patch I did actually put into CI but it was a bit surprising that you > seemed to be expecting that. There was no clear consensus. Some patches are still not acked. No worries, I will take the acked ones. I didn't see any b4 notifications from your side yet, so I assume the patches are still pending? Bart
On Thu, Feb 13, 2025 at 06:58:04PM +0100, Bartosz Golaszewski wrote: > On Thu, Feb 13, 2025 at 6:53 PM Mark Brown <broonie@kernel.org> wrote: > > If people are acking things that generally means they're expecting them > > to go along with the rest of the series. When you didn't apply the ASoC > > patch I did actually put into CI but it was a bit surprising that you > > seemed to be expecting that. > There was no clear consensus. Some patches are still not acked. What I would do in that situation is apply the patches that were acked and leave the rest. > No worries, I will take the acked ones. I didn't see any b4 > notifications from your side yet, so I assume the patches are still > pending? Yes, like I say they're in CI.
On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [15/15] ASoC: adau1701: use gpiod_multi_set_value_cansleep commit: ad0fbcebb5f6e093d433a0873758a2778d747eb8 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner 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. > > [...] Applied, thanks! [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep commit: e18d359b0a132eb6619836d1bf701f5b3b53299b [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f [10/15] iio: resolver: ad2s1210: use bitmap_write commit: a67e45055ea90048372066811da7c7fe2d91f9aa [11/15] mmc: pwrseq_simple: use gpiod_multi_set_value_cansleep commit: 2a5920429897201f75ba026c8aa3488c792b3bd7 [12/15] mux: gpio: use gpiod_multi_set_value_cansleep commit: 47a7c4f58e1f9967eb0ea6c1cb2c29e0ad2edb1a [14/15] phy: mapphone-mdm6600: use gpiod_multi_set_value_cansleep commit: c88aa68297390695b16fd9b7a33612257d8ef548 Best regards,
On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > This series was inspired by some minor annoyance I have experienced a > > few times in recent reviews. ... > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > [10/15] iio: resolver: ad2s1210: use bitmap_write > commit: a67e45055ea90048372066811da7c7fe2d91f9aa FWIW, Jonathan usually takes care of patch queue on weekends. But whatever, it's not my business after all :-)
On Fri, Feb 14, 2025 at 3:35 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > > This series was inspired by some minor annoyance I have experienced a > > > few times in recent reviews. > > ... > > > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > > [10/15] iio: resolver: ad2s1210: use bitmap_write > > commit: a67e45055ea90048372066811da7c7fe2d91f9aa > > FWIW, Jonathan usually takes care of patch queue on weekends. > But whatever, it's not my business after all :-) > Too many conflicting suggestions. I just picked up all Acked patches. ¯\_(ツ)_/¯ Bart
On Fri, 14 Feb 2025 15:37:48 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > On Fri, Feb 14, 2025 at 3:35 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > > > This series was inspired by some minor annoyance I have experienced a > > > > few times in recent reviews. > > > > ... > > > > > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > > > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > > > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > > > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > > > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > > > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > > > [10/15] iio: resolver: ad2s1210: use bitmap_write > > > commit: a67e45055ea90048372066811da7c7fe2d91f9aa > > > > FWIW, Jonathan usually takes care of patch queue on weekends. > > But whatever, it's not my business after all :-) > > > > Too many conflicting suggestions. I just picked up all Acked patches. ¯\_(ツ)_/¯ Resolution of any issues 'should' be easy enough. Let's keep an eye on how it goes as other series hit Linux next. Might be a little work to be done there and by Linus in next merge window. Jonathan > > Bart
On Sun, Feb 16, 2025 at 3:23 PM Jonathan Cameron <jic23@kernel.org> wrote: > > On Fri, 14 Feb 2025 15:37:48 +0100 > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > On Fri, Feb 14, 2025 at 3:35 PM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > > > > On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > > > > This series was inspired by some minor annoyance I have experienced a > > > > > few times in recent reviews. > > > > > > ... > > > > > > > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > > > > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > > > > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > > > > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > > > > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > > > > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > > > > [10/15] iio: resolver: ad2s1210: use bitmap_write > > > > commit: a67e45055ea90048372066811da7c7fe2d91f9aa > > > > > > FWIW, Jonathan usually takes care of patch queue on weekends. > > > But whatever, it's not my business after all :-) > > > > > > > Too many conflicting suggestions. I just picked up all Acked patches. ¯\_(ツ)_/¯ > > Resolution of any issues 'should' be easy enough. Let's keep an eye on how > it goes as other series hit Linux next. Might be a little work to be done there > and by Linus in next merge window. > > Jonathan > I'm totally fine with removing the iio commits from my queue if you prefer to take them. Bartosz
On Sun, 16 Feb 2025 16:55:04 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > On Sun, Feb 16, 2025 at 3:23 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > On Fri, 14 Feb 2025 15:37:48 +0100 > > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > On Fri, Feb 14, 2025 at 3:35 PM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > > > > > On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > > > > > This series was inspired by some minor annoyance I have experienced a > > > > > > few times in recent reviews. > > > > > > > > ... > > > > > > > > > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > > > > > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > > > > > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > > > > > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > > > > > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > > > > > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > > > > > [10/15] iio: resolver: ad2s1210: use bitmap_write > > > > > commit: a67e45055ea90048372066811da7c7fe2d91f9aa > > > > > > > > FWIW, Jonathan usually takes care of patch queue on weekends. > > > > But whatever, it's not my business after all :-) > > > > > > > > > > Too many conflicting suggestions. I just picked up all Acked patches. ¯\_(ツ)_/¯ > > > > Resolution of any issues 'should' be easy enough. Let's keep an eye on how > > it goes as other series hit Linux next. Might be a little work to be done there > > and by Linus in next merge window. > > > > Jonathan > > > > I'm totally fine with removing the iio commits from my queue if you > prefer to take them. > Hi Bartosz, That's probably going to prove slightly less painful, so please do. I'll merge in that immutable tag and pick them up once you've dropped them. Jonathan > Bartosz
On Mon, 10 Feb 2025 16:33:26 -0600 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 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:. Several maintainers have also requested an > immutable branch, so I expect that will be made available. And if there > is anything leftover after the next kernel release, I will resend it. I've applied 7-10 to the IIO tree after merging the immutable tag with patch 1. Jonathan > > --- > Changes in v3: > - Added IS_ERR_OR_NULL() check to gpiod_multi_set_value_cansleep() > - Added new patches to clean up accessing bitmap directly (ts-nbus, ad2s1210). > - Added function prefix for max3191x. > - Removed unnecessary braces in ad7606 patch. > - Picked up additional trailers. > - Link to v2: https://lore.kernel.org/r/20250206-gpio-set-array-helper-v2-0-1c5f048f79c3@baylibre.com > > 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 (15): > 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 > bus: ts-nbus: use bitmap_get_value8() > 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 > iio: resolver: ad2s1210: use bitmap_write > 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 | 15 +++++++++------ > drivers/gpio/gpio-max3191x.c | 18 +++++++----------- > drivers/iio/adc/ad7606.c | 3 +-- > drivers/iio/adc/ad7606_spi.c | 7 +++---- > drivers/iio/amplifiers/hmc425a.c | 3 +-- > drivers/iio/resolver/ad2s1210.c | 13 +++++-------- > 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 | 11 +++++++++++ > sound/soc/codecs/adau1701.c | 4 +--- > 13 files changed, 43 insertions(+), 48 deletions(-) > --- > base-commit: df4b2bbff898227db0c14264ac7edd634e79f755 > change-id: 20250131-gpio-set-array-helper-bd4a328370d3 > > Best regards,
On Mon, Feb 17, 2025 at 2:11 PM Jonathan Cameron <jic23@kernel.org> wrote: > > On Sun, 16 Feb 2025 16:55:04 +0100 > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > On Sun, Feb 16, 2025 at 3:23 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > On Fri, 14 Feb 2025 15:37:48 +0100 > > > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > On Fri, Feb 14, 2025 at 3:35 PM Andy Shevchenko > > > > <andy.shevchenko@gmail.com> wrote: > > > > > > > > > > On Fri, Feb 14, 2025 at 12:21 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > On Mon, 10 Feb 2025 16:33:26 -0600, David Lechner wrote: > > > > > > > This series was inspired by some minor annoyance I have experienced a > > > > > > > few times in recent reviews. > > > > > > > > > > ... > > > > > > > > > > > [07/15] iio: adc: ad7606: use gpiod_multi_set_value_cansleep > > > > > > commit: 8203bc81f025a3fb084357a3d8a6eb3053bc613a > > > > > > [08/15] iio: amplifiers: hmc425a: use gpiod_multi_set_value_cansleep > > > > > > commit: e18d359b0a132eb6619836d1bf701f5b3b53299b > > > > > > [09/15] iio: resolver: ad2s1210: use gpiod_multi_set_value_cansleep > > > > > > commit: 7920df29f0dd3aae3acd8a7115d5a25414eed68f > > > > > > [10/15] iio: resolver: ad2s1210: use bitmap_write > > > > > > commit: a67e45055ea90048372066811da7c7fe2d91f9aa > > > > > > > > > > FWIW, Jonathan usually takes care of patch queue on weekends. > > > > > But whatever, it's not my business after all :-) > > > > > > > > > > > > > Too many conflicting suggestions. I just picked up all Acked patches. ¯\_(ツ)_/¯ > > > > > > Resolution of any issues 'should' be easy enough. Let's keep an eye on how > > > it goes as other series hit Linux next. Might be a little work to be done there > > > and by Linus in next merge window. > > > > > > Jonathan > > > > > > > I'm totally fine with removing the iio commits from my queue if you > > prefer to take them. > > > Hi Bartosz, > > That's probably going to prove slightly less painful, so please do. > I'll merge in that immutable tag and pick them up once you've dropped them. > Done, you can push your branch out and the next "next" should be ok now. Bart
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:. Several maintainers have also requested an immutable branch, so I expect that will be made available. And if there is anything leftover after the next kernel release, I will resend it. --- Changes in v3: - Added IS_ERR_OR_NULL() check to gpiod_multi_set_value_cansleep() - Added new patches to clean up accessing bitmap directly (ts-nbus, ad2s1210). - Added function prefix for max3191x. - Removed unnecessary braces in ad7606 patch. - Picked up additional trailers. - Link to v2: https://lore.kernel.org/r/20250206-gpio-set-array-helper-v2-0-1c5f048f79c3@baylibre.com 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 (15): 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 bus: ts-nbus: use bitmap_get_value8() 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 iio: resolver: ad2s1210: use bitmap_write 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 | 15 +++++++++------ drivers/gpio/gpio-max3191x.c | 18 +++++++----------- drivers/iio/adc/ad7606.c | 3 +-- drivers/iio/adc/ad7606_spi.c | 7 +++---- drivers/iio/amplifiers/hmc425a.c | 3 +-- drivers/iio/resolver/ad2s1210.c | 13 +++++-------- 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 | 11 +++++++++++ sound/soc/codecs/adau1701.c | 4 +--- 13 files changed, 43 insertions(+), 48 deletions(-) --- base-commit: df4b2bbff898227db0c14264ac7edd634e79f755 change-id: 20250131-gpio-set-array-helper-bd4a328370d3 Best regards,