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(-)
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,
--
David Lechner <dlechner@baylibre.com>
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,
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,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
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 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 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. -- With Best Regards, Andy Shevchenko
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,
--
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 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,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
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 :-) -- With Best Regards, Andy Shevchenko
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, 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
© 2016 - 2026 Red Hat, Inc.