linux-stable.git/drivers, branch v4.16.7

sparc64: Fix mistake in oradax license text

2018-05-01T19:47:30+00:00

commit d3c68d0b4183ddfa05577348a231dd117e6563df upstream.

The license text in both oradax files mistakenly specifies "version 3" of
the GNU General Public License.  This is corrected to specify "version 2".

Signed-off-by: Rob Gardner 
Signed-off-by: Jonathan Helman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - add check to get PSP master only when PSP is detected

2018-05-01T19:47:30+00:00

commit 716c7c32eae4b8a45c4f5602b50453865929b670 upstream.

Paulian reported the below kernel crash on Ryzen 5 system:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000073
RIP: 0010:.LC0+0x41f/0xa00
RSP: 0018:ffffa9968003bdd0 EFLAGS: 00010002
RAX: ffffffffb113b130 RBX: 0000000000000000 RCX: 00000000000005a7
RDX: 00000000000000ff RSI: ffff8b46dee651a0 RDI: ffffffffb1bd617c
RBP: 0000000000000246 R08: 00000000000251a0 R09: 0000000000000000
R10: ffffd81f11a38200 R11: ffff8b52e8e0a161 R12: ffffffffb19db220
R13: 0000000000000007 R14: ffffffffb17e4888 R15: 5dccd7affc30a31e
FS:  0000000000000000(0000) GS:ffff8b46dee40000(0000) knlGS:0000000000000000
CR2: 0000000000000073 CR3: 000080128120a000 CR4: 00000000003406e0
Call Trace:
 ? sp_get_psp_master_device+0x56/0x80
 ? map_properties+0x540/0x540
 ? psp_pci_init+0x20/0xe0
 ? map_properties+0x540/0x540
 ? sp_mod_init+0x16/0x1a
 ? do_one_initcall+0x4b/0x190
 ? kernel_init_freeable+0x19b/0x23c
 ? rest_init+0xb0/0xb0
 ? kernel_init+0xa/0x100
 ? ret_from_fork+0x22/0x40

Since Ryzen does not support PSP/SEV firmware hence i->psp_data will
NULL in all sp instances. In those cases, 'i' will point to the
list head after list_for_each_entry(). Dereferencing the head will
cause kernel crash.

Add check to call get master device only when PSP/SEV is detected.

Reported-by: Paulian Bogdan Marinca 
Cc: Borislav Petkov 
Cc: Tom Lendacky 
CC: Gary R Hook 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Disallow enabling CRTC without primary plane with FB

2018-05-01T19:47:29+00:00

commit f2877656809386d7bc62c2b1c1b4e58404c486d4 upstream.

The below commit

    "drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"

introduces a slight behavioral change to rmfb. Instead of disabling a crtc
when the primary plane is disabled, it now preserves it.

Since DC is currently not equipped to handle this we need to fail such
a commit, otherwise we might see a corrupted screen.

This is based on Shirish's previous approach but avoids adding all
planes to the new atomic state which leads to a full update in DC for
any commit, and is not what we intend.

Theoretically DM should be able to deal with states with fully populated planes,
even for simple updates, such as cursor updates. This should still be
addressed in the future.

Signed-off-by: Harry Wentland 
Tested-by: Michel Dänzer 
Reviewed-by: Tony Cheng 
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Don't read EDID in atomic_check

2018-05-01T19:47:29+00:00

commit c7b8de00384be49dc1617a838b0ce89a0235f319 upstream.

We shouldn't attempt to read EDID in atomic_check. We really shouldn't
even be modifying the connector object, or any other non-state object,
but this is a start at least.

Moving EDID cleanup to dm_dp_mst_connector_destroy from
dm_dp_destroy_mst_connector to ensure the EDID is still available for
headless mode.

Signed-off-by: Harry Wentland 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix deadlock when flushing irq

2018-05-01T19:47:29+00:00

commit ad64dc0137968f09800e58174bbfd5eac9fe5418 upstream.

Lock irq table when reading a work in queue,
unlock to flush the work, lock again till all tasks
are cleared

Signed-off-by: Mikita Lipski 
Reviewed-by: Harry Wentland 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/i915: Enable display WA#1183 from its correct spot

2018-05-01T19:47:29+00:00

commit ac315c621f01d4b8a53dec317c7ae322fd26ff38 upstream.

The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.

I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.

Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
(cherry picked from commit b49be6622f08187129561cff0409f7b06b33de57)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/i915/audio: set minimum CD clock to twice the BCLK

2018-05-01T19:47:29+00:00

commit 904e1b1ff4c70044334f395aa751c8e73fb42714 upstream.

In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.

Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.

The proper fix would be to increase CDCLK dynamically from the audio
component hooks.

v2:
    - Address comment (Jani)
    - New design approach
v3: - Typo fix on top of v1

v4 by Jani: rewrite commit message, add comment in code

Cc: stable@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Wenkai Du 
Reviewed-by: Wenkai Du 
Tested-by: Wenkai Du 
Acked-by: Ville Syrjälä 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
(cherry picked from commit 2a5b95b448485e143ec3e004eabe53b31db78eb3)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/i915/fbdev: Enable late fbdev initial configuration

2018-05-01T19:47:29+00:00

commit 0b551f1e0fc50ee4e3cde2dd639cb010dae5b997 upstream.

If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN).  Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.

So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.

This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.

This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/

Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
  drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi 
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Chris Wilson 
Signed-off-by: José Roberto de Souza 
Tested-by: Paul Menzel 
Tested-by: frederik  # 4.15.17
Tested-by: Ian Pilcher 
Acked-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
(cherry picked from commit df9e6521749ab33cde306e8a4350b0ac7889220a)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders

2018-05-01T19:47:29+00:00

commit 75569c182e4f65cd8826a5853dc9cbca703cbd0e upstream.

Otherwise, the SQ may skip some of the register writes, or shader waves may
be allocated where we don't expect them, so that as a result we don't actually
reset all of the register SRAMs. This can lead to spurious ECC errors later on
if a shader uses an uninitialized register.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/edid: Reset more of the display info

2018-05-01T19:47:29+00:00

commit 1f6b8eef11c3d097bc8a6b2bbb868eb47ec6f7d8 upstream.

We're currently failing to reset everything in display_info.hdmi
which will potentially cause us to use stale information when
swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
with a HDMI 1.x monitor we will continue to think that the monitor
supports scrambling. That will lead to a black screen since the
HDMI 1.x monitor won't understand the scrambled signal.

Fix the problem by clearing display_info.hdmi fully. And while at
eliminate some duplicated code by calling drm_reset_display_info()
in drm_add_display_info().

Cc: stable@vger.kernel.org
Cc: Antony Chen 
Cc: Shashank Sharma 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180424130250.7028-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter 
Tested-by: Antony Chen 
Signed-off-by: Sean Paul 
Signed-off-by: Greg Kroah-Hartman