Remove i2c_board_info for driver that doesn't exist anymore.
Delete irq_flags for drivers that don't use them anymore.

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

There is already an entry in the spi device table for the codec, but the
modalias was wrong.  Also the config symbol name for the codec is wrong,
so this is fixed as well.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

This header was being rewritten while the asm-generic kbuild support
was in flight, so it missed out on the update.  Punt the stub and use
the kbuild now that everything has settled.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

SND_BF5XX_SOC is for machine drivers while SND_SOC is for codec drivers.

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

The ASoC codec name is "ad1836" and not "ad183x" as the change to rename
things ultimately did not get merged.

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

__kfree_rcu() in rcupdate.h bugs when parameter offset is not a constant
at compile time.  Since we build the kgdb_test module with -O0 and it
includes this header file, we hit the bug.  So drop the -O0 and mark the
one func we need for the test as noinline (so we can set a breakpoint on
it and have it be hit).

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

 Fix argument types for copy_to_user.
 Fix following sparse warnings:
 arch/blackfin/include/asm/uaccess.h:198:14: warning: incorrect type
in argument 2 (different address spaces)
 arch/blackfin/include/asm/uaccess.h:198:14:    expected void const *s
 arch/blackfin/include/asm/uaccess.h:198:14:    got void const
[noderef] <asn:1>*from
 arch/blackfin/include/asm/uaccess.h:208:14: warning: incorrect type
in argument 2 (different address spaces)
 arch/blackfin/include/asm/uaccess.h:208:14:    expected void const *s
 arch/blackfin/include/asm/uaccess.h:208:14:    got void const
[noderef] <asn:1>*from

Signed-off-by: Mikhail Gruzdev <michail.gruzdev@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Make sure our smp_send_reschedule() implementation matches the
scheduler_ipi() callback so that it can kick the idle cpu.

Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

IRQF_SHARED is not part of the IORESOURCE_IRQ bits. It's expressed by
IORESOURCE_IRQ_SHAREABLE.

IORESOURCE_IRQ_HIGHEDGE and IRQF_TRIGGER_HIGH are contradicting
values, an interrupt can hardly be configured for both level and edge
at the same time. This was introduced in commit 45138439(Blackfin
arch: flash memory map and dm9000 resources updating) of course
without any hint in the changelog what the heck this is supposed to
do.

Acked-by: Javier Herrero <jherrero@hvsistemas.es>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Now that common code supports SMP systems, switch our SMP atomic logic
over to it to avoid code duplication.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

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: Josh 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: Linus Torvalds <torvalds@linux-foundation.org>

Markers have removed already twice:

1: fc537766
2: eb878b3b

But a little bit is still here.

Signed-off-by: Tkhai Kirill <tkhai@yandex.ru>
Signed-off-by: Geert 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: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert 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: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert 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: Takashi 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: Linus 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: Thomas Gleinxer <tglx@linutronix.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell 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: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell 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: Javi Merino <javi.merino@arm.com>
Acked-by: Jassi Brar <jassi.brar@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This change adds support for the sh7372 A4R power domain.

The sh7372 A4R hardware power domain contains the
SH CPU Core and a set of I/O devices including
multimedia accelerators and I2C controllers.

One special case about A4R is the INTCS interrupt
controller that needs to be saved and restored to
keep working as expected. Also the LCDC hardware
blocks are in a different hardware power domain
but have their IRQs routed only through INTCS. So
as long as LCDCs are active we cannot power down
INTCS because that would risk losing interrupts.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

This change adds support for the sh7372 A3SP power domain.

The sh7372 A3SP hardware power domain contains a
wide range of I/O devices. The list of I/O devices
include SCIF serial ports, DMA Engine hardware,
SD and MMC controller hardware, USB controllers
and I2C master controllers.

This patch adds the A3SP low level code which
powers the hardware power domain on and off. It
also ties in platform devices to the pm domain
support code.

It is worth noting that the serial console is
hooked up to SCIFA0 on most sh7372 boards, and
the SCIFA0 port is included in the A3SP hardware
power domain. For this reason we cannot output
debug messages from the low level power control
code in the case of A3SP.

QoS support is needed in drivers before we can
enable the A3SP power control on the fly.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

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: Domenico Andreoli <cavokz@gmail.com>
Signed-off-by: Kukjin 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: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>

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: Mark Salter <msalter@redhat.com>
Signed-off-by: Russell 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: Afzal Mohammed <afzal@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell 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: Kjetil Oftedal <oftedal@gmail.com>
Signed-off-by: David 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: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Konrad 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: Konrad 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: Konrad 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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Create common extern definitions of _rambase, _ramstart and _ramend
instead of them being externed when used in code.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>

We do not need to have local extern declarations of memory_start and
memory_end in mm/init_no.c. There are declarations already in asm/page_no.h.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>

We should be including and using sections.h to get at the extern
definitions of the linker sections in the m68knommu mm init code.
Not defining them locally.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>

We should be including and using sections.h to get at the extern
definitions of the linker sections in the m68knommu startup code.
Not defining them locally.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>

The code for handling traps in the non-mmu case is a subset of the mmu
enabled case. Merge the non-mmu traps_no.c code back to a single traps.c.
There is actually no code mmu specific here at all, and the processor
specific code (for the more complex 68020/68030/68040/68060) is already
proplerly conditionaly used.

The format of console exception dump is a little different, but I don't
think will cause any one problems, it is purely for debug purposes.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>