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

ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830

2013-03-20T20:10:55+00:00

commit 069552777a121eb39da29de4bc0383483dbe1f7e upstream.

This adds additional error checking to the private edma api implementation
to catch the case where the edma_alloc_slot() has an invalid controller
parameter. The edma dmaengine wrapper driver relies on this condition
being handled in order to avoid setting up a second edma dmaengine
instance on DA830.

Verfied using a DA850 with the second EDMA controller platform instance
removed to simulate a DA830 which only has a single EDMA controller.

Reported-by: Tomas Novotny 
Signed-off-by: Matt Porter 
Tested-by: Tomas Novotny 
Signed-off-by: Sekhar Nori 
Signed-off-by: Greg Kroah-Hartman

ARM: w1-gpio: fix erroneous gpio requests

2013-03-20T20:10:54+00:00

commit 2d798a3f20ae992b0b69a2b68c04ada397c32ed4 upstream.

Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add
ext_pullup_enable pin in platform data") which added a gpio entry to the
platform data, but did not add the required initialisers to the board
files using it. Consequently, the driver would request gpio 0 at probe,
which could break other uses of the corresponding pin.

On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for
instance, breaks SPI0 on at91sam9g20.

Signed-off-by: Johan Hovold 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Greg Kroah-Hartman

ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels

2013-03-20T20:10:54+00:00

commit 7bf5b408b419fc849578e6e9fbd221bf43638eb6 upstream.

The ethernet controller used on kirkwood looses its MAC address
register contents when the corresponding clock is gated. As soon as
mv643xx_eth is built as module, the clock gets gated and when loading
the module, the MAC address is gone.

Proper DT support for the mv643xx_eth driver is expected soon, so we add
a workaround to always enable ge0/ge1 clocks on kirkwood. This workaround
is also already used on non-DT kirkwood kernels.

Reported-by: Simon Baatz 
Signed-off-by: Sebastian Hesselbarth 
Tested-by: Simon Baatz 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency

2013-03-14T18:26:36+00:00

commit 93fff4ce19f9978cc1c59db42760717477939249 upstream.

When DT support for kirkwood was first introduced, there was no clock
infrastructure.  As a result, we had to manually pass the
clock-frequency to the driver from the device node.

Unfortunately, on kirkwood, with minimal config or all module configs,
clock-frequency breaks booting because of_serial doesn't consume the
gate_clk when clock-frequency is defined.

The end result on kirkwood is that runit gets gated, and then the boot
fails when the kernel tries to write to the serial port.

Fix the issue by removing the clock-frequency parameter from all
kirkwood dts files.

Booted on dreamplug without earlyprintk and successfully logged in via
ttyS0.

Reported-by: Simon Baatz 
Tested-by: Simon Baatz 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mxs_defconfig: Make USB host functional again

2013-03-14T18:26:36+00:00

commit f6c49da98dd6eacb85034d21d16e1428e03e190f upstream.

commit 09f6ffde2e (USB: EHCI: fix build error by making ChipIdea host a normal
EHCI driver) introduced CONFIG_USB_EHCI_HCD as a dependency for USB_CHIPIDEA_HOST.

Select CONFIG_USB_EHCI_HCD, so that USB host can be functional again.

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

gpio: mvebu: Add clk support to prevent lockup

2013-03-14T18:26:36+00:00

commit de88747f514a4e0cca416a8871de2302f4f77790 upstream.

The kirkwood SoC GPIO cores use the runit clock. Add code to
clk_prepare_enable() runit, otherwise there is a danger of locking up
the SoC by accessing the GPIO registers when runit clock is not
ticking.

Reported-by: Simon Baatz 
Signed-off-by: Andrew Lunn 
Tested-by: Simon Baatz 
Acked-by: Linus Walleij 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

rtc: rtc-mv: Add support for clk to avoid lockups

2013-03-14T18:26:36+00:00

commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream.

The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
driver clk_prepare_enable() this clock, otherwise there is a danger
the SoC will lockup when accessing RTC registers with the clock
disabled.

Reported-by: Simon Baatz 
Signed-off-by: Andrew Lunn 
Tested-by: Simon Baatz 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit

2013-03-14T18:26:23+00:00

commit f2fe09b055e2549de41fb107b34c60bac4a1b0cf upstream.

Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2,
regardless of the settings in the HDCR.

This patch fixes the broken mask.

Reported-by: Christoffer Dall 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7659/1: mm: make mm->context.id an atomic64_t variable

2013-03-14T18:26:23+00:00

commit 8a4e3a9ead7e37ce1505602b564c15da09ac039f upstream.

mm->context.id is updated under asid_lock when a new ASID is allocated
to an mm_struct. However, it is also read without the lock when a task
is being scheduled and checking whether or not the current ASID
generation is up-to-date.

If two threads of the same process are being scheduled in parallel and
the bottom bits of the generation in their mm->context.id match the
current generation (that is, the mm_struct has not been used for ~2^24
rollovers) then the non-atomic, lockless access to mm->context.id may
yield the incorrect ASID.

This patch fixes this issue by making mm->context.id and atomic64_t,
ensuring that the generation is always read consistently. For code that
only requires access to the ASID bits (e.g. TLB flushing by mm), then
the value is accessed directly, which GCC converts to an ldrb.

Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7658/1: mm: fix race updating mm->context.id on ASID rollover

2013-03-14T18:26:23+00:00

commit 37f47e3d62533c931b04cb409f2eb299e6342331 upstream.

If a thread triggers an ASID rollover, other threads of the same process
must be made to wait until the mm->context.id for the shared mm_struct
has been updated to new generation and associated book-keeping (e.g.
TLB invalidation) has ben performed.

However, there is a *tiny* window where both mm->context.id and the
relevant active_asids entry are updated to the new generation, but the
TLB flush has not been performed, which could allow another thread to
return to userspace with a dirty TLB, potentially leading to data
corruption. In reality this will never occur because one CPU would need
to perform a context-switch in the time it takes another to do a couple
of atomic test/set operations but we should plug the race anyway.

This patch moves the active_asids update until after the potential TLB
flush on context-switch.

Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman