Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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

arch/s390/include/asm/bitops.h

+12 −19
Original line number Diff line number Diff line
@@ -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,

arch/s390/lib/find.c

+1 −3
Original line number Diff line number Diff line 
/*

 * 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