aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-s390/bitops.h
Commit message (Collapse)AuthorAge
* [S390] cleanup bitops.h.Heiko Carstens2006-06-29
| | | | | | | | | Encapsulate complete bitops.h with #ifdef __KERNEL__ and remove the now superfluous ALIGN_CS define and its users. This patch is needed for compiling klibc. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [PATCH] bitops: s390: use generic bitopsAkinobu Mita2006-03-26
| | | | | | | | | | | | | | - remove generic_ffs() - remove generic_fls() - remove generic_fls64() - remove generic_hweight{64,32,16,8}() - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit() Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] bitops: use non atomic operations for minix_*_bit() and ext2_*_bit()Akinobu Mita2006-03-26
| | | | | | | | | | | | | | | | Bitmap functions for the minix filesystem and the ext2 filesystem except ext2_set_bit_atomic() and ext2_clear_bit_atomic() do not require the atomic guarantees. But these are defined by using atomic bit operations on several architectures. (cris, frv, h8300, ia64, m32r, m68k, m68knommu, mips, s390, sh, sh64, sparc, sparc64, v850, and xtensa) This patch switches to non atomic bit operation. Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: remove one set of brackets in __constant_test_bit()Eric Paris2006-02-12
| | | | | | | | | | | Right now in __constant_test_bit for the s390 there is an extra set of () surrounding the calculation. This patch simply removes one set of () that is surrounding the whole clause. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [FLS64]: generic versionStephen Hemminger2006-01-03
| | | | | Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] s390: test_bit return valueChristian Borntraeger2005-11-07
| | | | | | | | | | | The test_bit function returns a non-boolean value, it returns 0,1,2,4,... instead of only 0 or 1. This causes wrongs results in the mincore system call. Check against 0 to get a proper boolean value. Signed-off-by: Christian Borntraeger <cborntra@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: find_next_{zero}_bit fixesMartin Schwidefsky2005-07-27
| | | | | | | | | | | | | | | | | | | The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!