Merge misc fixes from Andrew Morton:
 "Three fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm: numa: disable change protection for vma(VM_HUGETLB)
  include/linux/dmapool.h: declare struct device
  mm: move zone lock to a different cache line than order-0 free page lists

Unlike most (all?) other copies from user space, kernel module loading
is almost unlimited in size.  So we do a potentially huge
"copy_from_user()" when we copy the module data from user space to the
kernel buffer, which can be a latency concern when preemption is
disabled (or voluntary).

Also, because 'copy_from_user()' clears the tail of the kernel buffer on
failures, even a *failed* copy can end up wasting a lot of time.

Normally neither of these are concerns in real life, but they do trigger
when doing stress-testing with trinity.  Running in a VM seems to add
its own overheadm causing trinity module load testing to even trigger
the watchdog.

The simple fix is to just chunk up the module loading, so that it never
tries to copy insanely big areas in one go.  That bounds the latency,
and also the amount of (unnecessarily, in this case) cleared memory for
the failure case.
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The rule for 'copy_from_user()' is that it zeroes the remaining kernel
buffer even when the copy fails halfway, just to make sure that we don't
leave uninitialized kernel memory around.  Because even if we check for
errors, some kernel buffers stay around after thge copy (think page
cache).

However, the x86-64 logic for user copies uses a copy_user_generic()
function for all the cases, that set the "zerorest" flag for any fault
on the source buffer.  Which meant that it didn't just try to clear the
kernel buffer after a failure in copy_from_user(), it also tried to
clear the destination user buffer for the "copy_in_user()" case.

Not only is that pointless, it also means that the clearing code has to
worry about the tail clearing taking page faults for the user buffer
case.  Which is just stupid, since that case shouldn't happen in the
first place.

Get rid of the whole "zerorest" thing entirely, and instead just check
if the destination is in kernel space or not.  And then just use
memset() to clear the tail of the kernel buffer if necessary.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull media updates from Mauro Carvalho Chehab:
 "A series of fixup patches for version 4.0:

   - one VB2 core fixup, when stopping the stream;
   - one VB2 core fixup for dma-contig memory type;
   - driver fixes at rtl28xx, s5p (tv, jpeg, mfc, soc-camera, sh_veu,
     cx23885, gspca"

* tag 'media/v3.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] rtl28xxu: return success for unimplemented FE callback
  [media] rtl2832: disable regmap register cache
  [media] vb2: Fix dma_dir setting for dma-contig mem type
  [media] media: s5p-mfc: fix broken pointer cast on 64bit arch
  [media] media: s5p-mfc: fix mmap support for 64bit arch
  [media] cx23885: fix querycap
  [media] sh_veu: v4l2_dev wasn't set
  [media] s5p-mfc: Fix NULL pointer dereference caused by not set q->lock
  [media] s5p-jpeg: exynos3250: fix erroneous reset procedure
  [media] s5p-tv: hdmi needs I2C support
  [media] s5p-jpeg: Initialize cb and cr to zero
  [media] media: fix gspca drivers build dependencies
  [media] soc-camera: Fix devm_kfree() in soc_of_bind()
  [media] media: atmel-isi: increase the burst length to improve the performance
  [media] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop()

Currently when a process accesses a hugetlb range protected with
PROTNONE, unexpected COWs are triggered, which finally puts the hugetlb
subsystem into a broken/uncontrollable state, where for example
h->resv_huge_pages is subtracted too much and wraps around to a very
large number, and the free hugepage pool is no longer maintainable.

This patch simply stops changing protection for vma(VM_HUGETLB) to fix
the problem.  And this also allows us to avoid useless overhead of minor
faults.
Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Suggested-by: NMel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: David Rientjes <rientjes@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

dmapool uses struct device in function arguments but relies on an
implicit inclusion to declare struct device causing warnings in some
configurations:

  include/linux/dmapool.h:31:7: warning: 'struct device' declared inside parameter list

Fix this by adding a struct device declaration to the file.
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Huang Ying reported the following problem due to commit 3484b2de ("mm:
rearrange zone fields into read-only, page alloc, statistics and page
reclaim lines") from the Intel performance tests

    24b7e581  3484b2de
    ----------------  --------------------------
             %stddev     %change         %stddev
                 \          |                \
        152288 \261  0%     -46.2%      81911 \261  0%  aim7.jobs-per-min
           237 \261  0%     +85.6%        440 \261  0%  aim7.time.elapsed_time
           237 \261  0%     +85.6%        440 \261  0%  aim7.time.elapsed_time.max
         25026 \261  0%     +70.7%      42712 \261  0%  aim7.time.system_time
       2186645 \261  5%     +32.0%    2885949 \261  4%  aim7.time.voluntary_context_switches
       4576561 \261  1%     +24.9%    5715773 \261  0%  aim7.time.involuntary_context_switches

The problem is specific to very large machines under stress.  It was not
reproducible with the machines I had used to justify the original patch
because large numbers of CPUs are required.  When pressure is high enough,
the cache line is bouncing between CPUs trying to acquire the lock and the
holder of the lock adjusting free lists.  The intention was that the
acquirer of the lock would automatically have the cache line holding the
free lists but according to Huang, this is not a universal win.

One possibility is to move the zone lock to its own cache line but it
increases the size of the zone.  This patch moves the lock to the other
end of the free lists where they do not contend under high pressure.  It
does mean the page allocator paths now require more cache lines but Huang
reports that it restores performance to previous levels on large machines

             %stddev     %change         %stddev
                 \          |                \
         84568 \261  1%     +94.3%     164280 \261  1%  aim7.jobs-per-min
       2881944 \261  2%     -35.1%    1870386 \261  8%  aim7.time.voluntary_context_switches
           681 \261  1%      -3.4%        658 \261  0%  aim7.time.user_time
       5538139 \261  0%     -12.1%    4867884 \261  0%  aim7.time.involuntary_context_switches
         44174 \261  1%     -46.0%      23848 \261  1%  aim7.time.system_time
           426 \261  1%     -48.4%        219 \261  1%  aim7.time.elapsed_time
           426 \261  1%     -48.4%        219 \261  1%  aim7.time.elapsed_time.max
           468 \261  1%     -43.1%        266 \261  2%  uptime.boot
Signed-off-by: NMel Gorman <mgorman@suse.de>
Reported-by: NHuang Ying <ying.huang@intel.com>
Tested-by: NHuang Ying <ying.huang@intel.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull networking fixes from David Miller:

 1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
    previously SACK'd, from Neal Cardwell.

 2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
    from Cong WANG.

 3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
    from Cong WANG.

 4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.

 5) When we encapsulate for a tunnel device, skb->sk still points to the
    user socket.  So this leads to cases where we retraverse the
    ipv4/ipv6 output path with skb->sk being of some other address
    family (f.e. AF_PACKET).  This can cause things to crash since the
    ipv4 output path is dereferencing an AF_PACKET socket as if it were
    an ipv4 one.

    The short term fix for 'net' and -stable is to elide these socket
    checks once we've entered an encapsulation sequence by testing
    xmit_recursion.

    Longer term we have a better solution wherein we pass the tunnel's
    socket down through the output paths, but that is way too invasive
    for 'net' and -stable.

    From Hannes Frederic Sowa.

 6) l2tp_init() failure path forgets to unregister per-net ops, from
    Cong WANG.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
  net: dsa: fix filling routing table from OF description
  l2tp: unregister l2tp_net_ops on failure path
  mvneta: dont call mvneta_adjust_link() manually
  ipv6: protect skb->sk accesses from recursive dereference inside the stack
  netns: don't allocate an id for dead netns
  Revert "netns: don't clear nsid too early on removal"
  ip6mr: call del_timer_sync() in ip6mr_free_table()
  net: move fib_rules_unregister() under rtnl lock
  ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
  tcp: fix FRTO undo on cumulative ACK of SACKed range
  xen-netfront: transmit fully GSO-sized packets

Commit 1daa4303 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.

Fixes: 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.

However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.

This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.

To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.

This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: NPavel Nakonechny <pavel.nakonechny@skitlab.ru>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Pull input fixes from Dmitry Torokhov:
 "Updates for the input subsystem - two more tweaks for ALPS driver to
  work out kinks after splitting the touchpad, trackstick, and potential
  external PS/2 mouse into separate input devices.

  Changes to support ALPS SS4 devices (protocol V8) will be coming in
  4.1..."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: alps - document stick behavior for protocol V2
  Input: alps - report V2 Dualpoint Stick events via the right evdev node
  Input: alps - report interleaved bare PS/2 packets via dev3

Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Document that protocol V2 uses standard (bare) PS/2 mouse packets for the
DualPoint stick.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-By: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.

Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.

This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.

This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.

This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pull USB fixes from Greg KH:
 "Here are some small USB fixes and new device ids for 4.0-rc6.  Nothing
  major, some xhci fixes for reported problems, and some usb-serial
  device ids.

  All have been in linux-next for a while"

* tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
  usb: isp1760: fix spin unlock in the error path of isp1760_udc_start
  usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
  usb: xhci: handle Config Error Change (CEC) in xhci driver
  USB: keyspan_pda: add new device id
  USB: ftdi_sio: Added custom PID for Synapse Wireless product

Pull staging driver fixes from Greg KH:
 "Here are some staging driver fixes, well, really all just IIO driver
  fixes, for 4.0-rc6.  They fix issues that have been reported with
  these drivers.

  All of these patches have been in linux-next for a while"

* tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  iio: imu: Use iio_trigger_get for indio_dev->trig assignment
  iio: adc: vf610: use ADC clock within specification
  iio/adc/cc10001_adc.c: Fix !HAS_IOMEM build
  iio: core: Fix double free.
  iio:inv-mpu6050: Fix inconsistency for the scale channel
  staging: iio: dummy: Fix undefined symbol build error
  iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
  staging: iio: hmc5843: Set iio name property in sysfs
  iio: bmc150: change sampling frequency
  iio: fix drivers that check buffer->scan_mask

Pull tty/serial fixes from Greg KH:
 "Here are 3 serial driver fixes for 4.0-rc6.  They fix some reported
  issues with the samsung and fsl_lpuart drivers.

  All have been in linux-next for a while"

* tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: serial: fsl_lpuart: clear receive flag on FIFO flush
  tty: serial: fsl_lpuart: specify transmit FIFO size
  serial: samsung: Clear operation mode on UART shutdown

Pull input subsystem fixes from Dmitry Torokhov:
 "A fix for ALPS driver for issue introduced in the latest update and a
  tweak for yet another Lenovo box in Synaptics.

  There will be more ALPS tweaks coming.."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: define INPUT_PROP_ACCELEROMETER behavior
  Input: synaptics - fix min-max quirk value for E440
  Input: synaptics - add quirk for Thinkpad E440
  Input: ALPS - fix max coordinates for v5 and v7 protocols
  Input: add MT_TOOL_PALM

Pull block layer fix from Jens Axboe:
 "Just one patch in this pull request, fixing a regression caused by a
  'mathematically correct' change to lcm()"

* 'for-linus' of git://git.kernel.dk/linux-block:
  block: fix blk_stack_limits() regression due to lcm() change

Pull x86 fixes from Ingo Molnar:
 "Misc fixes: a SYSRET single-stepping fix, a dmi-scan robustization
  fix, a reboot quirk and a kgdb fixlet"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  kgdb/x86: Fix reporting of 'si' in kgdb on x86_64
  x86/asm/entry/64: Disable opportunistic SYSRET if regs->flags has TF set
  x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk
  MAINTAINERS: Change the x86 microcode loader maintainer
  firmware: dmi_scan: Prevent dmi_num integer overflow

Pull perf fixes from Ingo Molnar:
 "Two x86 Intel PMU constraint handling fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel: Fix Haswell CYCLE_ACTIVITY.* counter constraints
  perf/x86/intel: Filter branches for PEBS event

Pull devicetree fix from Grant Likely:
 "Simple bugfix for bad device tree data on the PA-Semi platform"

* tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
  drivers/of: Add empty ranges quirk for PA-Semi

Pull CIFS fixes from Steve French:
 "A set of small cifs fixes fixing a memory leak, kernel oops, and
  infinite loop (and some spotted by Coverity)"

* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
  Fix warning
  Fix another dereference before null check warning
  CIFS: session servername can't be null
  Fix warning on impossible comparison
  Fix coverity warning
  Fix dereference before null check warning
  Don't ignore errors on encrypting password in SMBTcon
  Fix warning on uninitialized buftype
  cifs: potential memory leaks when parsing mnt opts
  cifs: fix use-after-free bug in find_writable_file
  cifs: smb2_clone_range() - exit on unhandled error

First, let's explain the problem.
Suppose you have an ipip interface that stands in the netns foo and its link
part in the netns bar (so the netns bar has an nsid into the netns foo).
Now, you remove the netns bar:
 - the bar nsid into the netns foo is removed
 - the netns exit method of ipip is called, thus our ipip iface is removed:
   => a netlink message is built in the netns foo to advertise this deletion
   => this netlink message requests an nsid for bar, thus a new nsid is
      allocated for bar and never removed.

This patch adds a check in peernet2id() so that an id cannot be allocated for
a netns which is currently destroyed.
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts
commit 4217291e ("netns: don't clear nsid too early on removal").

This is not the right fix, it introduces races.
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We need to wait for the flying timers, since we
are going to free the mrtable right after it.

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We have to hold rtnl lock for fib_rules_unregister()
otherwise the following race could happen:

fib_rules_unregister():	fib_nl_delrule():
...				...
...				ops = lookup_rules_ops();
list_del_rcu(&ops->list);
				list_for_each_entry(ops->rules) {
fib_rules_cleanup_ops(ops);	  ...
  list_del_rcu();		  list_del_rcu();
				}

Note, net->rules_mod_lock is actually not needed at all,
either upper layer netns code or rtnl lock guarantees
we are safe.

Cc: Alexander Duyck <alexander.h.duyck@redhat.com>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is the IPv4 part for commit 905a6f96
(ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup).

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Pull drm fixes from Dave Airlie:
 "One drm core fix, one exynos regression fix, two sets of radeon fixes
  (Alex was a bit behind last week), and two i915 fixes.

  Nothing too serious we seem to have calmed down i915 since last week"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: fix wait in radeon_mn_invalidate_range_start
  drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
  drm: Exynos: Respect framebuffer pitch for FIMD/Mixer
  drm/i915: Reject the colorkey ioctls for primary and cursor planes
  drm/i915: Skip allocating shadow batch for 0-length batches
  drm/radeon: programm the VCE fw BAR as well
  drm/radeon: always dump the ring content if it's available
  radeon: Do not directly dereference pointers to BIOS area.
  drm/radeon/dpm: fix 120hz handling harder
  drm/edid: set ELD for firmware and debugfs override EDIDs

Pull irqchip fixes from Jason Cooper:
 "This is the second round of fixes for irqchip.  It contains some fixes
  found while the arm64 guys were writing the kvm gicv3 its emulation.

  GICv3 ITS:
    - Small batch of fixes discovered while writing the kvm ITS emulation"

* tag 'irqchip-fixes-4.0-2' of git://git.infradead.org/users/jcooper/linux:
  irqchip: gicv3-its: Use non-cacheable accesses when no shareability
  irqchip: gicv3-its: Fix PROP/PEND and BASE/CBASE confusion
  irqchip: gicv3-its: Fix device ID encoding
  irqchip: gicv3-its: Fix encoding of collection's target redistributor

Just two small fixes for radeon, both destined for stable.

* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: fix wait in radeon_mn_invalidate_range_start
  drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr

Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes

Fix display on issue to Exynos5250 based Snow(1366x768) board.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm: Exynos: Respect framebuffer pitch for FIMD/Mixer

one oops fixes and a 0-length allocation fix from next backported.

* tag 'drm-intel-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Reject the colorkey ioctls for primary and cursor planes
  drm/i915: Skip allocating shadow batch for 0-length batches

Here's a single drm core fix, cc: stable, that affects i915
users.

* tag 'topic/drm-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
  drm/edid: set ELD for firmware and debugfs override EDIDs

Return success for FE callback on case we don't have any special
implementation. fc0013 tuner driver calls that callback in order to
switch antenna input, even we don't provide antenna switch.
Returning error caused fc0013 driver given up tuning.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Caching register reads causes some random I/O errors on channel
change. Disable caching now in order to avoid those errors.

Reverts partly commit dcadb82aSigned-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>