- fix ioremap_nocache to actually return non-cacheable address
- add explicit ioremap_cache
- fix KIO aperture checking arithmetic
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Do not rely on compiler implicitly placing function arguments into
specifc registers, place them explicitly.

Move __simc and related helpers to platform/simcall.h
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

xtensa_irq_disable/xtensa_irq_enable used to call xtensa_irq_unmask with
wrong argument.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Fix caching attributes setup providing correct _PAGE_CA_* names.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

This allows building kernel in allnoconfig configuration.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

Now that binutils generate *.unlikely sections which don't follow
documented (info as) literal section naming rules, section name
transformation script doesn't work well resulting in the following
errors at vmlinux link time:

	main.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal
				     placed after use: .literal.unlikely

Fix section name transformation script by adding specific rule for
.text.unlikely sections.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NChris Zankel <chris@zankel.net>

The userspace part of UML uses the asm-offsets.h generator mechanism to
create definitions for UM_KERN_<LEVEL> that match the in-kernel
KERN_<LEVEL> constant definitions.

As of commit 04d2c8c8 ("printk: convert
the format for KERN_<LEVEL> to a 2 byte pattern"), KERN_<LEVEL> is no
longer expanded to the literal '"<LEVEL>"', but to '"\001" "LEVEL"', i.e.
it contains two parts.

However, the combo of DEFINE_STR() in
arch/x86/um/shared/sysdep/kernel-offsets.h and sed-y in Kbuild doesn't
support string literals consisting of multiple parts. Hence for all
UM_KERN_<LEVEL> definitions, only the SOH character is retained in the actual
definition, while the remainder ends up in the comment. E.g. in
include/generated/asm-offsets.h we get

    #define UM_KERN_INFO "\001" /* "6" KERN_INFO */

instead of

    #define UM_KERN_INFO "\001" "6" /* KERN_INFO */

This causes spurious '^A' output in some kernel messages:

    Calibrating delay loop... 4640.76 BogoMIPS (lpj=23203840)
    pid_max: default: 32768 minimum: 301
    Mount-cache hash table entries: 256
    ^AChecking that host ptys support output SIGIO...Yes
    ^AChecking that host ptys support SIGIO on close...No, enabling workaround
    ^AUsing 2.6 host AIO
    NET: Registered protocol family 16
    bio: create slab <bio-0> at 0
    Switching to clocksource itimer

To fix this:
  - Move the mapping from UM_KERN_<LEVEL> to KERN_<LEVEL> from
    arch/um/include/shared/common-offsets.h to
    arch/um/include/shared/user.h, which is preincluded for all userspace
    parts,
  - Preinclude include/linux/kern_levels.h for all userspace parts, to
    obtain the in-kernel KERN_<LEVEL> constant definitions. This doesn't
    violate the kernel/userspace separation, as include/linux/kern_levels.h
    is self-contained and doesn't expose any other kernel internals.
  - Remove the now unused STR() and DEFINE_STR() macros.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>

commit c1d7e01d (ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION)
forgot UML and broke IPC on it.
Also UML has to select ARCH_WANT_IPC_PARSE_VERSION usin Kconfig.

Reported-and-tested-by: <Toralf Förster toralf.foerster@gmx.de>
Signed-off-by: NRichard Weinberger <richard@nod.at>

we only use that to tell copy_thread() done by syscall from that
done by kernel_thread().  However, it's easier to do simply by
checking PF_KTHREAD in thread flags.

Merge sys_clone() guts for 32bit and 64bit, while we are at it...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

... rather than duplicating that in sigframe setup code (and doing that
inconsistently, at that)
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

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

... assuming it's needed to be done at all
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Some Orion5x devices allocate their coherent buffers from atomic
context. Increase size of atomic coherent pool to make sure such the
allocations won't fail during boot.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NOlof Johansson <olof@lixom.net>

There is no such part as KS8001, KS8041 or KS8051. There are only
KSZ8001, KSZ8041 and KSZ8051. Rename these parts as such to match
the Micrel naming.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: David J. Choi <david.choi@micrel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Linux ARM kernel <linux-arm-kernel@lists.infradead.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

An ABI numbering change was made in the hypervisor for Tilera's 4.1
MDE release (just shipped).  It's incompatible with the previous 4.0
release ABI numbering, so we track the new numbering going forward.
We plan to avoid modifying ABI numbering for these interfaces again.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

A recent patch in the linux-next tree caused a build failure on
C6X because C6X didn't define a read_barrier_depends() macro. C6X
does not support SMP and the architecture doesn't provide any
special memory ordering instructions, so it makes sense to just
use the generic barrier.h rather than patching the existing c6x
specific header.
Signed-off-by: NMark Salter <msalter@redhat.com>

The hypervisor is in charge of allocating the proper "NUMA" memory
and dealing with the CPU scheduler to keep them bound to the proper
NUMA node. The PV guests (and PVHVM) have no inkling of where they
run and do not need to know that right now. In the future we will
need to inject NUMA configuration data (if a guest spans two or more
NUMA nodes) so that the kernel can make the right choices. But those
patches are not yet present.

In the meantime, disable the NUMA capability in the PV guest, which
also fixes a bootup issue. Andre says:

"we see Dom0 crashes due to the kernel detecting the NUMA topology not
by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).

This will detect the actual NUMA config of the physical machine, but
will crash about the mismatch with Dom0's virtual memory. Variation of
the theme: Dom0 sees what it's not supposed to see.

This happens with the said config option enabled and on a machine where
this scanning is still enabled (K8 and Fam10h, not Bulldozer class)

We have this dump then:
NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
Scanning NUMA topology in Northbridge 24
Number of physical nodes 4
Node 0 MemBase 0000000000000000 Limit 0000000040000000
Node 1 MemBase 0000000040000000 Limit 0000000138000000
Node 2 MemBase 0000000138000000 Limit 00000001f8000000
Node 3 MemBase 00000001f8000000 Limit 0000000238000000
Initmem setup node 0 0000000000000000-0000000040000000
  NODE_DATA [000000003ffd9000 - 000000003fffffff]
Initmem setup node 1 0000000040000000-0000000138000000
  NODE_DATA [0000000137fd9000 - 0000000137ffffff]
Initmem setup node 2 0000000138000000-00000001f8000000
  NODE_DATA [00000001f095e000 - 00000001f0984fff]
Initmem setup node 3 00000001f8000000-0000000238000000
Cannot find 159744 bytes in node 3
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
.. snip..
  [<ffffffff81d23024>] sparse_early_usemaps_alloc_node+0x64/0x178
  [<ffffffff81d23348>] sparse_init+0xe4/0x25a
  [<ffffffff81d16840>] paging_init+0x13/0x22
  [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
  [<ffffffff81683954>] ? printk+0x3c/0x3e
  [<ffffffff81d01a38>] start_kernel+0xe5/0x468
  [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
  [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
  [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
"

so we just disable NUMA scanning by setting numa_off=1.

CC: stable@vger.kernel.org
Reported-and-Tested-by: NAndre Przywara <andre.przywara@amd.com>
Acked-by: NAndre Przywara <andre.przywara@amd.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When either of __alloc_from_contiguous or __alloc_remap_buffer fails
to provide a valid pointer, allocated memory is freed up and an error
is returned. 'pages' was however not freed before returning error.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>

In case of error, function module_alloc() in other platform never
returns ERR_PTR(), and all of the user only check for NULL, so
we'd better return NULL instead of ERR_PTR().

dpatch engine is used to auto generated this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

GNU Binutils 2.20.1 generates .eh_frame sections that uses R_SPARC_DISP32.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

kcmp has appeared on x86, but has not been noticed because
checksyscalls.sh is broken at the moment.  Reserve ARM syscall 378
for this should we ever need it, and add an __IGNORE entry for this
unimplemented syscall.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

While building the SUSE kernel packages, which build the scripts,
make clean, and then build everything, we have been running into spurious
build failures. We tracked them down to a simple dependency issue:

$ make mrproper
  CLEAN   arch/x86/tools
  CLEAN   scripts/basic
$ cp patches/config/x86_64/desktop .config
$ make archscripts
  HOSTCC  arch/x86/tools/relocs
/bin/sh: scripts/basic/fixdep: No such file or directory
make[3]: *** [arch/x86/tools/relocs] Error 1
make[2]: *** [archscripts] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

This was introduced by commit
6520fe55 (x86, realmode: 16-bit real-mode code support for relocs),
which added the archscripts dependency to archprepare.

This patch adds the scripts_basic dependency to the x86 archscripts.
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Running cpufreq driver on imx6q, the following warning is seen.

$ BUG: sleeping function called from invalid context at kernel/mutex.c:269

<snip>

stack backtrace:
Backtrace:
[<80011d64>] (dump_backtrace+0x0/0x10c) from [<803fc164>] (dump_stack+0x18/0x1c)
 r6:bf8142e0 r5:bf814000 r4:806ac794 r3:bf814000
[<803fc14c>] (dump_stack+0x0/0x1c) from [<803fd444>] (print_usage_bug+0x250/0x2b
8)
[<803fd1f4>] (print_usage_bug+0x0/0x2b8) from [<80060f90>] (mark_lock+0x56c/0x67
0)
[<80060a24>] (mark_lock+0x0/0x670) from [<80061a20>] (__lock_acquire+0x98c/0x19b
4)
[<80061094>] (__lock_acquire+0x0/0x19b4) from [<80062f14>] (lock_acquire+0x68/0x
7c)
[<80062eac>] (lock_acquire+0x0/0x7c) from [<80400f28>] (mutex_lock_nested+0x78/0
x344)
 r7:00000000 r6:bf872000 r5:805cc858 r4:805c2a04
[<80400eb0>] (mutex_lock_nested+0x0/0x344) from [<803089ac>] (clk_get_rate+0x1c/
0x58)
[<80308990>] (clk_get_rate+0x0/0x58) from [<80013c48>] (twd_update_frequency+0x1
8/0x50)
 r5:bf253d04 r4:805cadf4
[<80013c30>] (twd_update_frequency+0x0/0x50) from [<80068e20>] (generic_smp_call
_function_single_interrupt+0xd4/0x13c)
 r4:bf873ee0 r3:80013c30
[<80068d4c>] (generic_smp_call_function_single_interrupt+0x0/0x13c) from [<80013
34c>] (handle_IPI+0xc0/0x194)
 r8:00000001 r7:00000000 r6:80574e48 r5:bf872000 r4:80593958
[<8001328c>] (handle_IPI+0x0/0x194) from [<800084e8>] (gic_handle_irq+0x58/0x60)
 r8:00000000 r7:bf873f8c r6:bf873f58 r5:80593070 r4:f4000100
r3:00000005
[<80008490>] (gic_handle_irq+0x0/0x60) from [<8000e124>] (__irq_svc+0x44/0x60)
Exception stack(0xbf873f58 to 0xbf873fa0)
3f40:                                                       00000001 00000001
3f60: 00000000 bf814000 bf872000 805cab48 80405aa4 80597648 00000000 412fc09a
3f80: bf872000 bf873fac bf873f70 bf873fa0 80063844 8000f1f8 20000013 ffffffff
 r6:ffffffff r5:20000013 r4:8000f1f8 r3:bf814000
[<8000f1b8>] (default_idle+0x0/0x4c) from [<8000f428>] (cpu_idle+0x98/0x114)
[<8000f390>] (cpu_idle+0x0/0x114) from [<803f9834>] (secondary_start_kernel+0x11
c/0x140)
[<803f9718>] (secondary_start_kernel+0x0/0x140) from [<103f9234>] (0x103f9234)
 r6:10c03c7d r5:0000001f r4:4f86806a r3:803f921c

It looks that the warning is caused by that twd_update_frequency() gets
called from an atomic context while it calls clk_get_rate() where a
mutex gets held.

To fix the warning, let's convert common clk users over to clk notifiers
in place of CPUfreq notifiers.  This works out nicely for Cortex-A9
MPcore designs that scale all CPUs at the same frequency.

Platforms that have not been converted to the common clk framework and
support CPUfreq will rely on the old mechanism.  Once these platforms
are converted over fully then we can remove the CPUfreq-specific bits
for good.
Signed-off-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f->100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f->100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
 [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
 [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
 [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
 [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81abca7f>] start_kernel+0x90/0x390
 [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
 [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

CC: stable@vger.kernel.org
Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665Acked-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This patch updates the existing Intel IvyBridge (model 58)
support with proper PEBS event constraints. It cannot reuse
the same as SandyBridge because some events (0xd3) are
specific to IvyBridge.

Also there is no UOPS_DISPATCHED.THREAD on IVB, so do not
populate the PERF_COUNT_HW_STALLED_CYCLES_BACKEND mapping.
Signed-off-by: NStephane Eranian <eranian@google.com>
Cc: peterz@infradead.org
Cc: ak@linux.intel.com
Link: http://lkml.kernel.org/r/20120910230701.GA5898@quadSigned-off-by: NIngo Molnar <mingo@kernel.org>

Since i.MX has SPARSE_IRQ enabled the i.MX25 timer is broken. This
is because the internal irqs now start at an offset of NR_IRQS_LEGACY.
The patch fixed this up, but missed the i.MX25 timer which used a
hardcoded value instead of a define. This patch introduces a define
for the timer irq and uses it.

This is broken since introduced with 3.6-rc1:

| commit 8842a9e2
| Author: Shawn Guo <shawn.guo@linaro.org>
| Date:   Thu Jun 14 11:16:14 2012 +0800
|
|    ARM: imx: enable SPARSE_IRQ for imx platform
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>

Since commit eb92044e (ARM i.MX3: Make ccm base address a variable )
it is necessary to pass the CCM register base as a variable.

Fix the CCM register access in mach-armadillo5x0 by passing mx3_ccm_base and
avoid illegal accesses.

Also applies to v3.5
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org

As Al notes, we missed a TIF_NOTIFY_RESUME check which caused any
handlers without TIF_SIGPENDING also set to skip the notification:

	Looks like while it is in the relevant masks *and* checked in
	do_notify_resume() both on 32bit and 64bit variants since commit
	ab99c733 ("sh: Make syscall tracer
	use tracehook notifiers, add TIF_NOTIFY_RESUME.") they are
	actually *not* reached without simulataneous SIGPENDING, since
	the actual glue in the callers had not been updated back then and
	still checks for _TIF_SIGPENDING alone when deciding whether to
	hit do_notify_resume() or not.
Reported-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Tested-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Correct interrupt settings of sh_mmc:int and sh_mmc:error in board-kzm9g.c.
Signed-off-by: NTetsuyuki Kobayashi <koba@kmckk.co.jp>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

The spinlock clocks_lock can be held during ISR, hence it is not safe to
hold that lock with disabling interrupts.

It fixes following potential deadlock.

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-rc4+ #2 Not tainted
---------------------------------------------------------
swapper/0/1 just changed the state of lock:
 (&(&host->lock)->rlock){-.....}, at: [<c027fb0d>] sdhci_irq+0x15/0x564
but this lock took another, HARDIRQ-unsafe lock in the past:
 (clocks_lock){+.+...}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(clocks_lock);
                               local_irq_disable();
                               lock(&(&host->lock)->rlock);
                               lock(clocks_lock);
  <Interrupt>
    lock(&(&host->lock)->rlock);

 *** DEADLOCK ***
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Tested-by: NBo Shen <voice.shen@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The s390 page-table walk code, used for user copy and futex, currently
cannot handle huge pages. As far as user copy is concerned, that is
not really a problem because those functions will only be used on old
hardware that has no huge page support. But the futex code will also
use pagetable walk functions on current hardware when user space runs
in primary space mode. So, if a futex sits in a huge page, the futex
operation on it will result in a page fault loop or even data
corruption.

This patch adds the code for resolving huge page mappings in the user
access pagetable walk code on s390.
Signed-off-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

From 0cdf3aff, "ARM: SAMSUNG: use spin_lock_irqsave() in
clk_{enable,disable}":

  The clk_enable()and clk_disable() can be used process and ISR either.
  And actually it is used for real product and other platforms use it
  now. So spin_lock_irqsave() should be used instead.

We need to make a similar change in clk_set_parent(). Otherwise,
you can potentially get spinlock recursion:

BUG: spinlock recursion on CPU#0, kinteractive/68
 lock: 807832a8, .magic: dead4ead, .owner: kinteractive/68, .owner_cpu: 0
[<80015f54>] (unwind_backtrace+0x0/0x128) from [<804f2914>] (dump_stack+0x20/0x24)
[<804f2914>] (dump_stack+0x20/0x24) from [<804f57b8>] (spin_dump+0x80/0x94)
[<804f57b8>] (spin_dump+0x80/0x94) from [<804f57f8>] (spin_bug+0x2c/0x30)
[<804f57f8>] (spin_bug+0x2c/0x30) from [<80222730>] (do_raw_spin_lock+0x54/0x150)
[<80222730>] (do_raw_spin_lock+0x54/0x150) from [<804f96ec>] (_raw_spin_lock_irqsave+0x20/0x28)
[<804f96ec>] (_raw_spin_lock_irqsave+0x20/0x28) from [<80022ea4>] (clk_enable+0x3c/0x84)
[<80022ea4>] (clk_enable+0x3c/0x84) from [<8038336c>] (s5p_mfc_clock_on+0x60/0x74)
[<8038336c>] (s5p_mfc_clock_on+0x60/0x74) from [<8038645c>] (s5p_mfc_read_info+0x20/0x38)
[<8038645c>] (s5p_mfc_read_info+0x20/0x38) from [<8037ca3c>] (s5p_mfc_handle_frame+0x2e4/0x4bc)
[<8037ca3c>] (s5p_mfc_handle_frame+0x2e4/0x4bc) from [<8037d420>] (s5p_mfc_irq+0x1ec/0x6cc)
[<8037d420>] (s5p_mfc_irq+0x1ec/0x6cc) from [<8007fc74>] (handle_irq_event_percpu+0x8c/0x244)
[<8007fc74>] (handle_irq_event_percpu+0x8c/0x244) from [<8007fe78>] (handle_irq_event+0x4c/0x6c)
[<8007fe78>] (handle_irq_event+0x4c/0x6c) from [<80082dd8>] (handle_fasteoi_irq+0xe4/0x150)
[<80082dd8>] (handle_fasteoi_irq+0xe4/0x150) from [<8007f424>] (generic_handle_irq+0x3c/0x50)
[<8007f424>] (generic_handle_irq+0x3c/0x50) from [<8000f7c4>] (handle_IRQ+0x88/0xc8)
[<8000f7c4>] (handle_IRQ+0x88/0xc8) from [<80008564>] (gic_handle_irq+0x44/0x68)
[<80008564>] (gic_handle_irq+0x44/0x68) from [<8000e400>] (__irq_svc+0x40/0x60)
Exception stack(0xef3cbe68 to 0xef3cbeb0)
[<8000e400>] (__irq_svc+0x40/0x60) from [<80022cfc>] (clk_set_parent+0x30/0x74)
[<80022cfc>] (clk_set_parent+0x30/0x74) from [<803ac7f8>] (set_apll.isra.0+0x28/0xb0)
[<803ac7f8>] (set_apll.isra.0+0x28/0xb0) from [<803ac8e4>] (exynos5250_set_frequency+0x64/0xb8)
[<803ac8e4>] (exynos5250_set_frequency+0x64/0xb8) from [<803ac280>] (exynos_target+0x1b0/0x220)
[<803ac280>] (exynos_target+0x1b0/0x220) from [<803a4a0c>] (__cpufreq_driver_target+0xb0/0xd4)
[<803a4a0c>] (__cpufreq_driver_target+0xb0/0xd4) from [<803aab80>] (cpufreq_interactive_updown_task+0x214/0x264)
[<803aab80>] (cpufreq_interactive_updown_task+0x214/0x264) from [<80047d04>] (kthread+0x9c/0xa8)
[<80047d04>] (kthread+0x9c/0xa8) from [<8000fa48>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Suggested-by: NSunil Mazhavanchery <sunilm@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Minho Ban <mhban@samsung.com>
Cc: Jaecheol Lee <jc.lee@samsung.com>
Cc: Sunyoung Kang <sy0816.kang@samsung.com>
Cc: Olof Johansson <olofj@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

48d480b0 [[MIPS] Malta: Fix off by one bug in interrupt
handler.] did not take in account that irq_ffs() will also return 0 if for some reason
the set of pending interrupts happens to be empty.

This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
in something like the following:

CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
Oops[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
$ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
$ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
$12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
$16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
$20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
$24   : 0000000000000028 ffffffff803226e8
$28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
Hi    : 0000000000000000
Lo    : 0000006388974000
epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
    Not tainted
ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
Status: 9000a4e2    KX SX UX KERNEL EXL
Cause : 00808008
BadVA : 0000000000000000
PrId  : 000028a0 (Nevada)
Modules linked in:
Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
        ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
        9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
        ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
        0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
        0000000000000000 9000000018000000 90000000180003f9 0000000000000001
        0000000000000000 00000000000000ff 0000000000000018 0000000000000001
        0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
        ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
        0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
        ...
Call Trace:
[<ffffffff801772d0>] handle_irq_event_percpu+0x70/0x2f0
[<ffffffff8017ad24>] handle_percpu_irq+0x54/0x88
[<ffffffff801769f4>] generic_handle_irq+0x44/0x60
[<ffffffff801037f8>] do_IRQ+0x48/0x70
[<ffffffff80101c44>] ret_from_irq+0x0/0x4
[<ffffffff80326170>] serial8250_startup+0x310/0x870
[<ffffffff8032175c>] uart_startup.part.7+0x9c/0x330
[<ffffffff80321b4c>] uart_open+0x15c/0x1b0
[<ffffffff80302034>] tty_open+0x1fc/0x720
[<ffffffff801bffac>] chrdev_open+0x7c/0x180
[<ffffffff801b9ab8>] do_dentry_open.isra.14+0x288/0x390
[<ffffffff801bac5c>] nameidata_to_filp+0x5c/0xc0
[<ffffffff801ca700>] do_last.isra.33+0x330/0x8f0
[<ffffffff801caf3c>] path_openat+0xbc/0x440
[<ffffffff801cb3c8>] do_filp_open+0x38/0xa8
[<ffffffff801bade4>] do_sys_open+0x124/0x218
[<ffffffff80110538>] handle_sys+0x118/0x13c

Code: 02d5a825  12800012  02a0b02d <de820000> de850008  0040f809  0220202d  0040a82d  40026000
---[ end trace 5d8e7b9a86badd2d ]---
Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
cacheable for ARMv7 cores in the decompressor, ensuring that the
memory region attributes are obtained from the C and B bits, not from
the page tables.

Cc: Nicolas Pitre <nico@fluxnic.net>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NMatthew Leach <matthew.leach@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The managed clk functions are currently only available when the generic clk
lookup framework is build. But the managed clk functions are merely wrappers
around clk_get and clk_put and do not depend on any specifics of the generic
lookup functions and there are still quite a few custom implementations of the
clk API. So make the managed functions available whenever the clk API is
implemented.

The patch also removes the custom implementation of devm_clk_get for the
coldfire platform.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

 YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence.  Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.

 A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.

 This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything.  And
either way the alarm code has been since fixed anyway.
Signed-off-by: NMaciej W. Rozycki <macro@codesourcery.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4336/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fixing an off-by-one error in devmem_is_allowed(), which allows
accesses to physical addresses 0x100000-0x100fff, an extra page
past 1MB.
Signed-off-by: NT Makphaibulchoke <tmac@hp.com>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Cc: yinghai@kernel.org
Cc: tiwai@suse.de
Cc: dhowells@redhat.com
Link: http://lkml.kernel.org/r/1346210503-14276-1-git-send-email-tmac@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Current implementation simply ignores attribute flags. Thus, there is
no notification to userland of unsupported features. Check syscall's
attribute flags to let userland know if a feature is supported by the
kernel. This is also needed to distinguish between future kernels what
might support a feature.

Cc: <stable@vger.kernel.org> v3.5..
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120910093018.GO8285@erda.amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

This patch exports the clockticks event and its encoding to user level.
The clockticks event was exported for Nehalem/Westmere but not for Sandy
Bridge (client). Given that it uses a special encoding, it needs to be
exported to user tools, so users can do:

  # perf stat -a -C 0 -e uncore_cbox_0/clockticks/ sleep 1
Signed-off-by: NStephane Eranian <eranian@google.com>
Acked-by: NYan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120829130122.GA32336@quadSigned-off-by: NIngo Molnar <mingo@kernel.org>