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

x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'

2012-08-04T15:31:12+00:00

commit 141168c36cdee3ff23d9c7700b0edc47cb65479f and
commit 3f806e50981825fa56a7f1938f24c0680816be45 upstream.

Several fields in struct cpuinfo_x86 were not defined for the
!SMP case, likely to save space.  However, those fields still
have some meaning for UP, and keeping them allows some #ifdef
removal from other files.  The additional size of the UP kernel
from this change is not significant enough to worry about
keeping up the distinction:

	   text    data     bss     dec     hex filename
	4737168	 506459	 972040	6215667	 5ed7f3	vmlinux.o.before
	4737444	 506459	 972040	6215943	 5ed907	vmlinux.o.after

for a difference of 276 bytes for an example UP config.

If someone wants those 276 bytes back badly then it should
be implemented in a cleaner way.

Signed-off-by: Kevin Winchester 
Cc: Steffen Persvold 
Link: http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinchester@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Borislav Petkov 
Signed-off-by: Ben Hutchings

s390/idle: fix sequence handling vs cpu hotplug

2012-08-02T13:37:50+00:00

commit 0008204ffe85d23382d6fd0f971f3f0fbe70bae2 upstream.

The s390 idle accounting code uses a sequence counter which gets used
when the per cpu idle statistics get updated and read.

One assumption on read access is that only when the sequence counter is
even and did not change while reading all values the result is valid.
On cpu hotplug however the per cpu data structure gets initialized via
a cpu hotplug notifier on CPU_ONLINE.
CPU_ONLINE however is too late, since the onlined cpu is already running
and might access the per cpu data. Worst case is that the data structure
gets initialized while an idle thread is updating its idle statistics.
This will result in an uneven sequence counter after an update.

As a result user space tools like top, which access /proc/stat in order
to get idle stats, will busy loop waiting for the sequence counter to
become even again, which will never happen until the queried cpu will
update its idle statistics again. And even then the sequence counter
will only have an even value for a couple of cpu cycles.

Fix this by moving the initialization of the per cpu idle statistics
to cpu_init(). I prefer that solution in favor of changing the
notifier to CPU_UP_PREPARE, which would be a different solution to
the problem.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

powerpc: Add "memory" attribute for mfmsr()

2012-08-02T13:37:46+00:00

commit b416c9a10baae6a177b4f9ee858b8d309542fbef upstream.

Add "memory" attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().

Signed-off-by: Tiejun Chen 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings

x86, microcode: Sanitize per-cpu microcode reloading interface

2012-08-02T13:37:44+00:00

commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.

Microcode reloading in a per-core manner is a very bad idea for both
major x86 vendors. And the thing is, we have such interface with which
we can end up with different microcode versions applied on different
cores of an otherwise homogeneous wrt (family,model,stepping) system.

So turn off the possibility of doing that per core and allow it only
system-wide.

This is a minimal fix which we'd like to see in stable too thus the
more-or-less arbitrary decision to allow system-wide reloading only on
the BSP:

$ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
...

and disable the interface on the other cores:

$ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
-bash: echo: write error: Invalid argument

Also, allowing the reload only from one CPU (the BSP in
that case) doesn't allow the reload procedure to degenerate
into an O(n^2) deal when triggering reloads from all
/sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
simultaneously.

A more generic fix will follow.

Cc: Henrique de Moraes Holschuh 
Cc: Peter Zijlstra 
Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email-bp@amd64.org
Signed-off-by: H. Peter Anvin 
Signed-off-by: Ben Hutchings

x86, microcode: microcode_core.c simple_strtoul cleanup

2012-08-02T13:37:44+00:00

commit e826abd523913f63eb03b59746ffb16153c53dc4 upstream.

Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
instead of calling obsoleted simple_strtoul().

Signed-off-by: Shuah Khan 
Reviewed-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1336324264.2897.9.camel@lorien2
Signed-off-by: H. Peter Anvin 
Signed-off-by: Ben Hutchings

x86: Fix boot on Twinhead H12Y

2012-08-02T13:37:40+00:00

commit 80b3e557371205566a71e569fbfcce5b11f92dbe upstream.

Despite lots of investigation into why this is needed we don't
know or have an elegant cure. The only answer found on this
laptop is to mark a problem region as used so that Linux doesn't
put anything there.

Currently all the users add reserve= command lines and anyone
not knowing this needs to find the magic page that documents it.
Automate it instead.

Signed-off-by: Alan Cox 
Tested-and-bugfixed-by: Arne Fitzenreiter 
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231
Link: http://lkml.kernel.org/r/20120515174347.5109.94551.stgit@bluebook
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

powerpc/ftrace: Fix assembly trampoline register usage

2012-08-02T13:37:39+00:00

commit fd5a42980e1cf327b7240adf5e7b51ea41c23437 upstream.

Just like the module loader, ftrace needs to be updated to use r12
instead of r11 with newer gcc's.

Signed-off-by: Roger Blofeld 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings

ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI

2012-07-25T03:11:42+00:00

commit 76eb9a30db4bc8fd172f9155247264b5f2686d7b upstream.

Dell Precision M6600 is known to require PCI reboot, so add it to
the reboot blacklist in pci_reboot_dmi_table[].

https://bugzilla.kernel.org/show_bug.cgi?id=42749

cc: x86@kernel.org
Signed-off-by: Zhang Rui 
Signed-off-by: Len Brown 
Signed-off-by: Ben Hutchings

ACPI: Add a quirk for "AMILO PRO V2030" to ignore the timer overriding

2012-07-25T03:11:42+00:00

commit b939c2acf1dc42b08407ef5174f2e8d6f43dd5ea upstream.

commit f6b54f083cc66cf9b11d2120d8df3c2ad4e0836d upstream.

This is the 2nd part of fix for kernel bugzilla 40002:
    "IRQ 0 assigned to VGA"
https://bugzilla.kernel.org/show_bug.cgi?id=40002

The root cause is the buggy FW, whose ACPI tables assign the GSI 16
to 2 irqs 0 and 16(VGA), and the VGA is the right owner of GSI 16.
So add a quirk to ignore the irq0 overriding GSI 16 for the
FUJITSU SIEMENS AMILO PRO V2030 platform will solve this issue.

Reported-and-tested-by: Szymon Kowalczyk 
Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

ACPI: Remove one board specific WARN when ignoring timer overriding

2012-07-25T03:11:41+00:00

commit 5752cdb805ff89942d99d12118e2844e7db34df8 upstream.

commit 7f68b4c2e158019c2ec494b5cfbd9c83b4e5b253 upstream.

Current WARN msg is only for the ati_ixp4x0 board, while this function
is used by mulitple platforms. So this one board specific warning
is not appropriate any more.

Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings