Compiling for a classic m68k non-MMU target with no specific CPU
selected fails with the following error:

   arch/m68k/68000/ints.c: In function 'process_int':
>> arch/m68k/68000/ints.c:82:30: error: 'ISR' undeclared (first use in this function)
      82 |         unsigned long pend = ISR;
         |                              ^~~

This interrupt handling code is specific to the 68328 family of 68000
parts. There is a couple of variants (68EZ328, 68VZ328) and the common
ancestor of them the strait 68328.

The code here includes a specific header for each variant type. But if
none is selected then nothing is included to supply the appropriate
register and bit flags defines.

Rearrange the includes so that at least one type is always included.
At the very least the 68328 base type should be the fallback, so make
that true.

Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>

The non-mmu 68000 specific code is inconsistently placed under a directory
named "platform". Move it to arch/m68k/ along with the other platform and
machine directories.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

This patch merges all 68000 core cpus into one directory.
There is a lot of common code in the 68328, 68EZ328 and 68VZ328 directories.

This will also facilitate easy development of support for original stand
alone MC68000 CPU machines.

Signed-off-by: Luis Alves <ljalvs@gmail.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

The base of the real RAM resident hardware vectors, _ramvec, is declared in
our asm/traps.h. No need to have local declarations spread around in other
files that use this. So remove them.

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

commit 2502b667 ("Change the m68knommu irq
handling to use the generic irq framework.") removed the reporting of spurious
interrupts on nommu (68328 and 68360).

Bring it back in a generic way, using "atomic_t irq_err_count", as that's what
most of the other architectures are using.

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

Currently trap_init() is an empty function for m68knommu. Instead
the vectors are being setup as part of the IRQ initialization.
This is inconsistent with m68k and other architectures.

Change the local init_vectors() to be trap_init(), and init the
vectors at the correct time during startup. This will help merge of
m68k and m68knommu trap code in the furture.

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

Scripted with coccinelle.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

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>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

Fix compile error, by using correct loop variable:

arch/m68knommu/platform/68328/ints.c: In function ‘init_IRQ’:
arch/m68knommu/platform/68328/ints.c:182: error: ‘irq’ undeclared (first use in this function)
arch/m68knommu/platform/68328/ints.c:182: error: (Each undeclared identifier is reported only once
arch/m68knommu/platform/68328/ints.c:182: error: for each function it appears in.)

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

The use of __do_IRQ is deprecated, so lets stop using it.
Generally the interrupts on the supported processors here are
level triggered, so this is strait forward to switch over to
using the standard handle_level_irq flow handler. (Although
some ColdFire parts support edge triggered GPIO line  interrupts
we have no support for them yet).

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

Define the interrupt controller structures along with the interrupt
controller code for the 68328 CPU family. This brings the interrupt
setup and control into one place for this CPU family.

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

Change the m68knommu irq handling to use the generic irq framework.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Remove regs arg from bad interrupt handler.
Use irq_handler_t type for handler arg of local request_irq().

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Remove the inline 68328 romvec section asm code into its own file.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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!