redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity

s390/bitops: remove 31 bit related comments

Browse source 
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This commit is contained in:
Heiko Carstens 2015-10-08 13:51:44 +02:00 committed by Martin Schwidefsky
parent e4165dcbc0
commit 48002bd5af
2 changed files with 13 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
arch/s390/include/asm/bitops.h
View file

@ -11,30 +11,25 @@
* big-endian system because, unlike little endian, the number of each
* bit depends on the word size.
*
* The bitop functions are defined to work on unsigned longs, so for an
* s390x system the bits end up numbered:
* The bitop functions are defined to work on unsigned longs, so the bits
* end up numbered:
* |63..............0|127............64|191...........128|255...........192|
* and on s390:
* |31.....0|63....32|95....64|127...96|159..128|191..160|223..192|255..224|
*
* There are a few little-endian macros used mostly for filesystem
* bitmaps, these work on similar bit arrays layouts, but
* byte-oriented:
* bitmaps, these work on similar bit array layouts, but byte-oriented:
* |7...0|15...8|23...16|31...24|39...32|47...40|55...48|63...56|
*
* The main difference is that bit 3-5 (64b) or 3-4 (32b) in the bit
* number field needs to be reversed compared to the big-endian bit
* fields. This can be achieved by XOR with 0x38 (64b) or 0x18 (32b).
* The main difference is that bit 3-5 in the bit number field needs to be
* reversed compared to the big-endian bit fields. This can be achieved by
* XOR with 0x38.
*
* We also have special functions which work with an MSB0 encoding:
* on an s390x system the bits are numbered:
* We also have special functions which work with an MSB0 encoding.
* The bits are numbered:
* |0..............63|64............127|128...........191|192...........255|
* and on s390:
* |0.....31|32....63|64....95|96...127|128..159|160..191|192..223|224..255|
*
* The main difference is that bit 0-63 (64b) or 0-31 (32b) in the bit
* number field needs to be reversed compared to the LSB0 encoded bit
* fields. This can be achieved by XOR with 0x3f (64b) or 0x1f (32b).
* The main difference is that bit 0-63 in the bit number field needs to be
* reversed compared to the LSB0 encoded bit fields. This can be achieved by
* XOR with 0x3f.
*
*/
@ -299,10 +294,8 @@ static inline void __clear_bit_unlock(unsigned long nr,
/*
* Functions which use MSB0 bit numbering.
* On an s390x system the bits are numbered:
* The bits are numbered:
* |0..............63|64............127|128...........191|192...........255|
* and on s390:
* |0.....31|32....63|64....95|96...127|128..159|160..191|192..223|224..255|
*/
unsigned long find_first_bit_inv(const unsigned long *addr, unsigned long size);
unsigned long find_next_bit_inv(const unsigned long *addr, unsigned long size,

4
arch/s390/lib/find.c
View file

@ -1,10 +1,8 @@
/*
* MSB0 numbered special bitops handling.
*
* On s390x the bits are numbered:
* The bits are numbered:
* |0..............63|64............127|128...........191|192...........255|
* and on s390:
* |0.....31|32....63|64....95|96...127|128..159|160..191|192..223|224..255|
*
* The reason for this bit numbering is the fact that the hardware sets bits
* in a bitmap starting at bit 0 (MSB) and we don't want to scan the bitmap