While running Linux as guest on top of phyp, we possiblly have
PE that includes single PCI device. However, we didn't return
its PCI bus correctly and it leads to failure on recovery from
EEH errors for single-dev-PE. The patch fixes the issue.

Cc: <stable@vger.kernel.org> # v3.7+
Cc: Steve Best <sbest@us.ibm.com>
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Due to recent changes and expecations of proper cpu bindings, there are
now cases for many of the in-tree devicetrees where a WARN() will hit
on boot due to badly formatted /cpus nodes.

Downgrade this to a pr_warn() to be less alarmist, since it's not a
new problem.

Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN
without this, the others do not.
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 37f02195 (powerpc/pci: fix PCI-e devices rescan issue on powerpc
platform) fixes a problem with interrupt and DMA initialization on hot
plugged devices. With this commit, interrupt and DMA initialization for
hot plugged devices is handled in the pci device enable function.

This approach has a couple of drawbacks. First, it creates two code paths
for device initialization, one for hot plugged devices and another for devices
known during the initial PCI scan. Second, the initialization code for hot
plugged devices is only called when the device is enabled, ie typically
in the probe function. Also, the platform specific setup code is called each
time pci_enable_device() is called, not only once during device discovery,
meaning it is actually called multiple times, once for devices discovered
during the initial scan and again each time a driver is re-loaded.

The visible result is that interrupt pins are only assigned to hot plugged
devices when the device driver is loaded. Effectively this changes the PCI
probe API, since pci_dev->irq and the device's dma configuration will now
only be valid after pci_enable() was called at least once. A more subtle
change is that platform specific PCI device setup is moved from device
discovery into the driver's probe function, more specifically into the
pci_enable_device() call.

To fix the inconsistencies, add new function pcibios_add_device.
Call pcibios_setup_device from pcibios_setup_bus_devices if device setup
is not complete, and from pcibios_add_device if bus setup is complete.

With this change, device setup code is moved back into device initialization,
and called exactly once for both static and hot plugged devices.

[ This also fixes a regression introduced by the above patch which
  causes dev->irq to be overwritten under some cirumstances after
  MSIs have been enabled for the device which leads to crashes due
  to the MSI core "hijacking" dev->irq to store the base MSI number
  and not the LSI. --BenH
]

Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

new helpers - dir_emit_dot(file, ctx, dentry), dir_emit_dotdot(file, ctx),
dir_emit_dots(file, ctx).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

New method - ->iterate(file, ctx).  That's the replacement for ->readdir();
it takes callback from ctx->actor, uses ctx->pos instead of file->f_pos and
calls dir_emit(ctx, ...) instead of filldir(data, ...).  It does *not*
update file->f_pos (or look at it, for that matter); iterate_dir() does the
update.

Note that dir_emit() takes the offset from ctx->pos (and eventually
filldir_t will lose that argument).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

iterate_dir(): new helper, replacing vfs_readdir().

struct dir_context: contains the readdir callback (and will get more stuff
in it), embedded into whatever data that callback wants to deal with;
eventually, we'll be passing it to ->readdir() replacement instead of
(data,filldir) pair.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

io_remap_pfn_range() does all we need
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

io_remap_pfn_range() sets it
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This fixes the problem that "init=" options may not be passed to kernel
correctly.

parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from
redboot_command_line. Then init_setup() parses the "init=" options from
static_command_line, which is a copy of redboot_command_line, and keeps
the pointer to the init options in execute_command variable.

Since the commit 026cee00 upstream (params: <level>_initcall-like kernel
parameters), static_command_line becomes overwritten by saved_command_line at
do_initcall_level(). Notice that saved_command_line is a command line
which includes "mem=" string.

As a result, execute_command may point to weird string by the length of
"mem=" parameter.
I noticed this problem when using the command line like this:

    mem=128M console=ttyS0,115200 init=/bin/sh

Here is the processing flow of command line parameters.
    start_kernel()
      setup_arch(&command_line)
         parse_mem_cmdline(cmdline_p)
           * strcpy(boot_command_line, redboot_command_line);
           * Remove "mem=xxx" from redboot_command_line.
           * *cmdline_p = redboot_command_line;
      setup_command_line(command_line) <-- command_line is redboot_command_line
        * strcpy(saved_command_line, boot_command_line)
        * strcpy(static_command_line, command_line)
      parse_early_param()
        strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
        parse_early_options(tmp_cmdline);
          parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
      parse_args("Booting ..", static_command_line, ...);
        init_setup() <-- save the pointer in execute_command
      rest_init()
        kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);

At this point, execute_command points to "/bin/sh" string.

    kernel_init()
      kernel_init_freeable()
        do_basic_setup()
          do_initcalls()
            do_initcall_level()
              (*) strcpy(static_command_line, saved_command_line);

Here, execute_command gets to point to "200" string !!
Signed-off-by: NDavid Howells <dhowells@redhat.com>

This fixes the following compile error:

CC block/scsi_ioctl.o
block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
block/scsi_ioctl.c:449: error: invalid initializer
Signed-off-by: NDavid Howells <dhowells@redhat.com>

commit f8f7d63f ("powerpc/eeh: Trace eeh
device from I/O cache") broke EEH on pseries for devices that were
present during boot and have not been hotplugged/DLPARed.

eeh_check_failure will get the eeh_dev from the cache, and will get
NULL. eeh_addr_cache_build adds the addresses to the cache, but eeh_dev
for the giving pci_device is not set yet. Just reordering the call to
eeh_addr_cache_insert_dev works fine. The ordering is similar to the one
in eeh_add_device_late.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Acked-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

We are using this function, now that we have introduced
the support for UTMI clock for computing the USB host rate.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: NBo Shen <voice.shen@atmel.com>

at91sam9n12 has Full-speed only USB. So we should add
it to the list in at91_pllb_usbfs_clock_init() function.
Moreover, at91sam9n12 has an unusual PMC in the sense that it
has a PLLB but also has a USB clock register.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: NBo Shen <voice.shen@atmel.com>

Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NBo Shen <voice.shen@atmel.com>

Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>

tegra_pmc_parse_dt() references __initconst data. Fix it to be __init.
This matches its only usage; a call from tegra_pmc_init() which is
already __init. This fixes:

WARNING: vmlinux.o(.text.unlikely+0x580): Section mismatch in reference
from the function tegra_pmc_parse_dt() to the (unknown reference)
.init.rodata:(unknown)
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The following commit caused a fatal oops when booting on mpc83xx with
a non-express PCI bus (regardless of whether a PCI device is present):

commit 50d8f87d
Author: Rojhalat Ibrahim <imr@rtschenk.de>
Date:   Mon Apr 8 10:15:28 2013 +0200

    powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers

    Up to now the PCIe link status on Freescale PCIe controllers was only
    checked once at boot time. So hotplug did not work. With this patch the
    link status is checked on every config read. PCIe devices not present at
    boot time are found after doing 'echo 1 >/sys/bus/pci/rescan'.
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This patch fixes the issue by calling setup_indirect_pci for all device types.
fsl_indirect_read_config is now only used for booke/86xx PCIe controllers.
Reported-by: NMichael Guntsche <mike@it-loops.com>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NScott Wood <scottwood@freescale.com>

The HAVE_PWM symbol is only for legacy platforms that provide
the PWM API without using the generic framework. MXS actually
uses that framework, and selecting the symbol anyway might
cause build errors like

drivers/built-in.o: In function `pwm_beeper_resume':
:(.text+0x1f4fc0): undefined reference to `pwm_config'
:(.text+0x1f4fc8): undefined reference to `pwm_enable'
drivers/built-in.o: In function `pwm_beeper_suspend':
:(.text+0x1f4ffc): undefined reference to `pwm_disable'

when CONFIG_PWM is disabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>

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: NArnd Bergmann <arnd@arndb.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>

This commit fixes the regression on Armada 370 (the kernal hang during
boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".

When coming out of either a Wait for Interrupt (WFI) or a Wait for
Event (WFE) IDLE states, a specific timing sensitivity exists between
the retiring WFI/WFE instructions and the newly issued subsequent
instructions. This sensitivity can result in a CPU hang scenario.  The
workaround is to insert either a Data Synchronization Barrier (DSB) or
Data Memory Barrier (DMB) command immediately after the WFI/WFE
instruction.

This commit was based on the work of Lior Amsalem, but heavily
modified to apply the errata fix dynamically according to the
processor type thanks to the suggestions of Russell King and Nicolas
Pitre.
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NWilly Tarreau <w@1wt.eu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 1bc39742 (ARM: 7755/1: handle user space mapped pages in
flush_kernel_dcache_page) moved the implementation of
flush_kernel_dcache_page() into mm/flush.c but did not implement it
on noMMU ARM.
Signed-off-by: NSimon Baatz <gmbnomis@gmail.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Cc: <stable@vger.kernel.org> # 3.2+: 1bc39742: ARM: 7755/1
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The __cpu_logical_map array is statically initialized to 0, which is a valid
MPIDR value. To prevent issues with the current implementation, this patch
defines an MPIDR_INVALID value, and statically initializes the
__cpu_logical_map[] array to it. Entries in the arm_dt_init_cpu_maps()
tmp_map array used to stash DT reg properties while parsing DT are initialized
with the MPIDR_INVALID value as well for consistency.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The introduction of the cpu-map topology node in the cpus node implies
that cpus node might have children that are not cpu nodes. The DT
parsing code needs updating otherwise it would check for cpu nodes
properties in nodes that are not required to contain them, resulting
in warnings that have no bearing on bindings defined in the dts source file.

Cc: <stable@vger.kernel.org> [3.8+]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As it was already suggested by Russell King and Arnd Bergmann:

https://lkml.org/lkml/2013/5/16/133

moxart and gemini seem to be the only platforms using CPU_FA526,
and instead of pointing arm_pm_idle to an empty function from
platform code, it makes sense to remove WFI code from the processor
specific idle function.

Applies to arm-soc/for-next (and 3.10-rc1).

Changes since v1:

1. remove WFI but make sure cpu_fa526_do_idle do not fall through
   to cpu_fa526_dcache_clean_area

Note: moxart boots and prints to UART without this patch, but input is broken.
Signed-off-by: NJonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The following git commit changed the behavior of sscanf:

commit 53809751
Author: Jan Beulich <JBeulich@suse.com>
Date:   Mon Dec 17 16:01:31 2012 -0800
    sscanf: don't ignore field widths for numeric conversions

This broke the WWPN and LUN sysfs attributes for s390 reipl and dump
on panic.

Example:

$ echo 0x0123456701234567 > /sys/firmware/reipl/fcp/wwpn
$ cat /sys/firmware/reipl/fcp/wwpn
0x0001234567012345

So fix this and use format strings that work also with the
new sscanf implementation:

$ echo 0x012345670123456789 > /sys/firmware/reipl/fcp/wwpn
$ cat /sys/firmware/reipl/fcp/wwpn
0x0123456701234567

Cc: stable@vger.kernel.org # 3.8+
Reviewed-by: NSteffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The length of the registers area for the Marvell 370/XP Ethernet controller
was incorrect in the .dtsi: 0x2500, while it should have been 0x4000.
This problem wasn't noticed because there used to be a static mapping for
all the MMIO register region set up by ->map_io().

The register length was fixed in all the other device tree files,
except from the armada-xp-mv78260.dtsi, in the following commit:

  commit cf8088c5
  Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  Date:   Tue May 21 12:33:27 2013 +0200

    arm: mvebu: fix length of Ethernet registers area in .dtsi

This commit fixes a kernel panic in mvneta_probe(), when the kernel
tries to access the unmapped registers:

[  163.639092] mvneta d0070000.ethernet eth0: mac: 6e:3c:4f:87:17:2e
[  163.646962] mvneta d0074000.ethernet eth1: mac: 6a:04:4e:6f:f5:ef
[  163.654853] mvneta d0030000.ethernet eth2: mac: 2a:99:19:19:fc:4c
[  163.661258] Unable to handle kernel paging request at virtual address f011bcf0
[  163.668523] pgd = c0004000
[  163.671237] [f011bcf0] *pgd=2f006811, *pte=00000000, *ppte=00000000
[  163.677565] Internal error: Oops: 807 [#1] SMP ARM
[  163.682370] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc6-01850-gba0682e #11
[  163.690046] task: ef04c000 ti: ef03e000 task.ti: ef03e000
[  163.695467] PC is at mvneta_probe+0x34c/0xabc
[...]
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

dump_seek() does SEEK_CUR, not SEEK_SET; native binfmt_aout
handles it correctly (seeks by PAGE_SIZE - sizeof(struct user),
getting the current position to PAGE_SIZE), compat one seeks
by PAGE_SIZE and ends up at PAGE_SIZE + already written...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The following commit:

commit 7e348b90
Author: Robert Lee <rob.lee@linaro.org>
Date:   Tue Mar 20 15:22:43 2012 -0500

    ARM: at91: Consolidate time keeping and irq enable

    Enable core cpuidle timekeeping and irq enabling and remove that
    handling from this code.

introduced an additional zero to the state1 (suspend) target residency.

With a periodic tick, the cpu never enters the state1 with both 10000 and
100000.

With a tickless system, it enters to state1 much more often with the
initial value, roughly x7 more.

Fix it by setting the value to 10ms again.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
[nicola.ferre@atmel.com: add precisions given by Daniel to commit message]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Since 4b68520dc0ec96153bc0d87bca5ffba508edfcf
ARM: at91: add AIC5 support

we allocate the at91_extern_irq.

This patch makes it static and stores the non-dt extern irq in the soc
structure. It is then possible to use a at91_get_extern_irq() function
to get the value for outside of the irq driver. It is useful for passing
its value to at91_aic_init().
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
[nicolas.ferre@atmel.com: rework commit message]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

1. Check for allocation failure
2. Clear the buffer contents, as they may actually be written to flash
3. Don't leak the buffer

Compile-tested only.

[ Tested successfully on my buggy ASUS machine - Matt ]
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Fix arch_prepare_kprobe() to handle failures in copy instruction
correctly. This fix is related to the previous fix: 8101376d
which made __copy_instruction return an error result if failed,
but caller site was not updated to handle it. Thus, this is the
other half of the bugfix.

This fix is also related to the following bug-report:

   https://bugzilla.redhat.com/show_bug.cgi?id=910649Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NJonathan Lebon <jlebon@redhat.com>
Cc: Frank Ch. Eigler <fche@redhat.com>
Cc: systemtap@sourceware.org
Cc: yrl.pp-manager.tt@hitachi.com
Link: http://lkml.kernel.org/r/20130605031216.15285.2001.stgit@mhiramat-M0-7522Signed-off-by: NIngo Molnar <mingo@kernel.org>

The following change fixes the x86 implementation of
trigger_all_cpu_backtrace(), which was previously (accidentally,
as far as I can tell) disabled to always return false as on
architectures that do not implement this function.

trigger_all_cpu_backtrace(), as defined in include/linux/nmi.h,
should call arch_trigger_all_cpu_backtrace() if available, or
return false if the underlying arch doesn't implement this
function.

x86 did provide a suitable arch_trigger_all_cpu_backtrace()
implementation, but it wasn't actually being used because it was
declared in asm/nmi.h, which linux/nmi.h doesn't include. Also,
linux/nmi.h couldn't easily be fixed by including asm/nmi.h,
because that file is not available on all architectures.

I am proposing to fix this by moving the x86 definition of
arch_trigger_all_cpu_backtrace() to asm/irq.h.

Tested via: echo l > /proc/sysrq-trigger

Before the change, this uses a fallback implementation which
shows backtraces on active CPUs (using
smp_call_function_interrupt() )

After the change, this shows NMI backtraces on all CPUs
Signed-off-by: NMichel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1370518875-1346-1-git-send-email-walken@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

With this change, we no longer lose the innermost entry in the user-mode
part of the call chain.  See also the x86 port, which includes the ip,
and the corresponding change in arch/arm.
Signed-off-by: NJed Davis <jld@mozilla.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Book3E uses the hugepd at PMD level and don't encode pte directly
at the pmd level. So it will find the lower bits of pmd set
and the pmd_bad check throws error. Infact the current code
will never take the free_hugepd_range call at all because it will
clear the pmd if it find a hugepd pointer. Fix this by clearing
bad pmd only if it is not a hugepd pointer.

This is regression introduced by e2b3d202
"powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format"
Reported-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

I got a build error today that made me realize that it is not
possible to build a kernel for a SiRF platform without enabling
CONFIG_PRIMA2, since a lot of common code depends on CONFIG_PRIMA2.

This fixes all occurences that appear like common SiRF code.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMark Brown <broonie@linaro.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NMike Turquette <mturquette@linaro.org>

We are in the process of removing all the __cpuinit annotations.
While working on making that change, an existing problem was
made evident:

  WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
  in reference from the function cpu_init() to the function
  .init.text:load_ucode_ap()   The function cpu_init() references
  the function __init load_ucode_ap().  This is often because cpu_init
  lacks a __init annotation or the annotation of load_ucode_ap is wrong.

This now appears because in my working tree, cpu_init() is no longer
tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
hypothesis from the audit is the correct one, as there was an incorrect
__init tag on the prototype in the header (but __cpuinit was used on
the function itself.)

The audit is telling us that the prototype's __init annotation took
effect and the function did land in the .init.text section.  Checking
with objdump on a mainline tree that still has __cpuinit shows that
the __cpuinit on the function takes precedence over the __init on the
prototype, but that won't be true once we make __cpuinit a no-op.

Even though we are removing __cpuinit, we temporarily align both
the function and the prototype on __cpuinit so that the changeset
can be applied to stable trees  if desired.

[ hpa: build fix only, no object code change ]

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: stable <stable@vger.kernel.org> # 3.9+
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

We need to pick up the definition of raw_smp_processor_id() from
asm/smp.h.  For the !SMP case, we need to supply a definition of
raw_smp_processor_id().

Because of the include dependencies we cannot use smp_call_func_t in
asm/smp.h, but we do need linux/thread_info.h
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>