linux-toradex.git/arch, branch v4.0.5

ARC: unbork !LLSC build

2015-06-06T15:21:09+00:00

commit daaf40e53b5dbdf75255d58a45ce8ac65ca511a8 upstream.

Fixes: f7d11e93ee97a locking,arch,arc: Fold atomic_ops
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

MIPS: fix FP mode selection in lieu of .MIPS.abiflags data

2015-06-06T15:21:06+00:00

commit 620b155034570f577470cf5309f741bac6a6e32b upstream.

Commit 46490b572544 ("MIPS: kernel: elf: Improve the overall ABI and FPU
mode checks") reworked the ELF FP ABI mode selection logic, but when
CONFIG_MIPS_O32_FP64_SUPPORT is enabled it breaks the use of binaries
which have no PT_MIPS_ABIFLAGS program header & associated
.MIPS.abiflags section.

A default mode is selected based upon whether the ELF contains MIPS32 or
MIPS64 code, but that selection is made in arch_elf_pt_proc.
arch_elf_pt_proc only executes when a PT_MIPS_ABIFLAGS program header is
found. If one is not found then arch_elf_pt_proc is never called, and no
default overall_fp_mode value is selected. When arch_check_elf is
called, both abi0 & abi1 are MIPS_ABI_FP_UNKNOWN which leads to both
prog_req & interp_req being set to none_req. none_req matches none of
the conditions for mode selection at the end of arch_check_elf, so
overall_fp_mode is left untouched. Finally once mips_set_personality_fp
is called the BUG() in the default case is then hit & the kernel likely
panics.

Fix this by moving the selection of a default overall mode to the start
of arch_check_elf, which runs once per ELF executed regardless of
whether it has a PT_MIPS_ABIFLAGS program header.

Signed-off-by: Paul Burton 
Cc: Markos Chandras 
Cc: Matthew Fortune 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/9978/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures

2015-06-06T15:21:05+00:00

commit d045c77c1a69703143a36169c224429c48b9eecd upstream.

On architectures where the stack grows upwards (CONFIG_STACK_GROWSUP=y,
currently parisc and metag only) stack randomization sometimes leads to crashes
when the stack ulimit is set to lower values than STACK_RND_MASK (which is 8 MB
by default if not defined in arch-specific headers).

The problem is, that when the stack vm_area_struct is set up in fs/exec.c, the
additional space needed for the stack randomization (as defined by the value of
STACK_RND_MASK) was not taken into account yet and as such, when the stack
randomization code added a random offset to the stack start, the stack
effectively got smaller than what the user defined via rlimit_max(RLIMIT_STACK)
which then sometimes leads to out-of-stack situations and crashes.

This patch fixes it by adding the maximum possible amount of memory (based on
STACK_RND_MASK) which theoretically could be added by the stack randomization
code to the initial stack size. That way, the user-defined stack size is always
guaranteed to be at minimum what is defined via rlimit_max(RLIMIT_STACK).

This bug is currently not visible on the metag architecture, because on metag
STACK_RND_MASK is defined to 0 which effectively disables stack randomization.

The changes to fs/exec.c are inside an "#ifdef CONFIG_STACK_GROWSUP"
section, so it does not affect other platformws beside those where the
stack grows upwards (parisc and metag).

Signed-off-by: Helge Deller 
Cc: linux-parisc@vger.kernel.org
Cc: James Hogan 
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ARM: fix missing syscall trace exit

2015-06-06T15:21:05+00:00

commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: set display clock correctly for exynos4412-trats2

2015-06-06T15:21:05+00:00

commit 242ddf04297f2c4768bd8eb7593ab911910c5f76 upstream.

This patch sets display clock correctly. If Display clock isn't set
correctly then you would find below messages and Display controller
doesn't work correctly.

 exynos-drm: No connectors reported connected with modes
 [drm] Cannot find any crtc or sizes - going 1024x768

Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
Signed-off-by: Inki Dae 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: fix imx27 dtb build rule

2015-06-06T15:21:05+00:00

commit e46b5a6470a5e2c8e1096f8f60887ac19949055b upstream.

The i.MX27 dtb build should be controlled by CONFIG_SOC_IMX27 rather
than CONFIG_SOC_IMX31.

Signed-off-by: Shawn Guo 
Fixes: cb612390e546 ("ARM: dts: Only build dtb if associated Arch and/or SoC is enabled")
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx27: only map 4 Kbyte for fec registers

2015-06-06T15:21:05+00:00

commit a29ef819f3f34f89a1b9b6a939b4c1cdfe1e85ce upstream.

According to the imx27 documentation, fec has a 4 Kbyte
memory space map. Moreover, the actual 16 Kbyte mapping
overlaps the SCC (Security Controller) memory register
space. So, we reduce the memory register space to 4 Kbyte.

Signed-off-by: Philippe Reynes 
Acked-by: Uwe Kleine-König 
Fixes: 9f0749e3eb88 ("ARM i.MX27: Add devicetree support")
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: EXYNOS: Fix dereference of ERR_PTR returned by of_genpd_get_from_provider

2015-06-06T15:21:04+00:00

commit 0b7dc0ff95237a53287e52f1aab7408ebf1c4085 upstream.

ERR_PTR was dereferenced during sub domain parsing, if parent domain
could not be obtained (because of invalid phandle or deferred
registration of parent domain).

The Exynos power domain code checked whether
of_genpd_get_from_provider() returned NULL and in that case it skipped
that power domain node. However this function returns ERR_PTR or valid
pointer, not NULL.

Fixes: 0f7807518fe1 ("ARM: EXYNOS: add support for sub-power domains")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: 8356/1: mm: handle non-pmd-aligned end of RAM

2015-06-06T15:21:04+00:00

commit 965278dcb8ab0b1f666cc47937933c4be4aea48d upstream.

At boot time we round the memblock limit down to section size in an
attempt to ensure that we will have mapped this RAM with section
mappings prior to allocating from it. When mapping RAM we iterate over
PMD-sized chunks, creating these section mappings.

Section mappings are only created when the end of a chunk is aligned to
section size. Unfortunately, with classic page tables (where PMD_SIZE is
2 * SECTION_SIZE) this means that if a chunk is between 1M and 2M in
size the first 1M will not be mapped despite having been accounted for
in the memblock limit. This has been observed to result in page tables
being allocated from unmapped memory, causing boot-time hangs.

This patch modifies the memblock limit rounding to always round down to
PMD_SIZE instead of SECTION_SIZE. For classic MMU this means that we
will round the memblock limit down to a 2M boundary, matching the limits
on section mappings, and preventing allocations from unmapped memory.
For LPAE there should be no change as PMD_SIZE == SECTION_SIZE.

Signed-off-by: Mark Rutland 
Reported-by: Stefan Agner 
Tested-by: Stefan Agner 
Acked-by: Laura Abbott 
Tested-by: Hans de Goede 
Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

s390/mm: correct return value of pmd_pfn

2015-06-06T15:21:04+00:00

commit 7cded342c09f633666e71ee1ce048f218a9c5836 upstream.

Git commit 152125b7a882df36a55a8eadbea6d0edf1461ee7
"s390/mm: implement dirty bits for large segment table entries"
broke the pmd_pfn function, it changed the return value from
'unsigned long' to 'int'. This breaks all machine configurations
with memory above the 8TB line.

Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman