WSL2-Linux-Kernel/include/asm-parisc/types.h

#ifndef _PARISC_TYPES_H
#define _PARISC_TYPES_H

#include <asm-generic/int-ll64.h>

#ifndef __ASSEMBLY__

typedef unsigned short umode_t;

#endif /* __ASSEMBLY__ */

/*
 * These aren't exported outside the kernel to avoid name space clashes
 */
#ifdef __KERNEL__

#ifdef CONFIG_64BIT
#define BITS_PER_LONG 64
#define SHIFT_PER_LONG 6
#else
#define BITS_PER_LONG 32
#define SHIFT_PER_LONG 5
#endif

#ifndef __ASSEMBLY__

/* Dma addresses are 32-bits wide.  */

typedef u32 dma_addr_t;
typedef u64 dma64_addr_t;

#endif /* __ASSEMBLY__ */

#endif /* __KERNEL__ */

#endif
Linux-2.6.12-rc2 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! 2005-04-17 02:20:36 +04:00			`#ifndef _PARISC_TYPES_H`
			`#define _PARISC_TYPES_H`

parisc: types: use <asm-generic/int-.h> for the parisc architecture This modifies <asm-parisc/types.h> to use the <asm-generic/int-.h> generic include files. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Kyle McMartin <kyle@parisc-linux.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Grant Grundler <grundler@parisc-linux.org> 2008-04-06 21:35:09 +04:00			`#include <asm-generic/int-ll64.h>`

Linux-2.6.12-rc2 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! 2005-04-17 02:20:36 +04:00			`#ifndef __ASSEMBLY__`

			`typedef unsigned short umode_t;`

			`#endif /* __ASSEMBLY__ */`

			`/*`
			`* These aren't exported outside the kernel to avoid name space clashes`
			`*/`
			`#ifdef __KERNEL__`

[PARISC] convert to use CONFIG_64BIT instead of __LP64__ Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> 2007-01-28 17:09:20 +03:00			`#ifdef CONFIG_64BIT`
Linux-2.6.12-rc2 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! 2005-04-17 02:20:36 +04:00			`#define BITS_PER_LONG 64`
[PARISC] Update bitops from parisc tree Optimize ext2_find_next_zero_bit. Gives about 25% perf improvement with a rsync test with ext3. Signed-off-by: Randolph Chung <tausq@parisc-linux.org> fix ext3 performance - ext2_find_next_zero() was culprit. Kudos to jejb for pointing out the the possibility that ext2_test_bit and ext2_find_next_zero() may in fact not be enumerating bits in the bitmap because of endianess. Took sparc64 implementation and adapted it to our tree. I suspect the real problem is ffz() wants an unsigned long and was getting garbage in the top half of the unsigned int. Not confirmed but that's what I suspect. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Fix find_next_bit for 32-bit Make masking consistent for bitops From: Joel Soete <soete.joel@tiscali.be> Signed-off-by: Randolph Chung <tausq@parisc-linux.org> Add back incorrectly removed ext2_find_first_zero_bit definition Signed-off-by: James Bottomley <jejb@parisc-linux.org> Fixup bitops.h to use volatile for _bit() ops Based on this email thread: http://marc.theaimsgroup.com/?t=108826637900003 In a nutshell: _bit() want use of volatile. ___bit() are "relaxed" and don't use spinlock or volatile. other minor changes: o replaces hweight64() macro with alias to generic_hweight64() (Joel Soete) o cleanup ext2 macros so (a) it's obvious what the XOR magic is about and (b) one version that works for both 32/64-bit. o replace 2 uses of CONFIG_64BIT with __LP64__. bitops.h used both. I think header files that might go to user space should use something userspace will know about (__LP64__). Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Move SHIFT_PER_LONG to standard location for BITS_PER_LONG (asm/types.h) and ditch the second definition of BITS_PER_LONG in bitops.h Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> 2005-10-22 06:45:22 +04:00			`#define SHIFT_PER_LONG 6`
Linux-2.6.12-rc2 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! 2005-04-17 02:20:36 +04:00			`#else`
			`#define BITS_PER_LONG 32`
[PARISC] Update bitops from parisc tree Optimize ext2_find_next_zero_bit. Gives about 25% perf improvement with a rsync test with ext3. Signed-off-by: Randolph Chung <tausq@parisc-linux.org> fix ext3 performance - ext2_find_next_zero() was culprit. Kudos to jejb for pointing out the the possibility that ext2_test_bit and ext2_find_next_zero() may in fact not be enumerating bits in the bitmap because of endianess. Took sparc64 implementation and adapted it to our tree. I suspect the real problem is ffz() wants an unsigned long and was getting garbage in the top half of the unsigned int. Not confirmed but that's what I suspect. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Fix find_next_bit for 32-bit Make masking consistent for bitops From: Joel Soete <soete.joel@tiscali.be> Signed-off-by: Randolph Chung <tausq@parisc-linux.org> Add back incorrectly removed ext2_find_first_zero_bit definition Signed-off-by: James Bottomley <jejb@parisc-linux.org> Fixup bitops.h to use volatile for _bit() ops Based on this email thread: http://marc.theaimsgroup.com/?t=108826637900003 In a nutshell: _bit() want use of volatile. ___bit() are "relaxed" and don't use spinlock or volatile. other minor changes: o replaces hweight64() macro with alias to generic_hweight64() (Joel Soete) o cleanup ext2 macros so (a) it's obvious what the XOR magic is about and (b) one version that works for both 32/64-bit. o replace 2 uses of CONFIG_64BIT with __LP64__. bitops.h used both. I think header files that might go to user space should use something userspace will know about (__LP64__). Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Move SHIFT_PER_LONG to standard location for BITS_PER_LONG (asm/types.h) and ditch the second definition of BITS_PER_LONG in bitops.h Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> 2005-10-22 06:45:22 +04:00			`#define SHIFT_PER_LONG 5`
Linux-2.6.12-rc2 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! 2005-04-17 02:20:36 +04:00			`#endif`

			`#ifndef __ASSEMBLY__`

			`/* Dma addresses are 32-bits wide. */`

			`typedef u32 dma_addr_t;`
			`typedef u64 dma64_addr_t;`

			`#endif /* __ASSEMBLY__ */`

			`#endif /* __KERNEL__ */`

			`#endif`