Provide systems that do not support x2apic cluster mode
a mechanism to select x2apic physical mode using the
FADT FORCE_APIC_PHYSICAL_DESTINATION_MODE bit.

Changes from v1: (based on Suresh's comments)
 - removed #ifdef CONFIG_ACPI
 - removed #include <linux/acpi.h>
Signed-off-by: NGreg Pearson <greg.pearson@hp.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1335313436-32020-1-git-send-email-greg.pearson@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The second parameter to intel_scu_notifier_post is a void *, not
an integer.

This quiets the sparse noise:

 arch/x86/platform/mrst/mrst.c:808:48: warning: Using plain integer as NULL pointer
 arch/x86/platform/mrst/mrst.c:817:43: warning: Using plain integer as NULL pointer
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Link: http://lkml.kernel.org/r/201204241500.53685.hartleys@visionengravers.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Provide the proper override macros for x32 siginfo_t.  The combination
of a special type here and an overall alignment constraint actually
ends up with all the types being properly aligned, but the hack is
needed to keep the substructures inside siginfo_t from adding padding.

Note: use __attribute__((aligned())) since __aligned() is not exported
to user space.

[ v2: fix stray semicolon ]
Reported-by: NH.J. Lu <hjl.rools@gmail.com>
Cc: Bruce J. Beare <bruce.j.beare@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Link: http://lkml.kernel.org/r/CAMe9rOqF6Kh6-NK7oP0Fpzkd4SBAWU%2BG53hwBbSD4iA2UzyxuA@mail.gmail.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Check __LP64__ isn't a reliable way to tell if we are compiling for x32
since __LP64__ isnn't specified by x86-64 psABI.  Not all x86-64
compilers define __LP64__, which was added to GCC 3.3. The updated x32
psABI:

https://sites.google.com/site/x32abi/documents

definse _ILP32 and __ILP32__ for x32.  GCC trunk and 4.7 branch have
been updated to define _ILP32 and __ILP32__ for x32.  This patch
replaces __LP64__ check with __ILP32__.
Signed-off-by: NH.J. Lu <hjl.tools@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

With commit a2ef5c4f
"ACPI: Move module parameter gts and bfs to sleep.c" the
wake_sleep_flags is required when calling acpi_enter_sleep_state.

The assembler code in wakeup_*.S did not do that. One solution
is to call it from assembler and stick the wake_sleep_flags on
the stack (for 32-bit) or in %esi (for 64-bit). hpa and rafael
both suggested however to create a wrapper function to call
acpi_enter_sleep_state and call said wrapper function
("acpi_enter_s3") from assembler.

For 32-bit, the acpi_enter_s3 ends up looking as so:

  push   %ebp
  mov    %esp,%ebp
  sub    $0x8,%esp
  movzbl 0xc1809314,%eax [wake_sleep_flags]
  movl   $0x3,(%esp)
  mov    %eax,0x4(%esp)
  call   0xc12d1fa0 <acpi_enter_sleep_state>
  leave
  ret

And 64-bit:

  movzbl 0x9afde1(%rip),%esi        [wake_sleep_flags]
  push   %rbp
  mov    $0x3,%edi
  mov    %rsp,%rbp
  callq  0xffffffff812e9800 <acpi_enter_sleep_state>
  leaveq
  retq
Reviewed-by: NH. Peter Anvin <hpa@zytor.com>
Suggested-by: NH. Peter Anvin <hpa@zytor.com>
[v2: Remove extra assembler operations, per hpa review]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1335150198-21899-3-git-send-email-konrad.wilk@oracle.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

With commit a2ef5c4f
"ACPI: Move module parameter gts and bfs to sleep.c" the wake_sleep_flags
is required when calling acpi_enter_sleep_state, which means
that if there are functions outside the sleep.c code they
can't get the wake_sleep_flags values.

This converts the function in to a exported value and converts
the module config operands to a function.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NLin Ming <ming.m.lin@intel.com>
[v2: Parameters can be turned on/off dynamically]
[v3: unsigned char -> u8]
[v4: val -> kp->arg]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1335150198-21899-2-git-send-email-konrad.wilk@oracle.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

If the L3 disable slot is already in use, return -EEXIST instead of
-EINVAL. The caller, store_cache_disable(), checks this return value to
print an appropriate warning.

Also, we want to signal with -EEXIST that the current index we're
disabling has actually been already disabled on the node:

$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_0
$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_0
-bash: echo: write error: File exists
$ echo 12 > /sys/devices/system/cpu/cpu3/cache/index3/cache_disable_1
-bash: echo: write error: File exists
$ echo 12 > /sys/devices/system/cpu/cpu5/cache/index3/cache_disable_1
-bash: echo: write error: File exists

The old code would say

-bash: echo: write error: Invalid argument

for disable slot 1 when playing the example above with no output in
dmesg, which is clearly misleading.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20120419070053.GB16645@elgon.mountain
[Boris: add testing for the other index too]
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Current APIC code assumes MSR_IA32_APICBASE is present for all systems.
Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE
was introduced as an architectural MSR by Intel @ P6.

Code paths that can touch this MSR invalidly are when vendor == Intel &&
cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass
lapic on the kernel command line, on a P5.

The below patch stops Linux incorrectly interfering with the
MSR_IA32_APICBASE for P5 class machines. Other code paths exist that
touch the MSR - however those paths are not currently reachable for a
conformant P5.
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linux.intel.com>
Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>

Starting from 7e16838d "i387: support lazy restore of FPU state"
we assume that fpu_owner_task doesn't need restore_fpu_checking()
on the context switch, its FPU state should match what we already
have in the FPU on this CPU.

However, debugger can change the tracee's FPU state, in this case
we should reset fpu.last_cpu to ensure fpu_lazy_restore() can't
return true.

Change init_fpu() to do this, it is called by user_regset->set()
methods.
Reported-by: NJan Kratochvil <jan.kratochvil@redhat.com>
Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20120416204815.GB24884@redhat.com
Cc: <stable@vger.kernel.org> v3.3
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD
multi-node processors, e.g. Magny-Cours and Interlagos. There we
have 2 NUMA nodes on one socket. Thus there are cores having
different numa-node-id but with equal phys_proc_id.

There is no point to print error messages in such a situation.

The confusing/misleading error message was introduced with
commit 64be4c1c ("x86: Add
x86_init platform override to fix up NUMA core numbering").

Remove the default fixup function (especially the error message)
and replace it by a NULL pointer check, move the
Numascale-specific condition for calling the fixup into the
fixup-function itself and slightly adapt the comment.
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
Cc: <stable@kernel.org>
Cc: <sp@numascale.com>
Cc: <bp@amd64.org>
Cc: <daniel@numascale-asia.com>
Link: http://lkml.kernel.org/r/20120402160648.GR27684@alberich.amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The method used to work out whether we were booted by EFI firmware or
via a boot loader is broken. Because efi_main() is always executed
when booting from a boot loader we will dereference invalid pointers
either on the stack (CONFIG_X86_32) or contained in %rdx
(CONFIG_X86_64) when searching for an EFI System Table signature.

Instead of dereferencing these invalid system table pointers, add a
new entry point that is only used when booting from EFI firmware, when
we know the pointer arguments will be valid. With this change legacy
boot loaders will no longer execute efi_main(), but will instead skip
EFI stub initialisation completely.

[ hpa: Marking this for urgent/stable since it is a regression when
  the option is enabled; without the option the patch has no effect ]
Signed-off-by: NMatt Fleming <matt.hfleming@intel.com>
Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.comReported-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> v3.3

Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/20120411151238.GA4794@alberich.amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

The 'max' range needs to be unsigned, since the size of the user address
space is bigger than 2GB.

We know that 'count' is positive in 'long' (that is checked in the
caller), so we will truncate 'max' down to something that fits in a
signed long, but before we actually do that, that comparison needs to be
done in unsigned.

Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of
'strncpy_from_user()' and speed it up").  On x86-64 you can't trigger
this, since the user address space is much smaller than 63 bits, and on
x86-32 it works in practice, since you would seldom hit the strncpy
limits anyway.

I had actually tested the corner-cases, I had only tested them on
x86-64.  Besides, I had only worried about the case of a pointer *close*
to the end of the address space, rather than really far away from it ;)

This also changes the "we hit the user-specified maximum" to return
'res', for the trivial reason that gcc seems to generate better code
that way.  'res' and 'count' are the same in that case, so it really
doesn't matter which one we return.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

c5905afb ("static keys: Introduce 'struct static_key'...") renamed
struct jump_label_key to struct static_key.  Fixup ARM for this to
eliminate these build warnings:

  include/linux/jump_label.h:113:2:
  warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type
  include/asm/jump_label.h:17:82:
  note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *'
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.

This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.

Cc: stable@vger.kernel.org
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJonathan Austin <jonathan.austin@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
kernel then we will hang early during boot since the memory bank will
have wrapped around to zero.

This patch truncates memory banks for !LPAE configurations when the end
address is not representable in 32 bits.
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

During booting of cpu1, there is a short window where cpu1
is online, but not active where cpu1 is occupied by waiting
to become active. If cpu0 then decides to schedule something
on cpu1 and wait for it to complete, before cpu0 has set
cpu1 active, we have a deadlock.

Typically it's this CPU frequency transition that happens at
this time, so let's just not wait for it to happen, it will
happen whenever the CPU eventually comes online instead.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@kernel.org
Signed-off-by: NJonas Aaberg <jonas.aberg@stericsson.com>
Reviewed-by: NRickard Andersson <rickard.andersson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables.  Remove it.

Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.

Thanks to Russell King for pointing out the parts I missed under
plat-omap in the original version and also pointing out the build
errors when CPUFREQ_TABLE support was not enabled.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

These were incorrectly introduced and can cause problems for of_irq_init.

The correct way to define a root controller is no interrupt-parent set at
all or the interrupt-parent is set to the root controller itself when
inherited from a parent node.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Tested-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add config dependency for Exynos4 and Exynos5 device tree enabled machine
files on config options ARCH_EXYNOS4 and ARCH_EXYNOS5 respectively.
Enabling machine support without proper ARCH support enabled is incorrect.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The atmel_mxt_ts driver has been extended to support more 'configuration
objects' in commit 81c88a71 ("Input: atmel_mxt_ts - update object list"),
what broke the configuration values for NURI board. These values are
optional anyway, so remove them to get the driver working correctly.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

On some versions of NURI and UniversalC210 boards, camera clocks are
routed directly to xusbxti clock source. This patch sets the correct
value for this clock to let usb and camera sensors to work correctly and
avoid division by zero on driver's probe.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Regulator names should not contain slash to avoid issues with debugfs.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

When selecting SAMSUNG_PM_DEBUG, it complains about a missing printascii()
function if you do not select DEBUG_LL, so make the former select the latter.
Signed-off-by: NMaurus Cuelenaere <mcuelenaere@gmail.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path.  In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures.  The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing.  This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.

The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.

The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.
Reported-by: NMeelis Roos <mroos@linux.ee>
Suggested-by: NDavid Miller <davem@davemloft.net>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: NMeelis Roos <mroos@linux.ee>
Cc: stable@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().

Register DS using device_initcall() insteal.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Cc: stable@vger.kernel.org

The change
    commit 4416e9eb
    Author: Gregory Bean <gbean@codeaurora.org>
    Date:   Wed Jul 28 10:22:12 2010 -0700

        arm: msm: Fix section mismatch in smd.c.

fixes a section mismatch between the board file and the smd driver's
probe function, however, it misses the additional mismatches between
the probe function and some routines it calls.  Fix these up as well.
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

Fixes the following warnings,

arch/arm/mach-msm/board-trout.c: In function 'trout_init':
arch/arm/mach-msm/board-trout.c:71: error: 'system_rev' undeclared (first use in this function)
arch/arm/mach-msm/board-trout.c:71: error: (Each undeclared identifier is reported only once
arch/arm/mach-msm/board-trout.c:71: error: for each function it appears in.)

and

arch/arm/mach-msm/board-trout-panel.c: In function 'trout_init_panel':
arch/arm/mach-msm/board-trout-panel.c:267: error: 'system_rev' undeclared (first use in this function)
arch/arm/mach-msm/board-trout-panel.c:267: error: (Each undeclared identifier is reported only once
arch/arm/mach-msm/board-trout-panel.c:267: error: for each function it appears in.)

This came in with the following commit 9f97da78
which removes asm/system.h
Signed-off-by: NDaniel Walker <dwalker@fifo99.com>
cc: David Howells <dhowells@redhat.com>
cc: Bryan Huntsman <bryanh@codeaurora.org>
cc: linux-arm-msm@vger.kernel.org
cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

This old fixup causes a build failure, so I remove it just like in
trout.
Signed-off-by: NDaniel Walker <dwalker@fifo99.com>
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

commit 93f37888

    "Fix ia64 build errors (fallout from system.h disintegration)"

introduced arch/ia64/include/asm/cmpxchg.h as a temporary
build fix and stated:

    "... leave the migration of xchg() and cmpxchg() to this new
     header file for a future patch."

Migrate the appropriate chunks from asm/intrinsics.h and fix
the whitespace issues in the migrated chunk.

Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: David Howells <dhowells@redhat.com>
Acked-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

commit ec221208

    "Disintegrate asm/system.h for Alpha"

combined with commit b4816afa

    "Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h"

introduced the concept of asm/cmpxchg.h but the alpha arch
never got one.  Fork the cmpxchg content out of the asm/atomic.h
file to create one.

Some minor whitespace fixups were done on the block of code that
created the new file.

Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Acked-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Commit 94e5a85b ("ARM: earlier initialization of vectors page") made it
the responsibility of paging_init to initialise the vectors page.

This patch adds a call to early_trap_init for the !CONFIG_MMU case,
placing the vectors at CONFIG_VECTORS_BASE.

Cc: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The description for the CPU_HIGH_VECTOR Kconfig option for nommu builds
doesn't make any sense.

This patch fixes up the trivial grammatical error.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some bootloaders are broken enough to expose an ATAG_MEM with
a null size. Converting such tag to a memory node leads to
an unbootable system.

Skip over zero sized ATAG_MEM to avoid this situation.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

atags_to_fdt() returns 1 when it fails to find a valid FDT signature.
The CONFIG_ARM_ATAG_DTB_COMPAT code is supposed to retry with another
location, but only does so when the initial call doesn't fail.

Fix this by using the correct condition in the assembly code.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Exit early when there's no support for a particular CPU family. Also,
fixup the "no support for this CPU vendor" to be issued only when the
driver is attempted to be loaded on an unsupported vendor.

Cc: stable@vger.kernel.org
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com
[Boris: add a commit msg because Andreas is lazy]
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Loading the microcode driver on an unsupported CPU and subsequently
unloading the driver causes

 WARNING: at fs/sysfs/group.c:138 mc_device_remove+0x5f/0x70 [microcode]()
 Hardware name: 01972NG
 sysfs group ffffffffa00013d0 not found for kobject 'cpu0'
 Modules linked in: snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel btusb snd_hda_codec bluetooth thinkpad_acpi rfkill microcode(-) [last unloaded: cfg80211]
 Pid: 4560, comm: modprobe Not tainted 3.4.0-rc2-00002-g258f7426 #5
 Call Trace:
  [<ffffffff8103113b>] ? warn_slowpath_common+0x7b/0xc0
  [<ffffffff81031235>] ? warn_slowpath_fmt+0x45/0x50
  [<ffffffff81120e74>] ? sysfs_remove_group+0x34/0x120
  [<ffffffffa00000ef>] ? mc_device_remove+0x5f/0x70 [microcode]
  [<ffffffff81331eb9>] ? subsys_interface_unregister+0x69/0xa0
  [<ffffffff81563526>] ? mutex_lock+0x16/0x40
  [<ffffffffa0000c3e>] ? microcode_exit+0x50/0x92 [microcode]
  [<ffffffff8107051d>] ? sys_delete_module+0x16d/0x260
  [<ffffffff810a0065>] ? wait_iff_congested+0x45/0x110
  [<ffffffff815656af>] ? page_fault+0x1f/0x30
  [<ffffffff81565ba2>] ? system_call_fastpath+0x16/0x1b

on recent kernels.

This is due to commit 8a25a2fd ("cpu: convert 'cpu' and
'machinecheck' sysdev_class to a regular subsystem") which renders
commit 6c53cbfc ("x86, microcode: Correct sysdev_add error path")
useless.

See http://marc.info/?l=linux-kernel&m=133416246406478

Avoid above warning by restoring the old driver behaviour before
6c53cbfc ("x86, microcode: Correct sysdev_add error path").

Cc: stable@vger.kernel.org
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.comSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This patch replaces the old global setting of irq_virq_count that is only
used by the NOMAP mapping and instead uses a revmap_data property so that
the maximum NOMAP allocation can be set per NOMAP irq_domain.

There is exactly one user of irq_virq_count in-tree right now: PS3.
Also, irq_virq_count is only useful for the NOMAP mapping.  So,
instead of having a single global irq_virq_count values, this change
drops it entirely and added a max_irq argument to irq_domain_add_nomap().
That makes it a property of an individual nomap irq domain instead of
a global system settting.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Tested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>

Until we push the unaligned access support for tilegx, it's silly
to have arch/tile/kernel/proc.c generate a warning about an unused
variable.  Extend the #ifdef to cover all the code and data for now.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

This merges the 32- and 64-bit versions of the x86 strncpy_from_user()
by just rewriting it in C rather than the ancient inline asm versions
that used lodsb/stosb and had been duplicated for (trivial) differences
between the 32-bit and 64-bit versions.

While doing that, it also speeds them up by doing the accesses a word at
a time.  Finally, the new routines also properly handle the case of
hitting the end of the address space, which we have never done correctly
before (fs/namei.c has a hack around it for that reason).

Despite all these improvements, it actually removes more lines than it
adds, due to the de-duplication.  Also, we no longer export (or define)
the legacy __strncpy_from_user() function (that was defined to not do
the user permission checks), since it's not actually used anywhere, and
the user address space checks are built in to the new code.

Other architecture maintainers have been notified that the old hack in
fs/namei.c will be going away in the 3.5 merge window, in case they
copied the x86 approach of being a bit cavalier about the end of the
address space.

Cc: linux-arch@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Anvin" <hpa@zytor.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>