linux-stable.git/arch, branch v3.12.5

x86-64, build: Always pass in -mno-sse

2013-12-12T06:37:54+00:00

commit 5551a34e5aeab868f8d37f70d8754868921b4ee5 upstream.

Always pass in the -mno-sse argument, regardless if
-preferred-stack-boundary is supported.  We never want to generate SSE
instructions in the kernel unless we *really* know what we're doing.

According to H. J. Lu, any version of gcc new enough that we support
it at all should handle the -mno-sse option, so just add it
unconditionally.

Reported-by: Kevin B. Smith 
Signed-off-by: H. Peter Anvin 
Cc: H. J. Lu 
Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
Signed-off-by: Greg Kroah-Hartman

parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address

2013-12-12T06:37:54+00:00

commit 0576da2c08e3d332f1b0653030d28ab804585ab6 upstream.

locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)

Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.

The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.

Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: re-enable PCIe on Armada 370 DB

2013-12-12T06:37:53+00:00

commit 96039f735e290281d0c8a08fc467de2cd610543d upstream.

Commit 14fd8ed0a7fd19913 ("ARM: mvebu: Relocate Armada 370/XP PCIe
device tree nodes") relocated the PCIe controller DT nodes one level
up in the Device Tree, to reflect a more correct representation of the
hardware introduced by the mvebu-mbus Device Tree binding.

However, while most of the boards were properly adjusted accordingly,
the Armada 370 DB board was left unchanged, and therefore, PCIe is
seen as not enabled on this board. This patch fixes that by moving the
PCIe controller node one level-up in armada-370-db.dts.

Signed-off-by: Thomas Petazzoni 
Fixes: 14fd8ed0a7fd19913 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes"
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: use the virtual CPU registers to access coherency registers

2013-12-12T06:37:53+00:00

commit b6dda00cddcc71d2030668bc0cc0fed758c411c2 upstream.

The Armada XP provides a mechanism called "virtual CPU registers" or
"per-CPU register banking", to access the per-CPU registers of the
current CPU, without having to worry about finding on which CPU we're
running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
current CPU registers are at 0x21000.

However, in the Device Tree node that provides the register addresses
for the coherency unit (which is responsible for ensuring coherency
between processors, and I/O coherency between processors and the
DMA-capable devices), a mistake was made: the CPU0-specific registers
were specified instead of the virtual CPU registers. This means that
the coherency barrier needed for I/O coherency was not behaving
properly when executed from a CPU different from CPU0. This patch
fixes that by using the virtual CPU registers.

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Thomas Petazzoni 
Fixes: e60304f8cb7bb5 "arm: mvebu: Add hardware I/O Coherency support"
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260

2013-12-12T06:37:52+00:00

commit 2163e61c92d9337e721a0d067d88ae62b52e0d3e upstream.

mv78260 flavour of Marvell Armada XP SoC has 3 PCIe units. The
two first units are both x4 and quad x1 capable. The third unit
is only x4 capable. This patch fixes mv78260 .dtsi to reflect
those capabilities.

Signed-off-by: Arnaud Ebalard 
Acked-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable

2013-12-12T06:37:52+00:00

commit 12b69a599745fc9e203f61fbb7160b2cc5f479dd upstream.

Various Marvell datasheets advertise second PCIe unit of mv78230
flavour of Armada XP as x4/quad x1 capable. This second unit is in
fact only x1 capable. This patch fixes current mv78230 .dtsi to
reflect that, i.e. makes 1.0 the second interface (instead of 2.0
at the moment). This was successfully tested on a mv78230-based
ReadyNAS 2120 platform with a x1 device (FL1009 XHCI controller)
connected to this second interface.

Signed-off-by: Arnaud Ebalard 
Acked-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: sama5d3: reduce TWI internal clock frequency

2013-12-12T06:37:52+00:00

commit 58e7b1d5826ac6a64b1101d8a70162bc084a7d1e upstream.

With some devices, transfer hangs during I2C frame transmission. This issue
disappears when reducing the internal frequency of the TWI IP. Even if it is
indicated that internal clock max frequency is 66MHz, it seems we have
oversampling on I2C signals making TWI believe that a transfer in progress
is done.

This fix has no impact on the I2C bus frequency.

Signed-off-by: Ludovic Desroches 
Acked-by: Wolfram Sang 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx

2013-12-12T06:37:52+00:00

commit 2ba2866f782f7f1c38abc3dd56d3295efd289264 upstream.

pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.

Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x

SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.

This fixes a regression where WLAN did not work after a warm reset
or after one up/down cycle that happened when we move omap4 to boot
using device tree only. For reference, the kernel bug is described at:

https://bugzilla.kernel.org/show_bug.cgi?id=63821

Signed-off-by: Balaji T K 
[tony@atomide.com: update comments to describe the regression]
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: multi_v7_defconfig: enable SDHCI_BCM_KONA and MMC_BLOCK_MINORS=16

2013-12-12T06:37:52+00:00

commit f39918eec72c841037f16475867dac1a2b0bfc01 upstream.

Enable MMC/SD on the Broadcom mobile platforms, and increase the block
minors from the default 8 to 16 (since the Broadcom board by default
has root on the 8th partition).

Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: footbridge: fix EBSA285 LEDs

2013-12-12T06:37:52+00:00

commit 67130c5464f50428aea0b4526a6729d61f9a1d53 upstream.

- The LEDs register is write-only: it can't be read-modify-written.
- The LEDs are write-1-for-off not 0.
- The check for the platform was inverted.

Fixes: cf6856d693dd ("ARM: mach-footbridge: retire custom LED code")
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman