diff mbox series

[05/22] iio: replace bitmap_weight with bitmap_weitght_{eq,le} where appropriate

Message ID 20220510154750.212913-6-yury.norov@gmail.com (mailing list archive)
State New
Headers show
Series None | expand

Commit Message

Yury Norov May 10, 2022, 3:47 p.m. UTC
bitmap_weight_{eq,le} is better than bitmap_weight because it
may return earlier.

CC: Jonathan Cameron <jic23@kernel.org>
CC: Lars-Peter Clausen <lars@metafoo.de>
CC: Michael Hennerich <Michael.Hennerich@analog.com>
CC: linux-iio@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 drivers/iio/adc/ad_sigma_delta.c  | 2 +-
 drivers/iio/industrialio-buffer.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Jonathan Cameron May 14, 2022, 3:53 p.m. UTC | #1
On Tue, 10 May 2022 08:47:33 -0700
Yury Norov <yury.norov@gmail.com> wrote:

> bitmap_weight_{eq,le} is better than bitmap_weight because it
> may return earlier.
> 
> CC: Jonathan Cameron <jic23@kernel.org>
> CC: Lars-Peter Clausen <lars@metafoo.de>
> CC: Michael Hennerich <Michael.Hennerich@analog.com>
> CC: linux-iio@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
without being cc'd on the cover letter, there is no obvious way for
me to know this is reliant in some series to be found in next.

Please call out the exact dependency and whilst it's a long list,
it is good to cc all people cc'd on individual patches also
on the cover letter so they have that background information.

Change seems fine, but I've no idea when/if to pick it up because of
that lack of information.

Jonathan

> ---
>  drivers/iio/adc/ad_sigma_delta.c  | 2 +-
>  drivers/iio/industrialio-buffer.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c
> index 261a9a6b45e1..6445b591f071 100644
> --- a/drivers/iio/adc/ad_sigma_delta.c
> +++ b/drivers/iio/adc/ad_sigma_delta.c
> @@ -525,7 +525,7 @@ static bool ad_sd_validate_scan_mask(struct iio_dev *indio_dev, const unsigned l
>  {
>  	struct ad_sigma_delta *sigma_delta = iio_device_get_drvdata(indio_dev);
>  
> -	return bitmap_weight(mask, indio_dev->masklength) <= sigma_delta->num_slots;
> +	return bitmap_weight_le(mask, indio_dev->masklength, sigma_delta->num_slots);
>  }
>  
>  static const struct iio_buffer_setup_ops ad_sd_buffer_setup_ops = {
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index 06141ca27e1f..18d3d756aee1 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1824,7 +1824,7 @@ void iio_buffers_free_sysfs_and_mask(struct iio_dev *indio_dev)
>  bool iio_validate_scan_mask_onehot(struct iio_dev *indio_dev,
>  	const unsigned long *mask)
>  {
> -	return bitmap_weight(mask, indio_dev->masklength) == 1;
> +	return bitmap_weight_eq(mask, indio_dev->masklength, 1);
>  }
>  EXPORT_SYMBOL_GPL(iio_validate_scan_mask_onehot);
>
Joe Perches May 14, 2022, 4:31 p.m. UTC | #2
On Sat, 2022-05-14 at 16:53 +0100, Jonathan Cameron wrote:
> On Tue, 10 May 2022 08:47:33 -0700
> Yury Norov <yury.norov@gmail.com> wrote:
> 
> > bitmap_weight_{eq,le} is better than bitmap_weight because it
> > may return earlier.
> > 
> > CC: Jonathan Cameron <jic23@kernel.org>
> > CC: Lars-Peter Clausen <lars@metafoo.de>
> > CC: Michael Hennerich <Michael.Hennerich@analog.com>
> > CC: linux-iio@vger.kernel.org
> > CC: linux-kernel@vger.kernel.org
> > Signed-off-by: Yury Norov <yury.norov@gmail.com>
> without being cc'd on the cover letter, there is no obvious way for
> me to know this is reliant in some series to be found in next.
> 
> Please call out the exact dependency and whilst it's a long list,
> it is good to cc all people cc'd on individual patches also
> on the cover letter so they have that background information.

When doing a treewide change like this, vger would commonly
reject the message because of too many recipients.

> 
> Change seems fine, but I've no idea when/if to pick it up because of
> that lack of information.

You could try using lore with the in-reply-to message header id

https://lore.kernel.org/lkml/20220510154750.212913-6-yury.norov@gmail.com/

that gives you the entire thread.
Jonathan Cameron May 15, 2022, 4:40 p.m. UTC | #3
On Sat, 14 May 2022 09:31:23 -0700
Joe Perches <joe@perches.com> wrote:

> On Sat, 2022-05-14 at 16:53 +0100, Jonathan Cameron wrote:
> > On Tue, 10 May 2022 08:47:33 -0700
> > Yury Norov <yury.norov@gmail.com> wrote:
> >   
> > > bitmap_weight_{eq,le} is better than bitmap_weight because it
> > > may return earlier.
> > > 
> > > CC: Jonathan Cameron <jic23@kernel.org>
> > > CC: Lars-Peter Clausen <lars@metafoo.de>
> > > CC: Michael Hennerich <Michael.Hennerich@analog.com>
> > > CC: linux-iio@vger.kernel.org
> > > CC: linux-kernel@vger.kernel.org
> > > Signed-off-by: Yury Norov <yury.norov@gmail.com>  
> > without being cc'd on the cover letter, there is no obvious way for
> > me to know this is reliant in some series to be found in next.
> > 
> > Please call out the exact dependency and whilst it's a long list,
> > it is good to cc all people cc'd on individual patches also
> > on the cover letter so they have that background information.  
> 
> When doing a treewide change like this, vger would commonly
> reject the message because of too many recipients.

Hmm. I took a look via lore before sending this moan and didn't think
this actually had that large a list of CCs but maybe my counting wasn't
great (lots of overlaps between different patches).

The series is also not a tree wide change.
It's a set of changes related only by the fact they are using
a call to the same set of functions and the series is based
on next (which is usually a bad idea as a tree to base anything on).
Arguably there are two different sets of functions at that (the bitmap
ones and the cpumask ones)

This is a good set of changes, but taking it slowly and sending these
out as a number of different series after rc1 would have made
much more sense to me.  That way visibility would have been good
and they could have been applied through the various individual trees.

If there is a reason to want to take this via a common tree then
that information needs to be conveyed to all the subsystem maintainers.

Jonathan


> 
> > 
> > Change seems fine, but I've no idea when/if to pick it up because of
> > that lack of information.  
> 
> You could try using lore with the in-reply-to message header id
> 
> https://lore.kernel.org/lkml/20220510154750.212913-6-yury.norov@gmail.com/
> 
> that gives you the entire thread.
>
diff mbox series

Patch

diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c
index 261a9a6b45e1..6445b591f071 100644
--- a/drivers/iio/adc/ad_sigma_delta.c
+++ b/drivers/iio/adc/ad_sigma_delta.c
@@ -525,7 +525,7 @@  static bool ad_sd_validate_scan_mask(struct iio_dev *indio_dev, const unsigned l
 {
 	struct ad_sigma_delta *sigma_delta = iio_device_get_drvdata(indio_dev);
 
-	return bitmap_weight(mask, indio_dev->masklength) <= sigma_delta->num_slots;
+	return bitmap_weight_le(mask, indio_dev->masklength, sigma_delta->num_slots);
 }
 
 static const struct iio_buffer_setup_ops ad_sd_buffer_setup_ops = {
diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
index 06141ca27e1f..18d3d756aee1 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -1824,7 +1824,7 @@  void iio_buffers_free_sysfs_and_mask(struct iio_dev *indio_dev)
 bool iio_validate_scan_mask_onehot(struct iio_dev *indio_dev,
 	const unsigned long *mask)
 {
-	return bitmap_weight(mask, indio_dev->masklength) == 1;
+	return bitmap_weight_eq(mask, indio_dev->masklength, 1);
 }
 EXPORT_SYMBOL_GPL(iio_validate_scan_mask_onehot);