user/sven/linux.git/include/linux/bitmap.h, branch v3.18.94

lib: bitmap: add alignment offset for bitmap_find_next_zero_area()

2017-09-02T05:05:45Z

commit 5e19b013f55a884c59a14391b22138899d1cc4cc upstream. Add a bitmap_find_next_zero_area_off() function which works like bitmap_find_next_zero_area() function except it allows an offset to be specified when alignment is checked. This lets caller request a bit such that its number plus the offset is aligned according to the mask. [gregory.0xf0@gmail.com: Retrieved from https://patchwork.linuxtv.org/patch/6254/ and updated documentation] Signed-off-by: Michal Nazarewicz Signed-off-by: Kyungmin Park Signed-off-by: Marek Szyprowski Signed-off-by: Gregory Fong Cc: Joonsoo Kim Cc: Kukjin Kim Cc: Laurent Pinchart Cc: Laura Abbott Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

lib: bitmap: add missing mask in bitmap_andnot

2014-08-07T01:01:27Z

Apparently, bitmap_andnot is supposed to return whether the new bitmap is empty. But it didn't take potential garbage bits in the last word into account. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: add missing mask in bitmap_and

2014-08-07T01:01:27Z

Apparently, bitmap_and is supposed to return whether the new bitmap is empty. But it didn't take potential garbage bits in the last word into account. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: add missing mask in bitmap_shift_right

2014-08-07T01:01:27Z

There is no guarantee that *src does not contain garbage bits outside the lower nbits, so we need to mask it before the shift-and-assign. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: change parameter of bitmap_*_region to unsigned

2014-08-07T01:01:26Z

Changing the pos parameter of __reg_op to unsigned allows the compiler to generate slightly smaller and simpler code. Also update its callers bitmap_*_region to receive and pass unsigned int. The return types of bitmap_find_free_region and bitmap_allocate_region are still int to allow a negative error code to be returned. An int is certainly capable of representing any realistic return value. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: make the start index of bitmap_clear unsigned

2014-08-07T01:01:26Z

The compiler can generate slightly smaller and simpler code when it knows that "start" is non-negative. Also, use the names "start" and "len" for the two parameters for consistency with bitmap_set. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: make the start index of bitmap_set unsigned

2014-08-07T01:01:26Z

The compiler can generate slightly smaller and simpler code when it knows that "start" is non-negative. Also, use the names "start" and "len" for the two parameters in both header file and implementation, instead of the previous mix. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: make nbits parameter of bitmap_weight unsigned

2014-08-07T01:01:26Z

The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. I didn't change the return type, since that might change the semantics of some expression containing a call to bitmap_weight(). Certainly an int is capable of holding the result. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib: bitmap: make nbits parameter of bitmap_subset unsigned

2014-08-07T01:01:26Z

lib: bitmap: make nbits parameter of bitmap_intersects unsigned

2014-08-07T01:01:26Z