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

qxl: check for kmap failures

2016-09-30T08:12:48+00:00

commit f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream.

If kmap fails, it leads to memory corruption.

Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)')
Signed-off-by: Dan Carpenter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda
Signed-off-by: Greg Kroah-Hartman

Add braces to avoid "ambiguous ‘else’" compiler warnings

2016-09-24T08:09:41+00:00

commit 194dc870a5890e855ecffb30f3b80ba7c88f96d6 upstream.

Some of our "for_each_xyz()" macro constructs make gcc unhappy about
lack of braces around if-statements inside or outside the loop, because
the loop construct itself has a "if-then-else" statement inside of it.

The resulting warnings look something like this:

  drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
  drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
     if (ctx != dev_priv->kernel_context)
        ^

even if the code itself is fine.

Since the warning is fairly easy to avoid by adding a braces around the
if-statement near the for_each_xyz() construct, do so, rather than
disabling the otherwise potentially useful warning.

(The if-then-else statements used in the "for_each_xyz()" constructs are
designed to be inherently safe even with no braces, but in this case
it's quite understandable that gcc isn't really able to tell that).

This finally leaves the standard "allmodconfig" build with just a
handful of remaining warnings, so new and valid warnings hopefully will
stand out.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm: Only use compat ioctl for addfb2 on X86/IA64

2016-09-24T08:09:37+00:00

commit 47a66e45d7a7613322549c2475ea9d809baaf514 upstream.

Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
unaligned 64 bit field (modifier). This get packed differently between
32 bit and 64 bit modes on architectures that can handle unaligned 64
bit access (X86 and IA64).  Other architectures pack the structs the
same and don't need the compat wrapper. Use the same condition for
drm_mode_fb_cmd2 as we use for drm_update_draw.

Note that only the modifier will be packed differently between compat
and non-compat versions.

Reviewed-by: Rob Clark 
Signed-off-by: Kristian H. Kristensen 
[seanpaul added not at bottom of commit msg re: modifier]
Signed-off-by: Sean Paul 
Link: http://patchwork.freedesktop.org/patch/msgid/1473801645-116011-1-git-send-email-hoegsberg@chromium.org
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ignore OpRegion panel type except on select machines

2016-09-24T08:09:37+00:00

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 upstream.

Turns out
commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.

Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).

So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.

The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.

I suspect we can now also revert
commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.

v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
    gets populated too late

Cc: Rob Kramer 
Cc: Martin van Es 
Cc: Andrea Arcangeli 
Cc: Dave Airlie 
Cc: Marco Krüger 
Cc: Sean Greenslade 
Cc: Trudy Tective 
Cc: Robin Müller 
Cc: Alexander Kobel 
Cc: Alexey Shumitsky 
Cc: Emil Andersen Lauridsen 
Cc: oceans112@gmail.com
Cc: James Hogan 
Cc: James Bottomley 
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details")
Tested-by: Marco Krüger 
Tested-by: Alexey Shumitsky 
Tested-by: Sean Greenslade 
Tested-by: Emil Andersen Lauridsen 
Tested-by: Robin Müller 
Tested-by: oceans112@gmail.com
Tested-by: Rob Kramer 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com
Acked-by: Jani Nikula 
(cherry picked from commit c8ebfad7a063fe665417fa0eeb0da7cfe987d8ed)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm: atmel-hlcdc: Fix vertical scaling

2016-09-24T08:09:37+00:00

commit d31ed3f05763644840c654a384eaefa94c097ba2 upstream.

The code is applying the same scaling for the X and Y components,
thus making the scaling feature only functional when both components
have the same scaling factor.

Do the s/_w/_h/ replacement where appropriate to fix vertical scaling.

Signed-off-by: Jan Leupold 
Fixes: 1a396789f65a2 ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Boris Brezillon 
Signed-off-by: Greg Kroah-Hartman

drm/msm: protect against faults from copy_from_user() in submit ioctl

2016-09-24T08:09:23+00:00

commit d78d383ab354b0b9e1d23404ae0d9fbdeb9aa035 upstream.

An evil userspace could try to cause deadlock by passing an unfaulted-in
GEM bo as submit->bos (or submit->cmds) table.  Which will trigger
msm_gem_fault() while we already hold struct_mutex.  See:

https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c

Signed-off-by: Rob Clark 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix oops when userspace hands in a bad BO.

2016-09-15T06:20:27+00:00

commit 552416c146fadc67cd9b53ef7adf88d3381c43a6 upstream.

We'd end up NULL pointer dereferencing because we didn't take the
error path out in the parent.  Fixes igt vc4_lookup_fail test.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

2016-09-15T06:20:27+00:00

commit 9326e6f25574bbb8bd48206d245654780e3fd665 upstream.

Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed.  When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.

We were looking at "what's currently running in the binner", but since
the bin/render submission split, we may end up with the binner
completing and having no new job while the renderer is still
processing.  So, if we don't find a bin job at all, look at the
highest-seqno (last) render job to attach our overflow to.

Signed-off-by: Eric Anholt 
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Use drm_free_large() on handles to match its allocation.

2016-09-15T06:20:27+00:00

commit d5fb46e0e3b7e49ee83ba92efc3ab4e1a545ecc1 upstream.

If you managed to exceed the limit to switch to vmalloc, we'd use the
wrong free.

Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Greg Kroah-Hartman

drm/msm: fix use of copy_from_user() while holding spinlock

2016-09-15T06:20:27+00:00

commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 upstream.

Use instead __copy_from_user_inatomic() and fallback to slow-path where
we drop and re-aquire the lock in case of fault.

Reported-by: Vaishali Thakkar 
Signed-off-by: Rob Clark 
Signed-off-by: Greg Kroah-Hartman