The changes in the mmu version of entry.h (entry_mm.h) and the non-mmu
version (entry_no.h) are not about the presence or use of an MMU at all.
The main changes are to support the ColdFire processors. The code for
trap entry and exit for all types of 68k processor outside coldfire is
the same.

So merge the files back to a single entry.h and share the common 68k
entry/exit code. Some changes are required for the non-mmu entry
handlers to adopt the differing macros for system call and interrupt
entry, but this is quite strait forward. The changes for the ColdFire
remove a couple of instructions for the separate a7 register case, and
are no worse for the older single a7 register case.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NMaxim Kuvyrkov <maxim@codesourcery.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Commit f159ee78 ("locking,
m68k/asm-offsets: Rename pt_regs offset defines") breaks the
m68knommu entry code that relies on these define names.
Fix the files to match the new define names.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The return from software signal handling pushes code on the stack
that system calls to the kernels cleanup code. This is borrowed
directly from the m68k linux signal handler.

The rt signal case is not quite right for the restricted instruction
set of the ColdFire parts. And neither the normal signal case or rt
signal case properly flushes/pushes the appropriate cache lines.

Rework the return path to just call back through some code fragments
in the kernel proper (with no MMU in the way we can do this). No
cache problems, and less code overall.

Original patch submitted by Wilson Callan <wcallan@savantav.com>

Greg fixed the rt signal return path to use the proper system call
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

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!