linux-stable.git/drivers/gpu, branch v4.1.19

drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command

2016-03-04T15:25:44+00:00

[ Upstream commit 34855706c30d52b0a744da44348b5d1cc39fbe51 ]

This avoids integer overflows on 32bit machines when calculating
reloc_info size, as reported by Alan Cox.

Cc: stable@vger.kernel.org
Cc: gnomes@lxorguk.ukuu.org.uk
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/radeon: use post-decrement in error handling

2016-03-04T15:25:44+00:00

[ Upstream commit bc3f5d8c4ca01555820617eb3b6c0857e4df710d ]

We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.

Reviewed-by: Christian König 
Signed-off-by: Rasmus Villemoes 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon: hold reference to fences in radeon_sa_bo_new

2016-03-04T15:25:41+00:00

[ Upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb ]

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/i915/dsi: don't pass arbitrary data to sideband

2016-02-28T05:09:53+00:00

[ Upstream commit 26f6f2d301c1fb46acb1138ee155125815239b0d ]

Since sequence block v2 the second byte contains flags other than just
pull up/down. Don't pass arbitrary data to the sideband interface.

The rest may or may not work for sequence block v2, but there should be
no harm done.

Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/ebe3c2eee623afc4b3a134533b01f8d591d13f32.1454582914.git.jani.nikula@intel.com
(cherry picked from commit 4e1c63e3761b84ec7d87c75b58bbc8bcf18e98ee)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/i915/dsi: defend gpio table against out of bounds access

2016-02-28T05:09:53+00:00

[ Upstream commit 4db3a2448ec8902310acb78de39b6227a9a56ac8 ]

Do not blindly trust the VBT data used for indexing.

Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/cc32d40c2b47f2d2151811855ac2c3dabab1d57d.1454582914.git.jani.nikula@intel.com
(cherry picked from commit 5d2d0a12d3d08bf50434f0b5947bb73bac04b941)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/i915: Take all modeset locks for DP MST hotplug

2016-02-15T20:45:36+00:00

[ Upstream commit 8bb4da1df54a20d68c34427356e34315ba122c0f ]

While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.

The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.

Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.

The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/radeon: Take all modeset locks for DP MST hotplug

2016-02-15T20:45:36+00:00

[ Upstream commit 2ee6bcdcfa4d8b56b20bc6308cd5f9bced5b5324 ]

Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/dp/mst: fixup handling hotplug on port removal.

2016-02-15T20:45:36+00:00

[ Upstream commit df4839fdc9b3c922586b945f062f38cbbda022bb ]

output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.

In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.

In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.

this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.

Reviewed-by: Daniel Vetter 
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/dp/mst: Remove port after removing connector.

2016-02-15T20:45:35+00:00

[ Upstream commit 4772ff03df8094fd99d28de5fcf5df3a3e9c68bb ]

The port is removed synchronously, but the connector delayed.
This causes a use after free which can cause a kernel BUG with
slug_debug=FPZU. This is fixed by freeing the port after the
connector.

This fixes a regression introduced with
6b8eeca65b18ae77e175cc2b6571731f0ee413bf
"drm/dp/mst: close deadlock in connector destruction."

Cc: stable@vger.kernel.org
Cc: Dave Airlie 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/dp/mst: Calculate MST PBN with 31.32 fixed point

2016-02-15T20:45:35+00:00

[ Upstream commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 ]

Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.

This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.

Signed-off-by: Harry Wentland 
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin