linux-stable.git/arch/arm, branch v3.17.2

ARM: dts: imx28-evk: Let i2c0 run at 100kHz

2014-10-30T16:43:13+00:00

commit d1e61eb443dc7512885dfe89ee2f2a1c29fcb1da upstream.

Commit 78b81f4666fb ("ARM: dts: imx28-evk: Run I2C0 at 400kHz") caused issues
when doing the following sequence in loop:

- Boot the kernel
- Perform audio playback
- Reboot the system via 'reboot' command

In many times the audio card cannot be probed, which causes playback to fail.

After restoring to the original i2c0 frequency of 100kHz there is no such
problem anymore.

This reverts commit 78b81f4666fbb22a20b1e63e5baf197ad2e90e88.

Signed-off-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: Netgear RN102: Use Hardware BCH ECC

2014-10-30T16:43:12+00:00

commit ace8578182dc347b043c0825b9873f62fdaa5b77 upstream.

The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC
(strength = 4), while the pxa3xx NAND driver by default uses
Hamming ECC (strength = 1).

This patch changes the ECC mode on these machines to match that
of the bootloader and of the stock firmware. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.

Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file")
Signed-off-by: Ben Peddell 
Acked-by: Ezequiel Garcia 
Tested-by: Arnaud Ebalard 
Link: https://lkml.kernel.org/r/1410339341-3372-1-git-send-email-klightspeed@killerwolves.net
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC

2014-10-30T16:43:12+00:00

commit 500abb6ccb9e3f8d638a7f422443a8549245ef90 upstream.

The bootloader on the Netgear ReadyNAS RN2120 uses Hardware BCH
ECC (strength = 4), while the pxa3xx NAND driver by default uses
Hamming ECC (strength = 1).

This patch changes the ECC mode on these machines to match that
of the bootloader and of the stock firmware. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.

The issue was initially reported and fixed by Ben Pedell for
RN102. The RN2120 shares the same Hynix H27U1G8F2BTR NAND
flash and setup. This patch is based on Ben's fix for RN102.

Fixes: ad51eddd95ad ("ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts file")
Signed-off-by: Arnaud Ebalard 
Link: https://lkml.kernel.org/r/61f6a1b7ad0adc57a0e201b9680bc2e5f214a317.1410035142.git.arno@natisbad.org
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: Netgear RN104: Use Hardware BCH ECC

2014-10-30T16:43:12+00:00

commit 225b94cdf719d0bc522a354bdafc18e5da5ff83b upstream.

The bootloader on the Netgear ReadyNAS RN104 uses Hardware BCH
ECC (strength = 4), while the pxa3xx NAND driver by default uses
Hamming ECC (strength = 1).

This patch changes the ECC mode on these machines to match that
of the bootloader and of the stock firmware. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.

The issue was initially reported and fixed by Ben Pedell for
RN102. The RN104 shares the same Hynix H27U1G8F2BTR NAND
flash and setup. This patch is based on Ben's fix for RN102.

Fixes: 0373a558bd79 ("ARM: mvebu: Enable NAND controller in ReadyNAS 104 .dts file")
Signed-off-by: Arnaud Ebalard 
Link: https://lkml.kernel.org/r/920c7e7169dc6aaaa3eb4bced2336d38e77b8864.1410035142.git.arno@natisbad.org
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: Kirkwood: Fix DT based DSA.

2014-10-30T16:43:12+00:00

commit 4f5e01e96d424b54f5f0e89ee1ba9ccca03a3941 upstream.

During the conversion of boards to use DT to instantiate Distributed
Switch Architecture, nobody volunteered to test. As to be expected,
the conversion was flawed. Testers and access to hardware has now
become available, and this patch hopefully fixes the problems.

dsa,mii-bus must be a phandle to the top level mdio node, not the port
specific subnode of the mdio device.

dsa,ethernet must be a phandle to the port subnode within the ethernet
DT node, not the ethernet node.

Don't pinctrl hog the card detect gpio for mvsdio.

Rename the .dts files to make it clearer which file is for the Z0
stepping and which for the A0 or later stepping.

Signed-off-by: Andrew Lunn 
Cc: seugene@marvell.com
Tested-by: Eugene Sanivsky 
Fixes: e2eaa339af44: ("ARM: Kirkwood: convert rd88f6281-setup.c to DT.")
Fixes: e7c8f3808be8: ("ARM: kirkwood: Convert mv88f6281gtw_ge switch setup to DT")
Link: https://lkml.kernel.org/r/1409592941-22244-1-git-send-email-andrew@lunn.ch
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: at91/PMC: don't forget to write PMC_PCDR register to disable clocks

2014-10-30T16:43:12+00:00

commit cfa1950e6c6b72251e80adc736af3c3d2907ab0e upstream.

When introducing support for sama5d3, the write to PMC_PCDR register has
been accidentally removed.

Reported-by: Nathalie Cyrille 
Signed-off-by: Ludovic Desroches 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: fix at91sam9263ek DT mmc pinmuxing settings

2014-10-30T16:43:12+00:00

commit b65e0fb3d046cc65d0a3c45d43de351fb363271b upstream.

As discovered on a custom board similar to at91sam9263ek and basing
its devicetree on that one apparently the pin muxing doesn't get
set up properly. This was discovered since the custom boards u-boot
does funky stuff with the pin muxing and leaved it set to SPI
which made the MMC driver not work under Linux.
The fix is simply to define the given configuration as the default.
This probably worked by pure luck before, but it's better to
make the muxing explicitly set.

Signed-off-by: Andreas Henriksson 
Acked-by: Boris Brezillon 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

ARM: at91/dt: Fix typo regarding can0_clk

2014-10-30T16:43:12+00:00

commit 0a51d644c20f5c88fd3a659119d1903f74927082 upstream.

Otherwise the clock for can0 will never get enabled.

Signed-off-by: David Dueck 
Signed-off-by: Anthony Harivel 
Acked-by: Boris Brezillon 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

arm: Tell irq work about self IPI support

2014-10-15T10:29:23+00:00

commit 09f6edd424218eb69078551b2ecfada1f2d098eb upstream.

ARM irq work IPI support depends on SMP support. That information is
partly known at early boottime. Lets implement
arch_irq_work_has_interrupt() accordingly.

Acked-by: Peter Zijlstra (Intel) 
Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman

irq_work: Introduce arch_irq_work_has_interrupt()

2014-10-15T10:29:23+00:00

commit c5c38ef3d70377dc504a6a3f611a3ec814bc757b upstream.

The nohz full code needs irq work to trigger its own interrupt so that
the subsystem can work even when the tick is stopped.

Lets introduce arch_irq_work_has_interrupt() that archs can override to
tell about their support for this ability.

Signed-off-by: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman