linux-toradex.git/arch, branch v3.14.39

x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk

2015-04-19T08:11:07+00:00

commit 80313b3078fcd2ca51970880d90757f05879a193 upstream.

The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
both BIOS and UEFI mode while rebooting unless reboot=pci is
used. Add a quirk to reboot via the pci method.

The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.

Most of the time it already hangs during POST, but occasionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.

( Searching the web seems to suggest that other Bay Trail-D mainboards
  might be affected as well. )
--
Signed-off-by: Stefan Lippers-Hollmann 
Cc: Matt Fleming 
Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ARC: SA_SIGINFO ucontext regs off-by-one

2015-04-19T08:11:05+00:00

commit 6914e1e3f63caa829431160f0f7093292daef2d5 upstream.

The regfile provided to SA_SIGINFO signal handler as ucontext was off by
one due to pt_regs gutter cleanups in 2013.

Before handling signal, user pt_regs are copied onto user_regs_struct and copied
back later. Both structs are binary compatible. This was all fine until
commit 2fa919045b72 (ARC: pt_regs update #2) which removed the empty stack slot
at top of pt_regs (corresponding to first pad) and made the corresponding
fixup in struct user_regs_struct (the pad in there was moved out of
@scratch - not removed altogether as it is part of ptrace ABI)

 struct user_regs_struct {
+       long pad;
        struct {
-               long pad;
                long bta, lp_start, lp_end,....
        } scratch;
 ...
 }

This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
which is what this commit does.

This problem was hidden for 2 years, because both save/restore, despite
using wrong location, were using the same location. Only an interim
inspection (reproducer below) exposed the issue.

     void handle_segv(int signo, siginfo_t *info, void *context)
     {
 	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
               regs->scratch.r8, regs->scratch.r9);
     }

     int main()
     {
	struct sigaction sa;

	sa.sa_sigaction = handle_segv;
	sa.sa_flags = SA_SIGINFO;
	sigemptyset(&sa.sa_mask);
	sigaction(SIGSEGV, &sa, NULL);

	asm volatile(
	"mov	r7, 7	\n"
	"mov	r8, 8	\n"
	"mov	r9, 9	\n"
	"mov	r10, 10	\n"
	:::"r7","r8","r9","r10");

	*((unsigned int*)0x10) = 0;
     }

Fixes: 2fa919045b72ec892e "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

powerpc/mpc85xx: Add ranges to etsec2 nodes

2015-04-13T12:03:04+00:00

commit bb344ca5b90df62b1a3b7a35c6a9d00b306a170d upstream.

Commit 746c9e9f92dd "of/base: Fix PowerPC address parsing hack" limited
the applicability of the workaround whereby a missing ranges is treated
as an empty ranges.  This workaround was hiding a bug in the etsec2
device tree nodes, which have children with reg, but did not have
ranges.

Signed-off-by: Scott Wood 
Reported-by: Alexander Graf 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Little endian fixes for post mobility device tree update

2015-04-13T12:03:03+00:00

commit f6ff04149637723261aa4738958b0098b929ee9e upstream.

We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands is not endian safe as it relies
on parsing buffers returned by RTAS calls that thusly contains data in big
endian format.

This patch annotates variables and structure members with __be types as well
as performing necessary byte swaps to cpu endian for data that needs to be
parsed.

Signed-off-by: Tyrel Datwyler 
Cc: Nathan Fontenot 
Cc: Cyril Bur 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

arm64: Use the reserved TTBR0 if context switching to the init_mm

2015-04-13T12:03:03+00:00

commit e53f21bce4d35a93b23d8fa1a840860f6c74f59e upstream.

The idle_task_exit() function may call switch_mm() with next ==
&init_mm. On arm64, init_mm.pgd cannot be used for user mappings, so
this patch simply sets the reserved TTBR0.

Reported-by: Jon Medhurst (Tixy) 
Tested-by: Jon Medhurst (Tixy) 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

powerpc/book3s: Fix the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER

2015-04-13T12:03:03+00:00

commit 44d5f6f5901e996744858c175baee320ccf1eda3 upstream.

commit id 2ba9f0d has changed CONFIG_KVM_BOOK3S_64_HV to tristate to allow
HV/PR bits to be built as modules. But the MCE code still depends on
CONFIG_KVM_BOOK3S_64_HV which is wrong. When user selects
CONFIG_KVM_BOOK3S_64_HV=m to build HV/PR bits as a separate module the
relevant MCE code gets excluded.

This patch fixes the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER. This
makes sure that the relevant MCE code is included when HV/PR bits
are built as a separate modules.

Fixes: 2ba9f0d88750 ("kvm: powerpc: book3s: Support building HV and PR KVM as module")
Signed-off-by: Mahesh Salgaonkar 
Acked-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others

2015-03-26T14:06:59+00:00

commit d2192ea09858a8535b056fcede1a41d824e0b3d8 upstream.

Fixes: ee6c750761 (ARM: dts: dra7 clock data)

On DRA7x, For DPLL_IVA, the ref clock(CLKINP) is connected to sys_clk1 and
the bypass input(CLKINPULOW) is connected to iva_dpll_hs_clk_div clock.
But the bypass input is not directly routed to bypass clkout instead
both CLKINP and CLKINPULOW are connected to bypass clkout via a mux.

This mux is controlled by the bit - CM_CLKSEL_DPLL_IVA[23]:DPLL_BYP_CLKSEL
and it's POR value is zero which selects the CLKINP as bypass clkout.
which means iva_dpll_hs_clk_div is not the bypass clock for dpll_iva_ck

Fix this by adding another mux clock as parent in bypass mode.

This design is common to most of the PLLs and the rest have only one bypass
clock. Below is a list of the DPLLs that need this fix:

DPLL_IVA, DPLL_DDR,
DPLL_DSP, DPLL_EVE,
DPLL_GMAC, DPLL_PER,
DPLL_USB and DPLL_CORE

Signed-off-by: Ravikumar Kattekola 
Acked-by: Tero Kristo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: pm: fix at91rm9200 standby

2015-03-26T14:06:59+00:00

commit 84e871660bebfddb9a62ebd6f19d02536e782f0a upstream.

at91rm9200 standby and suspend to ram has been broken since
00482a4078f4. It is wrongly using AT91_BASE_SYS which is a physical address
and actually doesn't correspond to any register on at91rm9200.

Use the correct at91_ramc_base[0] instead.

Fixes: 00482a4078f4 (ARM: at91: implement the standby function for pm/cpuidle)

Signed-off-by: Alexandre Belloni 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

arm64: Honor __GFP_ZERO in dma allocations

2015-03-26T14:06:59+00:00

commit 7132813c384515c9dede1ae20e56f3895feb7f1e upstream.

Current implementation doesn't zero out the pages allocated.
Honor the __GFP_ZERO flag and zero out if set.

Cc:  # v3.14+
Acked-by: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Fix the build on GCC5

2015-03-26T14:06:58+00:00

commit e893286918d2cde3a94850d8f7101cd1039e0c62 upstream.

On gcc5 the kernel does not link:

  ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670.

Because prior GCC versions always emitted NOPs on ALIGN directives, but
gcc5 started omitting them.

.LSTARTFDEDLSI1 says:

        /* HACK: The dwarf2 unwind routines will subtract 1 from the
           return address to get an address in the middle of the
           presumed call instruction.  Since we didn't get here via
           a call, we need to include the nop before the real start
           to make up for it.  */
        .long .LSTART_sigreturn-1-.     /* PC-relative start address */

But commit 69d0627a7f6e ("x86 vDSO: reorder vdso32 code") from 2.6.25
replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before
__kernel_sigreturn.

Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses
vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN".

So fix this by adding to that point at least a single NOP and make the
function ALIGN possibly with more NOPs then.

Kudos for reporting and diagnosing should go to Richard.

Reported-by: Richard Biener 
Signed-off-by: Jiri Slaby 
Acked-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman