The classic m68k code has always supported an FPU (although it may have
been a software emulated one). The non-MMU m68k code has never supported FPU
hardware. To help in merging common code create a configation setting that
signifies if we are builing in FPU support or not.

This switch, CONFIG_FPU, is set as per the current use cases. So it is
always enabled if CONFIG_MMU is set, and disabled otherwise. With a little
extra code it will be possible to disable it on the classic m68k platforms
as well, and to enable it on non-MMU platforms that do have hardware FPU.

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

The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU
m68k case. But the underlying code to support it, update_persistent_clock(),
doesn't end up doing anything on the currently supported non-MMU platforms.
No platforms supply the necessary function support for writing back the RTC.

So lets remove this option and support code. This also brings m68knommu
in line with the m68k, which doesn't enabled this switch either.

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

frv, h8300, m68k, microblaze, openrisc, score, um and xtensa currently
do not register a CPU device.  Add the config option GENERIC_CPU_DEVICES
which causes a generic CPU device to be registered for each present CPU,
and make all these architectures select it.

Richard Weinberger <richard@nod.at> covered UML and suggested using
per_cpu.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lib: use generic pci_iomap on all architectures

Many architectures don't want to pull in iomap.c,
so they ended up duplicating pci_iomap from that file.
That function isn't trivial, and we are going to modify it
https://lkml.org/lkml/2011/11/14/183
so the duplication hurts.

This reduces the scope of the problem significantly,
by moving pci_iomap to a separate file and
referencing that from all architectures.

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  alpha: drop pci_iomap/pci_iounmap from pci-noop.c
  mn10300: switch to GENERIC_PCI_IOMAP
  mn10300: add missing __iomap markers
  frv: switch to GENERIC_PCI_IOMAP
  tile: switch to GENERIC_PCI_IOMAP
  tile: don't panic on iomap
  sparc: switch to GENERIC_PCI_IOMAP
  sh: switch to GENERIC_PCI_IOMAP
  powerpc: switch to GENERIC_PCI_IOMAP
  parisc: switch to GENERIC_PCI_IOMAP
  mips: switch to GENERIC_PCI_IOMAP
  microblaze: switch to GENERIC_PCI_IOMAP
  arm: switch to GENERIC_PCI_IOMAP
  alpha: switch to GENERIC_PCI_IOMAP
  lib: add GENERIC_PCI_IOMAP
  lib: move GENERIC_IOMAP to lib/Kconfig

Fix up trivial conflicts due to changes nearby in arch/{m68k,score}/Kconfig

We want to use the same timer support code for ColdFire CPU's when
running with MMU enabled or not. So use the same time_no.c code even
when the MMU is enabled for ColdFire. This also means we do not want
CONFIG_ARCH_USES_GETTIMEOFFSET set, since that code is only in time_mm.c.

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>

Create a config symbol to enable when using a ColdFire MMU. We then
use that to only compile the necessary arch mm files.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>

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>

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>

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>

The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the
MMU being present and enabled. It is a property of certain CPU families.
So select it based on those CPU types being selected.

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