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

ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys

2016-08-22T16:23:04+00:00

[ Upstream commit fc51b632c7b047c25807023b76f3877aed19c770 ]

It seems that recent kernels have a shorter timeout when scanning for
ethernet phys causing us to hit a timeout on boards where the phy's
regulator gets enabled just before scanning, which leads to non working
ethernet.

A 10ms startup delay seems to be enough to fix it, this commit adds a
20ms startup delay just to be safe.

This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board,
both of which have non-working ethernet on recent kernels without this
fix.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
Signed-off-by: Sasha Levin

ARM: mvebu: fix HW I/O coherency related deadlocks

2016-08-08T01:44:33+00:00

[ Upstream commit c5379ba8fccd99d5f99632c789f0393d84a57805 ]

Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.

This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).

Tested-by: Terry Stockert 
Tested-by: Romain Perier 
Cc: Terry Stockert 
Cc: Romain Perier 
Cc: 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin

ARM: OMAP3: Add cpuidle parameters table for omap3430

2016-07-12T12:47:57+00:00

[ Upstream commit 98f42221501353067251fbf11e732707dbb68ce3 ]

Based on CPU type choose generic omap3 or omap3430 specific cpuidle
parameters. Parameters for omap3430 were measured on Nokia N900 device and
added by commit 5a1b1d3a9efa ("OMAP3: RX-51: Pass cpu idle parameters")
which were later removed by commit 231900afba52 ("ARM: OMAP3: cpuidle -
remove rx51 cpuidle parameters table") due to huge code complexity.

This patch brings cpuidle parameters for omap3430 devices again, but uses
simple condition based on CPU type.

Fixes: 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle
parameters table")
Signed-off-by: Pali Rohár 
Acked-by: Daniel Lezcano 
Signed-off-by: Tony Lindgren 

Signed-off-by: Sasha Levin

ASoC: samsung: pass DMA channels as pointers

2016-07-12T12:47:20+00:00

[ Upstream commit b9a1a743818ea3265abf98f9431623afa8c50c86 ]

ARM64 allmodconfig produces a bunch of warnings when building the
samsung ASoC code:

sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data':
sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   playback_data->filter_data = (void *)playback->channel;
sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   capture_data->filter_data = (void *)capture->channel;

We could easily shut up the warning by adding an intermediate cast,
but there is a bigger underlying problem: The use of IORESOURCE_DMA
to pass data from platform code to device drivers is dubious to start
with, as what we really want is a pointer that can be passed into
a filter function.

Note that on s3c64xx, the pl08x DMA data is already a pointer, but
gets cast to resource_size_t so we can pass it as a resource, and it
then gets converted back to a pointer. In contrast, the data we pass
for s3c24xx is an index into a device specific table, and we artificially
convert that into a pointer for the filter function.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

KVM: arm/arm64: Stop leaking vcpu pid references

2016-07-12T12:47:14+00:00

[ Upstream commit 591d215afcc2f94e8e2c69a63c924c044677eb31 ]

kvm provides kvm_vcpu_uninit(), which amongst other things, releases the
last reference to the struct pid of the task that was last running the vcpu.

On arm64 built with CONFIG_DEBUG_KMEMLEAK, starting a guest with kvmtool,
then killing it with SIGKILL results (after some considerable time) in:
> cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff80007d5ea080 (size 128):
>  comm "lkvm", pid 2025, jiffies 4294942645 (age 1107.776s)
>  hex dump (first 32 bytes):
>    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>  backtrace:
>    [] create_object+0xfc/0x278
>    [] kmemleak_alloc+0x34/0x70
>    [] kmem_cache_alloc+0x16c/0x1d8
>    [] alloc_pid+0x34/0x4d0
>    [] copy_process.isra.6+0x79c/0x1338
>    [] _do_fork+0x74/0x320
>    [] SyS_clone+0x18/0x20
>    [] el0_svc_naked+0x24/0x28
>    [] 0xffffffffffffffff

On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(),
on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free().

Signed-off-by: James Morse 
Fixes: 749cf76c5a36 ("KVM: ARM: Initial skeleton to compile KVM support")
Cc:  # 3.10+
Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Sasha Levin

ARM: 8579/1: mm: Fix definition of pmd_mknotpresent

2016-07-11T15:15:55+00:00

[ Upstream commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 ]

Currently pmd_mknotpresent will use a zero entry to respresent an
invalidated pmd.

Unfortunately this definition clashes with pmd_none, thus it is
possible for a race condition to occur if zap_pmd_range sees pmd_none
whilst __split_huge_pmd_locked is running too with pmdp_invalidate
just called.

This patch fixes the race condition by modifying pmd_mknotpresent to
create non-zero faulting entries (as is done in other architectures),
removing the ambiguity with pmd_none.

[catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc:  # 3.11+
Reported-by: Kirill A. Shutemov 
Acked-by: Will Deacon 
Cc: Russell King 
Signed-off-by: Steve Capper 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8578/1: mm: ensure pmd_present only checks the valid bit

2016-07-11T15:11:03+00:00

[ Upstream commit 624531886987f0f1b5d01fb598034d039198e090 ]

In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
pmd entry, resulting in a not-present entry from the hardware's
perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
value and will therefore continue to return true even after a
pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
managing huge entries, this is only an issue for the 3-level case.

This patch fixes the 3-level pmd_present implementation to take into
account the valid bit. For bisectability, the change is made before the
fix to pmd_mknotpresent.

[catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc:  # 3.11+
Cc: Russell King 
Cc: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: fix PTRACE_SETVFPREGS on SMP systems

2016-06-20T03:47:42+00:00

[ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ]

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Cc: 
Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon 
Tested-by: Simon Marchi 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables

2016-06-03T15:30:30+00:00

[ Upstream commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f ]

The ARM architecture mandates that when changing a page table entry
from a valid entry to another valid entry, an invalid entry is first
written, TLB invalidated, and only then the new entry being written.

The current code doesn't respect this, directly writing the new
entry and only then invalidating TLBs. Let's fix it up.

Cc: 
Reported-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Sasha Levin

ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel

2016-05-17T18:51:37+00:00

[ Upstream commit 5616f36713ea77f57ae908bf2fef641364403c9f ]

The secondary CPU starts up in ARM mode. When the kernel is compiled in
thumb2 mode we have to explicitly compile the secondary startup
trampoline in ARM mode, otherwise the CPU will go to Nirvana.

Signed-off-by: Sascha Hauer 
Reported-by: Steffen Trumtrar 
Suggested-by: Ard Biesheuvel 
Cc: stable@vger.kernel.org
Signed-off-by: Dinh Nguyen 
Signed-off-by: Kevin Hilman 
Signed-off-by: Sasha Levin