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

ARM: mxs: stub out mxs_pm_init for !CONFIG_PM

2013-10-05T14:13:12+00:00

commit 7a9caf59f60e55a8caf96f856713bd0ef0cc25a7 upstream.

When building a kernel without CONFIG_PM, we get a link
error from referencing mxs_pm_init in the machine
descriptor. This defines a macro to NULL for that case.

Signed-off-by: Arnd Bergmann 
Acked-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: 7837/3: fix Thumb-2 bug in AES assembler code

2013-10-05T14:13:10+00:00

commit 40190c85f427dcfdbab5dbef4ffd2510d649da1f upstream.

Patch 638591c enabled building the AES assembler code in Thumb2 mode.
However, this code used arithmetic involving PC rather than adr{l}
instructions to generate PC-relative references to the lookup tables,
and this needs to take into account the different PC offset when
running in Thumb mode.

Signed-off-by: Ard Biesheuvel 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

x86, efi: Don't map Boot Services on i386

2013-10-05T14:13:10+00:00

commit 700870119f49084da004ab588ea2b799689efaf7 upstream.

Add patch to fix 32bit EFI service mapping (rhbz 726701)

Multiple people are reporting hitting the following WARNING on i386,

  WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
  Modules linked in:
  Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
  Call Trace:
   [] warn_slowpath_common+0x5f/0x80
   [] ? __ioremap_caller+0x3d3/0x440
   [] ? __ioremap_caller+0x3d3/0x440
   [] warn_slowpath_null+0x1d/0x20
   [] __ioremap_caller+0x3d3/0x440
   [] ? get_usage_chars+0xfb/0x110
   [] ? vprintk_emit+0x147/0x480
   [] ? efi_enter_virtual_mode+0x1e4/0x3de
   [] ioremap_cache+0x1a/0x20
   [] ? efi_enter_virtual_mode+0x1e4/0x3de
   [] efi_enter_virtual_mode+0x1e4/0x3de
   [] start_kernel+0x286/0x2f4
   [] ? repair_env_string+0x51/0x51
   [] i386_start_kernel+0x12c/0x12f

Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
boot service code until after switching to virtual mode") EFI Boot
Service regions are mapped for a period during boot. Unfortunately, with
the limited size of the i386 direct kernel map it's possible that some
of the Boot Service regions will not be directly accessible, which
causes them to be ioremap()'d, triggering the above warning as the
regions are marked as E820_RAM in the e820 memmap.

There are currently only two situations where we need to map EFI Boot
Service regions,

  1. To workaround the firmware bug described in 916f676f8
  2. To access the ACPI BGRT image

but since we haven't seen an i386 implementation that requires either,
this simple fix should suffice for now.

[ Added to changelog - Matt ]

Reported-by: Bryan O'Donoghue 
Acked-by: Tom Zanussi 
Acked-by: Darren Hart 
Cc: Josh Triplett 
Cc: Matthew Garrett 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Signed-off-by: Josh Boyer 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically

2013-10-05T14:13:09+00:00

commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream.

Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.

Signed-off-by: Masoud Sharbiani 
Signed-off-by: Vinson Lee 
Cc: Robin Holt 
Cc: Russell King 
Cc: Guan Xuetao 
Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

um: Implement probe_kernel_read()

2013-09-27T00:18:29+00:00

commit f75b1b1bedfb498cc43a992ce4d7ed8df3b1e770 upstream.

UML needs it's own probe_kernel_read() to handle kernel
mode faults correctly.
The implementation uses mincore() on the host side to detect
whether a page is owned by the UML kernel process.

This fixes also a possible crash when sysrq-t is used.
Starting with 3.10 sysrq-t calls probe_kernel_read() to
read details from the kernel workers. As kernel worker are
completely async pointers may turn NULL while reading them.

Signed-off-by: Richard Weinberger 
Cc: 
Cc: 
Signed-off-by: Greg Kroah-Hartman

MIPS: ath79: Fix ar933x watchdog clock

2013-09-27T00:18:27+00:00

commit a1191927ace7e6f827132aa9e062779eb3f11fa5 upstream.

The watchdog device on the AR933x is connected to
the AHB clock, however the current code uses the
reference clock. Due to the wrong rate, the watchdog
driver can't calculate correct register values for
a given timeout value and the watchdog unexpectedly
restarts the system.

The code uses the wrong value since the initial
commit 04225e1d227c8e68d685936ecf42ac175fec0e54
(MIPS: ath79: add AR933X specific clock init)

The patch fixes the code to use the correct clock
rate to avoid the problem.

Signed-off-by: Felix Fietkau 
Signed-off-by: Gabor Juhos 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5777/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

sched/x86: Optimize switch_mm() for multi-threaded workloads

2013-09-27T00:18:14+00:00

commit 8f898fbbe5ee5e20a77c4074472a1fd088dc47d1 upstream.

Dick Fowles, Don Zickus and Joe Mario have been working on
improvements to perf, and noticed heavy cache line contention
on the mm_cpumask, running linpack on a 60 core / 120 thread
system.

The cause turned out to be unnecessary atomic accesses to the
mm_cpumask. When in lazy TLB mode, the CPU is only removed from
the mm_cpumask if there is a TLB flush event.

Most of the time, no such TLB flush happens, and the kernel
skips the TLB reload. It can also skip the atomic memory
set & test.

Here is a summary of Joe's test results:

 * The __schedule function dropped from 24% of all program cycles down
   to 5.5%.

 * The cacheline contention/hotness for accesses to that bitmask went
   from being the 1st/2nd hottest - down to the 84th hottest (0.3% of
   all shared misses which is now quite cold)

 * The average load latency for the bit-test-n-set instruction in
   __schedule dropped from 10k-15k cycles down to an average of 600 cycles.

 * The linpack program results improved from 133 GFlops to 144 GFlops.
   Peak GFlops rose from 133 to 153.

Reported-by: Don Zickus 
Reported-by: Joe Mario 
Tested-by: Joe Mario 
Signed-off-by: Rik van Riel 
Reviewed-by: Paul Turner 
Acked-by: Linus Torvalds 
Link: http://lkml.kernel.org/r/20130731221421.616d3d20@annuminas.surriel.com
[ Made the comments consistent around the modified code. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/mce: Pay no attention to 'F' bit in MCACOD when parsing 'UC' errors

2013-09-27T00:18:14+00:00

commit 0ca06c0857aee11911f91621db14498496f2c2cd upstream.

The 0x1000 bit of the MCACOD field of machine check MCi_STATUS
registers is only defined for corrected errors (where it means
that hardware may be filtering errors see SDM section 15.9.2.1).

For uncorrected errors it may, or may not be set - so we should mask
it out when checking for the architecturaly defined recoverable
error signatures (see SDM 15.9.3.1 and 15.9.3.2)

Acked-by: Naveen N. Rao 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

x86, amd_nb: Clarify F15h, model 30h GART and L3 support

2013-09-27T00:18:14+00:00

commit 7d64ac6422092adbbdaa279ab32f9d4c90a84558 upstream.

F15h, models 0x30 and later don't have a GART. Note that. Also check
CPUID leaf 0x80000006 for L3 prescence because there are models which
don't sport an L3 cache.

Signed-off-by: Aravind Gopalakrishnan 
[ Boris: rewrite commit message, cleanup comments. ]
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP

2013-09-27T00:18:13+00:00

commit bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5 upstream.

For performance reasons, when SMAP is in use, SMAP is left open for an
entire put_user_try { ... } put_user_catch(); block, however, calling
__put_user() in the middle of that block will close SMAP as the
STAC..CLAC constructs intentionally do not nest.

Furthermore, using __put_user() rather than put_user_ex() here is bad
for performance.

Thus, introduce new [compat_]save_altstack_ex() helpers that replace
__[compat_]save_altstack() for x86, being currently the only
architecture which supports put_user_try { ... } put_user_catch().

Reported-by: H. Peter Anvin 
Signed-off-by: Al Viro 
Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/n/tip-es5p6y64if71k8p5u08agv9n@git.kernel.org
Signed-off-by: Greg Kroah-Hartman