linux.git/include/asm-m68k, branch v2.6.26-rc7

m68k: Add ext2_find_{first,next}_bit() for ext4

2008-06-13T01:05:39+00:00

Add ext2_find_{first,next}_bit(), which are needed for ext4.  They're
derived out of the ext2_find_next_zero_bit found in the same file.
Compile tested with crosstools

[Reworked to preserve all symmetry with ext2_find_{first,next}_zero_bit()]

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10393

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

m68k: Prefix ISA type with ISA_TYPE_

2008-05-18T20:28:50+00:00

The *_ISA type defines are quite generic and cause namespace conflicts
(e.g. with `AMIGAHW_DECLARE(GG2_ISA)' in ) for some kernel
configurations. Use ISA_TYPE_* to avoid such conflicts.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

m68k: export m68k_mmutype

2008-05-18T20:28:50+00:00

UIO needs m68k_mmutype:

ERROR: "m68k_mmutype" [drivers/uio/uio.ko] undefined!

(noticed by Christian T. Steigies)

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

m68k: Make gcc aware that BUG() does not return

2008-05-18T20:28:48+00:00

Use `__builtin_trap()' instead of `asm volatile("illegal")' in the m68k BUG()
macros (as suggested by Andrew Pinski), to kill warnings in code that assumes
BUG() does not return.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

m68k: Convert access_ok() to an inline function

2008-05-18T20:28:48+00:00

Convert access_ok() from a macro to an inline function, so the compiler no
longer complains about unused variables:

    fs/read_write.c: In function 'rw_copy_check_uvector':
    fs/read_write.c:556: warning: unused variable 'buf'

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

m68k: remove old mac_esp cruft

2008-05-05T19:38:50+00:00

Remove the rest of the old mac_esp driver. Also ditch the rest of the
machw mechanism, it needs to be replaced by a fake openfirmware tree.

Signed-off-by: Finn Thain 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Torvalds

m68k: types: use for the m68k architecture

2008-05-02T23:18:28+00:00

This modifies  to use the 
generic include files.

Signed-off-by: H. Peter Anvin 
Cc: Geert Uytterhoeven 
Cc: Roman Zippel

rename div64_64 to div64_u64

2008-05-01T15:03:58+00:00

Rename div64_64 to div64_u64 to make it consistent with the other divide
functions, so it clearly includes the type of the divide.  Move its definition
to math64.h as currently no architecture overrides the generic implementation.
 They can still override it of course, but the duplicated declarations are
avoided.

Signed-off-by: Roman Zippel 
Cc: Avi Kivity 
Cc: Russell King 
Cc: Geert Uytterhoeven 
Cc: Ralf Baechle 
Cc: David Howells 
Cc: Jeff Dike 
Cc: Ingo Molnar 
Cc: "David S. Miller" 
Cc: Patrick McHardy 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel: Move arches to use common unaligned access

2008-04-29T15:06:27+00:00

Unaligned access is ok for the following arches:
cris, m68k, mn10300, powerpc, s390, x86

Arches that use the memmove implementation for native endian, and
the byteshifting for the opposite endianness.
h8300, m32r, xtensa

Packed struct for native endian, byteshifting for other endian:
alpha, blackfin, ia64, parisc, sparc, sparc64, mips, sh

m86knommu is generic_be for Coldfire, otherwise unaligned access is ok.

frv, arm chooses endianness based on compiler settings, uses the byteshifting
versions.  Remove the unaligned trap handler from frv as it is now unused.

v850 is le, uses the byteshifting versions for both be and le.

Remove the now unused asm-generic implementation.

Signed-off-by: Harvey Harrison 
Acked-by: David S. Miller 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: introduce pte_special pte bit

2008-04-28T15:58:23+00:00

s390 for one, cannot implement VM_MIXEDMAP with pfn_valid, due to their memory
model (which is more dynamic than most).  Instead, they had proposed to
implement it with an additional path through vm_normal_page(), using a bit in
the pte to determine whether or not the page should be refcounted:

vm_normal_page()
{
	...
        if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
                if (vma->vm_flags & VM_MIXEDMAP) {
#ifdef s390
			if (!mixedmap_refcount_pte(pte))
				return NULL;
#else
                        if (!pfn_valid(pfn))
                                return NULL;
#endif
                        goto out;
                }
	...
}

This is fine, however if we are allowed to use a bit in the pte to determine
refcountedness, we can use that to _completely_ replace all the vma based
schemes.  So instead of adding more cases to the already complex vma-based
scheme, we can have a clearly seperate and simple pte-based scheme (and get
slightly better code generation in the process):

vm_normal_page()
{
#ifdef s390
	if (!mixedmap_refcount_pte(pte))
		return NULL;
	return pte_page(pte);
#else
	...
#endif
}

And finally, we may rather make this concept usable by any architecture rather
than making it s390 only, so implement a new type of pte state for this.
Unfortunately the old vma based code must stay, because some architectures may
not be able to spare pte bits.  This makes vm_normal_page a little bit more
ugly than we would like, but the 2 cases are clearly seperate.

So introduce a pte_special pte state, and use it in mm/memory.c.  It is
currently a noop for all architectures, so this doesn't actually result in any
compiled code changes to mm/memory.o.

BTW:
I haven't put vm_normal_page() into arch code as-per an earlier suggestion.
The reason is that, regardless of where vm_normal_page is actually
implemented, the *abstraction* is still exactly the same. Also, while it
depends on whether the architecture has pte_special or not, that is the
only two possible cases, and it really isn't an arch specific function --
the role of the arch code should be to provide primitive functions and
accessors with which to build the core code; pte_special does that. We do
not want architectures to know or care about vm_normal_page itself, and
we definitely don't want them being able to invent something new there
out of sight of mm/ code. If we made vm_normal_page an arch function, then
we have to make vm_insert_mixed (next patch) an arch function too. So I
don't think moving it to arch code fundamentally improves any abstractions,
while it does practically make the code more difficult to follow, for both
mm and arch developers, and easier to misuse.

[akpm@linux-foundation.org: build fix]
Signed-off-by: Nick Piggin 
Acked-by: Carsten Otte 
Cc: Jared Hulbert 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds