| Message ID | 893c3b4f03266c9496137cc98ac2b1bd27f92c73.1570633189.git.vilhelm.gray@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce the for_each_set_clump8 macro | expand |
On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray <vilhelm.gray@gmail.com> 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. > > Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> > Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Suggested-by: Lukas Wunner <lukas@wunner.de> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Andy Shevchenko <andy.shevchenko@gmail.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> > --- > include/asm-generic/bitops/find.h | 17 +++++++++++++++ > include/linux/bitmap.h | 35 +++++++++++++++++++++++++++++++ > include/linux/bitops.h | 5 +++++ > lib/find_bit.c | 14 +++++++++++++ > 4 files changed, 71 insertions(+) > > diff --git a/include/asm-generic/bitops/find.h b/include/asm-generic/bitops/find.h > index 8a1ee10014de..9fdf21302fdf 100644 > --- a/include/asm-generic/bitops/find.h > +++ b/include/asm-generic/bitops/find.h > @@ -80,4 +80,21 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr, > > #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */ > > +/** > + * find_next_clump8 - find next 8-bit clump with set bits in a memory region > + * @clump: location to store copy of found clump > + * @addr: address to base the search on > + * @size: bitmap size in number of bits > + * @offset: bit offset at which to start searching > + * > + * Returns the bit offset for the next set clump; the found clump value is > + * copied to the location pointed by @clump. If no bits are set, returns @size. > + */ > +extern unsigned long find_next_clump8(unsigned long *clump, > + const unsigned long *addr, > + unsigned long size, unsigned long offset); > + > +#define find_first_clump8(clump, bits, size) \ > + find_next_clump8((clump), (bits), (size), 0) > + > #endif /*_ASM_GENERIC_BITOPS_FIND_H_ */ > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h > index 90528f12bdfa..761fab5b60a7 100644 > --- a/include/linux/bitmap.h > +++ b/include/linux/bitmap.h > @@ -66,6 +66,8 @@ > * bitmap_allocate_region(bitmap, pos, order) Allocate specified bit region > * bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf to dst > * bitmap_to_arr32(buf, src, nbits) Copy nbits from buf to u32[] dst > + * bitmap_get_value8(map, start) Get 8bit value from map at start > + * bitmap_set_value8(map, value, start) Set 8bit value to map at start > * > * Note, bitmap_zero() and bitmap_fill() operate over the region of > * unsigned longs, that is, bits behind bitmap till the unsigned long > @@ -488,6 +490,39 @@ static inline void bitmap_from_u64(unsigned long *dst, u64 mask) > dst[1] = mask >> 32; > } > > +/** > + * bitmap_get_value8 - get an 8-bit value within a memory region > + * @map: 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 @src > + * memory region. > + */ > +static inline unsigned long bitmap_get_value8(const unsigned long *map, > + unsigned long start) Why is the return type "unsigned long" where you know it return the 8-bit value ? u8? > +{ > + const size_t index = BIT_WORD(start); > + const unsigned long offset = start % BITS_PER_LONG; > + > + return (map[index] >> offset) & 0xFF; > +} > + > +/** > + * bitmap_set_value8 - set an 8-bit value within a memory region > + * @map: 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 *map, unsigned long value, Same here, "u8 value" > + unsigned long start) > +{ > + const size_t index = BIT_WORD(start); > + const unsigned long offset = start % BITS_PER_LONG; > + > + map[index] &= ~(0xFF << offset); > + map[index] |= value << offset; > +} > + > #endif /* __ASSEMBLY__ */ > > #endif /* __LINUX_BITMAP_H */ > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > index cf074bce3eb3..fb94a10f7853 100644 > --- a/include/linux/bitops.h > +++ b/include/linux/bitops.h > @@ -40,6 +40,11 @@ extern unsigned long __sw_hweight64(__u64 w); > (bit) < (size); \ > (bit) = find_next_zero_bit((addr), (size), (bit) + 1)) > > +#define for_each_set_clump8(start, clump, bits, size) \ > + for ((start) = find_first_clump8(&(clump), (bits), (size)); \ > + (start) < (size); \ > + (start) = find_next_clump8(&(clump), (bits), (size), (start) + 8)) > + > static inline int get_bitmask_order(unsigned int count) > { > int order; > diff --git a/lib/find_bit.c b/lib/find_bit.c > index 5c51eb45178a..e35a76b291e6 100644 > --- a/lib/find_bit.c > +++ b/lib/find_bit.c > @@ -214,3 +214,17 @@ EXPORT_SYMBOL(find_next_bit_le); > #endif > > #endif /* __BIG_ENDIAN */ > + > +unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr, Ditto. "u8 *clump" > + unsigned long size, unsigned long offset) > +{ > + offset = find_next_bit(addr, size, offset); > + if (offset == size) > + return size; > + > + offset = round_down(offset, 8); > + *clump = bitmap_get_value8(addr, offset); > + > + return offset; > +} > +EXPORT_SYMBOL(find_next_clump8); > -- > 2.23.0 > -- Best Regards Masahiro Yamada
On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > <vilhelm.gray@gmail.com> 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. > > > > Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > > Suggested-by: Lukas Wunner <lukas@wunner.de> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Andy Shevchenko <andy.shevchenko@gmail.com> > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> > > --- > > include/asm-generic/bitops/find.h | 17 +++++++++++++++ > > include/linux/bitmap.h | 35 +++++++++++++++++++++++++++++++ > > include/linux/bitops.h | 5 +++++ > > lib/find_bit.c | 14 +++++++++++++ > > 4 files changed, 71 insertions(+) > > > > diff --git a/include/asm-generic/bitops/find.h b/include/asm-generic/bitops/find.h > > index 8a1ee10014de..9fdf21302fdf 100644 > > --- a/include/asm-generic/bitops/find.h > > +++ b/include/asm-generic/bitops/find.h > > @@ -80,4 +80,21 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr, > > > > #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */ > > > > +/** > > + * find_next_clump8 - find next 8-bit clump with set bits in a memory region > > + * @clump: location to store copy of found clump > > + * @addr: address to base the search on > > + * @size: bitmap size in number of bits > > + * @offset: bit offset at which to start searching > > + * > > + * Returns the bit offset for the next set clump; the found clump value is > > + * copied to the location pointed by @clump. If no bits are set, returns @size. > > + */ > > +extern unsigned long find_next_clump8(unsigned long *clump, > > + const unsigned long *addr, > > + unsigned long size, unsigned long offset); > > + > > +#define find_first_clump8(clump, bits, size) \ > > + find_next_clump8((clump), (bits), (size), 0) > > + > > #endif /*_ASM_GENERIC_BITOPS_FIND_H_ */ > > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h > > index 90528f12bdfa..761fab5b60a7 100644 > > --- a/include/linux/bitmap.h > > +++ b/include/linux/bitmap.h > > @@ -66,6 +66,8 @@ > > * bitmap_allocate_region(bitmap, pos, order) Allocate specified bit region > > * bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf to dst > > * bitmap_to_arr32(buf, src, nbits) Copy nbits from buf to u32[] dst > > + * bitmap_get_value8(map, start) Get 8bit value from map at start > > + * bitmap_set_value8(map, value, start) Set 8bit value to map at start > > * > > * Note, bitmap_zero() and bitmap_fill() operate over the region of > > * unsigned longs, that is, bits behind bitmap till the unsigned long > > @@ -488,6 +490,39 @@ static inline void bitmap_from_u64(unsigned long *dst, u64 mask) > > dst[1] = mask >> 32; > > } > > > > +/** > > + * bitmap_get_value8 - get an 8-bit value within a memory region > > + * @map: 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 @src > > + * memory region. > > + */ > > +static inline unsigned long bitmap_get_value8(const unsigned long *map, > > + unsigned long start) > > Why is the return type "unsigned long" where you know > it return the 8-bit value ? > > u8? The primary reason is to be consistent with the datatype of the bitmap: https://lkml.org/lkml/2019/1/12/26 This should also make it easier to extent to other sizes in the future since we won't have to change the interface in order to support 16-bit or 32-bit values -- they should easily fit within an unsigned long. William Breathitt Gray > > > > > +{ > > + const size_t index = BIT_WORD(start); > > + const unsigned long offset = start % BITS_PER_LONG; > > + > > + return (map[index] >> offset) & 0xFF; > > +} > > + > > +/** > > + * bitmap_set_value8 - set an 8-bit value within a memory region > > + * @map: 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 *map, unsigned long value, > > > Same here, "u8 value" > > > > > + unsigned long start) > > +{ > > + const size_t index = BIT_WORD(start); > > + const unsigned long offset = start % BITS_PER_LONG; > > + > > + map[index] &= ~(0xFF << offset); > > + map[index] |= value << offset; > > +} > > + > > #endif /* __ASSEMBLY__ */ > > > > #endif /* __LINUX_BITMAP_H */ > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > > index cf074bce3eb3..fb94a10f7853 100644 > > --- a/include/linux/bitops.h > > +++ b/include/linux/bitops.h > > @@ -40,6 +40,11 @@ extern unsigned long __sw_hweight64(__u64 w); > > (bit) < (size); \ > > (bit) = find_next_zero_bit((addr), (size), (bit) + 1)) > > > > +#define for_each_set_clump8(start, clump, bits, size) \ > > + for ((start) = find_first_clump8(&(clump), (bits), (size)); \ > > + (start) < (size); \ > > + (start) = find_next_clump8(&(clump), (bits), (size), (start) + 8)) > > + > > static inline int get_bitmask_order(unsigned int count) > > { > > int order; > > diff --git a/lib/find_bit.c b/lib/find_bit.c > > index 5c51eb45178a..e35a76b291e6 100644 > > --- a/lib/find_bit.c > > +++ b/lib/find_bit.c > > @@ -214,3 +214,17 @@ EXPORT_SYMBOL(find_next_bit_le); > > #endif > > > > #endif /* __BIG_ENDIAN */ > > + > > +unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr, > > > Ditto. "u8 *clump" > > > > > > + unsigned long size, unsigned long offset) > > +{ > > + offset = find_next_bit(addr, size, offset); > > + if (offset == size) > > + return size; > > + > > + offset = round_down(offset, 8); > > + *clump = bitmap_get_value8(addr, offset); > > + > > + return offset; > > +} > > +EXPORT_SYMBOL(find_next_clump8); > > -- > > 2.23.0 > > > > > -- > Best Regards > > Masahiro Yamada
On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > <vilhelm.gray@gmail.com> 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. > Why is the return type "unsigned long" where you know > it return the 8-bit value ? Because bitmap API operates on unsigned long type. This is not only consistency, but for sake of flexibility in case we would like to introduce more calls like clump16 or so. Same comment for the rest.
Hi Andy, On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > <vilhelm.gray@gmail.com> 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. > > > Why is the return type "unsigned long" where you know > > it return the 8-bit value ? > > Because bitmap API operates on unsigned long type. This is not only > consistency, but for sake of flexibility in case we would like to introduce > more calls like clump16 or so. TBH, that doesn't convince me: those functions explicitly take/return an 8-bit value, and have "8" in their name. The 8-bit value is never really related to, retrieved from, or stored in a full "unsigned long" element of a bitmap, only to/from/in a part (byte) of it. Following your rationale, all of iowrite{8,16,32,64}*() should take an "unsigned long" value, too. Gr{oetje,eeting}s, Geert
On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Andy, > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > <vilhelm.gray@gmail.com> 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. > > > > > Why is the return type "unsigned long" where you know > > > it return the 8-bit value ? > > > > Because bitmap API operates on unsigned long type. This is not only > > consistency, but for sake of flexibility in case we would like to introduce > > more calls like clump16 or so. > > TBH, that doesn't convince me: those functions explicitly take/return an > 8-bit value, and have "8" in their name. The 8-bit value is never > really related to, retrieved from, or stored in a full "unsigned long" > element of a bitmap, only to/from/in a part (byte) of it. > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > "unsigned long" value, too. > +1 Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned int nbits); void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); static inline void bitmap_from_u64(unsigned long *dst, u64 mask); If you want to see more examples from other parts, int of_property_read_u8(const struct device_node *np, const char *propname, u8 *out_value) int of_property_read_u16(const struct device_node *np, const char *propname, u16 *out_value)
On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > <vilhelm.gray@gmail.com> 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. > > > > > > > Why is the return type "unsigned long" where you know > > > > it return the 8-bit value ? > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > consistency, but for sake of flexibility in case we would like to introduce > > > more calls like clump16 or so. > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > 8-bit value, and have "8" in their name. The 8-bit value is never > > really related to, retrieved from, or stored in a full "unsigned long" > > element of a bitmap, only to/from/in a part (byte) of it. > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > "unsigned long" value, too. > > > > +1 > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > int nbits); > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > If you want to see more examples from other parts, Geert's and yours examples both are not related. They are about fixed-width properies when we know that is the part of protocol. Here we have no protocol which stricts us to the mentioned fixed-width types. So, I can tell an opposite, your arguments didn't convince me. Imagine the function which does an or / and / xor operation on bitmap. Now, when I supply unsigned long, I will see operations on one type in _one_ function independently of the size. Your proposal will make an unneded churn.
Hi Andy, On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > <vilhelm.gray@gmail.com> 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. > > > > > > > > > Why is the return type "unsigned long" where you know > > > > > it return the 8-bit value ? > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > more calls like clump16 or so. > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > really related to, retrieved from, or stored in a full "unsigned long" > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > "unsigned long" value, too. > > > > > > > +1 > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > int nbits); > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > If you want to see more examples from other parts, > > Geert's and yours examples both are not related. They are about > fixed-width properies when we know that is the part of protocol. > Here we have no protocol which stricts us to the mentioned fixed-width types. Yes you have: they are functions to store/retrieve an 8-bit value from the middle of the bitmap, which is reflected in their names ("clump8", "value8"). The input/output value is clearly separated from the actual bitmap, which is referenced by the "unsigned long *". If you add new "value16" functions, they will be intended to store/retrieve 16-bit values. Besides, if retrieving an 8-bit value requires passing an "unsigned long *", the caller needs two variables: one unsigned long to pass the address of, and one u8 to copy the returned value into. > So, I can tell an opposite, your arguments didn't convince me. > > Imagine the function which does an or / and / xor operation on bitmap. > Now, when I supply unsigned long, I will see > operations on one type in _one_ function independently of the size. > Your proposal will make an unneded churn. Depends on what kind of value you will use to do the logical operation with the bitmap: - Full bitmap => unsigned long * + size, - Single bitmap "word" => unsigned long, - 8-bit value => u8, - 16-bit value => u16 Gr{oetje,eeting}s, Geert
On Thu, Oct 10, 2019 at 9:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > > <yamada.masahiro@socionext.com> wrote: > > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > > <vilhelm.gray@gmail.com> 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. > > > > > > > > > > > Why is the return type "unsigned long" where you know > > > > > > it return the 8-bit value ? > > > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > > more calls like clump16 or so. > > > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > > really related to, retrieved from, or stored in a full "unsigned long" > > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > > "unsigned long" value, too. > > > > > > > > > > +1 > > > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > > int nbits); > > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > > > > > If you want to see more examples from other parts, > > > > Geert's and yours examples both are not related. They are about > > fixed-width properies when we know that is the part of protocol. > > Here we have no protocol which stricts us to the mentioned fixed-width types. > > Yes you have: they are functions to store/retrieve an 8-bit value from > the middle of the bitmap, which is reflected in their names ("clump8", > "value8"). > The input/output value is clearly separated from the actual bitmap, > which is referenced by the "unsigned long *". > > If you add new "value16" functions, they will be intended to store/retrieve > 16-bit values. And if I add 4-bit, 12-bit or 24-bit values, what should I use? > Besides, if retrieving an 8-bit value requires passing an > "unsigned long *", the caller needs two variables: one unsigned long to > pass the address of, and one u8 to copy the returned value into. Why do you need a temporary variable? In some cases it might make sense, but in general simple cases I don't see what you may achieve with it. I looked at bitmap.h and see few functions may have benefited of actually eliminating a use of long -> u8 -> long conversion. Here is the question what we are mostly doing after we got a clump out of bitmap. > > So, I can tell an opposite, your arguments didn't convince me. > > > > Imagine the function which does an or / and / xor operation on bitmap. > > Now, when I supply unsigned long, I will see > > operations on one type in _one_ function independently of the size. > > Your proposal will make an unneded churn. > > Depends on what kind of value you will use to do the logical operation > with the bitmap: > - Full bitmap => unsigned long * + size, > - Single bitmap "word" => unsigned long, > - 8-bit value => u8, > - 16-bit value => u16
Hi Andy, On Thu, Oct 10, 2019 at 9:42 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Oct 10, 2019 at 9:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > > > <yamada.masahiro@socionext.com> wrote: > > > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > > > <vilhelm.gray@gmail.com> 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. > > > > > > > > > > > > > Why is the return type "unsigned long" where you know > > > > > > > it return the 8-bit value ? > > > > > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > > > more calls like clump16 or so. > > > > > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > > > really related to, retrieved from, or stored in a full "unsigned long" > > > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > > > "unsigned long" value, too. > > > > > > > > > > > > > +1 > > > > > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > > > int nbits); > > > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > > > > > > > > > If you want to see more examples from other parts, > > > > > > Geert's and yours examples both are not related. They are about > > > fixed-width properies when we know that is the part of protocol. > > > Here we have no protocol which stricts us to the mentioned fixed-width types. > > > > Yes you have: they are functions to store/retrieve an 8-bit value from > > the middle of the bitmap, which is reflected in their names ("clump8", > > "value8"). > > The input/output value is clearly separated from the actual bitmap, > > which is referenced by the "unsigned long *". > > > > If you add new "value16" functions, they will be intended to store/retrieve > > 16-bit values. > > And if I add 4-bit, 12-bit or 24-bit values, what should I use? Whatever is needed to store that? I agree "unsigned long" is appropriate for a generic function to extract a bit field of 1 to BITS_PER_LONG bits. > > Besides, if retrieving an 8-bit value requires passing an > > "unsigned long *", the caller needs two variables: one unsigned long to > > pass the address of, and one u8 to copy the returned value into. > > Why do you need a temporary variable? In some cases it might make > sense, but in general simple cases I don't see what you may achieve > with it. Because find_next_clump8() takes a pointer to store the output value. > I looked at bitmap.h and see few functions may have benefited of > actually eliminating a use of long -> u8 -> long conversion. > > Here is the question what we are mostly doing after we got a clump out > of bitmap. If I call find_next_clump8() to extract a byte, I guess I want to process an u8 aftwerwards? Gr{oetje,eeting}s, Geert
On Thu, Oct 10, 2019 at 09:49:51AM +0200, Geert Uytterhoeven wrote: > On Thu, Oct 10, 2019 at 9:42 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Oct 10, 2019 at 9:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > > > > <yamada.masahiro@socionext.com> wrote: > > > > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > > > > <vilhelm.gray@gmail.com> wrote: > > > > > > > > Why is the return type "unsigned long" where you know > > > > > > > > it return the 8-bit value ? > > > > > > > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > > > > more calls like clump16 or so. > > > > > > > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > > > > really related to, retrieved from, or stored in a full "unsigned long" > > > > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > > > > "unsigned long" value, too. > > > > > > > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > > > > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > > > > int nbits); > > > > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > > > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > > > If you want to see more examples from other parts, > > > > > > > > Geert's and yours examples both are not related. They are about > > > > fixed-width properies when we know that is the part of protocol. > > > > Here we have no protocol which stricts us to the mentioned fixed-width types. > > > > > > Yes you have: they are functions to store/retrieve an 8-bit value from > > > the middle of the bitmap, which is reflected in their names ("clump8", > > > "value8"). > > > The input/output value is clearly separated from the actual bitmap, > > > which is referenced by the "unsigned long *". > > > > > > If you add new "value16" functions, they will be intended to store/retrieve > > > 16-bit values. > > > > And if I add 4-bit, 12-bit or 24-bit values, what should I use? > > Whatever is needed to store that? > I agree "unsigned long" is appropriate for a generic function to extract a > bit field of 1 to BITS_PER_LONG bits. > > > > Besides, if retrieving an 8-bit value requires passing an > > > "unsigned long *", the caller needs two variables: one unsigned long to > > > pass the address of, and one u8 to copy the returned value into. > > > > Why do you need a temporary variable? In some cases it might make > > sense, but in general simple cases I don't see what you may achieve > > with it. > > Because find_next_clump8() takes a pointer to store the output value. So does regmap_read(). 8 appeared there during review when it has been proposed to optimize to 8-bit clumps as most of the current users utilize it. The initial idea was to be bit-width agnostic. And with current API it's possible to easy convert to other formats later if we need. > > I looked at bitmap.h and see few functions may have benefited of > > actually eliminating a use of long -> u8 -> long conversion. > > > > Here is the question what we are mostly doing after we got a clump out > > of bitmap. > > If I call find_next_clump8() to extract a byte, I guess I want to process an u8 > aftwerwards? Some functions may expect a width-(semi-)dependent types, like regmap_write(). Yes, it's possible to supply u8 there and have an implicit type cast.
Hi Andy, On Thu, Oct 10, 2019 at 10:08 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Oct 10, 2019 at 09:49:51AM +0200, Geert Uytterhoeven wrote: > > On Thu, Oct 10, 2019 at 9:42 AM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > On Thu, Oct 10, 2019 at 9:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko > > > > <andy.shevchenko@gmail.com> wrote: > > > > > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > > > > > <yamada.masahiro@socionext.com> wrote: > > > > > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > > > > > <vilhelm.gray@gmail.com> wrote: > > > > > > > > > > Why is the return type "unsigned long" where you know > > > > > > > > > it return the 8-bit value ? > > > > > > > > > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > > > > > more calls like clump16 or so. > > > > > > > > > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > > > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > > > > > really related to, retrieved from, or stored in a full "unsigned long" > > > > > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > > > > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > > > > > "unsigned long" value, too. > > > > > > > > > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > > > > > > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > > > > > int nbits); > > > > > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > > > > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > > > > > If you want to see more examples from other parts, > > > > > > > > > > Geert's and yours examples both are not related. They are about > > > > > fixed-width properies when we know that is the part of protocol. > > > > > Here we have no protocol which stricts us to the mentioned fixed-width types. > > > > > > > > Yes you have: they are functions to store/retrieve an 8-bit value from > > > > the middle of the bitmap, which is reflected in their names ("clump8", > > > > "value8"). > > > > The input/output value is clearly separated from the actual bitmap, > > > > which is referenced by the "unsigned long *". > > > > > > > > If you add new "value16" functions, they will be intended to store/retrieve > > > > 16-bit values. > > > > > > And if I add 4-bit, 12-bit or 24-bit values, what should I use? > > > > Whatever is needed to store that? > > I agree "unsigned long" is appropriate for a generic function to extract a > > bit field of 1 to BITS_PER_LONG bits. > > > > > > Besides, if retrieving an 8-bit value requires passing an > > > > "unsigned long *", the caller needs two variables: one unsigned long to > > > > pass the address of, and one u8 to copy the returned value into. > > > > > > Why do you need a temporary variable? In some cases it might make > > > sense, but in general simple cases I don't see what you may achieve > > > with it. > > > > Because find_next_clump8() takes a pointer to store the output value. > > So does regmap_read(). I believe that one is different, as it is a generic function, and the width of the returned value depends on the regmap config. > 8 appeared there during review when it has been proposed to optimize to 8-bit > clumps as most of the current users utilize it. The initial idea was to be > bit-width agnostic. And with current API it's possible to easy convert to other > formats later if we need. "optimized for 8-bit clumps" and "out-of-line function that takes an unsigned long pointer for an output parameter" don't match well, IMHO. Gr{oetje,eeting}s, Geert
On Thu, Oct 10, 2019 at 10:21:45AM +0200, Geert Uytterhoeven wrote: > Hi Andy, > > On Thu, Oct 10, 2019 at 10:08 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Oct 10, 2019 at 09:49:51AM +0200, Geert Uytterhoeven wrote: > > > On Thu, Oct 10, 2019 at 9:42 AM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > On Thu, Oct 10, 2019 at 9:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > On Thu, Oct 10, 2019 at 7:49 AM Andy Shevchenko > > > > > <andy.shevchenko@gmail.com> wrote: > > > > > > On Thu, Oct 10, 2019 at 5:31 AM Masahiro Yamada > > > > > > <yamada.masahiro@socionext.com> wrote: > > > > > > > On Thu, Oct 10, 2019 at 3:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > > > On Wed, Oct 9, 2019 at 7:09 PM Andy Shevchenko > > > > > > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > > On Thu, Oct 10, 2019 at 01:28:08AM +0900, Masahiro Yamada wrote: > > > > > > > > > > On Thu, Oct 10, 2019 at 12:27 AM William Breathitt Gray > > > > > > > > > > <vilhelm.gray@gmail.com> wrote: > > > > > > > > > > > > Why is the return type "unsigned long" where you know > > > > > > > > > > it return the 8-bit value ? > > > > > > > > > > > > > > > > > > Because bitmap API operates on unsigned long type. This is not only > > > > > > > > > consistency, but for sake of flexibility in case we would like to introduce > > > > > > > > > more calls like clump16 or so. > > > > > > > > > > > > > > > > TBH, that doesn't convince me: those functions explicitly take/return an > > > > > > > > 8-bit value, and have "8" in their name. The 8-bit value is never > > > > > > > > really related to, retrieved from, or stored in a full "unsigned long" > > > > > > > > element of a bitmap, only to/from/in a part (byte) of it. > > > > > > > > > > > > > > > > Following your rationale, all of iowrite{8,16,32,64}*() should take an > > > > > > > > "unsigned long" value, too. > > > > > > > > > > > > > > Using u8/u16/u32/u64 looks more consistent with other bitmap helpers. > > > > > > > > > > > > > > void bitmap_from_arr32(unsigned long *bitmap, const u32 *buf, unsigned > > > > > > > int nbits); > > > > > > > void bitmap_to_arr32(u32 *buf, const unsigned long *bitmap, unsigned int nbits); > > > > > > > static inline void bitmap_from_u64(unsigned long *dst, u64 mask); > > > > > > > > > > > > > > If you want to see more examples from other parts, > > > > > > > > > > > > Geert's and yours examples both are not related. They are about > > > > > > fixed-width properies when we know that is the part of protocol. > > > > > > Here we have no protocol which stricts us to the mentioned fixed-width types. > > > > > > > > > > Yes you have: they are functions to store/retrieve an 8-bit value from > > > > > the middle of the bitmap, which is reflected in their names ("clump8", > > > > > "value8"). > > > > > The input/output value is clearly separated from the actual bitmap, > > > > > which is referenced by the "unsigned long *". > > > > > > > > > > If you add new "value16" functions, they will be intended to store/retrieve > > > > > 16-bit values. > > > > > > > > And if I add 4-bit, 12-bit or 24-bit values, what should I use? > > > > > > Whatever is needed to store that? > > > I agree "unsigned long" is appropriate for a generic function to extract a > > > bit field of 1 to BITS_PER_LONG bits. > > > > > > > > Besides, if retrieving an 8-bit value requires passing an > > > > > "unsigned long *", the caller needs two variables: one unsigned long to > > > > > pass the address of, and one u8 to copy the returned value into. > > > > > > > > Why do you need a temporary variable? In some cases it might make > > > > sense, but in general simple cases I don't see what you may achieve > > > > with it. > > > > > > Because find_next_clump8() takes a pointer to store the output value. > > > > So does regmap_read(). > > I believe that one is different, as it is a generic function, and the > width of the > returned value depends on the regmap config. > > > 8 appeared there during review when it has been proposed to optimize to 8-bit > > clumps as most of the current users utilize it. The initial idea was to be > > bit-width agnostic. And with current API it's possible to easy convert to other > > formats later if we need. > > "optimized for 8-bit clumps" and "out-of-line function that takes an > unsigned long pointer for an output parameter" don't match well, IMHO. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds "Optimize" may not be the best way of describing it. I conceded to introducing a restricted implementation (i.e. for_each_set_clump8) since there were disagreements on the best approach for an implementation a generic for_each_set_clump macro that could support any bit size. So I settled for introducing just for_each_set_clump8 since it has an implementation everyone could agree on and I didn't want to stall the patchset for this introduction. I'm hoping to propose the generic for_each_set_clump macro again in the future after for_each_set_clump8 has had time to be utilized. There are some files that I think might benefit from such a generic implementation (e.g. gpio-thunderx with 64-bit ports and gpio-xilinx with variable size channels). In such case, for_each_set_clump8 would likely be reimplemented as a macro hardcoding an 8 passed to for_each_set_clump -- or perhaps just eliminated and replaced with for_each_set_clump directly -- so maintaining clump as unsigned long pointer is useful since we won't need to worry about redeclaring variables to match the datatype. Though I admit that there are advantages in specifying the datatype as u8 (or u16, u32, etc.). If we know the size then it's reasonable to expect that the implementation can be optimized to not worry about variable sizes and boundaries -- as exemplified by the simplicity of the for_each_set_clump8 implementation. So that may be an argument for keeping the for_each_set_clump8 implementation separate from the generic for_each_set_clump implementation. William Breathitt Gray
diff --git a/include/asm-generic/bitops/find.h b/include/asm-generic/bitops/find.h index 8a1ee10014de..9fdf21302fdf 100644 --- a/include/asm-generic/bitops/find.h +++ b/include/asm-generic/bitops/find.h @@ -80,4 +80,21 @@ extern unsigned long find_first_zero_bit(const unsigned long *addr, #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */ +/** + * find_next_clump8 - find next 8-bit clump with set bits in a memory region + * @clump: location to store copy of found clump + * @addr: address to base the search on + * @size: bitmap size in number of bits + * @offset: bit offset at which to start searching + * + * Returns the bit offset for the next set clump; the found clump value is + * copied to the location pointed by @clump. If no bits are set, returns @size. + */ +extern unsigned long find_next_clump8(unsigned long *clump, + const unsigned long *addr, + unsigned long size, unsigned long offset); + +#define find_first_clump8(clump, bits, size) \ + find_next_clump8((clump), (bits), (size), 0) + #endif /*_ASM_GENERIC_BITOPS_FIND_H_ */ diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h index 90528f12bdfa..761fab5b60a7 100644 --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -66,6 +66,8 @@ * bitmap_allocate_region(bitmap, pos, order) Allocate specified bit region * bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf to dst * bitmap_to_arr32(buf, src, nbits) Copy nbits from buf to u32[] dst + * bitmap_get_value8(map, start) Get 8bit value from map at start + * bitmap_set_value8(map, value, start) Set 8bit value to map at start * * Note, bitmap_zero() and bitmap_fill() operate over the region of * unsigned longs, that is, bits behind bitmap till the unsigned long @@ -488,6 +490,39 @@ static inline void bitmap_from_u64(unsigned long *dst, u64 mask) dst[1] = mask >> 32; } +/** + * bitmap_get_value8 - get an 8-bit value within a memory region + * @map: 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 @src + * memory region. + */ +static inline unsigned long bitmap_get_value8(const unsigned long *map, + unsigned long start) +{ + const size_t index = BIT_WORD(start); + const unsigned long offset = start % BITS_PER_LONG; + + return (map[index] >> offset) & 0xFF; +} + +/** + * bitmap_set_value8 - set an 8-bit value within a memory region + * @map: 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 *map, unsigned long value, + unsigned long start) +{ + const size_t index = BIT_WORD(start); + const unsigned long offset = start % BITS_PER_LONG; + + map[index] &= ~(0xFF << offset); + map[index] |= value << offset; +} + #endif /* __ASSEMBLY__ */ #endif /* __LINUX_BITMAP_H */ diff --git a/include/linux/bitops.h b/include/linux/bitops.h index cf074bce3eb3..fb94a10f7853 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -40,6 +40,11 @@ extern unsigned long __sw_hweight64(__u64 w); (bit) < (size); \ (bit) = find_next_zero_bit((addr), (size), (bit) + 1)) +#define for_each_set_clump8(start, clump, bits, size) \ + for ((start) = find_first_clump8(&(clump), (bits), (size)); \ + (start) < (size); \ + (start) = find_next_clump8(&(clump), (bits), (size), (start) + 8)) + static inline int get_bitmask_order(unsigned int count) { int order; diff --git a/lib/find_bit.c b/lib/find_bit.c index 5c51eb45178a..e35a76b291e6 100644 --- a/lib/find_bit.c +++ b/lib/find_bit.c @@ -214,3 +214,17 @@ EXPORT_SYMBOL(find_next_bit_le); #endif #endif /* __BIG_ENDIAN */ + +unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr, + unsigned long size, unsigned long offset) +{ + offset = find_next_bit(addr, size, offset); + if (offset == size) + return size; + + offset = round_down(offset, 8); + *clump = bitmap_get_value8(addr, offset); + + return offset; +} +EXPORT_SYMBOL(find_next_clump8);
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. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Suggested-by: Lukas Wunner <lukas@wunner.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> --- include/asm-generic/bitops/find.h | 17 +++++++++++++++ include/linux/bitmap.h | 35 +++++++++++++++++++++++++++++++ include/linux/bitops.h | 5 +++++ lib/find_bit.c | 14 +++++++++++++ 4 files changed, 71 insertions(+)