dma: mv_xor: fix error handling of mv_xor_channel_add()

When mv_xor_channel_add() fails for one XOR channel, we jump to the
err_channel_add label to clean up all previous channels that had been
initialized correctly. Unfortunately, while handling this error
condition, we were disposing the IRQ mapping before calling
mv_xor_channel_remove() (which does the free_irq()), which is
incorrect.

Instead, do things properly in the reverse order of the
initialization: first remove the XOR channel (so that free_irq() is
done), and then dispose the IRQ mapping.

This avoids ugly warnings when for some reason one of the XOR channel
fails to initialize.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a bug fix for a change introduced in 3.8, so it should be
applied to 3.8.
dma: mv_xor: fix error handling for clocks

When a channel fails to initialize, we release all ressources,
including clocks. However, a XOR unit is not necessarily associated to
a clock (some variants of Marvell SoCs have a clock for XOR units,
some don't), so we shouldn't unconditionally be releasing the clock.

Instead, just like we do in the mv_xor_remove() function, we should
check if one clock was found before releasing it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a bug fix for a change introduced in 3.8, so it should be
applied to 3.8.
arm: cache-l2x0: aurora: Invalidate during clean operation with WT enable

This patch fixes a bug for Aurora L2 cache controller when the
write-through mode is enable. For the clean operation even if we don't
have to flush the lines we still need to invalidate them.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
arm: cache-l2x0: aurora: Use writel_relaxed instead of writel

The use of writel instead of writel_relaxed lead to deadlock in some
situation (SMP on Armada 370 for instance). The use of writel_relaxed
as it was done in the rest of this driver fixes this bug.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
arm: mvebu: Use dw-apb-uart instead of ns16650 as UART driver

The UART controller used in the Armada 370 and Armada XP SoCs is the
Synopsys DesignWare 8250 (aka Synopsys DesignWare ABP UART). The
improper use of the ns16550 can lead to a kernel oops during boot if
a character is sent to the UART before the initialization of the
driver. The DW APB has an extra interrupt that gets raised when
writing to the LCR when busy. This explains why we need to use
dw-apb-uart driver to handle this.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
net: mvneta: fix driver operation in SMP context

In order for the driver to behave properly in a SMP context, the same
transmit queue should be used by the kernel in dev_queue_xmit() and in
the driver's mvneta_tx() function. To achieve that, the driver now
implements the ->ndo_select_txq() operation.

For now, it always returns the same transmit queue, txq_def, until the
driver is expanded to properly take advantage of the multiqueue
capabilities of the hardware.

[Thomas Petazzoni: reword commit message]
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: Armada XP MV78230 has two cores, not one

Contrary to our understanding at the time armada-xp-mv78230.dtsi was
written, the MV78230 variant of the Armada XP SoC has two cores and
not one. This patch updates the .dtsi file to take into account this
reality.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces

We originally thought that the MV78230 variant of the Armada XP had
four Ethernet interfaces, like the other variants MV78260 and
MV78460. In fact, this is not true, and the MV78230 has only three
Ethernet interfaces.

So, the definitions of the Ethernet interfaces is now done as follows:

 * armada-370-xp.dtsi: definitions of the first two interfaces, that
   are common to Armada 370 and Armada XP

 * armada-xp.dtsi: definition of the third interface, common to all
   Armada XP variants.

 * armada-xp-mv78260.dtsi and armada-xp-mv78460.dtsi: definition of
   the fourth interface.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

The Armada 370 and Armada XP .dtsi files contained a mix of
space-based and tabulation-based indentation, with not even the same
width. This commit homogenize the indentation by using tabs everywhere
and making the indentation level match the DT information level.

The only non-whitespace change in this patch is the addition of a
semi-colon at the end of the cpus { }; section in
armada-xp-mv78230.dtsi.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.