linux/arch/m68k/lib, branch v3.0.77

m68k: use kernel processor defines for conditional optimizations

2011-06-14T01:42:29Z

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

m68knommu: move EXPORT of local checksumming functions to definitions

2011-05-24T00:03:51Z

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

m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.c

2011-05-24T00:03:50Z

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

m68k: remove duplicate memcpy() implementation

2011-05-24T00:03:49Z

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 Acked-by: Geert Uytterhoeven

m68k: remove duplicate memset() implementation

2011-05-24T00:03:49Z

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 Acked-by: Geert Uytterhoeven

m68k: remove duplicate memmove() implementation

2011-05-24T00:03:49Z

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 Acked-by: Geert Uytterhoeven

m68k: merge mmu and non-mmu versions of lib/Makefile

2011-05-24T00:03:49Z

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 Acked-by: Geert Uytterhoeven

m68k: merge mmu and non-mmu versions of muldi3

2011-05-24T00:03:49Z

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 Acked-by: Geert Uytterhoeven

m68k: merge m68k and m68knommu arch directories

2011-03-25T04:05:13Z

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 , which was originally written by Arnd Bergmann . > 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 > _mm. and the m68knommu version of the file is moved into the > corresponding m68k directory and renamed _no. and a small > wrapper file . 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 _mm. > #else > #include _no. > #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

m68k: remove arch specific non-optimized memcmp()

2011-02-15T23:42:24Z

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 ea61bc461d09e8d331a307916530aaae808c72a2 ("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 Acked-by: Geert Uytterhoeven