Commit 48002bd5 authored by Heiko Carstens's avatar Heiko Carstens Committed by Martin Schwidefsky

s390/bitops: remove 31 bit related comments

Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
parent e4165dcb
......@@ -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,
......
/*
* 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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment