Commit Graph

30 Commits

Author SHA1 Message Date
Geert Uytterhoeven 5df58f3aac m68k: delay, muldi3 - Use CONFIG_CPU_HAS_NO_MULDIV64
instead of open coding CONFIG_M68000 || CONFIG_COLDFIRE

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>
2012-06-10 10:18:30 +02:00
Geert Uytterhoeven d8ce7263e1 m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
2012-06-06 15:31:28 +02:00
Greg Ungerer e08d703cc2 m68k: modify user space access functions to support ColdFire CPUs
Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.

The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.

Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.

The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-12-30 10:20:21 +10:00
Greg Ungerer 84f3fb7a2a m68k: handle presence of 64bit mul/div instructions cleanly
The traditional 68000 processors and the newer reduced instruction set
ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
divide instructions. This is not a difference based on the presence of
a hardware MMU or not.

Create a new config symbol to mark that a CPU type doesn't support the
longer multiply/divide instructions. Use this then as a basis for using
the fast 64bit based divide (in div64.h) and for linking in the extra
libgcc functions that may be required (mulsi3, divsi3, etc).

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-12-24 21:47:57 +10:00
Greg Ungerer 7f73bafc46 m68k: simpler m68k and ColdFire CPU's can use generic csum code
We have two implementations of the IP checksuming code for the m68k arch.
One uses the more advanced instructions available in 68020 and above
processors, the other uses the simpler instructions available on the
original 68000 processors and the modern ColdFire processors.

This simpler code is pretty much the same as the generic lib implementation
of the IP csum functions. So lets just switch over to using that. That
means we can completely remove the checksum_no.c file, and only have the
local fast code used for the more complex 68k CPU family members.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-24 21:47:57 +10:00
Greg Ungerer f230e80b42 m68k: fix memcpy to unmatched/unaligned source and dest on 68000
The original 68000 processors cannot copy 16bit or larger quantities from
odd addresses. All newer members of the 68k family (including ColdFire)
can do this.

In the current memcpy implementation after trying to align the destination
address to a 16bit boundary if we end up with an odd source address we go
off and try to copy multi-byte quantities from it. This will trap on the
68000.

The only solution if we end with an odd source address is to byte wise
copy the whole memcpy region. We only need to do this if we are supporting
original 68000 processors.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-10-18 14:22:24 +10:00
Greg Ungerer 7c946199cd m68k: merge and clean up delay.h files
The real difference between the mmu and non-mmu varients of the delay.h
files has nothing to do with having an mmu or not. It is processor family
differences that means slightly different code. Merge the delay_mm.h and
delay_no.h files back into a single file.

The primarly difference we need to deal with is whether the processor
supports a 32bit * 32bit -> 64bit multiply. Without it we need to do some
shift scaling as well as use a 32bit * 32bit -> 32bit multiply. If building
for a multi-CPU type kernel then we must use the simpler mult/shift scaling.

This version of delay code allows the CPU32 family to use a 64bit mul,
since it supports this instruction, the old code did not.

The changes use macros where appropriate to try and optimize constant sized
udelay times. And it removes the use of a fixed lib function for the non-mmu
case. Code size on typical kernel configurations is similar, or only larger
by a few tens of bytes.

Also removed the unused muldiv() code from delay_mm.h.

Build and run tested on ColdFire and ARAnyM. Build tested only on 68328
and 68360 (CPU32).

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-07-25 11:20:41 +10:00
Greg Ungerer 734c3ce3bd m68k: use kernel processor defines for conditional optimizations
Older m68k-linux compilers will include pre-defined symbols that
confuse what processor it is being targeted for. For example gcc-4.1.2
will pre-define __mc68020__ even if you specify the target processor
as -m68000 on the gcc command line. Newer versions of gcc have this
corrected.

In a few places the m68k code uses defined(__mc68020__) for optimizations
that include instructions that are specific to the CPU 68020 and above.
When compiling with older compilers this will be true even when we have
selected to compile for the older 68000 processors.

Switch to using the kernel processor defines, CONFIG_M68020 and friends.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-14 11:42:29 +10:00
Greg Ungerer b33972eb47 m68knommu: move EXPORT of local checksumming functions to definitions
The EXPORT_SYMBOL() of the local lib checksum functions belongs with
the definitions, not in some other random code file. So move then there.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-05-24 10:03:51 +10:00
Greg Ungerer 9461702d2a m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.c
We don't need an arch/m68k/lib/checksum.c wrapper to include the correct
mmu or non-mmu version of the checksum code. Let the Makefile just build
the appropriate one.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-05-24 10:03:50 +10:00
Greg Ungerer 66d83ab32a m68k: remove duplicate memcpy() implementation
Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memcpy(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memcpy(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-05-24 10:03:49 +10:00
Greg Ungerer d10ed2f538 m68k: remove duplicate memset() implementation
Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memset(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memset(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-05-24 10:03:49 +10:00
Greg Ungerer 80160de89d m68k: remove duplicate memmove() implementation
Merging the mmu and non-mmu directories we ended up with duplicate
(and identical) implementations of memmove(). Remove one of them.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-05-24 10:03:49 +10:00
Greg Ungerer b82ed87e67 m68k: merge mmu and non-mmu versions of lib/Makefile
We can easily support the slight differences in libs needed by the
mmu and non-mmu builds in a single Makefile, so merge them back into
a single file again.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-05-24 10:03:49 +10:00
Greg Ungerer 98d655a68f m68k: merge mmu and non-mmu versions of muldi3
The implementation of gcc's muldi3 support function differs only in
the use of the machine's 64 bit sized mul or not. (It isn't based
on using an MMU or not). Merge the current mmu and non-mmu versions
of arc/m68k/lib/muldi3 and use the appropriate pre-processor
conditionals to get the right version for all m68k processor types.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-05-24 10:03:49 +10:00
Greg Ungerer 66d857b08b m68k: merge m68k and m68knommu arch directories
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.

This is a brute force merge, based on a script from Stephen King
<sfking@fdwdc.com>, which was originally written by Arnd Bergmann
<arnd@arndb.de>.

> The script was inspired by the script Sam Ravnborg used to merge the
> includes from m68knommu. For those files common to both arches but
> differing in content, the m68k version of the file is renamed to
> <file>_mm.<ext> and the m68knommu version of the file is moved into the
> corresponding m68k directory and renamed <file>_no.<ext> and a small
> wrapper file <file>.<ext> is used to select between the two version. Files
> that are common to both but don't differ are removed from the m68knommu
> tree and files and directories that are unique to the m68knommu tree are
> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
>
> To select between the the versions of the files, the wrapper uses
>
> #ifdef CONFIG_MMU
> #include <file>_mm.<ext>
> #else
> #include <file>_no.<ext>
> #endif

On top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.

With this in place there is now quite a bit of scope for merge cleanups
in future patches.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-03-25 14:05:13 +10:00
Greg Ungerer f9d693d237 m68k: remove arch specific non-optimized memcmp()
The m68k arch implements its own memcmp() function. It is not optimized
in any way (it is the most strait forward coding of memcmp you can get).
Remove it and use the kernels standard memcmp() implementation.

This also goes part of the way to fixing a regression caused by commit
ea61bc461d ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memcmp() function
defined, since there is none in the m68knommu/lib functions.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-02-16 09:42:24 +10:00
Mathieu Desnoyers a0c14d28df Stringify support commas
> This is a no-no for those archs that still use -traditional.
 > > I dunno if this is a problem for you at the moment and the
 > > right fix is anyway to nuke -traditional.
 > >
 > >     Sam

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-20 17:24:38 -07:00
Al Viro 337e3c48e9 provide out-of-line strcat() for m68k
Whether we sidestep it in init/main.c or not, such situations
will arise again; compiler does generate calls of strcat()
on optimizations, so we really ought to have an out-of-line
version...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-05-21 16:56:00 -07:00
Matthew Wilcox 64ac24e738 Generic semaphore implementation
Semaphores are no longer performance-critical, so a generic C
implementation is better for maintainability, debuggability and
extensibility.  Thanks to Peter Zijlstra for fixing the lockdep
warning.  Thanks to Harvey Harrison for pointing out that the
unlikely() was unnecessary.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
2008-04-17 10:42:34 -04:00
Al Viro 547c178b72 missing exports of csum_...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17 11:01:07 -07:00
Geert Uytterhoeven 3c46bdcaec m68k: implement __clear_user()
m68k: implement __clear_user(), which is needed by fs/signalfd.c

Since we always let the MMU do all checking, clear_user() and __clear_user()
are identical. The old clear_user() is renamed to __clear_user() for
consistency.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-15 08:54:00 -07:00
Geert Uytterhoeven f5456e040e m68k: export csum_partial_copy_from_user
net/rxrpc/af-rxrpc.ko needs csum_partial_copy_from_user

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-04 17:59:08 -07:00
Al Viro 2061acaaae [NET]: M68K checksum annotations and cleanups.
* sanitize prototypes, annotate

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-02 21:23:07 -08:00
Roman Zippel 6c04c28a65 [PATCH] m68k: fix typo in __generic_copy_to_user
Jump to the correct exit label after exception

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-06 08:53:40 -07:00
Roman Zippel d6359fd783 [PATCH] m68k: cleanup string functions
- cleanup asm of string functions
- deinline strncat()/strncmp()
- provide non-inlined strcpy()

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-06 08:53:40 -07:00
Roman Zippel d94af931af [PATCH] m68k: clean up uaccess.h
This uninlines a few large functions in uaccess.h and cleans up the rest.
It includes a (hopefully temporary) workaround for the broken typeof of
gcc-4.1.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-23 07:43:01 -07:00
Al Viro 6225d85f17 [PATCH] m68k: checksum __user annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-12 09:09:03 -08:00
Roman Zippel 072dffda1d [PATCH] m68k: cleanup inline mem functions
Use the builtin functions for memset/memclr/memcpy, special optimizations for
page operations have dedicated functions now.  Uninline memmove/memchr and
move all functions into a single file and clean it up a little.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:19 -07:00
Linus Torvalds 1da177e4c3 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-16 15:20:36 -07:00