All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	akpm@linux-foundation.org, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux@rasmusvillemoes.dk, yamada.masahiro@socionext.com,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	geert@linux-m68k.org, preid@electromag.com.au, lukas@wunner.de,
	sean.nyekjaer@prevas.dk, morten.tiljeset@prevas.dk,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v16 01/14] bitops: Introduce the for_each_set_clump8 macro
Date: Mon, 7 Oct 2019 11:18:51 -0400	[thread overview]
Message-ID: <20191007151851.GA3494@icarus> (raw)
In-Reply-To: <20191007082156.GL32742@smile.fi.intel.com>

On Mon, Oct 07, 2019 at 11:21:56AM +0300, Andy Shevchenko wrote:
> On Sun, Oct 06, 2019 at 11:10:58AM -0400, William Breathitt Gray wrote:
> > This macro iterates for each 8-bit group of bits (clump) with set bits,
> > within a bitmap memory region. For each iteration, "start" is set to the
> > bit offset of the found clump, while the respective clump value is
> > stored to the location pointed by "clump". Additionally, the
> > bitmap_get_value8 and bitmap_set_value8 functions are introduced to
> > respectively get and set an 8-bit value in a bitmap memory region.
> 
> Very much thank you for an update!
> I have comments below.
> 
> > +/**
> > + * bitmap_get_value8 - get an 8-bit value within a memory region
> 
> Since it's in find.h I would not collide with bitmap namespace.
> How about
> 
> 	find_and_get_value8()

We modeled the interface for these on the existing bitmap functions, so
perhaps it would be better to move bitmap_get_value8 and
bitmap_set_value8 to include/linux/bitmap.h so that they are with the
rest of the bitmap functions -- afterall, they are operating on bitmaps.

> > + * @addr: address to the bitmap memory region
> > + * @start: bit offset of the 8-bit value; must be a multiple of 8
> > + *
> > + * Returns the 8-bit value located at the @start bit offset within the @addr
> > + * memory region.
> > + */
> > +static inline unsigned long bitmap_get_value8(const unsigned long *addr,
> > +					      unsigned long start)
> > +{
> > +	const size_t index = BIT_WORD(start);
> > +	const unsigned long offset = start % BITS_PER_LONG;
> > +
> > +	return (addr[index] >> offset) & 0xFF;
> > +}
> > +
> > +/**
> > + * bitmap_set_value8 - set an 8-bit value within a memory region
> 
> 	find_and_set_value8()
> 
> ?
> 
> > + * @addr: address to the bitmap memory region
> > + * @value: the 8-bit value; values wider than 8 bits may clobber bitmap
> > + * @start: bit offset of the 8-bit value; must be a multiple of 8
> > + */
> > +static inline void bitmap_set_value8(unsigned long *addr, unsigned long value,
> > +				     unsigned long start)
> > +{
> > +	const size_t index = BIT_WORD(start);
> > +	const unsigned long offset = start % BITS_PER_LONG;
> > +
> > +	addr[index] &= ~(0xFF << offset);
> > +	addr[index] |= value << offset;
> > +}
> 
> -- 
> With Best Regards,
> Andy Shevchenko

The find_next_clump8 function can remain exposed via
include/linux/find.h since it fits in with the rest of the functions
there.

The reason I moved the definition to lib/find_bit.c is due to the
circular dependency that arose from the round_down macro. Should I try
to move the definition back to include/linux/find.h and reimplement it
without the round_down macro; or is it best to keep this simpler
implementation here in lib/find_bit.c?

William Breathitt Gray

WARNING: multiple messages have this Message-ID (diff)
From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	linux-gpio@vger.kernel.org, yamada.masahiro@socionext.com,
	linus.walleij@linaro.org, linux-pm@vger.kernel.org,
	linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org,
	morten.tiljeset@prevas.dk, sean.nyekjaer@prevas.dk,
	bgolaszewski@baylibre.com, lukas@wunner.de, geert@linux-m68k.org,
	akpm@linux-foundation.org, preid@electromag.com.au,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v16 01/14] bitops: Introduce the for_each_set_clump8 macro
Date: Mon, 7 Oct 2019 11:18:51 -0400	[thread overview]
Message-ID: <20191007151851.GA3494@icarus> (raw)
In-Reply-To: <20191007082156.GL32742@smile.fi.intel.com>

On Mon, Oct 07, 2019 at 11:21:56AM +0300, Andy Shevchenko wrote:
> On Sun, Oct 06, 2019 at 11:10:58AM -0400, William Breathitt Gray wrote:
> > This macro iterates for each 8-bit group of bits (clump) with set bits,
> > within a bitmap memory region. For each iteration, "start" is set to the
> > bit offset of the found clump, while the respective clump value is
> > stored to the location pointed by "clump". Additionally, the
> > bitmap_get_value8 and bitmap_set_value8 functions are introduced to
> > respectively get and set an 8-bit value in a bitmap memory region.
> 
> Very much thank you for an update!
> I have comments below.
> 
> > +/**
> > + * bitmap_get_value8 - get an 8-bit value within a memory region
> 
> Since it's in find.h I would not collide with bitmap namespace.
> How about
> 
> 	find_and_get_value8()

We modeled the interface for these on the existing bitmap functions, so
perhaps it would be better to move bitmap_get_value8 and
bitmap_set_value8 to include/linux/bitmap.h so that they are with the
rest of the bitmap functions -- afterall, they are operating on bitmaps.

> > + * @addr: address to the bitmap memory region
> > + * @start: bit offset of the 8-bit value; must be a multiple of 8
> > + *
> > + * Returns the 8-bit value located at the @start bit offset within the @addr
> > + * memory region.
> > + */
> > +static inline unsigned long bitmap_get_value8(const unsigned long *addr,
> > +					      unsigned long start)
> > +{
> > +	const size_t index = BIT_WORD(start);
> > +	const unsigned long offset = start % BITS_PER_LONG;
> > +
> > +	return (addr[index] >> offset) & 0xFF;
> > +}
> > +
> > +/**
> > + * bitmap_set_value8 - set an 8-bit value within a memory region
> 
> 	find_and_set_value8()
> 
> ?
> 
> > + * @addr: address to the bitmap memory region
> > + * @value: the 8-bit value; values wider than 8 bits may clobber bitmap
> > + * @start: bit offset of the 8-bit value; must be a multiple of 8
> > + */
> > +static inline void bitmap_set_value8(unsigned long *addr, unsigned long value,
> > +				     unsigned long start)
> > +{
> > +	const size_t index = BIT_WORD(start);
> > +	const unsigned long offset = start % BITS_PER_LONG;
> > +
> > +	addr[index] &= ~(0xFF << offset);
> > +	addr[index] |= value << offset;
> > +}
> 
> -- 
> With Best Regards,
> Andy Shevchenko

The find_next_clump8 function can remain exposed via
include/linux/find.h since it fits in with the rest of the functions
there.

The reason I moved the definition to lib/find_bit.c is due to the
circular dependency that arose from the round_down macro. Should I try
to move the definition back to include/linux/find.h and reimplement it
without the round_down macro; or is it best to keep this simpler
implementation here in lib/find_bit.c?

William Breathitt Gray

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-10-07 15:19 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-06 15:10 [PATCH v16 00/14] Introduce the for_each_set_clump8 macro William Breathitt Gray
2019-10-06 15:10 ` William Breathitt Gray
2019-10-06 15:10 ` [PATCH v16 01/14] bitops: " William Breathitt Gray
2019-10-06 15:10   ` William Breathitt Gray
2019-10-07  8:21   ` Andy Shevchenko
2019-10-07  8:21     ` Andy Shevchenko
2019-10-07 15:18     ` William Breathitt Gray [this message]
2019-10-07 15:18       ` William Breathitt Gray
2019-10-06 15:10 ` [PATCH v16 02/14] lib/test_bitmap.c: Add for_each_set_clump8 test cases William Breathitt Gray
2019-10-06 15:10   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 03/14] gpio: 104-dio-48e: Utilize for_each_set_clump8 macro William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 04/14] gpio: 104-idi-48: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 05/14] gpio: gpio-mm: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 06/14] gpio: ws16c48: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 07/14] gpio: pci-idio-16: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 08/14] gpio: pcie-idio-24: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 09/14] gpio: uniphier: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 10/14] gpio: 74x164: Utilize the " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-07  8:24   ` Andy Shevchenko
2019-10-07  8:24     ` Andy Shevchenko
2019-10-06 15:11 ` [PATCH v16 11/14] thermal: intel: intel_soc_dts_iosf: Utilize " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-07  8:44   ` Andy Shevchenko
2019-10-07  8:44     ` Andy Shevchenko
2019-10-06 15:11 ` [PATCH v16 12/14] gpio: pisosr: Utilize the " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 13/14] gpio: max3191x: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-06 15:11 ` [PATCH v16 14/14] gpio: pca953x: " William Breathitt Gray
2019-10-06 15:11   ` William Breathitt Gray
2019-10-07  8:45   ` Andy Shevchenko
2019-10-07  8:45     ` Andy Shevchenko
2019-10-07  8:45     ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191007151851.GA3494@icarus \
    --to=vilhelm.gray@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lukas@wunner.de \
    --cc=morten.tiljeset@prevas.dk \
    --cc=preid@electromag.com.au \
    --cc=sean.nyekjaer@prevas.dk \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.