linux.git/arch/arm, branch v4.1.29

ARM: OMAP3: Add cpuidle parameters table for omap3430

2016-07-11T03:07:15+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-11T03:06:54+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-11T02:27:12+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-11T00:19:54+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-11T00:19:54+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-17T19:37:18+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-03T23:15:37+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-17T17:42:47+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

ARM: OMAP2+: hwmod: Fix updating of sysconfig register

2016-04-20T05:03:41+00:00

[ Upstream commit 3ca4a238106dedc285193ee47f494a6584b6fd2f ]

Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
when necessary") talks about verification of sysconfig cache value before
updating it, only during idle path. But the patch is adding the
verification in the enable path. So, adding the check in a proper place
as per the commit description.

Not keeping this check during enable path as there is a chance of losing
context and it is safe to do on idle as the context of the register will
never be lost while the device is active.

Signed-off-by: Lokesh Vutla 
Acked-by: Tero Kristo 
Cc: Jon Hunter 
Cc:  # 3.12+
Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
[paul@pwsan.com: appears to have been caused by my own mismerge of the
 originally posted patch]
Signed-off-by: Paul Walmsley 

Signed-off-by: Sasha Levin

ARM: dts: armada-375: use armada-370-sata for SATA

2016-04-18T12:50:36+00:00

[ Upstream commit b3a7f31eb7375633cd6a742f19488fc5a4208b36 ]

The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
requires the PHY speed to be set in the LP_PHY_CTL register for SATA
hotplug to work.

Therefore, this commit updates the compatible string used to describe
the SATA IP in Armada 375 from marvell,orion-sata to
marvell,armada-370-sata.

Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
Cc: 
Signed-off-by: Lior Amsalem 
Signed-off-by: Thomas Petazzoni 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin