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

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

ARM: 7657/1: head: fix swapper and idmap population with LPAE and big-endian

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

commit d61947a164760ac520cb416768afdf38c33d60e7 upstream.

The LPAE page table format uses 64-bit descriptors, so we need to take
endianness into account when populating the swapper and idmap tables
during early initialisation.

This patch ensures that we store the two words making up each page table
entry in the correct order when running big-endian.

Acked-by: Catalin Marinas 
Tested-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7654/1: Preserve L_PTE_VALID in pte_modify()

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

commit 69dde4c52dbac2891b49ff9723d9c84efc5baf6f upstream.

Following commit 26ffd0d4 (ARM: mm: introduce present, faulting entries
for PAGE_NONE), if a page has been mapped as PROT_NONE, the L_PTE_VALID
bit is cleared by the set_pte_ext() code. With LPAE the software and
hardware pte share the same location and subsequent modifications of pte
range (change_protection()) will leave the L_PTE_VALID bit cleared.

This patch adds the L_PTE_VALID bit to the newprot mask in pte_modify().

Signed-off-by: Catalin Marinas 
Reported-by: Subash Patel 
Tested-by: Subash Patel 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock

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

commit 70264367a243a68b1d5636ffb570183449803cbe upstream.

When udelay() is implemented using an architected timer, it is wrong
to scale loops_per_jiffy when changing the CPU clock frequency since
the timer clock remains constant.

The lpj should probably become an implementation detail relevant to
the CPU loop based delay routine only and more confined to it. In the
mean time this is the minimal fix needed to have expected delays with
the timer based implementation when cpufreq is also in use.

Reported-by: Viresh Kumar 
Signed-off-by: Nicolas Pitre 
Tested-by: Viresh Kumar 
Acked-by: Liviu Dudau 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman