gas used to accept (and ignore?) .size directives which referred to
undefined symbols, as this does.  In binutils 2.21 these are treated
as fatal errors.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

This function is only called by percpu_timer_setup() which is
also __cpuinit marked. Thus it's safe to mark this function as
__cpuinit as well.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ARM user backtrace code can get into an infinite loop if it
runs into an invalid stack frame which points back to itself.
This situation has been observed in practice.  Fix it by capping
the number of entries in the backtrace.  This is also what other
architectures do in their backtrace code.
Signed-off-by: NSonny Rao <sonnyrao@chromium.org>
Acked-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Several Davinci platforms select the I2C EEPROM support, but don't
select I2C support.  This causes I2C EEPROM support to be built into
the kernel, but I2C support may not be configured to be built in.
This leads to linker errors due to missing I2C symbols.

Arrange for I2C to be selected whenever EEPROM_AT24 is selected.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Commit 54ce6883 (davinci: da8xx: add spi
resources and registration routine) wrongly assumed that SPI1 is mapped at
the same address on DA830/OMAP-L137 and DA850/OMAP-L138; actually, the base
address was valid only for the latter SoC. Teach the code to pass the correct
SPI1 memory resource for both SoCs...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Current board configurations involving the MityDSP-L138 and MityARM-1808
only have one attached PHY, but it's address may not be the same.  Default
the behavior to auto-probe for the PHY and use the first one found.
Signed-off-by: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

For the MityDSP-L138/MityARM-1808 SOMS, the NAND controller id (which needs
to correspond to the chipselect, and is used for controlling the HW ECC
computation) is not correct.  Fix it.
Signed-off-by: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Add REGULATOR_CHANGE_STATUS flag to magician bq24022 regulator to enable charging.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Add REGULATOR_CHANGE_STATUS flag to hx4700 bq24022 regulator. Without this
flag the bq24022 cannot be enabled and the battery will not charge.
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Tested-by: NDmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Fixup davinci UART low-level debug code for new ARM generic p2v changes.

Based on OMAP changes by Tony Lindgren

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Fix the following warning:

CC      arch/arm/mach-mx5/board-mx53_loco.o
arch/arm/mach-mx5/board-mx53_loco.c:203: warning: initialization discards qualifiers from pointer target type
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Because of speculative event roll back, it is possible for some event coutners
to decrease between reads on POWER7.  This causes a problem with the way that
counters are updated.  Delta calues are calculated in a 64 bit value and the
top 32 bits are masked.  If the register value has decreased, this leaves us
with a very large positive value added to the kernel counters.  This patch
protects against this by skipping the update if the delta would be negative.
This can lead to a lack of precision in the coutner values, but from my testing
the value is typcially fewer than 10 samples at a time.
Signed-off-by: NEric B Munson <emunson@mgebm.net>
Cc: stable@kernel.org
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This problem was noticed on an MPC855T platform. Ftrace did oops
when trying to write to the kernel text segment.

Many thanks to Joakim for finding the root cause of this problem.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

We currently enable interrupts before the dispatch log for the boot
cpu is setup. If a timer interrupt comes in early enough we oops in
scan_dispatch_log:

Unable to handle kernel paging request for data at address 0x00000010

...

.scan_dispatch_log+0xb0/0x170
.account_system_vtime+0xa0/0x220
.irq_enter+0x88/0xc0
.do_IRQ+0x48/0x230

The patch below adds a check to scan_dispatch_log to ensure the
dispatch log has been allocated.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Create a special kmem
cache for DTL buffers with the alignment requirement.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Recent commit b987812b caused
a compile failure on UP because a considerably large block
of the file was included within CONFIG_SMP, hence making a stub
function not exposed on UP builds when it needed to be.

Relocate the stub to the #else /* ! CONFIG_SMP */ section
and also annotate the relevant else/endif so that nobody
else falls into the same trap I did.
Reported-by: NMichael Guntsche <mike@it-loops.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Following commit 091738a2 ("genirq: Remove real old transition
functions") we removed an automatic conversion of no_irq_chip to
dummy_irq_chip.  This change needs to be propagated back into the alpha
backend.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is a new warning in gcc 4.6.  Several of these variables are
used within #if 0 code, which probably ought to be removed.  Most
of the changes are legitimate cleanups.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are outstanding gcc 4.6 warnings that need to be cleaned up
in the subdirectory.  No sense forcing the issue immediately.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Issue manifests as:

In file included from arch/arm/mach-pxa/include/mach/hardware.h:62,
                  from arch/arm/mach-pxa/include/mach/gpio.h:28,
                  from /home/jic23/src/kernel/temp-remove/arch/arm/include/asm/gpio.h:5,
                  from include/linux/gpio.h:7,
                  from drivers/staging/iio/gyro/adis16080_core.c:8:
 /home/jic23/src/kernel/temp-remove/arch/arm/include/asm/cputype.h:57: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'read_cpuid_id'
...
Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
the BIOS forgets to do is (or is just too old). Letting
these errors enabled can cause a sync-flood on the CPU
causing a reboot.

The AMD BKDG recommends disabling GART TLB Wlk Error completely.

This patch is the fix for

	https://bugzilla.kernel.org/show_bug.cgi?id=33012

on my machine.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.orgTested-by: NAlexandre Demers <alexandre.f.demers@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Currently, numa=fake boot parameter is broken. If it's used,
kernel may panic due to devide by zero error depending on CPU
configuration

Call Trace:
 [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
 [<ffffffff81086aff>] ? local_clock+0x6f/0x80
 [<ffffffff81050533>] load_balance+0xa3/0x600
 [<ffffffff81050f53>] idle_balance+0xf3/0x180
 [<ffffffff81550092>] schedule+0x722/0x7d0
 [<ffffffff81550538>] ? wait_for_common+0x128/0x190
 [<ffffffff81550a65>] schedule_timeout+0x265/0x320
 [<ffffffff81095815>] ? lock_release_holdtime+0x35/0x1a0
 [<ffffffff81550538>] ? wait_for_common+0x128/0x190
 [<ffffffff8109bb6c>] ? __lock_release+0x9c/0x1d0
 [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
 [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
 [<ffffffff81550540>] wait_for_common+0x130/0x190
 [<ffffffff81051920>] ? try_to_wake_up+0x510/0x510
 [<ffffffff8155067d>] wait_for_completion+0x1d/0x20
 [<ffffffff8107f36c>] kthread_create_on_node+0xac/0x150
 [<ffffffff81077bb0>] ? process_scheduled_works+0x40/0x40
 [<ffffffff8155045f>] ? wait_for_common+0x4f/0x190
 [<ffffffff8107a283>] __alloc_workqueue_key+0x1a3/0x590
 [<ffffffff81e0cce2>] cpuset_init_smp+0x6b/0x7b
 [<ffffffff81df3d07>] kernel_init+0xc3/0x182
 [<ffffffff8155d5e4>] kernel_thread_helper+0x4/0x10
 [<ffffffff81553cd4>] ? retint_restore_args+0x13/0x13
 [<ffffffff81df3c44>] ? start_kernel+0x400/0x400
 [<ffffffff8155d5e0>] ? gs_change+0x13/0x13

The divede by zero is caused by the following line,
group->cpu_power==0:

 kernel/sched_fair.c::update_sg_lb_stats()
        /* Adjust by relative CPU power of the group */
        sgs->avg_load = (sgs->group_load * SCHED_LOAD_SCALE) / group->cpu_power;

This regression was caused by commit e23bba60 ("x86-64, NUMA: Unify
emulated distance mapping") because it changes cpu -> node
mapping in the process of dropping fake_physnodes().

  old) all cpus are assinged node 0
  now) cpus are assigned round robin
       (the logic is implemented by numa_init_array())

  Note: The change in behavior only happens if the system doesn't
        have neither ACPI SRAT table nor AMD northbridge NUMA
	information.

Round robin assignment doesn't work because init_numa_sched_groups_power()
assumes all logical cpus in the same physical cpu share the same node
(then it only accounts for group_first_cpu()), and the simple round robin
breaks the above assumption.

Thus, this patch implements a reassignment of node-ids if buggy firmware
or numa emulation makes wrong cpu node map. Tt enforce all logical cpus
in the same physical cpu share the same node.
Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: NTejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Shaohui Zheng <shaohui.zheng@intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/20110415203928.1303.A69D9226@jp.fujitsu.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Add syscalls for name_to_handle_at, open_by_handle_at, clock_adjtime
and syncfs.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 8a5ec0ba "Lockless (and preemptless) fastpaths for slub" makes use
of this_cpu_cmpxchg_double() which needs this_cpu_cmpxchg16b_emu() on
x86_64.  Implementing cmpxchg16b emulation for UML would introduce too
much complexity.  So just disable it.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reported-by: NSergei Trofimovich <slyich@gmail.com>
Acked-by: NPekka Enberg <penberg@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 1de1502c ("x86, um: now we can get rid of trivial uml headers")
removed accidentally bug.h which broke UML's call tracer and bug
handler.

Without asm-generic/bug.h UML uses BUG() from arch/x86/ which makes use
of ud2.  UML cannot use ud2, it raises SIGILL in user mode.  As UML has
a different stack for handling signals the call trace will be cut off.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reported-by: NSergei Trofimovich <slyich@gmail.com>
Tested-by: NSergei Trofimovich <slyich@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix a possible problem with mport registration left non-cleared after
fsl_rio_setup() exits on link error.  Abort mport initialization if
registration failed.

This patch is applicable to 2.6.39-rc1 only.  The problem does not exist
for earlier versions.
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are optional bits that may complement a personality ID.  It is
therefore wrong to simply test against the absolute current->personality
value to determine the effective personality.  The PER_LINUX_32BIT is
itself just PER_LINUX with one of those optional bits set.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Our SET_PERSONALITY() implementation was overwriting all existing
personality flags, including ADDR_NO_RANDOMIZE, making them unavailable
to processes being exec'd after a call to personality() in user space.
This prevents the gdb test suite from running successfully.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This config option isn't actually used anywhere and can be safely
removed. The last user was traps.c before commit 082f47a7 ([ARM]
always allow dump_stack() to produce a backtrace, 2007-07-05).
Reviewed-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

s3c_pm_show_resume_irqs() is used by some s3c_pm_arch_show_resume_irqs()
implementations, which get included through mach/pm-core.h. Add __maybe_unused
to silence warnings when it isn't used (e.g. on S3C64XX platforms).
Signed-off-by: NMaurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch fixes build error that occurs on enabling the Samsung
specific PM CRC check code. Missed removing this reference of
s3c_sleep_save_phys during move to generic cpu suspend/resume
support.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The s3c_pm_check_resume_pin() is not being used and can be safely
removed to fix the build warning.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The recent commit (10774912647781) wasn't entirely correct.  While
it fixed some issues, it introduced others.  So pull in the fixes
from the public cache flush functions, and document why we need to
call things directly ourselves.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

If the period of a gptimer is fairly low, we might miss an interrupt
by acking it too late (we end up acking the new int as well).
Reported-by: NIsabelle Leonardi <i.leonardi@detracom.fr>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

We only want to clear the run bit for this one timer, not all status bits.
So don't read the whole reg and then write all the bits back out.
Reported-by: NIsabelle Leonardi <i.leonardi@detracom.fr>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

When suspending/resuming, the common task freezing code will run in
parallel and freeze processes on each core.  This is because the code
uses the non-smp version of memory barriers (as well it should).

The Blackfin smp barrier logic at the moment contains the cache sync
logic, but the non-smp barriers do not.  This is incorrect as Rafel
summarized:
> ...
> The existing memory barriers are SMP barriers too, but they are more
> than _just_ SMP barriers.  At least that's how it is _supposed_ to be
> (eg. rmb() is supposed to be stronger than smp_rmb()).
> ...
> However, looking at the blackfin's definitions of SMP barriers I see
> that it uses extra stuff that should _also_ be used in the definitions
> of the mandatory barriers.
> ...

URL: http://lkml.org/lkml/2011/4/13/11
LKML-Reference: <BANLkTi=F-C-vwX4PGGfbkdTBw3OWL-twfg@mail.gmail.com>
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Disable USB_ARCH_HAS_EHCI in arch Kconfig and enable it in usb Kconfig

Warning log:
warning: (MICROBLAZE) selects USB_ARCH_HAS_EHCI which has unmet
direct dependencies (USB_SUPPORT)
Signed-off-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>