Conflicts:
	arch/arm/Kconfig
	arch/arm/mach-exynos4/mach-nuri.c

Conflicts:
	arch/arm/Kconfig
	arch/arm/mach-ns9xxx/include/mach/uncompress.h

Fixing a few "please, no space before tabs" and "empty line at end of
file" warnings on the way.

LAKML-Reference: 1299271882-2130-6-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Since support for mxc91231 was introduced 2009 it only saw patches that
were part of (mxc or arm) global cleanups. The only supported machine
only had 4 devices (2x UART, sdhc, watchdog).

Cc: Dmitriy Taychenachev <dimichxp@gmail.com>
LAKML-Reference: 1302211482-17926-1-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Now that both users of plat-stmp have been deleted in previous patches,
delete the platform, too.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This mach has not seen any updates since the initial inclusion besides
generic cleanup. Furthermore:

- The i.MX23 covered in mach-mxs is just a renamed version of the
  STMP378x.

- mach-stmp378x has a lot of reinvented interfaces, leaking all sorts of
  mach-related includes into the drivers. One example is the dmaengine
  which does not use the linux dmaengine-API but some privately exported
  symbols. So drivers cannot be reused. mach-mxs does it better.

- There is only one board defined (which I couldn't find any trace of
  despite being a development board). It has been converted to
  mach-mxs in a previous patch.

Since the only user of this mach was converted, it means that
mach-stmp378x can go.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This mach has not seen any updates since the initial inclusion besides
generic cleanup. Furthermore:

- It has a lot of reinvented interfaces, leaking all sorts of
  mach-related includes into the drivers. One example is the dmaengine
  which does not use the linux dmaengine-API but some privately exported
  symbols. So, drivers cannot be reused. mach-mxs is very similar and
  does it better.

- It can be doubted that this worked at all. Check the DMA routines in
  stmp37xx.c for copy/paste bugs. A lot of APBX-related stuff is
  actually writing into registers for APBH.

- There is only one board defined (which I couldn't find any trace of
  despite being a development board). In this board, only two devices
  have resources, the debug uart and the application uart. Neither of
  those have the needed custom drivers merged (and never will). debug
  uart is amba-pl011 which has an in-kernel driver without the
  mach-specific-stuff. appuart has a driver which was introduced for
  mach-mxs, and this one is reusable for a properly done mach.

So, this single board registers only unsupported devices and the
generic code looks suspicious and has poor design. Delete this
stuff. If there is interest, it is wiser to restart using
mach-mxs.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The port is actually unmaintained and only received global
cleanups and a few build fixes since mid 2008.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>