linux-toradex.git/drivers, branch v4.9.15

drivers: hv: Turn off write permission on the hypercall page

2017-03-15T02:02:52+00:00

commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 upstream.

The hypercall page only needs to be executable but currently it is setup to
be writable as well. Fix the issue.

Signed-off-by: K. Y. Srinivasan 
Acked-by: Kees Cook 
Reported-by: Stephen Hemminger 
Tested-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

2017-03-15T02:02:51+00:00

commit 998d75730b40afc218c059d811869abe9676b305 upstream.

If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may
use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation
for a vbt in mailbox #4 for this.

This fixes the driver not finding the VBT on a jumper ezpad mini3
cherrytrail tablet and on a ACER SW5_017 machine.

Signed-off-by: Hans de Goede 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1487088758-30050-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit dfb65e71ea2c1d97ac373cc0587dc60b3307581a)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

2017-03-15T02:02:51+00:00

commit aa9323dd49b23932a09023012f050556de64f118 upstream.

Until recently vlv_steal_power_sequencer() wasn't being called for
normal DP ports, and hence it could assert that it should only be
called for pipe A and B (since pipe C doesn't support eDP). However
that changed when we started to consider normal DP ports as well when
choosing a PPS. So we will now get spurious warnings when
vlv_steal_power_sequencer() does get called for pipe C. Avoid this by
moving the WARN down into vlv_detach_power_sequencer() where this
assertion should still hold.

Cc: Imre Deak 
Fixes: 9f2bdb006a7e ("drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV")
References: https://bugs.freedesktop.org/show_bug.cgi?id=95287
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20170208175254.10958-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak 
(cherry picked from commit d158694f452252d0fef335a775aeb3eb74fe7af0)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm: Cancel drm_fb_helper_resume_work on unload

2017-03-15T02:02:50+00:00

commit 24f76b2c87ed68f79f9f0705b11ccbefaaa0d390 upstream.

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Chris Wilson 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman

drm: Cancel drm_fb_helper_dirty_work on unload

2017-03-15T02:02:50+00:00

commit f21b9a92ca7c29382909eaab9facc2cf46f2cc0b upstream.

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: Chris Wilson 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman

drm/i915/gvt: Disable access to stolen memory as a guest

2017-03-15T02:02:50+00:00

commit ddd09373628adcbdc3f7b9098d22328834f8d772 upstream.

Explicitly disable stolen memory when running as a guest in a virtual
machine, since the memory is not mediated between clients and reserved
entirely for the host. The actual size should be reported as zero, but
like every other quirk we want to tell the user what is happening.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028
Signed-off-by: Chris Wilson 
Cc: Zhenyu Wang 
Cc: Joonas Lahtinen 
Link: http://patchwork.freedesktop.org/patch/msgid/20161109103905.17860-1-chris@chris-wilson.co.uk
Reviewed-by: Zhenyu Wang 
(cherry picked from commit 04a68a35ce6d7b54749989f943993020f48fed62)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/atomic: fix an error code in mode_fixup()

2017-03-15T02:02:50+00:00

commit f9ad86e42d0303eeb8e0d41bb208153022ebd9d2 upstream.

Having "ret" be a bool type works for everything except
ret = funcs->atomic_check().  The other functions all return zero on
error but ->atomic_check() returns negative error codes.  We want to
propagate the error code but instead we return 1.

I found this bug with static analysis and I don't know if it affects
run time.

Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers")
Signed-off-by: Dan Carpenter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170207234601.GA23981@mwanda
Signed-off-by: Greg Kroah-Hartman

drm/imx: imx-tve: Do not set the regulator voltage

2017-03-15T02:02:50+00:00

commit fc12bccda8b6f5c38139eceec9e369ed78091b2b upstream.

Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:

63ff0000.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff0000.tve (ops imx_tve_ops): -22

When the 'dac-supply' is not passed in the device tree a dummy regulator is
used and setting its voltage is not allowed.

To fix this issue, do not set the dac-supply voltage inside the driver
and let its voltage be specified in the device tree.

Print a warning if the the 'dac-supply' voltage has a value different
from 2.75V.

Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()")
Suggested-by: Lucas Stach 
Signed-off-by: Fabio Estevam 
Signed-off-by: Philipp Zabel 
Signed-off-by: Greg Kroah-Hartman

dmaengine: imx-sdma - correct the dma transfer residue calculation

2017-03-15T02:02:49+00:00

commit 85f57752b33cf12f1d583f0c10b752292de00abe upstream.

The residue calculation was taking in consideration that dma
transaction status will be always retrieved in the dma callback
used to inform that dma transfer is complete. However this is not
the case for all subsystems that use dma. Some subsystems use a
timer to check the dma status periodically.

Therefore the calculation was updated and residue is calculated
accordingly by a) update the residue calculation taking in
consideration the last used buffer index by using *buf_ptail* variable
and b) chn_real_count (number of bytes transferred) is initialized to
zero, when dma channel is created, to avoid using an uninitialized
value in residue calculation when dma status is checked without
waiting dma complete event.

Signed-off-by: Nandor Han 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
Tested-by: Marek Vasut 
Signed-off-by: Vinod Koul 
Cc: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Work around drm removal of control nodes

2017-03-15T02:02:49+00:00

commit 31788ca803a0c89078f9e604e64286fbd9077926 upstream.

vmware tools has a daemon that gets layout information from the GUI and
forwards it to DRM so that the modesetting code can set preferred connector
locations and modes. This daemon was using control nodes but since control
nodes were just removed, make it possible for the daemon to use render- or
primary nodes instead. This is a bit ugly but will allow drm to proceed with
removal of the mostly unused control-node code and allow vmware to proceed
with fixing up automatic layout settings for gnome-shell/wayland.

We bump minor to inform user-space about the api change.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170221104227.2854-1-thellstrom@vmware.com
Signed-off-by: Greg Kroah-Hartman