The spi support code works on SPARC too. No reason to exclude it from
the party.
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

CONFIG_HOTPLUG is going away as an option.  As result the __dev*
markings will be going away.

Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.

Bill Pemberton has done most of the legwork on this series. I've used
his script to purge the attributes from the drivers/gpio tree.
Reported-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Linux 3.7-rc8

This patch allows to specify that a SPI device is connected in 3-wire mode via
device tree.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Fix problem discovered with sparse:
+ drivers/spi/spi.c:1554:37: sparse: incompatible types in comparison expression (different signedness)
drivers/spi/spi.c: In function 'spi_write_then_read':
drivers/spi/spi.c:1554:23: warning: comparison of distinct pointer types lacks a cast [enabled by default]

The change to SPI_BUFSIZ was introduced in commit b3a223ee, "spi:
Remove SPI_BUFSIZ restriction on spi_write_then_read()"

Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Support these transfer modes from the SPI layer by setting
the appropriate register bits before doing the transfer.

This was tested on the Marvell kirkwood SOC that uses this driver.
Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Rolf Manderscheid <rvm@obsidianresearch.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

The MSIOF hardware block is used in the SH Mobile series as well, so we
add it here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

clk_get() no longer needs a character string for associating the right
clock as this is done via the device struct now.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).

Since we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

This driver is obsolete and can't even be built anymore since the
platform it depends has been removed.

The STMP series is completely covered by the MXS platform these days, so
spi-mxs can be used instead.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Pull in the changes Mark has queued up for SPI

This patch add new driver for CLPS711X SPI master controller.
Due to platform limitations driver supports only 8 bit transfer mode.
Chip select control is handled via GPIO.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Pull EDAC fixes from Mauro Carvalho Chehab:
 "One EDAC core fix, and a few driver fixes (i7300, i9275x, i7core)."

* git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac:
  i7core_edac: fix panic when accessing sysfs files
  i7300_edac: Fix error flag testing
  edac: Fix the dimm filling for csrows-based layouts
  i82975x_edac: Fix dimm label initialization

Pull media fixes from Mauro Carvalho Chehab:
 "Some driver fixes for s5p/exynos (mostly race fixes)"

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] s5p-mfc: Handle multi-frame input buffer
  [media] s5p-mfc: Bug fix of timestamp/timecode copy mechanism
  [media] exynos-gsc: Add missing video device vfl_dir flag initialization
  [media] exynos-gsc: Fix settings for input and output image RGB type
  [media] exynos-gsc: Don't use mutex_lock_interruptible() in device release()
  [media] fimc-lite: Don't use mutex_lock_interruptible() in device release()
  [media] s5p-fimc: Don't use mutex_lock_interruptible() in device release()
  [media] s5p-fimc: Prevent race conditions during subdevs registration

In commit 9d73fc2d ("open*(2) compat fixes (s390, arm64)") I said:
>
> 	The usual rules for open()/openat()/open_by_handle_at() are
> 1) native 32bit - don't force O_LARGEFILE in flags
> 2) native 64bit - force O_LARGEFILE in flags
> 3) compat on 64bit host - as for native 32bit
> 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for native 64bit
>
> There are only two exceptions - s390 compat has open() forcing O_LARGEFILE and
> arm64 compat has open_by_handle_at() doing the same thing.  The same binaries
> on native host (s390/31 and arm resp.) will *not* force O_LARGEFILE, so IMO
> both are emulation bugs.

Three exceptions, actually - parisc open() is another case like that.
Native 32bit won't force O_LARGEFILE, the same binary on parisc64 will.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This reverts commit 800d4d30.

Between commits 8323f26c ("sched: Fix race in task_group()") and
800d4d30 ("sched, autogroup: Stop going ahead if autogroup is
disabled"), autogroup is a wreck.

With both applied, all you have to do to crash a box is disable
autogroup during boot up, then reboot..  boom, NULL pointer dereference
due to commit 800d4d30 not allowing autogroup to move things, and
commit 8323f26c making that the only way to switch runqueues:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
  Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
  RIP: effective_load.isra.43+0x50/0x90
  Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
  Call Trace:
    select_task_rq_fair+0x255/0x780
    try_to_wake_up+0x156/0x2c0
    wake_up_state+0xb/0x10
    signal_wake_up+0x28/0x40
    complete_signal+0x1d6/0x250
    __send_signal+0x170/0x310
    send_signal+0x40/0x80
    do_send_sig_info+0x47/0x90
    group_send_sig_info+0x4a/0x70
    kill_pid_info+0x3a/0x60
    sys_kill+0x97/0x1a0
    ? vfs_read+0x120/0x160
    ? sys_read+0x45/0x90
    system_call_fastpath+0x16/0x1b
  Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
  RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
   RSP <ffff880221ddfbd8>
  CR2: 0000000000000000
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge 'block-dev' branch.

I was going to just mark everything here for stable and leave it to the
3.8 merge window, but having decided on doing another -rc, I migth as
well merge it now.

This removes the bd_block_size_semaphore semaphore that was added in
this release to fix a race condition between block size changes and
block IO, and replaces it with atomicity guaratees in fs/buffer.c
instead, along with simplifying fs/block-dev.c.

This removes more lines than it adds, makes the code generally simpler,
and avoids the latency/rt issues that the block size semaphore
introduced for mount.

I'm not happy with the timing, but it wouldn't be much better doing this
during the merge window and then having some delayed back-port of it
into stable.

* block-dev:
  blkdev_max_block: make private to fs/buffer.c
  direct-io: don't read inode->i_blkbits multiple times
  blockdev: remove bd_block_size_semaphore again
  fs/buffer.c: make block-size be per-page and protected by the page lock

Pull networking fixes from David Miller:

 1) 8139cp leaks memory in error paths, from Francois Romieu.

 2) do_tcp_sendpages() cannot handle order > 0 pages, but they can
    certainly arrive there now, fix from Eric Dumazet.

 3) Race condition and sysfs fixes in bonding from Nikolay Aleksandrov.

 4) Remain-on-Channel fix in mac80211 from Felix Liao.

 5) CCK rate calculation fix in iwlwifi, from Emmanuel Grumbach.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  8139cp: fix coherent mapping leak in error path.
  tcp: fix crashes in do_tcp_sendpages()
  bonding: fix race condition in bonding_store_slaves_active
  bonding: make arp_ip_target parameter checks consistent with sysfs
  bonding: fix miimon and arp_interval delayed work race conditions
  mac80211: fix remain-on-channel (non-)cancelling
  iwlwifi: fix the basic CCK rates calculation

Pull md bugfix from NeilBrown:
 "Single bugfix for raid1/raid10.

  Fixes a recently introduced deadlock."

* tag 'md-3.7-fixes' of git://neil.brown.name/md:
  md/raid1{,0}: fix deadlock in bitmap_unplug.

The usual rules for open()/openat()/open_by_handle_at() are
 1) native 32bit - don't force O_LARGEFILE in flags
 2) native 64bit - force O_LARGEFILE in flags
 3) compat on 64bit host - as for native 32bit
 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for
    native 64bit

There are only two exceptions - s390 compat has open() forcing
O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same
thing.  The same binaries on native host (s390/31 and arm resp.) will
*not* force O_LARGEFILE, so IMO both are emulation bugs.

Objections? The fix is obvious...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

linux/err.h was included twice.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Fix the below warning
drivers/spi/spi-omap2-mcspi.c:336:34: warning: symbol 'tx' shadows an earlier one
drivers/spi/spi-omap2-mcspi.c:327:12: originally declared here

So delete the u8 tx as it is assigned and not used(resigned afterwards).
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Pull  late workqueue fixes from Tejun Heo:
 "Unfortunately, I have two really late fixes.  One was for a
  long-standing bug and queued for 3.8 but I found out about a
  regression introduced during 3.7-rc1 two days ago, so I'm sending out
  the two fixes together.

  The first (long-standing) one is rescuer_thread() entering exit path
  w/ TASK_INTERRUPTIBLE.  It only triggers on workqueue destructions
  which isn't very frequent and the exit path can usually survive being
  called with TASK_INTERRUPT, so it was hidden pretty well.  Apparently,
  if you're reiserfs, this could lead to the exiting kthread sleeping
  indefinitely holding a mutex, which is never good.

  The fix is simple - restoring TASK_RUNNING before returning from the
  kthread function.

  The second one is introduced by the new mod_delayed_work().
  mod_delayed_work() was missing special case handling for 0 delay.
  Instead of queueing the work item immediately, it queued the timer
  which expires on the closest next tick.  Some users of the new
  function converted from "[__]cancel_delayed_work() +
  queue_delayed_work()" combination became unhappy with the extra delay.

  Block unplugging led to noticeably higher number of context switches
  and intel 6250 wireless failed to associate with WPA-Enterprise
  network.  The fix, again, is fairly simple.  The 0 delay special case
  logic from queue_delayed_work_on() should be moved to
  __queue_delayed_work() which is shared by both queue_delayed_work_on()
  and mod_delayed_work_on().

  The first one is difficult to trigger and the failure mode for the
  latter isn't completely catastrophic, so missing these two for 3.7
  wouldn't make it a disastrous release, but both bugs are nasty and the
  fixes are fairly safe"

* 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay
  workqueue: exit rescuer_thread() as TASK_RUNNING

cp_open
[...]
        rc = cp_alloc_rings(cp);
        if (rc)
                return rc;

cp_alloc_rings
[...]
        mem = dma_alloc_coherent(&cp->pdev->dev, CP_RING_BYTES,
                                 &cp->ring_dma, GFP_KERNEL);

- cp_alloc_rings never frees the coherent mapping it allocates
- neither do cp_open when cp_alloc_rings fails
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Recent network changes allowed high order pages being used
for skb fragments.

This uncovered a bug in do_tcp_sendpages() which was assuming its caller
provided an array of order-0 page pointers.

We only have to deal with a single page in this function, and its order
is irrelevant.
Reported-by: Willy Tarreau <w@1wt.eu>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

8376fe22 ("workqueue: implement mod_delayed_work[_on]()")
implemented mod_delayed_work[_on]() using the improved
try_to_grab_pending().  The function is later used, among others, to
replace [__]candel_delayed_work() + queue_delayed_work() combinations.

Unfortunately, a delayed_work item w/ zero @delay is handled slightly
differently by mod_delayed_work_on() compared to
queue_delayed_work_on().  The latter skips timer altogether and
directly queues it using queue_work_on() while the former schedules
timer which will expire on the closest tick.  This means, when @delay
is zero, that [__]cancel_delayed_work() + queue_delayed_work_on()
makes the target item immediately executable while
mod_delayed_work_on() may induce delay of upto a full tick.

This somewhat subtle difference breaks some of the converted users.
e.g. block queue plugging uses delayed_work for deferred processing
and uses mod_delayed_work_on() when the queue needs to be immediately
unplugged.  The above problem manifested as noticeably higher number
of context switches under certain circumstances.

The difference in behavior was caused by missing special case handling
for 0 delay in mod_delayed_work_on() compared to
queue_delayed_work_on().  Joonsoo Kim posted a patch to add it -
("workqueue: optimize mod_delayed_work_on() when @delay == 0")[1].
The patch was queued for 3.8 but it was described as optimization and
I missed that it was a correctness issue.

As both queue_delayed_work_on() and mod_delayed_work_on() use
__queue_delayed_work() for queueing, it seems that the better approach
is to move the 0 delay special handling to the function instead of
duplicating it in mod_delayed_work_on().

Fix the problem by moving 0 delay special case handling from
queue_delayed_work_on() to __queue_delayed_work().  This replaces
Joonsoo's patch.

[1] http://thread.gmane.org/gmane.linux.kernel/1379011/focus=1379012Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Anders Kaseorg <andersk@MIT.EDU>
Reported-and-tested-by: Zlatko Calusic <zlatko.calusic@iskon.hr>
LKML-Reference: <alpine.DEB.2.00.1211280953350.26602@dr-wily.mit.edu>
LKML-Reference: <50A78AA9.5040904@iskon.hr>
Cc: Joonsoo Kim <js1304@gmail.com>

A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling
off, never to be seen again.  In the case where this occurred, an exiting
thread hit reiserfs homebrew conditional resched while holding a mutex,
bringing the box to its knees.

PID: 18105  TASK: ffff8807fd412180  CPU: 5   COMMAND: "kdmflush"
 #0 [ffff8808157e7670] schedule at ffffffff8143f489
 #1 [ffff8808157e77b8] reiserfs_get_block at ffffffffa038ab2d [reiserfs]
 #2 [ffff8808157e79a8] __block_write_begin at ffffffff8117fb14
 #3 [ffff8808157e7a98] reiserfs_write_begin at ffffffffa0388695 [reiserfs]
 #4 [ffff8808157e7ad8] generic_perform_write at ffffffff810ee9e2
 #5 [ffff8808157e7b58] generic_file_buffered_write at ffffffff810eeb41
 #6 [ffff8808157e7ba8] __generic_file_aio_write at ffffffff810f1a3a
 #7 [ffff8808157e7c58] generic_file_aio_write at ffffffff810f1c88
 #8 [ffff8808157e7cc8] do_sync_write at ffffffff8114f850
 #9 [ffff8808157e7dd8] do_acct_process at ffffffff810a268f
    [exception RIP: kernel_thread_helper]
    RIP: ffffffff8144a5c0  RSP: ffff8808157e7f58  RFLAGS: 00000202
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: ffffffff8107af60  RDI: ffff8803ee491d18
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
    R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
Signed-off-by: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Pull vfs fixes from Al Viro:
 "A bunch of fixes; the last one is this cycle regression, the rest are
  -stable fodder."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fix off-by-one in argument passed by iterate_fd() to callbacks
  lookup_one_len: don't accept . and ..
  cifs: get rid of blind d_drop() in readdir
  nfs_lookup_revalidate(): fix a leak
  don't do blind d_drop() in nfs_prime_dcache()

Pull RCU fix from Ingo Molnar:
 "Fix leaking RCU extended quiescent state, which might trigger warnings
  and mess up the extended quiescent state tracking logic into thinking
  that we are in "RCU user mode" while we aren't."

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rcu: Fix unrecovered RCU user mode in syscall_trace_leave()

Pull perf fixes from Ingo Molnar:
 "This is mostly about unbreaking architectures that took the UAPI
  changes in the v3.7 cycle, plus misc fixes."

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf kvm: Fix building perf kvm on non x86 arches
  perf kvm: Rename perf_kvm to perf_kvm_stat
  perf: Make perf build for x86 with UAPI disintegration applied
  perf powerpc: Use uapi/unistd.h to fix build error
  tools: Pass the target in descend
  tools: Honour the O= flag when tool build called from a higher Makefile
  tools: Define a Makefile function to do subdir processing
  x86: Export asm/{svm.h,vmx.h,perf_regs.h}
  perf tools: Fix strbuf_addf() when the buffer needs to grow
  perf header: Fix numa topology printing
  perf, powerpc: Fix hw breakpoints returning -ENOSPC

Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

 - Don't build 'perf kvm stat" on non-x86 arches, fix from Xiao Guangrong.

 - UAPI fixes to get perf building again in non-x86 arches, from David Howells.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Pull x86 fixes from Peter Anvin.

This includes the resume-time FPU corruption fix from the chromeos guys,
marked for stable.

* 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, fpu: Avoid FPU lazy restore after suspend
  x86-32: Unbreak booting on some 486 clones
  x86, kvm: Remove incorrect redundant assembly constraint

Pull C6X fixes from Mark Salter.

* tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreaming:
  c6x: use generic kvm_para.h
  c6x: remove internal kernel symbols from exported setup.h
  c6x: fix misleading comment
  c6x: run do_notify_resume with interrupts enabled

Pull assorted signal-related fixes from Al Viro:
 "uml regression fix (braino in sys_execve() patch) + a bunch of fucked
  sigaltstack-on-rt_sigreturn uses, similar to sparc64 fix that went in
  through davem's tree.  m32r horrors not included - that one's waiting
  for maintainer."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal:
  microblaze: rt_sigreturn is too trigger-happy about sigaltstack errors
  score: do_sigaltstack() expects a userland pointer...
  sh64: fix altstack switching on sigreturn
  openrisk: fix altstack switching on sigreturn
  um: get_safe_registers() should be done in flush_thread(), not start_thread()

Pull CIFS fixes from Steve French:
 "Two low risk, small fixes, that fix cifs regressions introduced in
  3.7."

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  CIFS: Fix wrong buffer pointer usage in smb_set_file_info
  cifs: fix writeback race with file that is growing

Pull remoteproc fix from Ohad Ben-Cohen:
 "A single remoteproc fix for an error path issue reported by Ido Yariv."

* tag 'rproc-3.7-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  remoteproc: fix error path of ->find_vqs

Pull target fix from Nicholas Bellinger:
 "So just a single target fix for v3.7.0 this time around from Roland to
  address a aborted command bug w/ tcm_qla2xxx fabric ports.

  Also, there is one outstanding IBLOCK + virtio-blk bug that is still
  being tracked down effecting v3.6.x, but AFAICT thus far this appears
  to be a bug outside of target code."

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target: Fix handling of aborted commands

When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running
on the same CPU, this will result in a corrupted FPU context.

Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU,
so nobody will try to lazy restore a state which doesn't exist in the hardware.

Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off,
by doing thousands of suspend/resume cycles with 4 processes doing FPU
operations running. Without the patch, a process is killed after a
few hundreds cycles by a SIGFPE.

Cc: Duncan Laurie <dlaurie@chromium.org>
Cc: Olof Johansson <olofj@chromium.org>
Cc: <stable@kernel.org> v3.4+ # for 3.4 need to replace this_cpu_write by percpu_write
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Link: http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpalatin@chromium.orgSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>

Pull DRM fixes from Dave Airlie:
 "Just driver fixes, nothing major, except maybe the Ironlake rc6
  disable:

   - intel:
     * revert ironlake rc6 - we still have one ilk regression, but this
       gets rid of one big one
     * turn off cloning
     * a directed fix for Apple edp
   - radeon: one modesetting fix
   - exynos: minor fixes"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  radeon: fix pll/ctrc mapping on dce2 and dce3 hardware
  Revert "drm/i915: enable rc6 on ilk again"
  drm/i915: do not default to 18 bpp for eDP if missing from VBT
  drm/exynos: Fix potential NULL pointer dereference in exynos_drm_encoder.c
  drm/exynos: Make exynos4/5_fimd_driver_data static
  drm/exynos: fix overlay updating issue
  drm/exynos: remove unnecessary code.
  drm/exynos: fix linux framebuffer address setting.
  drm/i915: disable cloning on sdvo