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
next prev parent 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: linkBe 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.