This patch fixes unaligned memory access for the 68000 core based cpu's.

Some time ago, my cpu (68000) was raising address/bus error's when mounting
cifs shares (didn't bother to debug it at the time). After developing the
MMC/SD card driver I was having the same issue when mounting the vfat fs.

I've traced the issue down to the 'unaligned.h' file. (I guess nobody has
ever used unaligned.h back in the 68328 'era'.
Signed-off-by: Luis Alves <ljalvs@gmail.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

The majority of the m68k architecture dma code is the same, so merge the
current separated files dma_no.c and dma_mm.c back into a single dma.c

The main alloc and free routines are a little different, so we keep a
single #ifdef based on CONFIG_MMU for them. All the other support functions
are now identical.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Introduce cache_push() and cache_clear() functions for the non-MMU m68k
devices. With these in place we can more easily merge some of the common
m68k arch code.

In particular by reorganizing the __flush_cache_all() code and separating
the cache push and clear functions it becomes trivial to implement the
new cache_push() and cache_clear() functions.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

The code that adds each ColdFire platforms GPIO signals is duplicated in
each platforms specific code. Remove it from each platforms code and put
a single version in the existing ColdFire gpio subsystem init code.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.

We also need to rename some of the GPIO registers to be consistent with
all other ColdFire parts (we can't use the new GPIO macros otherwise).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

We have very large tables in the ColdFire CPU GPIO setup code that essentially
boil down to 2 distinct types of GPIO pin initiaization. Using 2 macros we can
reduce these large tables to at most a dozen lines of setup code, and in quite
a few cases a single table entry.

Introduce these 2 macros into the existing mcfgpio.h header.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Steven King <sfking@fdwdc.com>

This patch removes the following warning:
fs/binfmt_flat.c:752: warning: unused variable 'persistent'.
There is neither functionality change, nor extra code generated.
Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

The MMU (signal_mm.c) and non-MMU (signal_no.c) versions of the m68k
architecture signal handling code are very similar. Most of their code is
the same.

Merge the two back into a single signal.c, and move some of the code around
inside the file to minimize the number of #ifdefs required. Specificially
we can group out the CONFIG_FPU and the CONFIG_MMU code. We end up needing
a few other "#ifdef CONFIG_MMU" as well, but not too many.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

.. and this should hopefully be the last -rc before final 3.4 release.

Pull ARM: SoC fixes from Olof Johansson:
 "I was hoping to be done with fixes for 3.4 but we got two branches
  from subarch maintainers the last couple of days.  So here is one
  last(?) pull request for arm-soc containing 7 patches:

   - Five of them are for shmobile dealing with SMP setup and compile
     failures
   - The remaining two are for regressions on the Samsung platforms"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: EXYNOS: fix ctrlbit for exynos5_clk_pdma1
  ARM: EXYNOS: use s5p-timer for UniversalC210 board
  ARM / mach-shmobile: Invalidate caches when booting secondary cores
  ARM / mach-shmobile: sh73a0 SMP TWD boot regression fix
  ARM / mach-shmobile: r8a7779 SMP TWD boot regression fix
  ARM: mach-shmobile: convert ag5evm to use the generic MMC GPIO hotplug helper
  ARM: mach-shmobile: convert mackerel to use the generic MMC GPIO hotplug helper