md/raid5: add missing spin_lock_init.

commit b17459c05000fdbe8d10946570a26510f86ec0f
   raid5: add a per-stripe lock

added a spin_lock to the 'stripe_head' struct.
Unfortunately there are two places where this struct is allocated
but the spin lock was only initialised in one of them.

So add the missing spin_lock_init.

Signed-off-by: NeilBrown <neilb@suse.de>
ARM: dma-mapping: Fix potential memory leak in atomic_pool_init()

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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
c6x: use asm-generic/barrier.h

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: Mark Salter <msalter@redhat.com>
gpio-lpc32xx: Fix value handling of gpio_direction_output()

For GPIOs of gpio-lpc32xx, gpio_direction_output() ignores the value argument
(initial value of output). This patch fixes this by setting the level
accordingly.

Cc: stable@kernel.org
Signed-off-by: Roland Stigge <stigge@antcom.de>
Acked-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
i3200_edac: Fix memory rank size

commit a895bf8b1e1ea4c032a8fa8a09475a2ce09fe77a incorrectly
changed the logic that fills the memory bank size. Fix it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
i5000: Fix the memory size calculation with 2R memories

When 2R memories are found, the memory size should be multiplied
by two, otherwise, it will report half of the memory size:

       +-----------------------------------------------+
       |                      mc0                      |
       |        branch0        |        branch1        |
       | channel0  | channel1  | channel0  | channel1  |
-------+-----------------------------------------------+
slot3: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
slot2: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
-------+-----------------------------------------------+
slot1: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
slot0: |  1024 MB  |  1024 MB  |  1024 MB  |  1024 MB  |
-------+-----------------------------------------------+

(the above machine have 4 x 2GB 2R memories)

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
sb_edac: Avoid overflow errors at memory size calculation

Sandy bridge EDAC is calculating the memory size with overflow.
Basically, the size field and the integer calculation is using 32 bits.
More bits are needed, when the DIMM memories have high density.

The net result is that memories are improperly reported there, when
high-density DIMMs are used:

EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 0, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 1, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800

As the number of pages value is handled at the EDAC core as unsigned
ints, the driver shows the 16 GB memories at sysfs interface as 16760832
MB! The fix is simple: calculate the number of pages as unsigned 64-bits
integer.

After the patch, the memory size (16 GB) is properly detected:

EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 0, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 1, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800

Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drm/nouveau: silence a debug message triggered by newer userspace

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nvc0/ltcg: mask off intr 0x10

NVIDIA do that at startup too on Fermi, so perhaps the heap of 0x10
intrs we receive are normal and we can ignore them.

On Kepler NVIDIA *don't* do this, but the hardware appears to come up
with the bit masked off by default - so that's probably why :)

This should silence some interrupt spam seen on Fermi+ boards.

Backported patch from reworked nouveau kernel tree.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

These just silence some printks that we are seeing that we shouldn't

* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nvc0/ltcg: mask off intr 0x10
  drm/nouveau: silence a debug message triggered by newer userspace
vmwgfx: corruption in vmw_event_fence_action_create()

We don't allocate enough data for this struct.  As soon as we start
modifying event->event on the next lines, then we're going beyond the
end of the memory we allocated.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
drm/udl: limit modes to the sku pixel limits.

Otherwise when X starts we commonly get a black screen scanning
out nothing, its wierd dpms on/off from userspace brings it back,

With this on F18, multi-seat works again with my 1920x1200 monitor
which is above the sku limit for the device I have.

Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ASoC: wm2000: Correct register size

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
syscalls: add __NR_kcmp syscall to generic unistd.h

Commit d97b46a64 ("syscalls, x86: add __NR_kcmp syscall" ) added a new
syscall to support checkpoint restore. It is currently x86-only, but
that restriction will be removed in a subsequent patch. Unfortunately,
the kernel checksyscalls script had a bug which suppressed any warning
to other architectures that the kcmp syscall was not implemented. A
patch to checksyscalls is being tested in linux-next and other
architectures are seeing warnings about kcmp being unimplemented.

This patch adds __NR_kcmp to <asm-generic/unistd.h> so that kcmp is
wired in for architectures using the generic syscall list.

Signed-off-by: Mark Salter <msalter@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
MAINTAINERS: update Intel C600 SAS driver maintainers

Cc: Lukasz Dorau <lukasz.dorau@intel.com>
Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreaming

Pull c6x arch fixes from Mark Salter:
  - Add __NR_kcmp to generic syscall list
  - C6X: Use generic asm/barrier.h

* tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreaming:
  syscalls: add __NR_kcmp syscall to generic unistd.h
  c6x: use asm-generic/barrier.h
drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN

PFIFO_INTR = 0x40000000 appears to be a normal case on nvc0/nve0 PFIFO,
the binary driver appears to completely ignore it in its PFIFO interrupt
handler and even masks off the bit (as we do) in PFIFO_INTR_EN at init
time.

The bits still light up in the hardware sometimes though, so lets just
ignore any bits we haven't explicitely requested.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
ARM: Orion5x: Fix too small coherent pool.

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: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Olof Johansson <olof@lixom.net>
md/raid10: fix "enough" function for detecting if array is failed.

The 'enough' function is written to work with 'near' arrays only
in that is implicitly assumes that the offset from one 'group' of
devices to the next is the same as the number of copies.
In reality it is the number of 'near' copies.

So change it to make this number explicit.

This bug makes it possible to run arrays without enough drives
present, which is dangerous.
It is appropriate for an -stable kernel, but will almost certainly
need to be modified for some of them.

Cc: stable@vger.kernel.org
Reported-by: Jakub Husák <jakub@gooseman.cz>
Signed-off-by: NeilBrown <neilb@suse.de>
Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Another spurious dmesg quitening.

* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN