Introduced the suspend/resume function for the OMAP4430 internal PHY.
This will be used by the twl6030-usb transceiver driver.
Moved the clock enable/disable function calls and power on/off of the PHY
code from power on/off functions to suspend/resume function.

Pass the suspend function through board data for OMAP4430sdp and OMAP4panda.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: NHema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The secondary interrupt controller of the ColdFire 5249 code is not
setting the edge triggered flow handler. Set it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The m68knommu arch does not define or use IRQ_FLG_LOCK in its irq
subsystem. Remove obsolete use of it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Add missing linker section __modver to fix:

  LD      vmlinux
/usr/local/bin/../m68k-uclinux/bin/ld.real: error: no memory region specified for loadable section `__modver'
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Compiling for 68360 targets gives:

  CC      arch/m68knommu/platform/68360/ints.o
arch/m68knommu/platform/68360/ints.c: In function ‘init_IRQ’:
arch/m68knommu/platform/68360/ints.c:135:16: error: ‘irq’ undeclared (first use in this function)
arch/m68knommu/platform/68360/ints.c:135:16: note: each undeclared identifier is reported only once for each function it appears in

Fix variable name used.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Add an m68k/coldfire optimized memmove() function for the m68knommu arch.
This is the same function as used by m68k. Simple speed tests show this
is faster once buffers are larger than 4 bytes, and significantly faster
on much larger buffers (4 times faster above about 100 bytes).

This also goes part of the way to fixing a regression caused by commit
ea61bc46 ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memmove() fucntion
defined, since there was none in the m68knommu/lib functions.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The m68k arch implements its own memcmp() function. It is not optimized
in any way (it is the most strait forward coding of memcmp you can get).
Remove it and use the kernels standard memcmp() implementation.

This also goes part of the way to fixing a regression caused by commit
ea61bc46 ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memcmp() function
defined, since there is none in the m68knommu/lib functions.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

task_show_regs used to be a debugging aid in the early bringup days
of Linux on s390. /proc/<pid>/status is a world readable file, it
is not a good idea to show the registers of a process. The only
correct fix is to remove task_show_regs.
Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The "Type 2" SMBIOS record that contains Board Name is not
strictly required and may be absent in the SMBIOS on some
platforms.

( Please note that Type 2 is not listed in Table 3 in Sec 6.2
  ("Required Structures and Data") of the SMBIOS v2.7
  Specification. )

Use the Manufacturer Name (aka System Vendor) name.
Print Board Name only when it is present.

Before the fix:
  (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011
 (ii) oops output:  Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6

After the fix:
  (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011
 (ii) oops output:  Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6
Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Cc: <stable@kernel.org> # .3x - good for debugging, please apply as far back as it applies cleanly
LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

mp_find_ioapic() prints errors like:

    ERROR: Unable to locate IOAPIC for GSI 13

if it can't find the IOAPIC that manages that specific GSI. I
see errors like that at every boot of a laptop that apparently
doesn't have any IOAPICs.

But if there are no IOAPICs it doesn't seem to be an error that
none can be found. A solution that gets rid of this message is
to directly return if nr_ioapics (still) is zero. (But keep
returning -1 in that case, so nothing breaks from this change.)

The call chain that generates this error is:

pnpacpi_allocated_resource()
    case ACPI_RESOURCE_TYPE_IRQ:
        pnpacpi_parse_allocated_irqresource()
            acpi_get_override_irq()
                 mp_find_ioapic()
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

We use it in non __cpuinit code now too so drop marker.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
LKML-Reference: <20110211171754.GA21047@aftab>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

commit a3c08e5d(x86: Convert irq_chip access to new functions)
accidentally zapped desc = irq_to_desc(irq); in the vector loop.
So we lock some random irq descriptor.

Add it back.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <stable@kernel.org> # .37

Fix this deadlock - we are already holding the mutex:

=======================================================
[ INFO: possible circular locking dependency detected ] 2.6.38-rc4-test+ #1
-------------------------------------------------------
bash/1850 is trying to acquire lock:
 (text_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f

but task is already holding lock:
 (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (smp_alt){+.+...}:
       [<ffffffff81082d02>] lock_acquire+0xcd/0xf8
       [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339
       [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
       [<ffffffff8101050f>] alternatives_smp_switch+0x77/0x1d8
       [<ffffffff81926a6f>] do_boot_cpu+0xd7/0x762
       [<ffffffff819277dd>] native_cpu_up+0xe6/0x16a
       [<ffffffff81928e28>] _cpu_up+0x9d/0xee
       [<ffffffff81928f4c>] cpu_up+0xd3/0xe7
       [<ffffffff82268d4b>] kernel_init+0xe8/0x20a
       [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10

-> #1 (cpu_hotplug.lock){+.+.+.}:
       [<ffffffff81082d02>] lock_acquire+0xcd/0xf8
       [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339
       [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
       [<ffffffff810568cc>] get_online_cpus+0x41/0x55
       [<ffffffff810a1348>] stop_machine+0x1e/0x3e
       [<ffffffff819314c1>] text_poke_smp_batch+0x3a/0x3c
       [<ffffffff81932b6c>] arch_optimize_kprobes+0x10d/0x11c
       [<ffffffff81933a51>] kprobe_optimizer+0x152/0x222
       [<ffffffff8106bb71>] process_one_work+0x1d3/0x335
       [<ffffffff8106cfae>] worker_thread+0x104/0x1a4
       [<ffffffff810707c4>] kthread+0x9d/0xa5
       [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10

-> #0 (text_mutex){+.+.+.}:

other info that might help us debug this:

6 locks held by bash/1850:
 #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
 #1:  (s_active#75){.+.+.+}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
 #2:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
 #3:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
 #4:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f
 #5:  (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f

stack backtrace:
Pid: 1850, comm: bash Not tainted 2.6.38-rc4-test+ #1
Call Trace:

 [<ffffffff81080eb2>] print_circular_bug+0xa8/0xb7
 [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43
 [<ffffffff81010302>] alternatives_smp_unlock+0x3d/0x93
 [<ffffffff81010630>] alternatives_smp_switch+0x198/0x1d8
 [<ffffffff8102568a>] native_cpu_die+0x65/0x95
 [<ffffffff818cc4ec>] _cpu_down+0x13e/0x202
 [<ffffffff8117a619>] sysfs_write_file+0x108/0x144
 [<ffffffff8111f5a2>] vfs_write+0xac/0xff
 [<ffffffff8111f7a9>] sys_write+0x4a/0x6e
Reported-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: mathieu.desnoyers@efficios.com
Cc: rusty@rustcorp.com.au
Cc: ananth@in.ibm.com
Cc: masami.hiramatsu.pt@hitachi.com
Cc: fweisbec@gmail.com
Cc: jbeulich@novell.com
Cc: jbaron@redhat.com
Cc: mhiramat@redhat.com
LKML-Reference: <1297458466.5226.93.camel@laptop>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The ptrace debug information register was advertising breakpoint and
watchpoint resources for unsupported debug architectures. This meant
that setting breakpoints on these architectures would appear to succeed,
although they would never fire in reality.

This patch fixes the breakpoint slot probing so that it returns 0 when
running on an unsupported debug architecture.
Reported-by: NUlrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Reading baseline CP14 registers, other than DBGDIDR, when the OS Lock
is set leads to UNPREDICTABLE behaviour.

This patch ensures that we clear the OS lock before accessing anything
other than the DBGDIDR, thereby avoiding this behaviour.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

locomo_info isn't actually used as a platform_data on collie platform:
 arm/mach-sa1100/collie.c:237: warning: ‘locomo_info’ defined but not used

So locomo driver doesn't setup IRQs correctly. Pass locomo_info to the
driver.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

rmk says: "You might as well make OABI_COMPAT depend on !THUMB2_KERNEL.
OABI userland is useless without FPA support."

nwfpe doesn't work with Thumb-2 anyway and will probably never get
ported, so I can't argue with that.

This patch implements the dependency change.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Previously we were relying on it being pulled in by other headers for
the prototype of s3c24xx_irq_suspend() and s3c24xx_irq_resume().
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch cleans following up.
- Moved definition of System MMU IPNUM into mach/sysmmu.h
- Removed useless SYSMMU_DEBUG configuration
- Removed useless header file plat/sysmmu.h
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The 's5pv310_device_sysmmu' is used on SMDKV310. But since it is not
compiled now, there is a build error. To fix this compilation error,
S5PV310_DEV_SYSMMU needs to be selected for SMDKV310 board.
This patch enables System MMU support on SMDKV310.
Signed-off-by: NThomas Abraham <thomas.ab@samsung.com>
[kgene.kim@samsung.com: Adding description]
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Since tail is the previous fp - 1, we need to compare the new fp with tail + 1
to ensure that we don't end up passing in the same tail again, in order to
avoid a potential infinite loop in the perf interrupt handler (which has been
observed to occur).  A similar fix seems to be needed in the OProfile code.
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With certain configurations, we inline the unlock functions in modules,
which results in SMP alternatives being created in modules.  We need to
fix those up when loading a module to prevent undefined instruction
faults.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

SWP emulation requires that CPU domain support is disabled in order to
work safely.  Make that explicit in the kernel configuration to prevent
illegal configurations being generated.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Additionally doing things conditionally upon smp_processor_id()
being zero is generally a bad idea, as this means CPU 0 cannot
be offlined and brought back online later again.

While there may be other places where this is done, I think adding
more of those should be avoided so that some day SMP can really
become "symmetrical".
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
LKML-Reference: <4D525C7E0200007800030EE1@vpn.id2.novell.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which
when they include support for SMP kernels means that the resulting
kernel is unsafe on SMP and can result in corrupted filesystems as we
end up using unsafe bitops.

Re-enable the use of V6K instructions on such kernels, and let such
kernels running on V6 CPUs eat undefined instruction faults which will
be much safer than filesystem corruption.  Next merge window we can fix
this properly (as it requires a much bigger set of changes.)
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The gs_index loading code uses the swapgs instruction to
switch to the user gs_base temporarily. This is unsave in an
lightweight exit-path in KVM on AMD because the
KERNEL_GS_BASE MSR is switches lazily. An NMI happening in
the critical path of load_gs_index may use the wrong GS_BASE
value then leading to unpredictable behavior, e.g. a
triple-fault.

This patch fixes the issue by making sure that load_gs_index
is called only with a valid KERNEL_GS_BASE value loaded in
KVM.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Reported-and-tested-by: NSven Neumann <s.neumann@raumfeld.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The use of wrong SD detect pin was introduced by this commit:

  ARM: pxa: Push Colibri evalboard MFP into module files

This fixes it.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Since mfpr_mmio_base[0] is not always valid on later SoCs,
fixed mpfr_sync() to read back from valid mfp offset always.
Signed-off-by: NYu Tang <ytang5@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The _TIF_WORK_MASK definition was removed in the clean up of MMU and
non-MMU arch/m68k/include/asm/thread_info*.h files (this was commit
cddafa35, "merge MMU and non-MMU
thread_info.h").

It didn't get cleaned out of the entry.S code for the 68328 and 68360
based platforms. And it was replaced by a hard coded constant mask for
coldfire platforms. There is currently no need to mask any of these bits,
so fix all uses (and former uses) to check for any non-zero value.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix msr instructions detection. The current code
just use msrclr for loading msr content and compare
it with proper MSR content. If msrclr is not implemented
r8 contains pc address.
Previous code wanted to use MSR carry bit but if msrclr
wasn't implemented carry wasn't cleared.
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Do not disable irq in asm but use irq macros.
Systems with MSR=0 couldn't use pte_update function
because msrclr was hardcoded.
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Microblaze ASM doesn't support hex values for mfs instructions.

/tmp/ccwiXVmt.s: Assembler messages:
/tmp/ccwiXVmt.s:19: Warning: ignoring operands: x00
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Patch: Fix IRQ flag handling naming
(sha1: f9ee29270c11dba7d0fe0b83ce47a4d8e8d2101)
introduced problem on system with MSR=0.
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We reserve lowmem for the things that need it, like the ACPI
wakeup code, way early to guarantee availability.  This happens
before we set up the proper pagetables, so set_memory_x() has no
effect.

Until we have a better solution, use an initcall to mark the
wakeup code executable.
Originally-by: NMatthieu Castet <castet.matthieu@free.fr>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Matthias Hopf <mhopf@suse.de>
Cc: rjw@sisk.pl
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <4D4F8019.2090104@zytor.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Spinlocks on shared processor partitions use H_YIELD to notify the
hypervisor we are waiting on another virtual CPU. Unfortunately this means
the hcall tracepoints can recurse.

The patch below adds a percpu depth and checks it on both the entry and
exit hcall tracepoints.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@kernel.org

When converting to the new cpumask code I screwed up:

-       if (cpu_isset(cpu, numa_cpumask_lookup_table[node])) {
-               cpu_clear(cpu, numa_cpumask_lookup_table[node]);
+       if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
+               cpumask_set_cpu(cpu, node_to_cpumask_map[node]);

This was introduced in commit 25863de0 (powerpc/cpumask: Convert NUMA code
to new cpumask API)

Fix it.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

There is no need to start up the timer and monitor topology changes on a
dedicated processor partition, so disable it.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>