* [PATCH 04/49] iio: fix opencoded for_each_set_bit() [not found] <20220210224933.379149-1-yury.norov@gmail.com> @ 2022-02-10 22:48 ` Yury Norov 2022-02-11 8:45 ` Andy Shevchenko 2022-02-11 17:17 ` Christophe JAILLET 0 siblings, 2 replies; 5+ messages in thread From: Yury Norov @ 2022-02-10 22:48 UTC (permalink / raw) To: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton, Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel, Jonathan Cameron, Lars-Peter Clausen, Alexandru Ardelean, Nathan Chancellor, linux-iio iio_simple_dummy_trigger_h() is mostly an opencoded for_each_set_bit(). Using for_each_set_bit() make code much cleaner, and more effective. Signed-off-by: Yury Norov <yury.norov@gmail.com> --- drivers/iio/dummy/iio_simple_dummy_buffer.c | 48 ++++++++------------- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c index d81c2b2dad82..3bc1b7529e2a 100644 --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c @@ -45,41 +45,31 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p) { struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; + int i = 0, j; u16 *data; data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL); if (!data) goto done; - if (!bitmap_empty(indio_dev->active_scan_mask, indio_dev->masklength)) { - /* - * Three common options here: - * hardware scans: certain combinations of channels make - * up a fast read. The capture will consist of all of them. - * Hence we just call the grab data function and fill the - * buffer without processing. - * software scans: can be considered to be random access - * so efficient reading is just a case of minimal bus - * transactions. - * software culled hardware scans: - * occasionally a driver may process the nearest hardware - * scan to avoid storing elements that are not desired. This - * is the fiddliest option by far. - * Here let's pretend we have random access. And the values are - * in the constant table fakedata. - */ - int i, j; - - for (i = 0, j = 0; - i < bitmap_weight(indio_dev->active_scan_mask, - indio_dev->masklength); - i++, j++) { - j = find_next_bit(indio_dev->active_scan_mask, - indio_dev->masklength, j); - /* random access read from the 'device' */ - data[i] = fakedata[j]; - } - } + /* + * Three common options here: + * hardware scans: certain combinations of channels make + * up a fast read. The capture will consist of all of them. + * Hence we just call the grab data function and fill the + * buffer without processing. + * software scans: can be considered to be random access + * so efficient reading is just a case of minimal bus + * transactions. + * software culled hardware scans: + * occasionally a driver may process the nearest hardware + * scan to avoid storing elements that are not desired. This + * is the fiddliest option by far. + * Here let's pretend we have random access. And the values are + * in the constant table fakedata. + */ + for_each_set_bit(j, indio_dev->active_scan_mask, indio_dev->masklength) + data[i++] = fakedata[j]; iio_push_to_buffers_with_timestamp(indio_dev, data, iio_get_time_ns(indio_dev)); -- 2.32.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 04/49] iio: fix opencoded for_each_set_bit() 2022-02-10 22:48 ` [PATCH 04/49] iio: fix opencoded for_each_set_bit() Yury Norov @ 2022-02-11 8:45 ` Andy Shevchenko 2022-02-11 17:17 ` Christophe JAILLET 1 sibling, 0 replies; 5+ messages in thread From: Andy Shevchenko @ 2022-02-11 8:45 UTC (permalink / raw) To: Yury Norov Cc: Rasmus Villemoes, Andrew Morton, Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel, Jonathan Cameron, Lars-Peter Clausen, Alexandru Ardelean, Nathan Chancellor, linux-iio On Thu, Feb 10, 2022 at 02:48:48PM -0800, Yury Norov wrote: > iio_simple_dummy_trigger_h() is mostly an opencoded for_each_set_bit(). > Using for_each_set_bit() make code much cleaner, and more effective. I would wait for some testing, but from code perspective looks good. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Signed-off-by: Yury Norov <yury.norov@gmail.com> > --- > drivers/iio/dummy/iio_simple_dummy_buffer.c | 48 ++++++++------------- > 1 file changed, 19 insertions(+), 29 deletions(-) > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c > index d81c2b2dad82..3bc1b7529e2a 100644 > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c > @@ -45,41 +45,31 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p) > { > struct iio_poll_func *pf = p; > struct iio_dev *indio_dev = pf->indio_dev; > + int i = 0, j; > u16 *data; > > data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL); > if (!data) > goto done; > > - if (!bitmap_empty(indio_dev->active_scan_mask, indio_dev->masklength)) { > - /* > - * Three common options here: > - * hardware scans: certain combinations of channels make > - * up a fast read. The capture will consist of all of them. > - * Hence we just call the grab data function and fill the > - * buffer without processing. > - * software scans: can be considered to be random access > - * so efficient reading is just a case of minimal bus > - * transactions. > - * software culled hardware scans: > - * occasionally a driver may process the nearest hardware > - * scan to avoid storing elements that are not desired. This > - * is the fiddliest option by far. > - * Here let's pretend we have random access. And the values are > - * in the constant table fakedata. > - */ > - int i, j; > - > - for (i = 0, j = 0; > - i < bitmap_weight(indio_dev->active_scan_mask, > - indio_dev->masklength); > - i++, j++) { > - j = find_next_bit(indio_dev->active_scan_mask, > - indio_dev->masklength, j); > - /* random access read from the 'device' */ > - data[i] = fakedata[j]; > - } > - } > + /* > + * Three common options here: > + * hardware scans: certain combinations of channels make > + * up a fast read. The capture will consist of all of them. > + * Hence we just call the grab data function and fill the > + * buffer without processing. > + * software scans: can be considered to be random access > + * so efficient reading is just a case of minimal bus > + * transactions. > + * software culled hardware scans: > + * occasionally a driver may process the nearest hardware > + * scan to avoid storing elements that are not desired. This > + * is the fiddliest option by far. > + * Here let's pretend we have random access. And the values are > + * in the constant table fakedata. > + */ > + for_each_set_bit(j, indio_dev->active_scan_mask, indio_dev->masklength) > + data[i++] = fakedata[j]; > > iio_push_to_buffers_with_timestamp(indio_dev, data, > iio_get_time_ns(indio_dev)); > -- > 2.32.0 > -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 04/49] iio: fix opencoded for_each_set_bit() 2022-02-10 22:48 ` [PATCH 04/49] iio: fix opencoded for_each_set_bit() Yury Norov 2022-02-11 8:45 ` Andy Shevchenko @ 2022-02-11 17:17 ` Christophe JAILLET 2022-06-04 15:41 ` Jonathan Cameron 1 sibling, 1 reply; 5+ messages in thread From: Christophe JAILLET @ 2022-02-11 17:17 UTC (permalink / raw) To: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton, Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel, Jonathan Cameron, Lars-Peter Clausen, Alexandru Ardelean, Nathan Chancellor, linux-iio Le 10/02/2022 à 23:48, Yury Norov a écrit : > iio_simple_dummy_trigger_h() is mostly an opencoded for_each_set_bit(). > Using for_each_set_bit() make code much cleaner, and more effective. > > Signed-off-by: Yury Norov <yury.norov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > --- > drivers/iio/dummy/iio_simple_dummy_buffer.c | 48 ++++++++------------- > 1 file changed, 19 insertions(+), 29 deletions(-) > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c > index d81c2b2dad82..3bc1b7529e2a 100644 > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c > @@ -45,41 +45,31 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p) > { > struct iio_poll_func *pf = p; > struct iio_dev *indio_dev = pf->indio_dev; > + int i = 0, j; > u16 *data; > > data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL); > if (!data) > goto done; > > - if (!bitmap_empty(indio_dev->active_scan_mask, indio_dev->masklength)) { > - /* > - * Three common options here: > - * hardware scans: certain combinations of channels make > - * up a fast read. The capture will consist of all of them. > - * Hence we just call the grab data function and fill the > - * buffer without processing. > - * software scans: can be considered to be random access > - * so efficient reading is just a case of minimal bus > - * transactions. > - * software culled hardware scans: > - * occasionally a driver may process the nearest hardware > - * scan to avoid storing elements that are not desired. This > - * is the fiddliest option by far. > - * Here let's pretend we have random access. And the values are > - * in the constant table fakedata. > - */ > - int i, j; > - > - for (i = 0, j = 0; > - i < bitmap_weight(indio_dev->active_scan_mask, > - indio_dev->masklength); > - i++, j++) { > - j = find_next_bit(indio_dev->active_scan_mask, > - indio_dev->masklength, j); > - /* random access read from the 'device' */ > - data[i] = fakedata[j]; > - } > - } > + /* > + * Three common options here: > + * hardware scans: certain combinations of channels make > + * up a fast read. The capture will consist of all of them. > + * Hence we just call the grab data function and fill the > + * buffer without processing. > + * software scans: can be considered to be random access > + * so efficient reading is just a case of minimal bus > + * transactions. > + * software culled hardware scans: > + * occasionally a driver may process the nearest hardware > + * scan to avoid storing elements that are not desired. This > + * is the fiddliest option by far. > + * Here let's pretend we have random access. And the values are > + * in the constant table fakedata. > + */ Nitpicking: you could take advantage of the tab you save to use the full width of the line and save some lines of code. Just my 2c. CJ > + for_each_set_bit(j, indio_dev->active_scan_mask, indio_dev->masklength) > + data[i++] = fakedata[j]; > > iio_push_to_buffers_with_timestamp(indio_dev, data, > iio_get_time_ns(indio_dev)); ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 04/49] iio: fix opencoded for_each_set_bit() 2022-02-11 17:17 ` Christophe JAILLET @ 2022-06-04 15:41 ` Jonathan Cameron 2022-06-11 13:50 ` Jonathan Cameron 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Cameron @ 2022-06-04 15:41 UTC (permalink / raw) To: Christophe JAILLET Cc: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton, Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel, Lars-Peter Clausen, Alexandru Ardelean, Nathan Chancellor, linux-iio On Fri, 11 Feb 2022 18:17:37 +0100 Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote: > Le 10/02/2022 à 23:48, Yury Norov a écrit : > > iio_simple_dummy_trigger_h() is mostly an opencoded for_each_set_bit(). > > Using for_each_set_bit() make code much cleaner, and more effective. > > > > Signed-off-by: Yury Norov <yury.norov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > --- > > drivers/iio/dummy/iio_simple_dummy_buffer.c | 48 ++++++++------------- > > 1 file changed, 19 insertions(+), 29 deletions(-) > > > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c > > index d81c2b2dad82..3bc1b7529e2a 100644 > > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c > > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c > > @@ -45,41 +45,31 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p) > > { > > struct iio_poll_func *pf = p; > > struct iio_dev *indio_dev = pf->indio_dev; > > + int i = 0, j; > > u16 *data; > > > > data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL); > > if (!data) > > goto done; > > > > - if (!bitmap_empty(indio_dev->active_scan_mask, indio_dev->masklength)) { > > - /* > > - * Three common options here: > > - * hardware scans: certain combinations of channels make > > - * up a fast read. The capture will consist of all of them. > > - * Hence we just call the grab data function and fill the > > - * buffer without processing. > > - * software scans: can be considered to be random access > > - * so efficient reading is just a case of minimal bus > > - * transactions. > > - * software culled hardware scans: > > - * occasionally a driver may process the nearest hardware > > - * scan to avoid storing elements that are not desired. This > > - * is the fiddliest option by far. > > - * Here let's pretend we have random access. And the values are > > - * in the constant table fakedata. > > - */ > > - int i, j; > > - > > - for (i = 0, j = 0; > > - i < bitmap_weight(indio_dev->active_scan_mask, > > - indio_dev->masklength); > > - i++, j++) { > > - j = find_next_bit(indio_dev->active_scan_mask, > > - indio_dev->masklength, j); > > - /* random access read from the 'device' */ > > - data[i] = fakedata[j]; > > - } > > - } > > + /* > > + * Three common options here: > > + * hardware scans: certain combinations of channels make > > + * up a fast read. The capture will consist of all of them. > > + * Hence we just call the grab data function and fill the > > + * buffer without processing. > > + * software scans: can be considered to be random access > > + * so efficient reading is just a case of minimal bus > > + * transactions. > > + * software culled hardware scans: > > + * occasionally a driver may process the nearest hardware > > + * scan to avoid storing elements that are not desired. This > > + * is the fiddliest option by far. > > + * Here let's pretend we have random access. And the values are > > + * in the constant table fakedata. > > + */ > > Nitpicking: you could take advantage of the tab you save to use the full > width of the line and save some lines of code. Tweaked whilst applying. Sorry this one took so long. I marked it as a patch that I'd revisit if and tidy up if there was no v2 sent, but then managed to forget about it until I came to do a clean out of patchwork today. Anyhow, now applied to the togreg branch of iio.git - initially pushed out as testing for 0-day to see if we missed anything. Thanks, Jonathan > > Just my 2c. > > CJ > > > > + for_each_set_bit(j, indio_dev->active_scan_mask, indio_dev->masklength) > > + data[i++] = fakedata[j]; > > > > iio_push_to_buffers_with_timestamp(indio_dev, data, > > iio_get_time_ns(indio_dev)); > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 04/49] iio: fix opencoded for_each_set_bit() 2022-06-04 15:41 ` Jonathan Cameron @ 2022-06-11 13:50 ` Jonathan Cameron 0 siblings, 0 replies; 5+ messages in thread From: Jonathan Cameron @ 2022-06-11 13:50 UTC (permalink / raw) To: Christophe JAILLET Cc: Yury Norov, Andy Shevchenko, Rasmus Villemoes, Andrew Morton, Michał Mirosław, Greg Kroah-Hartman, Peter Zijlstra, David Laight, Joe Perches, Dennis Zhou, Emil Renner Berthing, Nicholas Piggin, Matti Vaittinen, Alexey Klimov, linux-kernel, Lars-Peter Clausen, Alexandru Ardelean, Nathan Chancellor, linux-iio On Sat, 4 Jun 2022 16:41:13 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Fri, 11 Feb 2022 18:17:37 +0100 > Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote: > > > Le 10/02/2022 à 23:48, Yury Norov a écrit : > > > iio_simple_dummy_trigger_h() is mostly an opencoded for_each_set_bit(). > > > Using for_each_set_bit() make code much cleaner, and more effective. > > > > > > Signed-off-by: Yury Norov <yury.norov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > --- > > > drivers/iio/dummy/iio_simple_dummy_buffer.c | 48 ++++++++------------- > > > 1 file changed, 19 insertions(+), 29 deletions(-) > > > > > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c b/drivers/iio/dummy/iio_simple_dummy_buffer.c > > > index d81c2b2dad82..3bc1b7529e2a 100644 > > > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c > > > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c > > > @@ -45,41 +45,31 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq, void *p) > > > { > > > struct iio_poll_func *pf = p; > > > struct iio_dev *indio_dev = pf->indio_dev; > > > + int i = 0, j; > > > u16 *data; > > > > > > data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL); > > > if (!data) > > > goto done; > > > > > > - if (!bitmap_empty(indio_dev->active_scan_mask, indio_dev->masklength)) { > > > - /* > > > - * Three common options here: > > > - * hardware scans: certain combinations of channels make > > > - * up a fast read. The capture will consist of all of them. > > > - * Hence we just call the grab data function and fill the > > > - * buffer without processing. > > > - * software scans: can be considered to be random access > > > - * so efficient reading is just a case of minimal bus > > > - * transactions. > > > - * software culled hardware scans: > > > - * occasionally a driver may process the nearest hardware > > > - * scan to avoid storing elements that are not desired. This > > > - * is the fiddliest option by far. > > > - * Here let's pretend we have random access. And the values are > > > - * in the constant table fakedata. > > > - */ > > > - int i, j; > > > - > > > - for (i = 0, j = 0; > > > - i < bitmap_weight(indio_dev->active_scan_mask, > > > - indio_dev->masklength); > > > - i++, j++) { > > > - j = find_next_bit(indio_dev->active_scan_mask, > > > - indio_dev->masklength, j); > > > - /* random access read from the 'device' */ > > > - data[i] = fakedata[j]; > > > - } > > > - } > > > + /* > > > + * Three common options here: > > > + * hardware scans: certain combinations of channels make > > > + * up a fast read. The capture will consist of all of them. > > > + * Hence we just call the grab data function and fill the > > > + * buffer without processing. > > > + * software scans: can be considered to be random access > > > + * so efficient reading is just a case of minimal bus > > > + * transactions. > > > + * software culled hardware scans: > > > + * occasionally a driver may process the nearest hardware > > > + * scan to avoid storing elements that are not desired. This > > > + * is the fiddliest option by far. > > > + * Here let's pretend we have random access. And the values are > > > + * in the constant table fakedata. > > > + */ > > > > Nitpicking: you could take advantage of the tab you save to use the full > > width of the line and save some lines of code. > > Tweaked whilst applying. > > Sorry this one took so long. I marked it as a patch that I'd revisit if and > tidy up if there was no v2 sent, but then managed to forget about it until > I came to do a clean out of patchwork today. > > Anyhow, now applied to the togreg branch of iio.git - initially pushed out > as testing for 0-day to see if we missed anything. And dropped again during a rebase as a different version has gone upstream through a pull request to Linus. Whilst I have no strong opinion on that in general, I am a little grumpy that a version was merged that was never posted to the mailing lists (that I can find on lore.kernel.org.) Sure the changes were minor and easy to verify as harmless, but none the less they should have been posted. Jonathan > > Thanks, > > Jonathan > > > > > Just my 2c. > > > > CJ > > > > > > > + for_each_set_bit(j, indio_dev->active_scan_mask, indio_dev->masklength) > > > + data[i++] = fakedata[j]; > > > > > > iio_push_to_buffers_with_timestamp(indio_dev, data, > > > iio_get_time_ns(indio_dev)); > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-06-11 13:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20220210224933.379149-1-yury.norov@gmail.com>
2022-02-10 22:48 ` [PATCH 04/49] iio: fix opencoded for_each_set_bit() Yury Norov
2022-02-11 8:45 ` Andy Shevchenko
2022-02-11 17:17 ` Christophe JAILLET
2022-06-04 15:41 ` Jonathan Cameron
2022-06-11 13:50 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox