When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
noticed a warning about the asm operand for test_bit in kprobes'
can_boost.  I discovered that this caused only the first long of
twobyte_is_boostable[] to be output.

Jakub filed and fixed gcc PR50571 to correct the warning and this output
issue.  But to solve it for less current gcc, we can make kprobes'
twobyte_is_boostable[] non-const, and it won't be optimized out.

Before:

    CC      arch/x86/kernel/kprobes.o
  In file included from include/linux/bitops.h:22:0,
                   from include/linux/kernel.h:17,
                   from [...]/arch/x86/include/asm/percpu.h:44,
                   from [...]/arch/x86/include/asm/current.h:5,
                   from [...]/arch/x86/include/asm/processor.h:15,
                   from [...]/arch/x86/include/asm/atomic.h:6,
                   from include/linux/atomic.h:4,
                   from include/linux/mutex.h:18,
                   from include/linux/notifier.h:13,
                   from include/linux/kprobes.h:34,
                   from arch/x86/kernel/kprobes.c:43:
  [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
  [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
        without lvalue in asm operand 1 is deprecated [enabled by default]

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 00 00 00 00 	bt     %eax,0x0
                          554: R_386_32	.rodata.cst4

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
  Contents of section .rodata.cst4:
   0000 4c030000                             L...

Only a single long of twobyte_is_boostable[] is in the object file.

After, without the const on twobyte_is_boostable:

  $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
       551:	0f a3 05 20 00 00 00 	bt     %eax,0x20
                          554: R_386_32	.data

  $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o

  arch/x86/kernel/kprobes.o:     file format elf32-i386

  Contents of section .data:
   0000 48000000 00000000 00000000 00000000  H...............
   0010 00000000 00000000 00000000 00000000  ................
   0020 4c030000 0f000200 ffff0000 ffcff0c0  L...............
   0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77  ....;.......&..w

Now all 32 bytes are output into .data instead.
Signed-off-by: NJosh Stone <jistone@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Markers have removed already twice:

1: fc537766
2: eb878b3b

But a little bit is still here.
Signed-off-by: NTkhai Kirill <tkhai@yandex.ru>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add missing return statement. The docs say that the level 4 PSC IRQs
relate to MACE DMA and SCC. Since those drivers don't call
mac_irq_pending() this patch has no affect. But it should be fixed all the
same, since it can be useful for MACE debugging.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The algorithm described in the comment compares two reads from the RTC but
the code actually reads once and compares the result to an uninitialized
value. This causes the compiler to warn, "last_result maybe used
uninitialized". Make the code match the comment, fix the warning and
perhaps improve reliability. Tested on a Quadra 700.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Commit 4b239f45 ("x86-64, mm: Put early page table high") causes a S4
regression since 2.6.39, namely the machine reboots occasionally at S4
resume.  It doesn't happen always, overall rate is about 1/20.  But,
like other bugs, once when this happens, it continues to happen.

This patch fixes the problem by essentially reverting the memory
assignment in the older way.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Yinghai Lu <yinghai.lu@oracle.com>
[ We'll hopefully find the real fix, but that's too late for 3.1 now ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The problem is related to the early enabling of interrupts and the
per cpu timer setup before the cpu is marked online. This doesn't
need to be done in order to call calibrate_delay().

calibrate_delay() monitors jiffies, which are updated from the CPU
which is waiting for the new CPU to set the online bit.

So simply calibrate_delay() can be called on the new CPU just from
the interrupt disabled region and move the local timer setup after
stored the cpu data and before enabling interrupts.

This solves both the cpu_online vs. cpu_active problem and the
affinity setting of the per cpu timers.
Signed-off-by: NThomas Gleinxer <tglx@linutronix.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows mapping external memory such as SRAM for use.

This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If two requests have been submitted and one of them is running, if you
call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time
between the spin_lock_irqsave() and the _state() check in which the
running transaction may finish.  In that case, we don't receive the
interrupt (because they are disabled), but _start() sees that the DMA
is stopped, so it starts it.  The problem is that it sends the
transaction that has just finished again, because pl330_update()
hasn't mark it as done yet.

This patch fixes this race condition by not calling _start() if the
DMA is already executing transactions.  When interrupts are reenabled,
pl330_update() will call _start().

Reference: <1317892206-3600-1-git-send-email-javi.merino@arm.com>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Acked-by: NJassi Brar <jassi.brar@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

v2:
- register_syscore_ops(&s3c24xx_irq_syscore_ops) does not need to be
  conditionally compiled out, it is already optimized out on !CONFIG_PM
- fix also s3c2412 and s3c2416 affected by the same build issue

v1:
s3c2440.c fails to build if !CONFIG_PM because in such case
s3c2410_pm_syscore_ops is not defined. Same error should happen also
in s3c2410.c and s3c2442.c
Signed-off-by: NDomenico Andreoli <cavokz@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Offsets of the irq controller registers were calculated
correctly only for first GPIO bank. This patch fixes
calculation of the register offsets for all GPIO banks.
Reported-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Rather than clipping the number of CPUs using the compile-time NR_CPUS
constant, use the runtime nr_cpu_ids value instead.  This allows the
nr_cpus command line option to work as expected.

Cc: <stable@kernel.org>
Reported-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Upon adding new board LL debug support, if the resultant code
addition would not cause PC relative offset of "hexbuf" from
"adr r2, hexbuf" (+2) instruction to be representable in a
shifted 8-bit value (hence indirectly putting higher aligment
requirement on larger offsets), following error occurs,

arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:138: Error: invalid constant (428) after fixup

Fix it by bringing "hexbuf" closer so that "adr"
can have the offset.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently no type of alignment is specified for PCI expansion roms while 
parsing the openfirmware tree. This causes calls to pci_map_rom() to fail.
IORESOURCE_SIZEALIGN is the default alignment used for rom resouces in 
pci/probe.c, and has been verified to work with various cards on a ultra 10.
Signed-off-By: NKjetil Oftedal <oftedal@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Per Ian Campbell suggestion to defend against future breakage
in case we expand the P2M values, incorporate the defines
in the string array.
Suggested-by: NIan Campbell <Ian.Campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We could be referencing the last + 1 element of level_name[]
array which would cause a pointer exception, because of the
initial setup of lvl=4.

[v1: No need to do this for type_name, pointed out by Ian Campbell]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We get:
linux/arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
linux/arch/x86/xen/enlighten.c:226: warning: ‘cx’ may be used uninitialized in this function
linux/arch/x86/xen/enlighten.c:240: note: ‘cx’ was declared here

and the cx is really not set but passed in the xen_cpuid instruction
which masks the value with returned masked_ecx from cpuid. This
can potentially lead to invalid data being stored in cx.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There are three different modes: PV, HVM, and initial domain 0. In all
the cases we would return -1 for failure instead of a proper error code.
Fix this by propagating the error code from the generic IRQ code.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add vision_ep9307, rwi_ews, usb_a9g20, karo, apf9328, tx37, tx25,
tx51, mx51_m2id, pca101, gplugd, smdk4212 and smdk4412.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add a private iommu pointer to the ARM-specific arch data in the
device struct, which will be used to attach iommu-specific data
to devices which require iommu support.

Different iommu implementations (on different platforms) will attach
different types of data to this pointer, so 'void *' is currently used
(the downside is reduced typesafety).

Note: ia64, x86 and sparc have this exact iommu extension as well, and
if others are likely to adopt it too, we might want to consider
adding this to the device struct itself directly.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The 64bit division functions never had unwinding annotations
added. This prevents a backtrace from being printed within
the function and if a division by 0 occurs. Add the annotations.
Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Get rid of this complaint from dash:

    AS      arch/arm/boot/compressed/lib1funcs.o
  /bin/sh: 1: [: y: unexpected operator
    LD      arch/arm/boot/compressed/vmlinux
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This resolves the following sparse warning from readl() and other macros,
which ends up embedding readl_relaxed() using the same variable.

arch/arm/mach-tegra/dma.c:169:8: warning: symbol '__v' shadows an earlier one
arch/arm/mach-tegra/dma.c:169:8: originally declared here
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This exposes the PB1176 ROM if you compile in the MTD physmap
mapping and also the map_rom chiptype.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This copy really don't need to do at the very second before the kernel
would crash.
Signed-off-by: NLei Wen <leiwen@marvell.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The Cache Type Register L1Ip field identifies I-caches with a PIPT
policy using the encoding 11b.

This patch extends the cache policy parsing to identify PIPT I-caches
correctly and prevent them from being treated as VIPT aliasing in cases
where they are sufficiently large.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Get rid of the mdesc pointer in the fixup function call.  No one uses
the mdesc pointer, it shouldn't be modified anyway, and we can't wrap
it, so let's remove it.

Platform files found by:

  $ regexp=$(git grep -h '\.fixup.*=' arch/arm |
		sed 's!.*= *\([^,]*\),* *!\1!' | sort -u |
		tr '\n' '|' | sed 's,|$,,;s,|,\\|,g')
  $ git grep $regexp arch/arm
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

ARM uses its own BUG() handler which makes its output slightly different
from other archtectures.

One of the problems is that the ARM implementation doesn't report the function
with the BUG() in it, but always reports the PC being in __bug(). The generic
implementation doesn't have this problem.

Currently we get something like:

kernel BUG at fs/proc/breakme.c:35!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
PC is at __bug+0x20/0x2c

With this patch it displays:

kernel BUG at fs/proc/breakme.c:35!
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
...
PC is at write_breakme+0xd0/0x1b4

This implementation uses an undefined instruction to implement BUG, and sets up
a bug table containing the relevant information. Many versions of gcc do not
support %c properly for ARM (inserting a # when they shouldn't) so we work
around this using distasteful macro magic.

v1: Initial version to replace existing ARM BUG() implementation with something
more similar to other architectures.

v2: Add Thumb support, remove backtrace whitespace output changes. Change to
use macros instead of requiring the asm %d flag to work (thanks to
Dave Martin <dave.martin@linaro.org>)

v3: Remove old BUG() implementation in favor of this one.
Remove the Backtrace: message (will submit this separately).
Use ARM_EXIT_KEEP() so that some architectures can dump exit text at link time
thanks to Stephen Boyd <sboyd@codeaurora.org> (although since we always
define GENERIC_BUG this might be academic.)
Rebase to linux-2.6.git master.

v4: Allow BUGS in modules (these were not reported correctly in v3)
(thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting that.)
Remove __bug() as this is no longer needed.

v5: Add %progbits as the section flags.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Tested-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Update the Integrator defconfig with some sensible defaults:
- Compile a combined image supporting Integrator/AP and
  Integrator/CP, with the core modules CM720, CM920, CM922,
  CM926, CM1020, CM1022 and CM1026 in a single image, this
  works just fine and gives some nice compilation coverage
- NOHZ (tickless) and HRTIMERS turned on
- Compile using EABI, let's assume recent compilers are used
  now (tested using GCC 4.4.1)
- Remove forced 32MiB at command line, the bootloader usually
  knows this better, and my U-Boot patches nowadays make that
  boot loader pass the correct adjusted value
- Enable the MTD Physmap flash driver, so that the changes done
  earlier by Marc Zyngier replacing integrator-flash takes
  effect
- Enable the PL030 RTC driver that has not been default-compiled
  with any config for a while

This has been tested on the real hardware Integrator AP with
both an ARM920T and ARM926EJ-S core module.

Cc: Marc Zyngier <Marc.Zyngier@arm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We already have a clock definition for the 24MHz clock in
the Integrator, use that instead of some unclear defines
from the platform.h header. Also delete the senseless
comment that the file shouldn't be edited, I just edited it
and the world didn't come to an end, so it's obviously
false. If anyone still has the mentioned ".s file" and the
s2h awk script generating that header, raise your hand
(and give me your files).
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Drop mult, shift and delta calculations and let the
clockevent core scale this as appropriate.

Set the minimum interval to 1 rather than 15 (0xf), there
is nothing in the data sheets I have indicating that 15
should be some minimum value.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The Integrator AP timer has no problem supporting oneshot
ticks with proper code, so let's do it so we can have
NOHZ configured in for this platform too.

Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

These macros are not used by anything since the switch to
generic time in commit b9cedda2
so let's retire them.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As per request of rmk, the options should be sorted alphabetically.
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the legacy ARM LED code for simpad devices and
register a stadard LED platform device using GPIO line
instead.
Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Register keyboard, polled keyboard and I2C platform
devices based on GPIOs.
Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

- prepend CS3 accessors by simpad_ to indicate they
  are specific to simpad devices.
- use spinlock to protect shadow register.
- implement 8 read-only pins.
- use readl/writel macros so barriers are used where
  necessary.
- register CS3 as GPIO controller with 24 pins
  (16 output only and 8 input only).
- fix PCMCIA driver to access the read-only pins
  rather than the shadow register for status bits.
Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add ucb1x00 GPIO definitions to simpad.h and add gpio_base
to ucb1x00 platform device so the pins are available using
the GPIO API.
Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently, show_regs calls __backtrace which does
nothing if CONFIG_FRAME_POINTER is not set. Switch to
dump_stack which handles both CONFIG_FRAME_POINTER and
CONFIG_ARM_UNWIND correctly.

__backtrace is now superseded by dump_stack in general
and show_regs was the last caller so remove __backtrace
as well.
Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Current Versatile Express CPU hotplug code includes a hardcoded WFI
instruction, in ARM encoding.  When the kernel is compiled in Thumb-2
mode, this is invalid and causes the machine to hang hard when a CPU
is offlined.

Using the wfi macro (which uses the appropriate assembler mnemonic)
causes the correct instruction to be emitted in either case.  As a
consequence of this change, an apparently vestigial "cc" clobber is
dropped from the asm (the macro uses "memory" only).
Signed-off-by: NNick Bowler <nbowler@elliptictech.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When v6 and >=v7 boards are supported in the same kernel, the
__und_usr code currently makes a build-time assumption that Thumb-2
instructions occurring in userspace don't need to be supported.
Strictly speaking this is incorrect.

This patch fixes the above case by doing a run-time check on the
CPU architecture in these cases.  This only affects kernels which
support v6 and >=v7 CPUs together: plain v6 and plain v7 kernels
are unaffected.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Reviewed-by: NJon Medhurst <tixy@yxit.co.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>