Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to u8500_secondary_startup().
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>

Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to msm_secondary_startup().
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>

Once the ENDPROC is in place, BSYM() in not longer necessary
to get correct pointer to versatile_secondary_startup().
Tested-by: NJon Medhurst <tixy@linaro.org>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NDave Martin <dave.martin@linaro.org>

Commit 2a95ea6c ("procfs: do not overflow get_{idle,iowait}_time
for nohz") did not take into account that one some architectures jiffies
and cputime use different units.

This causes get_idle_time() to return numbers in the wrong units, making
the idle time fields in /proc/stat wrong.

Instead of converting the usec value returned by
get_cpu_{idle,iowait}_time_us to units of jiffies, use the new function
usecs_to_cputime64 to convert it to the correct unit of cputime64_t.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Acked-by: NMichal Hocko <mhocko@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "Artem S. Tashkinov" <t.artem@mailcity.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

SROMC static memory mapping is included in the common s5p initialization
code. Hence, remove the duplicated SROMC static memory mapping for EXYNOS.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Cc: stable@kernel.org
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Following is happened when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
is selected without building of s3c2410-iotiming.c file:

arch/arm/mach-s3c2440/built-in.o:(.data+0x38c): undefined reference to `s3c2410_iotiming_debugfs

Basically, the CONFIG_S3C2410_IOTIMING is not selected for
MACH_MINI2440. Because the s3c2410-iotiming.c is not ever
compiled and enabling CONFIG_CPU_FREQ_S3C24XX_DEBUGFS option
caused undefined reference to s3c2410_iotiming_debugfs()
defined in that file.  The s3c2410_iotiming_debugfs defined
as NULL for this case.
Signed-off-by: NDenis Kuzmenko <linux@solonet.org.ua>
Cc: stable@kernel.org
[kgene.kim@samsung.com: removed useless changes]
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This is required for THIS_MODULE.  We recently stopped acquiring
it via some other header.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently kvmppc_start_thread() tries to wake other SMT threads via
xics_wake_cpu().  Unfortunately xics_wake_cpu only exists when
CONFIG_SMP=Y so when compiling with CONFIG_SMP=N we get:

  arch/powerpc/kvm/built-in.o: In function `.kvmppc_start_thread':
  book3s_hv.c:(.text+0xa1e0): undefined reference to `.xics_wake_cpu'

The following should be fine since kvmppc_start_thread() shouldn't
called to start non-zero threads when SMP=N since threads_per_core=1.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Unlike all of the other cpuid bits, the TSC deadline timer bit is set
unconditionally, regardless of what userspace wants.

This is broken in several ways:
 - if userspace doesn't use KVM_CREATE_IRQCHIP, and doesn't emulate the TSC
   deadline timer feature, a guest that uses the feature will break
 - live migration to older host kernels that don't support the TSC deadline
   timer will cause the feature to be pulled from under the guest's feet;
   breaking it
 - guests that are broken wrt the feature will fail.

Fix by not enabling the feature automatically; instead report it to userspace.
Because the feature depends on KVM_CREATE_IRQCHIP, which we cannot guarantee
will be called, we expose it via a KVM_CAP_TSC_DEADLINE_TIMER and not
KVM_GET_SUPPORTED_CPUID.

Fixes the Illumos guest kernel, which uses the TSC deadline timer feature.

[avi: add the KVM_CAP + documentation]
Reported-by: NAlexey Zaytsev <alexey.zaytsev@gmail.com>
Tested-by: NAlexey Zaytsev <alexey.zaytsev@gmail.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

User space may create the PIT and forgets about setting up the irqchips.
In that case, firing PIT IRQs will crash the host:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm]
...
Call Trace:
 [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm]
 [<ffffffff81071431>] process_one_work+0x111/0x4d0
 [<ffffffff81071bb2>] worker_thread+0x152/0x340
 [<ffffffff81075c8e>] kthread+0x7e/0x90
 [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10

Prevent this by checking the irqchip mode before starting a timer. We
can't deny creating the PIT if the irqchips aren't set up yet as
current user land expects this order to work.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Add a req_running field to the pl330_thread to track which request (if
any) has been submitted to the DMA.  This mechanism replaces the old
one in which we tried to guess the same by looking at the PC of the
DMA, which could prevent the driver from sending more requests if it
didn't guess correctly.

Reference: <1323631637-9610-1-git-send-email-javi.merino@arm.com>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Acked-by: NJassi Brar <jaswinder.singh@linaro.org>
Tested-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Activation conditions for a workaround should not be encoded in the
workaround's direct dependencies if this makes otherwise reasonable
configuration choices impossible.

This patches uses the SMP/UP patching facilities instead to compile
out the workaround if the configuration means that it is definitely
not needed.

This means that configs for buggy silicon can simply select
ARM_ERRATA_751472, without preventing a UP kernel from being built
or duplicatiing knowledge about when to activate the workaround.
This seems the correct way to do things, because the erratum is a
property of the silicon, irrespective of what the kernel config
happens to be.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Activation conditions for a workaround should not be encoded in the
workaround's direct dependencies if this makes otherwise reasonable
configuration choices impossible.

The workaround for erratum 720789 only affects a code path which is
not active in UP kernels; hence it should be safe to turn on in UP
kernels, without penalty.

This patch simply removes the extra dependency on SMP from Kconfig.

This means that configs for buggy silicon can simply select
ARM_ERRATA_720789, without preventing a UP kernel from being built
or duplicatiing knowledge about when to activate the workaround.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use raw_spin_unlock_irqrestore() as equivalent to
raw_spin_lock_irqsave().
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1324646665-13334-1-git-send-email-robert.richter@amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

This change fixes a linking problem, which happens if oprofile
is selected to be compiled as built-in:

  `oprofile_arch_exit' referenced in section `.init.text' of
  arch/arm/oprofile/built-in.o: defined in discarded section
  `.exit.text' of arch/arm/oprofile/built-in.o

The problem is appeared after commit 87121ca5, which
introduced oprofile_arch_exit() calls from __init function. Note
that the aforementioned commit has been backported to stable
branches, and the problem is known to be reproduced at least
with 3.0.13 and 3.1.5 kernels.
Signed-off-by: NVladimir Zapolskiy <vladimir.zapolskiy@nokia.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: oprofile-list <oprofile-list@lists.sourceforge.net>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20111222151540.GB16765@erda.amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

This silently was working for many years and stopped working on
Niagara-T3 machines.

We need to set the MSIQ to VALID before we can set it's state to IDLE.

On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
errors.  The hypervisor documentation says, rather ambiguously, that
the MSIQ must be "initialized" before one can set the state.

I previously understood this to mean merely that a successful setconf()
operation has been performed on the MSIQ, which we have done at this
point.  But it seems to also mean that it has been set VALID too.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The former implementation adds a fix gpiochip label string
to the framework. This is confusing because orion_gpio_init
is called more than once and this ends up in different gpiochips
with the same label.

This patch adds the already present orion_gpio_chip_count to the
label string to make it unique in the system.
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

When printing the code bytes in show_registers(), the markers around the
byte at the fault address could make the printk() format string look
like a valid log level and facility code.  This would prevent this byte
from being printed and result in a spurious newline:

[ 7555.765589] Code: 8b 32 e9 94 00 00 00 81 7d 00 ff 00 00 00 0f 87 96 00 00 00 48 8b 83 c0 00 00 00 44 89 e2 44 89 e6 48 89 df 48 8b 80 d8 02 00 00
[ 7555.765683]  8b 48 28 48 89 d0 81 e2 ff 0f 00 00 48 c1 e8 0c 48 c1 e0 04

Add KERN_CONT where needed, and elsewhere in show_registers() for
consistency.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Link: http://lkml.kernel.org/r/4EEFA7AE.9020407@ladisch.deSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6
bytes.

In case a conditional jump is followed by a long jump, conditional jump
target is one byte past the start of target instruction.
Signed-off-by: NMarkus Kötter <nepenthesdev@gmail.com>
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If oprofilefs_ulong_from_user() is called with count equals
zero, *val remains unchanged. Depending on the implementation it
might be uninitialized.

Change oprofilefs_ulong_from_user()'s interface to return count
on success. Thus, we are able to return early if count equals
zero which avoids using *val uninitialized. Fixing all users of
oprofilefs_ulong_ from_user().

This follows write syscall implementation when count is zero:
"If count is zero ... [and if] no errors are detected, 0 will be
returned without causing any other effect." (man 2 write)
Reported-By: NMike Waychison <mikew@google.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Cc: oprofile-list <oprofile-list@lists.sourceforge.net>
Link: http://lkml.kernel.org/r/20111219153830.GH16765@erda.amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

in 0d6cfa3a I fixed the mach-types
records. We also need to make the name consistent in Kconfig else
the machine_is_eukrea_cpuimx35sd macro fails, and thus audio codec
is not properly initalized.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

commit 8d75a262 "ARM: mx35: use generic function for displaying silicon revision"
disabled IIM clock after reading silicon revision which will prevent
reboot in internal boot mode.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Jason Liu <jason.hui@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

- add new machine APF9328
- update CPUIMX25 -> CPUIMX25SD
- add drivers :
	- MXC nand driver
	- DM9000
	- SMSC Phy
	- SPIdev
	- Led GPIO
Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

in 0d6cfa3a I fixed the mach-types
records. We also need to make the name consistent in Kconfig else
the machine_is_eukrea_cpuimx25sd macro fails, and thus audio codec
is not properly initalized.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

WARNING: arch/arm/plat-mxc/built-in.o(.data+0x488): Section mismatch in reference from the variable mxc_driver to the function .init.text:mxc_cpufreq_init()
The variable mxc_driver references
the function __init mxc_cpufreq_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: NRichard Zhao <richard.zhao@linaro.org>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

According to imx pwm RM, the real period value should be
PERIOD value in PWMPR plus 2.

PWMO (Hz) = PCLK(Hz) / (period +2)
Signed-off-by: NJason Chen <jason.chen@linaro.org>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Cc: stable@kernel.org

Seems the commit 7e89098c was overly aggressive in adding iva and mailbox
hwmods so now they are registered twice.

------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c()
omap_hwmod: iva: _register returned -22
Modules linked in:
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64)
[<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c)
[<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c)
[<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28)
[<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4)
[<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264)
[<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040)
---[ end trace 1b75b31a2719ed1c ]---
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c()
omap_hwmod: mailbox: _register returned -22
Modules linked in:
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64)
[<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c)
[<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c)
[<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28)
[<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4)
[<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264)
[<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040)
---[ end trace 1b75b31a2719ed1d ]---
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The bisection implemented in unwind_find_origin() stopped to early.  If
there is only a single entry left to check the original code just took
the end point as origin which might be wrong.

This was introduced in commit de66a979 ("ARM: 7187/1: fix unwinding
for XIP kernels").
Reported-and-tested-by: NNick Bowler <nbowler@elliptictech.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

d312ae87 "xen: use maximum reservation to limit amount of usable RAM"
clamped the total amount of RAM to the current maximum reservation. This is
correct for dom0 but is not correct for guest domains. In order to boot a guest
"pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
future memory expansion the guest must derive max_pfn from the e820 provided by
the toolstack and not the current maximum reservation (which can reflect only
the current maximum, not the guest lifetime max). The existing algorithm
already behaves this correctly if we do not artificially limit the maximum
number of pages for the guest case.

For a guest booted with maxmem=512, memory=128 this results in:
 [    0.000000] BIOS-provided physical RAM map:
 [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
 [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
-[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
-[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
+[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
...
 [    0.000000] NX (Execute Disable) protection: active
 [    0.000000] DMI not present or invalid.
 [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
 [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
-[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
+[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
 [    0.000000] initial memory mapped : 0 - 027ff000
 [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
-[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
-[    0.000000]  0000000000 - 0008100000 page 4k
-[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
+[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
+[    0.000000]  0000000000 - 0020800000 page 4k
+[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
 [    0.000000] xen: setting RW the range 27e8000 - 27ff000
 [    0.000000] 0MB HIGHMEM available.
-[    0.000000] 129MB LOWMEM available.
-[    0.000000]   mapped low ram: 0 - 08100000
-[    0.000000]   low ram: 0 - 08100000
+[    0.000000] 520MB LOWMEM available.
+[    0.000000]   mapped low ram: 0 - 20800000
+[    0.000000]   low ram: 0 - 20800000

With this change "xl mem-set <domain> 512M" will successfully increase the
guest RAM (by reducing the balloon).

There is no change for dom0.
Reported-and-Tested-by: NGeorge Shuklin <george.shuklin@gmail.com>
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: stable@kernel.org
Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The "(insn & 0x01800000) != 0x01800000" test matches 'restore'
but that is a legitimate place to see the %lo() part of a 32-bit
symbol relocation, particularly in tail calls.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Tested-by: NSergei Trofimovich <slyfox@gentoo.org>

Commit 10299e2e (ARM: RX-51:
Enable isp1704 power on/off) added power management for isp1704.

However, the transceiver should be powered on by default,
otherwise USB doesn't work at all for networking during
boot.

All kernels after v3.0 are affected.

Cc: stable@kernel.org
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: NSebastian Reichel <sre@debian.org>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commits 09d28d ("ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src")
and 7bc0c4 ("ARM: OMAP: mcbsp: Start generalize signal muxing functions")
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.

Fix this by moving these pdata assignments before those calls.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Reported-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This hangs my MacBook Air at boot time; I get no console
messages at all. I reverted this on top of -rc5 and my machine
boots again.

This reverts commit e8c71062.
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Huang Ying <huang.ying.caritas@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@consoleSigned-off-by: NIngo Molnar <mingo@elte.hu>

arm_dma_zone_size is used by arm_bootmem_free() which is called by
paging_init(). Thus it needs to be set before calling it.
Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Cc: stable@kernel.org
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

efi_call_phys_prelog() sets up a 1:1 mapping of the physical address
range in swapper_pg_dir. Instead of replacing then restoring entries
in swapper_pg_dir we should be using initial_page_table which already
contains the 1:1 mapping.

It's safe to blindly switch back to swapper_pg_dir in the epilog
because the physical EFI routines are only called before
efi_enter_virtual_mode(), e.g. before any user processes have been
forked. Therefore, we don't need to track which pgd was in %cr3 when
we entered the prelog.

The previous code actually contained a bug because it assumed that the
kernel was loaded at a physical address within the first 8MB of ram,
usually at 0x100000. However, this isn't the case with a
CONFIG_RELOCATABLE=y kernel which could have been loaded anywhere in
the physical address space.

Also delete the ancient (and bogus) comments about the page table
being restored after the lock is released. There is no locking.

Cc: Matthew Garrett <mjg@redhat.com>
Cc: Darrent Hart <dvhart@linux.intel.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1323346250.3894.74.camel@mfleming-mobl1.ger.corp.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

With the 3.2-rc kernel, IOMMU 2M pages in KVM works.  But when I tried
to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page
failed to be used.

The root cause is that 1GB page allocation calls gup_huge_pud() while 2M
page calls gup_huge_pmd.  If compound pages are used and the page is a
tail page, gup_huge_pmd() increases _mapcount to record tail page are
mapped while gup_huge_pud does not do that.

So when the mapped page is relesed, it will result in kernel oops
because the page is not marked mapped.

This patch add tail process for compound page in 1GB huge page which
keeps the same process as 2M page.

Reproduce like:
1. Add grub boot option: hugepagesz=1G hugepages=8
2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages
3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages
	-net none -device pci-assign,host=07:00.1

  kernel BUG at mm/swap.c:114!
  invalid opcode: 0000 [#1] SMP
  Call Trace:
    put_page+0x15/0x37
    kvm_release_pfn_clean+0x31/0x36
    kvm_iommu_put_pages+0x94/0xb1
    kvm_iommu_unmap_memslots+0x80/0xb6
    kvm_assign_device+0xba/0x117
    kvm_vm_ioctl_assigned_device+0x301/0xa47
    kvm_vm_ioctl+0x36c/0x3a2
    do_vfs_ioctl+0x49e/0x4e4
    sys_ioctl+0x5a/0x7c
    system_call_fastpath+0x16/0x1b
  RIP  put_compound_page+0xd4/0x168
Signed-off-by: NYouquan Song <youquan.song@intel.com>
Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>