drm/amdgpu/gmc8: use the vram location programmed by the vbios

This makes mc programming much simpler in future patches.

Since evergreen, the vbios has been programming the fb location
to the proper vram size.  The only reason to reprogram it would
be to change the location.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: disable vga render in dce hw_init

This got dropped accidently with the fb location changes, but for
some reason, this doesn't seem to cause an issue on all cards which
is why I never saw it despite extensive testing.  I suspect it may
only be an issue on systems with a legacy sbios that enables vga.

Tested-by: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: simplify VM shadow handling v2

Now that we don't join PTE updates any more we don't need to call
the update function twice for this.

v2: rebased

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: enable 4 level page table on raven (v3)

v1: enable 4 level-page table on raven
v2: add back legacy 2 level page table on raven
v3: set num_level in initial switch statement

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: use kernel is_power_of_2 rather than local version

Use the kernel provided version.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Merge branch 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux into drm-next

single r700 fix.
* 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: Fix eDP for single-display iMac10,1 (v2)

Merge tag 'drm-misc-next-fixes-2017-07-10' of git://anongit.freedesktop.org/git/drm-misc into drm-next

Core Changes:
- Fix empty timestamps on hw without vlbank counter (Laurent)
- Clear atomic state before retrying ww/mutex acquisition in remove_fb (Maarten)

Driver Changes:
- rockchip: Fix incorrect NULL pointer check after allocation (Gustavo)

Cc: Gustavo A. R. Silva <garsilva@embeddedor.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
* tag 'drm-misc-next-fixes-2017-07-10' of git://anongit.freedesktop.org/git/drm-misc:
  drm/rockchip: fix NULL check on devm_kzalloc() return value
  drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
  drm: vblank: Fix vblank timestamp update
  DRM: Fix an incorrectly formatted table
  bridge: Fix panel-bridge error return on !panel.
  drm/rockchip: gem: add the lacks lock and trivial changes

Merge tag 'drm-intel-next-fixes-2017-07-11' of git://anongit.freedesktop.org/git/drm-intel into drm-next

drm/i915 fixes for v4.13-rc1

* tag 'drm-intel-next-fixes-2017-07-11' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Make DP-MST connector info work
  drm/i915/gvt: Use fence error from GVT request for workload status
  drm/i915/gvt: remove scheduler_mutex in per-engine workload_thread
  drm/i915/gvt: Revert "drm/i915/gvt: Fix possible recursive locking issue"
  drm/i915/gvt: Audit the command buffer address
  drm/i915/gvt: Fix a memory leak in intel_gvt_init_gtt()
  drm/i915/fbdev: Check for existence of ifbdev->vma before operations
  drm/i915: Hold RPM wakelock while initializing OA buffer
  drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
  drm/i915/cfl: Fix Workarounds.
  drm/i915: Avoid undefined behaviour of "u32 >> 32"
  drm/i915: reintroduce VLV/CHV PFI programming power domain workaround
  drm/i915: Fix an error checking test
  drm/i915: Disable MSI for all pre-gen5
  drm/i915/gvt: Make function dpy_reg_mmio_readx safe
  drm/i915/gvt: Don't read ADPA_CRT_HOTPLUG_MONITOR from host
  drm/i915/gvt: Set initial PORT_CLK_SEL vreg for BDW
  drm/i915/gvt: Fix inconsistent locks holding sequence
  drm/i915/gvt: Fix possible recursive locking issue

Merge branch 'mediatek-drm-next-4.13' of https://github.com/ckhu-mediatek/linux.git-tags into drm-next

This include new color format support and some fixups.

* 'mediatek-drm-next-4.13' of https://github.com/ckhu-mediatek/linux.git-tags:
  drm/mediatek: separate color module to fixup error memory reallocation
  drm/mediatek: check for memory allocation failure
  drm/mediatek: re-phrase DRM_INFO error message
  drm/mediatek: use platform_register_drivers
  drm/mediatek: Support UYVY and YUYV format for overlay

Merge tag 'gvt-fixes-2017-07-11' of https://github.com/01org/gvt-linux into drm-intel-next-fixes

gvt-fixes-2017-07-11

- Revert "drm/i915/gvt: Fix possible recursive locking issue" (Chuanxiao),
  which is incomplete fix and it's actually VFIO issue, so revert.
- remove unneeded scheduler mutex for performance fix (Weinan)
- other misc error handling fix and cmd address audit

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170711055333.jhrmvx6ilvg2qlnn@zhen-hp.sh.intel.com

drm/i915: Make DP-MST connector info work

Commit 9a148a96fc3a ("drm/i915/debugfs: add dp mst info") adds support
for DP-MST to intel_connector_info, but forgot to remove the early
return for DP-MST.

Remove it, and print out MST connectors directly.

Fixes: 9a148a96fc3a ("drm/i915/debugfs: add dp mst info")
Cc: <stable@vger.kernel.org> # v4.11+
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
(cherry picked from commit 77d1f615c78a73a04254fa2bff07ee9fa27145d9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/gvt: Use fence error from GVT request for workload status

The req->fence.error will be set if this request caused GPU hang so
we can use this value to workload->status to indicate whether this
GVT request caused any problem. If it caused GPU hang, we shouldn't
trigger any context switch back to the guest.

v2:
- only take -EIO from fence->error. (Zhenyu)

Fixes: 8f1117abb408 (drm/i915/gvt: handle workload lifecycle properly)
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: remove scheduler_mutex in per-engine workload_thread

For the vGPU workloads, now GVT-g use per vGPU scheduler, the per-ring
work_thread only pick workload belongs to the current vGPU. And with time
slice based scheduler, it waits all the engines become idle before do vGPU
switch. So we can run free dispatch in per-ring work_thread, different ring
running in different 'vGPU' won't happen.

For the workloads between vGPU and Host, this scheduler_mutex can't block
host to dispatch workload into other ring engines.

Here remove this mutex since it impacts the performance when applications
use more than 1 ring engines in 1 vgpu.

ring0 running in vGPU1, ring1 running in Host. Will happen.
ring0 running in vGPU1, ring1 running in vGPU2. Won't happen.

Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Revert "drm/i915/gvt: Fix possible recursive locking issue"

This reverts commit 62d02fd1f807bf5a259a242c483c9fb98a242630.

The rwsem recursive trace should not be fixed from kvmgt side by using
a workqueue and it is an issue should be fixed in VFIO. So this one
should be reverted.

Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Audit the command buffer address

The command buffer address in context like ring buffer base address
and wa_ctx address need to be audit to make sure they are in the
valid GGTT range.

Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Fix a memory leak in intel_gvt_init_gtt()

It will causes memory leak, if the function setup_spt_oos() fail,
in the function intel_gvt_init_gtt(),
which allocated by get_zeroed_page() and mapped by dma_map_page().

Unmap and free the page,  after STP oos initialize fail,
it will fix this issue.

Signed-off-by: Zhou, Wenjia <zhiyuan_zhu@htc.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/rockchip: fix NULL check on devm_kzalloc() return value

The right variable to check here is port, not dp.

This issue was detected using Coccinelle and the following semantic patch:

@@
expression x;
identifier fld;
@@

* x = devm_kzalloc(...);
  ... when != x == NULL
  x->fld

Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170706215833.GA25411@embeddedgus

drm/i915/fbdev: Check for existence of ifbdev->vma before operations

Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer
flushes") adds a dependency to ifbdev->vma when flushing the framebufer,
but the checks are only against the existence of the ifbdev->fb and not
against ifbdev->vma. This leaves a window of opportunity where we may
try to operate on the fbdev prior to it being probed (thanks to
asynchronous booting).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534
Fixes: fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622160211.783-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 15727ed0d944ce1dec8b9e1082dd3df29a0fdf44)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/radeon: Fix eDP for single-display iMac10,1 (v2)

The late 2009, 27 inch Apple iMac10,1 has an
internal eDP display and an external Mini-
Displayport output, driven by a DCE-3.2, RV730
Radeon Mobility HD-4670.

The machine worked fine in a dual-display setup
with eDP panel + externally connected HDMI
or DVI-D digital display sink, connected via
MiniDP to DVI or HDMI adapter.

However, booting the machine single-display with
only eDP panel results in a completely black
display - even backlight powering off, as soon as
the radeon modesetting driver loads.

This patch fixes the single dispay eDP case by
assigning encoders based on dig->linkb, similar
to DCE-4+. While this should not be generally
necessary (Alex: "...atom on normal boards
should be able to handle any mapping."), Apple
seems to use some special routing here.

One remaining problem not solved by this patch
is that an external Minidisplayport->DP sink
does still not work on iMac10,1, whereas external
DVI and HDMI sinks continue to work.

The problem affects at least all tested kernels
since Linux 3.13 - didn't test earlier kernels, so
backporting to stable probably makes sense.

v2: With the original patch from 2016, Alex was worried it
    will break other DCE3.2 systems. Use dmi_match() to
    apply this special encoder assignment only for the
    Apple iMac 10,1 from late 2009.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

the drm_file parameter is unused, so remove it.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux into drm-next

Fixes for 4.13:
- Various fixes for Raven
- Various fixes for Vega10
- Stability fixes for KIQ
- Fix reloading the driver
- Fix S3 on vega10
- Misc other fixes

* 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux: (26 commits)
  drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu.
  amdgpu: Set cik/si_support to 1 by default if radeon isn't built
  drm/amdgpu/gfx9: fix driver reload with KIQ
  drm/amdgpu/gfx8: fix driver reload with KIQ
  drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay
  drm/ttm: Fix use-after-free in ttm_bo_clean_mm
  drm/amd/amdgpu: move get memory type function from early init to sw init
  drm/amdgpu/cgs: always set reference clock in mode_info
  drm/amdgpu: fix vblank_time when displays are off
  drm/amd/powerplay: power value format change for Vega10
  drm/amdgpu/gfx9: support the amdgpu.disable_cu option
  drm/amd/powerplay: change PPSMC_MSG_GetCurrPkgPwr for Vega10
  drm/amdgpu: Make amdgpu_cs_parser_init static (v2)
  drm/amdgpu/cs: fix a typo in a comment
  drm/amdgpu: Fix the exported always on CU bitmap
  drm/amdgpu/gfx9: gfx_v9_0_enable_gfx_static_mg_power_gating() can be static
  drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup
  drm/amd/powerplay/cz: print message if smc message fails
  drm/amdgpu: fix typo in amdgpu_debugfs_test_ib_init
  drm/amdgpu: enable mmhub pg on raven
  ...

drm/amd/powerplay: fix bug fail to remove sysfs when rmmod amdgpu.

when hw_fini, pp will disable dpm.so remove sysfs before
disable dpm.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

amdgpu: Set cik/si_support to 1 by default if radeon isn't built

It was required to explicitly set these parameters to 1, even if the
radeon driver isn't built at all, which is not intuitive.

Reported-by: Shawn Starr <shawn.starr@rogers.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/gfx9: fix driver reload with KIQ

Drop the KCQ disabling via KIQ.  We disable the MEC shortly
after anyway, so there is no need to wait for all of this.
Doing so seems to leave the MEC in a bad way.

Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/gfx8: fix driver reload with KIQ

Drop the deactivation in KIQ init and drop the KCQ disabling
via KIQ.  We disable the MEC shortly after anyway, so there is
no need to wait for all of this.  Doing so seems to leave the
MEC in a bad way.

Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Don't call amd_powerplay_destroy() if we don't have powerplay

amd_powerplay_destroy() expects a handle pointing to a struct pp_instance.
On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The
resulting attempt to kfree() fields of the wrong struct ends in fire:

[   91.560405] BUG: unable to handle kernel paging request at ffffebe000000620
[   91.560414] IP: kfree+0x57/0x160
[   91.560416] PGD 0
[   91.560416] P4D 0

[   91.560420] Oops: 0000 [#1] SMP
[   91.560422] Modules linked in: tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
[   91.560438] CPU: 6 PID: 3598 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1
[   91.560443] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
[   91.560448] task: ffff8805063d6a00 task.stack: ffffc90003400000
[   91.560451] RIP: 0010:kfree+0x57/0x160
[   91.560454] RSP: 0018:ffffc90003403cc0 EFLAGS: 00010286
[   91.560457] RAX: 000077ff80000000 RBX: 00000000000186a0 RCX: 0000000180400035
[   91.560460] RDX: 0000000180400036 RSI: ffffea001418e740 RDI: ffffea0000000000
[   91.560463] RBP: ffffc90003403cd8 R08: 000000000639d201 R09: 0000000180400035
[   91.560467] R10: ffffebe000000600 R11: 0000000000000300 R12: ffff880500530030
[   91.560470] R13: ffffffffa01e70fc R14: 00000000ffffffff R15: ffff880500530000
[   91.560473] FS:  00007f7e500c3700(0000) GS:ffff88051ed80000(0000) knlGS:0000000000000000
[   91.560478] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   91.560480] CR2: ffffebe000000620 CR3: 0000000503103000 CR4: 00000000001406e0
[   91.560483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   91.560487] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   91.560489] Call Trace:
[   91.560530]  amd_powerplay_destroy+0x1c/0x60 [amdgpu]
[   91.560558]  amdgpu_pp_late_fini+0x44/0x60 [amdgpu]
[   91.560575]  amdgpu_fini+0x254/0x490 [amdgpu]
[   91.560593]  amdgpu_device_fini+0x58/0x1b0 [amdgpu]
[   91.560610]  amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu]
[   91.560622]  drm_dev_unregister+0x3c/0xe0 [drm]
[   91.560638]  amdgpu_pci_remove+0x19/0x30 [amdgpu]
[   91.560643]  pci_device_remove+0x39/0xc0
[   91.560648]  device_release_driver_internal+0x155/0x210
[   91.560651]  driver_detach+0x38/0x70
[   91.560655]  bus_remove_driver+0x4c/0xa0
[   91.560658]  driver_unregister+0x2c/0x40
[   91.560662]  pci_unregister_driver+0x21/0x90
[   91.560689]  amdgpu_exit+0x15/0x406 [amdgpu]
[   91.560694]  SyS_delete_module+0x1a8/0x270
[   91.560698]  ? exit_to_usermode_loop+0x92/0xa0
[   91.560702]  entry_SYSCALL_64_fastpath+0x13/0x94
[   91.560705] RIP: 0033:0x7f7e4fc118e7
[   91.560708] RSP: 002b:00007fff978ca118 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[   91.560713] RAX: ffffffffffffffda RBX: 000055afe21bc200 RCX: 00007f7e4fc118e7
[   91.560716] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055afe21bc268
[   91.560719] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999
[   91.560722] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff978c9100
[   91.560725] R13: 0000000000000000 R14: 0000000000000000 R15: 000055afe21bc200
[   91.560728] Code: 00 00 00 80 ff 77 00 00 48 bf 00 00 00 00 00 ea ff ff 49 01 da 48 0f 42 05 57 33 bd 00 49 01 c2 49 c1 ea 0c 49 c1 e2 06 49 01 fa <49> 8b 42 20 48 8d 78 ff a8 01 4c 0f 45 d7 49 8b 52 20 48 8d 42
[   91.560759] RIP: kfree+0x57/0x160 RSP: ffffc90003403cc0
[   91.560761] CR2: ffffebe000000620
[   91.560765] ---[ end trace 08a9f3cd82223c1d ]---

Fixes: 1c8638024846 (drm/amd/powerplay: refine powerplay interface.)
Signed-off-by: John Brooks <john@fastquake.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/ttm: Fix use-after-free in ttm_bo_clean_mm

We unref the man->move fence in ttm_bo_clean_mm() and then call
ttm_bo_force_list_clean() which waits on it, except the refcount is now
zero so a warning is generated (or worse):

[149492.279301] refcount_t: increment on 0; use-after-free.
[149492.279309] ------------[ cut here ]------------
[149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30
[149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(
-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
[149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1
[149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
[149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000
[149492.279329] RIP: 0010:refcount_inc+0x2b/0x30
[149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286
[149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000
[149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8
[149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee
[149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960
[149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178
[149492.279334] FS:  00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000
[149492.279335] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0
[149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[149492.279338] Call Trace:
[149492.279345]  ttm_bo_force_list_clean+0xb9/0x110 [ttm]
[149492.279348]  ttm_bo_clean_mm+0x7a/0xe0 [ttm]
[149492.279375]  amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu]
[149492.279392]  amdgpu_bo_fini+0x12/0x40 [amdgpu]
[149492.279415]  gmc_v7_0_sw_fini+0x32/0x40 [amdgpu]
[149492.279430]  amdgpu_fini+0x2c9/0x490 [amdgpu]
[149492.279445]  amdgpu_device_fini+0x58/0x1b0 [amdgpu]
[149492.279461]  amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu]
[149492.279470]  drm_dev_unregister+0x3c/0xe0 [drm]
[149492.279485]  amdgpu_pci_remove+0x19/0x30 [amdgpu]
[149492.279487]  pci_device_remove+0x39/0xc0
[149492.279490]  device_release_driver_internal+0x155/0x210
[149492.279491]  driver_detach+0x38/0x70
[149492.279493]  bus_remove_driver+0x4c/0xa0
[149492.279494]  driver_unregister+0x2c/0x40
[149492.279496]  pci_unregister_driver+0x21/0x90
[149492.279520]  amdgpu_exit+0x15/0x406 [amdgpu]
[149492.279523]  SyS_delete_module+0x1a8/0x270
[149492.279525]  ? exit_to_usermode_loop+0x92/0xa0
[149492.279528]  entry_SYSCALL_64_fastpath+0x13/0x94
[149492.279529] RIP: 0033:0x7fc53fcb68e7
[149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7
[149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268
[149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999
[149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0
[149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200
[149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff
[149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]---

Unref the fence *after* waiting for it.

v2: Set man->move to NULL after dropping the last ref (Christian König)

Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean)
Signed-off-by: John Brooks <john@fastquake.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/i915: Hold RPM wakelock while initializing OA buffer

OA buffer initialization involves access to HW registers to set
the OA base, head and tail. Ensure device is awake while setting
these. With this, all oa.ops are covered under RPM and forcewake
wakelock.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498585181-23048-1-git-send-email-sagar.a.kamble@intel.com
Fixes: d79651522e89c ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Cc: <stable@vger.kernel.org> # v4.11+
(cherry picked from commit 987f8c444aa2c33d98e7030d0c5f0a5325cc84ea)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming

The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
and hence the CURSOR_COEFF_MASK should be (0x3F << 0)

Fixes: 04416108ccea ("drm/i915/cnl: Add registers related to voltage
swing sequences.")
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498785241-21138-1-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit fcace3b9b727e25ffa3f7ad2c96e76b8584a9f3e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/cfl: Fix Workarounds.

During the review of Coffee Lake workarounds Mika pointed out
that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
should be removed from CFL and with that I should carry the rv-b.

However when doing the v2 I removed another Workaround that should
remain because although not mentioned by spec the history of hangs
around it advocates on its favor.

On some follow-up patches I continued operating on the wrong
workardound, but Ville noticed that, so here is the fix for the
current CFL code that is upstream already.

Fixes: 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake workarounds.")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
(cherry picked from commit 98eed3d1ade53596e1c8785e049f03da4480a820)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Avoid undefined behaviour of "u32 >> 32"

When computing a hash for looking up relocation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
halve it until the allocation succeeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting a value by the width of the operand is
undefined, so limit the smallest hash table we use to order 1.

v2: Keep the retry allocation flag for the final pass

Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to vma")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629150425.27508-1-chris@chris-wilson.co.uk
(cherry picked from commit 4d470f7359c4bf22518baa30700ad45649371a22)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: reintroduce VLV/CHV PFI programming power domain workaround

There are still cases on these platforms where an attempt is made to
configure the CDCLK while the power domain is off, like when coming back
from a suspend.  So the workaround below is still needed.

This effectively reverts commit 63ff30442519 ("drm/i915: Nuke the
VLV/CHV PFI programming power domain workaround").

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 886015a0ad43c7fc034b23ea4614ba39162f9ddd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix an error checking test

'dma_buf_vmap' returns NULL on error, not an error pointer.

Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627053854.21152-1-christophe.jaillet@wanadoo.fr
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 7c3f5317b8c2828ab10e8cf87c8ab5232d1966d0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Disable MSI for all pre-gen5

We have pretty clear evidence that MSIs are getting lost on g4x and
somehow the interrupt logic doesn't seem to recover from that state
even if we try hard to clear the IIR.

Disabling IER around the normal IIR clearing in the irq handler isn't
sufficient to avoid this, so the problem really seems to be further
up the interrupt chain. This should guarantee that there's always
an edge if any IIR bits are set after the interrupt handler is done,
which should normally guarantee that the CPU interrupt is generated.
That approach seems to work perfectly on VLV/CHV, but apparently
not on g4x.

MSI is documented to be broken on 965gm at least. The chipset spec
says MSI is defeatured because interrupts can be delayed or lost,
which fits well with what we're seeing on g4x. Previously we've
already disabled GMBUS interrupts on g4x because somehow GMBUS
manages to raise legacy interrupts even when MSI is enabled.

Since there's such widespread MSI breakahge all over in the pre-gen5
land let's just give up on MSI on these platforms.

Seqno reporting might be negatively affected by this since the legcy
interrupts aren't guaranteed to be ordered with the seqno writes,
whereas MSI interrupts may be? But an occasioanlly missed seqno
seems like a small price to pay for generally working interrupts.

Cc: stable@vger.kernel.org
Cc: Diego Viola <diego.viola@gmail.com>
Tested-by: Diego Viola <diego.viola@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb

All atomic state should be cleared when drm_modeset_backoff() is
called, because it drops all locks and the state becomes invalid.

The call to drm_atomic_state_clear was missing in atomic_remove_fb,
so add the missing call there.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629115954.26029-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.")
Cc: stable@vger.kernel.org # v4.12-rc1+

drm/amd/amdgpu: move get memory type function from early init to sw init

On PX system, it will get memory type before gpu post , and get unkown type.

Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/cgs: always set reference clock in mode_info

It's relevent regardless of whether there are displays
enabled.  Fixes garbage values for ref clock in powerplay
leading to incorrect fan speed reporting when displays
are disabled.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101653
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: fix vblank_time when displays are off

If the displays are off, set the vblank time to max to make
sure mclk switching is enabled.  Avoid mclk getting set
to high when no displays are attached.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101528
fixes: 09be4a5219 (drm/amd/powerplay/smu7: add vblank check for mclk switching (v2))
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Merge tag 'gvt-fixes-2017-06-29' of https://github.com/01org/gvt-linux into drm-intel-next-fixes

gvt-fixes-2017-06-29

- two race fixes for VFIO locks from Chuanxiao
- virtual display fix for BDW from Xiong

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629065424.kxopjbvntuakbyz2@zhen-hp.sh.intel.com

drm/amd/powerplay: power value format change for Vega10

Power value is an integer on vega10.

Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/gfx9: support the amdgpu.disable_cu option

This is ported from gfx8.

Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay: change PPSMC_MSG_GetCurrPkgPwr for Vega10

To follow up SMU FW 28.35.0.

Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Make amdgpu_cs_parser_init static (v2)

The function is called only once inside the .c file.
v2: update the commit message (Michel)

Signed-off-by: Alex Xie <AlexBin.Xie@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/cs: fix a typo in a comment

Signed-off-by: Alex Xie <AlexBin.Xie@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: Fix the exported always on CU bitmap

Newer asics with 4 SEs are not able to fit the entire bitmask in the
original field, use an array instead.

v2: keep cu_ao_mask for backward compatibility.

Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/gfx9: gfx_v9_0_enable_gfx_static_mg_power_gating() can be static

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup

Rather than casting and shifting.  Fixes sparse cast warnings.

Reviewed-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay/cz: print message if smc message fails

Helpful in debugging.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: fix typo in amdgpu_debugfs_test_ib_init

The debugfs interface has calls a function that was evidently
defined under the wrong name in some configurations:

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:64:12: error: 'amdgpu_debugfs_test_ib_ring_init' used but never defined [-Werror]
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3803:12: error: 'amdgpu_debugfs_test_ib_init' defined but not used [-Werror=unused-function]

This fixes the function name.

Fixes: 4f0955fcc052 ("drm/amdgpu: export test ib debugfs interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: enable mmhub pg on raven

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: add new flag AMD_PG_SUPPORT_MMHUB

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: add interface to enable/disable mmhub pg on raven

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: add mmhub pg init sequence on raven

MMHub Powergating init sequence.

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay: add support for ATOM GFXCLK table v2.

New vbios table format on some boards.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: fix the memory corruption on S3

psp->cmd will be used on resume phase, so we can not free it on hw_init.
Otherwise, a memory corruption will be triggered.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Xiaojie Yuan <Xiaojie.Yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: fix vulkan test performance drop and hang on VI

caused by not program dynamic_cu_mask_addr in the KIQ MQD.

v2: create struct vi_mqd_allocation in FB which will contain
1. PM4 MQD structure.
2. Write Pointer Poll Memory.
3. Read Pointer Report Memory
4. Dynamic CU Mask.
5. Dynamic RB Mask.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: vblank: Fix vblank timestamp update

Commit 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in
get_vblank_timestamp") inverted a condition by mistake that resulted in
vblank timestamps always being 0 on hardware without a vblank counter.
Fix it.

Fixes: 3fcdcb270936 ("drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp")
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629123720.27173-1-laurent.pinchart+renesas@ideasonboard.com

drm/i915/gvt: Make function dpy_reg_mmio_readx safe

The dpy_reg_mmio_read_x functions directly copy 4 bytes data to the
target address with considering the length. If may cause the target
memory corrupted if the requested length less than 4 bytes. Fix it
for safety even we already have some checking to avoid this happen.
And for convince, the 3 functions are merged.

Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Merge tag 'drm-intel-next-fixes-2017-06-27' of git://anongit.freedesktop.org/git/drm-intel into drm-next

Just three minor fixups for stuff in -next.

* tag 'drm-intel-next-fixes-2017-06-27' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Clear execbuf's vma backpointer upon release
  drm/i915: Pass the right flags to i915_vma_move_to_active()
  drm/i915/cnl: Fix RMW on ddi vswing sequence.

Merge tag 'drm-amdkfd-next-2017-06-25' of git://people.freedesktop.org/~gabbayo/linux into drm-next

amdkfd fixes

* tag 'drm-amdkfd-next-2017-06-25' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: Spelling s/apreture/aperture/
  drm/amdkfd: NULL dereference involving create_process()

Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next

- a fix from Eric for synchronization with etnaviv exported dma-bufs
- thermal throttle support for newer GPU cores
- updated module clock gating to work around GPU errata
- a fix to restore userspace buffer cache performance

* 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux:
  drm/etnaviv: restore ETNA_PREP_NOSYNC behaviour
  drm/etnaviv: implement cooling support for new GPU cores
  drm/etnaviv: update MLCG disables with info from newer Vivante driver
  drm/etnaviv: update common.xml.h
  drm/etnaviv: Expose our reservation object when exporting a dmabuf.

Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next-fixes

Backmerge drm-next with rc7

drm/mediatek: separate color module to fixup error memory reallocation

Previous patch (c5f228ef6c drm/mediatek: add *driver_data for different
hardware settings) calls devm_kfree() and then devm_kzalloc() to
reallocate color module data structure.  But this reallocation cannnot
guarantee the new address is unchanged, but the caller will use the
old address, which is wrong.

Fix it by separate color module from general components, this patch
separate color module to independent files, like mtk_disp_ovl.c and
mtk_disp_rdma.c do

Fixes: c5f228ef6ccd ("drm/mediatek: add *driver_data for different hardware settings")
Signed-off-by: YT Shen <yt.shen@mediatek.com>
Tested-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek>

drm/mediatek: check for memory allocation failure

If 'devm_kmalloc_array' returns NULL, we should return -ENOMEM as already
done a few lines above instead of deferencing a NULL pointer a few lines
below.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>

drm/mediatek: re-phrase DRM_INFO error message

The current message contains a spelling mistake and is not easily
parsable. Re-phrase it to be more understandable.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>

drm/mediatek: use platform_register_drivers

Use platform_register_drivers instead of open coding the iteration over
component platform drivers in the mtk_drm_drv and mtk_hdmi modules.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: CK Hu <ck.hu@mediatek.com>

drm/mediatek: Support UYVY and YUYV format for overlay

MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.

Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: CK Hu <ck.hu@mediatek.com>

drm/i915/gvt: Don't read ADPA_CRT_HOTPLUG_MONITOR from host

When host connects a crt screen, linux guest will detect two
screens: crt and dp. This is wrong as linux guest has only
one dp.

In order to avoid guest get host crt screen, we should set
ADPA_CRT_HOTPLUG_MONITOR to none. But MMIO_RO(PCH_ADPA) prevent
from that. So MMIO_DH should be used instead of MMIO_RO.

v2: Clear its staus to none at initialize, so guest don't
    get host crt.(Zhangyu)
v3: SKL doesn't have this register, limit it to pre_skl.(xiong)

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Set initial PORT_CLK_SEL vreg for BDW

On BDW, when host physical screen and guest virtual screen aren't on
the same DDI port, guest i915 driver prints the following error and
stop running.
[    6.775873] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000068
[    6.775928] IP: intel_ddi_clock_get+0x81/0x430 [i915]
[    6.776206] Call Trace:
[    6.776233]  ? vgpu_read32+0x4f/0x100 [i915]
[    6.776264]  intel_ddi_get_config+0x11c/0x230 [i915]
[    6.776298]  intel_modeset_setup_hw_state+0x313/0xd40 [i915]
[    6.776334]  intel_modeset_init+0xe49/0x18d0 [i915]
[    6.776368]  ? vgpu_write32+0x53/0x100 [i915]
[    6.776731]  ? intel_i2c_reset+0x42/0x50 [i915]
[    6.777085]  ? intel_setup_gmbus+0x32a/0x350 [i915]
[    6.777427]  i915_driver_load+0xabc/0x14d0 [i915]
[    6.777768]  i915_pci_probe+0x4f/0x70 [i915]

The null pointer is guest intel_crtc_state->shared_dpll which is
setted in haswell_get_ddi_pll(). When guest and host screen are
on different DDI port, host driver won't set PORT_CLK_SET(guest_port),
so haswell_get_ddi_pll() will return null and don't set
pipe_config->shared_dpll, once the following program refernce this
structure, it will print the above error.

This patch set the initial val of guest PORT_CLK_SEL(guest_port) to
LCPLL_810. And guest i915 driver will reset this value according to
guest screen mode.

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Backmerge tag 'v4.12-rc7' into drm-next

Linux 4.12-rc7

Needed at least rc6 for drm-misc-next-fixes, may as well go to rc7

DRM: Fix an incorrectly formatted table

The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
using "+" signs where "|" needs to be.  That, in turn, causes the PDF build
to fail.

Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170623140013.0703107a@lwn.net

drm/i915: Clear execbuf's vma backpointer upon release

commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the
execobjects array") jiggled around the error handling and replace a test
that we cleaned up properly after ourselves with an assertion. That
assertion failed because in the release function (moments after the
assertion) we were indeed forgetting to mark the vma as cleared. The
consequence was when testing an invalid relocation address, we would try
to release the vma twice (following the couple of attempts to verify the
address) and on the second release notice that the first release was
incomplete.

Testcase: igt/gem_reloc_overflow/invalid-address
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622104722.2583-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 51d05e1b29676a0425749a1533b87e3ad3c6f176)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pass the right flags to i915_vma_move_to_active()

i915_vma_move_to_active() takes the execobject flags and not a boolean!
Instead of passing EXEC_OBJECT_WRITE we passed true [i.e.
EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the
vma->last_fence access and since we forgot to clear that on unbinding,
we caused a use-after-free.

[  321.263854] BUG: KASAN: use-after-free in i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264001] Read of size 8 at addr ffff880100fc67d8 by task gem_exec_reloc/2868

[  321.264181] CPU: 0 PID: 2868 Comm: gem_exec_reloc Not tainted 4.12.0-rc6-CI-Custom_2759+ #1
[  321.264195] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F6 02/17/2015
[  321.264208] Call Trace:
[  321.264234]  dump_stack+0x67/0x99
[  321.264260]  print_address_description+0x77/0x290
[  321.264437]  ? i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264459]  kasan_report+0x269/0x350
[  321.264487]  __asan_report_load8_noabort+0x14/0x20
[  321.264660]  i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264841]  ? intel_ring_context_pin+0x131/0x690 [i915]
[  321.265021]  i915_gem_request_alloc+0x2c6/0x1220 [i915]
[  321.265044]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  321.265226]  i915_gem_do_execbuffer+0xac0/0x2a20 [i915]
[  321.265250]  ? __lock_acquire+0xceb/0x5450
[  321.265269]  ? entry_SYSCALL_64_fastpath+0x1c/0xb1
[  321.265291]  ? kvmalloc_node+0x6b/0x80
[  321.265310]  ? kvmalloc_node+0x6b/0x80
[  321.265489]  ? eb_relocate_slow+0xbe0/0xbe0 [i915]
[  321.265520]  ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[  321.265549]  ? debug_check_no_locks_freed+0x280/0x280
[  321.265591]  ? __might_fault+0xc6/0x1b0
[  321.265782]  i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[  321.265815]  drm_ioctl+0x4ba/0xaa0
[  321.265986]  ? i915_gem_execbuffer+0xde0/0xde0 [i915]
[  321.266017]  ? drm_getunique+0x270/0x270
[  321.266068]  do_vfs_ioctl+0x17f/0xfa0
[  321.266091]  ? __fget+0x1ba/0x330
[  321.266112]  ? lock_acquire+0x390/0x390
[  321.266133]  ? ioctl_preallocate+0x1d0/0x1d0
[  321.266164]  ? __fget+0x1db/0x330
[  321.266194]  ? __fget_light+0x79/0x1f0
[  321.266219]  SyS_ioctl+0x3c/0x70
[  321.266247]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  321.266265] RIP: 0033:0x7fcede207357
[  321.266279] RSP: 002b:00007ffef0effe58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  321.266307] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fcede207357
[  321.266321] RDX: 00007ffef0effef0 RSI: 0000000040406469 RDI: 0000000000000004
[  321.266335] RBP: ffffffff812097c6 R08: 0000000000000008 R09: 0000000000000000
[  321.266349] R10: 0000000000000008 R11: 0000000000000246 R12: ffff880116bcff98
[  321.266363] R13: ffffffff81cb7cb3 R14: ffff880116bcff70 R15: 0000000000000000
[  321.266385]  ? __this_cpu_preempt_check+0x13/0x20
[  321.266406]  ? trace_hardirqs_off_caller+0x1d6/0x2c0

[  321.266487] Allocated by task 2868:
[  321.266568]  save_stack_trace+0x16/0x20
[  321.266586]  kasan_kmalloc+0xee/0x180
[  321.266602]  kasan_slab_alloc+0x12/0x20
[  321.266620]  kmem_cache_alloc+0xc7/0x2e0
[  321.266795]  i915_vma_instance+0x28c/0x1540 [i915]
[  321.266964]  eb_lookup_vmas+0x5a7/0x2250 [i915]
[  321.267130]  i915_gem_do_execbuffer+0x69a/0x2a20 [i915]
[  321.267296]  i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[  321.267315]  drm_ioctl+0x4ba/0xaa0
[  321.267333]  do_vfs_ioctl+0x17f/0xfa0
[  321.267350]  SyS_ioctl+0x3c/0x70
[  321.267369]  entry_SYSCALL_64_fastpath+0x1c/0xb1

[  321.267428] Freed by task 177:
[  321.267502]  save_stack_trace+0x16/0x20
[  321.267521]  kasan_slab_free+0xad/0x180
[  321.267539]  kmem_cache_free+0xc5/0x340
[  321.267710]  i915_vma_unbind+0x666/0x10a0 [i915]
[  321.267880]  i915_vma_close+0x23a/0x2f0 [i915]
[  321.268048]  __i915_gem_free_objects+0x17d/0xc70 [i915]
[  321.268215]  __i915_gem_free_work+0x49/0x70 [i915]
[  321.268234]  process_one_work+0x66f/0x1410
[  321.268252]  worker_thread+0xe1/0xe90
[  321.268269]  kthread+0x304/0x410
[  321.268285]  ret_from_fork+0x27/0x40

[  321.268346] The buggy address belongs to the object at ffff880100fc6640
                which belongs to the cache i915_vma of size 656
[  321.268550] The buggy address is located 408 bytes inside of
                656-byte region [ffff880100fc6640, ffff880100fc68d0)
[  321.268741] The buggy address belongs to the page:
[  321.268837] page:ffffea000403f000 count:1 mapcount:0 mapping:          (null) index:0xffff880100fc5980 compound_mapcount: 0
[  321.269045] flags: 0x8000000000008100(slab|head)
[  321.269147] raw: 8000000000008100 0000000000000000 ffff880100fc5980 00000001001e001d
[  321.269312] raw: ffffea0004038e20 ffff880116b46240 ffff88011646c640 0000000000000000
[  321.269484] page dumped because: kasan: bad access detected

[  321.269665] Memory state around the buggy address:
[  321.269778]  ffff880100fc6680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.269949]  ffff880100fc6700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270115] >ffff880100fc6780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270279]                                                     ^
[  321.270410]  ffff880100fc6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270576]  ffff880100fc6880: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
[  321.270740] ==================================================================
[  321.270903] Disabling lock debugging due to kernel taint

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101511
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
(cherry picked from commit 25ffaa67459e988e73210543f7e05dfbf3f16163)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/cnl: Fix RMW on ddi vswing sequence.

Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.

v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).

Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497897572-22520-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit 1f588aeb60b4412019546ce596f179635abc2ac3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gvt: Fix inconsistent locks holding sequence

There are two kinds of locking sequence.

One is in the thread which is started by vfio ioctl to do
the iommu unmapping. The locking sequence is:
down_read(&group_lock) ----> mutex_lock(&cached_lock)

The other is in the vfio release thread which will unpin all
the cached pages. The lock sequence is:
mutex_lock(&cached_lock) ---> down_read(&group_lock)

And, the cache_lock is used to protect the rb tree of the cache
node and doing vfio unpin doesn't require this lock. Move the
vfio unpin out of the cache_lock protected region.

v2:
- use for style instead of do{}while(1). (Zhenyu)

Fixes: f30437c5e7bf ("drm/i915/gvt: add KVMGT support")
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Fix possible recursive locking issue

vfio_unpin_pages will hold a read semaphore however it is already hold
in the same thread by vfio ioctl. It will cause below warning:

[ 5102.127454] ============================================
[ 5102.133379] WARNING: possible recursive locking detected
[ 5102.139304] 4.12.0-rc4+ #3 Not tainted
[ 5102.143483] --------------------------------------------
[ 5102.149407] qemu-system-x86/1620 is trying to acquire lock:
[ 5102.155624]  (&container->group_lock){++++++}, at: [<ffffffff817768c6>] vfio_unpin_pages+0x96/0xf0
[ 5102.165626]
but task is already holding lock:
[ 5102.172134]  (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.182522]
other info that might help us debug this:
[ 5102.189806]  Possible unsafe locking scenario:

[ 5102.196411]        CPU0
[ 5102.199136]        ----
[ 5102.201861]   lock(&container->group_lock);
[ 5102.206527]   lock(&container->group_lock);
[ 5102.211191]
*** DEADLOCK ***

[ 5102.217796]  May be due to missing lock nesting notation

[ 5102.225370] 3 locks held by qemu-system-x86/1620:
[ 5102.230618]  #0:  (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.241482]  #1:  (&(&iommu->notifier)->rwsem){++++..}, at: [<ffffffff810de775>] __blocking_notifier_call_chain+0x35/0x70
[ 5102.253713]  #2:  (&vgpu->vdev.cache_lock){+.+...}, at: [<ffffffff8157b007>] intel_vgpu_iommu_notifier+0x77/0x120
[ 5102.265163]
stack backtrace:
[ 5102.270022] CPU: 5 PID: 1620 Comm: qemu-system-x86 Not tainted 4.12.0-rc4+ #3
[ 5102.277991] Hardware name: Intel Corporation S1200RP/S1200RP, BIOS S1200RP.86B.03.01.APER.061220151418 06/12/2015
[ 5102.289445] Call Trace:
[ 5102.292175]  dump_stack+0x85/0xc7
[ 5102.295871]  validate_chain.isra.21+0x9da/0xaf0
[ 5102.300925]  __lock_acquire+0x405/0x820
[ 5102.305202]  lock_acquire+0xc7/0x220
[ 5102.309191]  ? vfio_unpin_pages+0x96/0xf0
[ 5102.313666]  down_read+0x2b/0x50
[ 5102.317259]  ? vfio_unpin_pages+0x96/0xf0
[ 5102.321732]  vfio_unpin_pages+0x96/0xf0
[ 5102.326024]  intel_vgpu_iommu_notifier+0xe5/0x120
[ 5102.331283]  notifier_call_chain+0x4a/0x70
[ 5102.335851]  __blocking_notifier_call_chain+0x4d/0x70
[ 5102.341490]  blocking_notifier_call_chain+0x16/0x20
[ 5102.346935]  vfio_iommu_type1_ioctl+0x87b/0x920
[ 5102.351994]  vfio_fops_unl_ioctl+0x81/0x280
[ 5102.356660]  ? __fget+0xf0/0x210
[ 5102.360261]  do_vfs_ioctl+0x93/0x6a0
[ 5102.364247]  ? __fget+0x111/0x210
[ 5102.367942]  SyS_ioctl+0x41/0x70
[ 5102.371542]  entry_SYSCALL_64_fastpath+0x1f/0xbe

put the vfio_unpin_pages in a workqueue can fix this.

v2:
- use for style instead of do{}while(1). (Zhenyu)
v3:
- rename gvt_cache_mark to gvt_cache_mark_remove. (Zhenyu)

Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Linux 4.12-rc7

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fix from Thomas Gleixner:
 "A single fix to unbreak the vdso32 build for 64bit kernels caused by
  excess #includes in the mshyperv header"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mshyperv: Remove excess #includes from mshyperv.h

Merge branch 'timers-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull timer fixes from Thomas Gleixner:
 "A few fixes for timekeeping and timers:

   - Plug a subtle race due to a missing READ_ONCE() in the timekeeping
     code where reloading of a pointer results in an inconsistent
     callback argument being supplied to the clocksource->read function.

   - Correct the CLOCK_MONOTONIC_RAW sub-nanosecond accounting in the
     time keeping core code, to prevent a possible discontuity.

   - Apply a similar fix to the arm64 vdso clock_gettime()
     implementation

   - Add missing includes to clocksource drivers, which relied on
     indirect includes which fails in certain configs.

   - Use the proper iomem pointer for read/iounmap in a probe function"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW
  time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
  time: Fix clock->read(clock) race around clocksource changes
  clocksource: Explicitly include linux/clocksource.h when needed
  clocksource/drivers/arm_arch_timer: Fix read and iounmap of incorrect variable

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Thomas Gleixner:
 "Three fixlets for perf:

   - Return the proper error code if aux buffers for a event are not
     supported.

   - Calculate the probe offset for inlined functions correctly

   - Update the Skylake DTLB load/store miss event so it can count 1G
     TLB entries as well"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf probe: Fix probe definition for inlined functions
  perf/x86/intel: Add 1G DTLB load/store miss support for SKL
  perf/aux: Correct return code of rb_alloc_aux() if !has_aux(ev)

Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq fix from Thomas Gleixner:
 "A single fix for the MIPS GIC to prevent ftrace recursion"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/mips-gic: Mark count and compare accessors notrace

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input fixes from Dmitry Torokhov:

 - a quirk to i8042 to ignore timeout bit on Lifebook AH544

 - a fixup to Synaptics RMI function 54 that was breaking some Dells

 - a fix for memory leak in soc_button_array driver

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics-rmi4 - only read the F54 query registers which are used
  Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
  Input: soc_button_array - fix leaking the ACPI button descriptor buffer

Merge git://git./linux/kernel/git/nab/target-pending

Pull SCSI target fixes from Nicholas Bellinger:
 "Here are the target-pending fixes for v4.12-rc7 that have been queued
  up for the last 2 weeks. This includes:

   - Fix a TMR related kref underflow detected by the recent refcount_t
     conversion in upstream.

   - Fix a iscsi-target corner case during explicit connection logout
     timeout failure.

   - Address last fallout in iscsi-target immediate data handling from
     v4.4 target-core now allowing control CDB payload underflow"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  iscsi-target: Reject immediate data underflow larger than SCSI transfer length
  iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP
  target: Fix kref->refcount underflow in transport_cmd_finish_abort

Merge tag 'kbuild-fixes-v4.12-2' of git://git./linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:
 "Nothing scary, just some random fixes:

   - fix warnings of host programs

   - fix "make tags" when COMPILED_SOURCE=1 is specified along with O=

   - clarify help message of C=1 option

   - fix dependency for ncurses compatibility check

   - fix "make headers_install" for fakechroot environment"

* tag 'kbuild-fixes-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kconfig: fix sparse warnings in nconfig
  kbuild: fix header installation under fakechroot environment
  kconfig: Check for libncurses before menuconfig
  Kbuild: tiny correction on `make help`
  tags: honor COMPILED_SOURCE with apart output directory
  genksyms: add printf format attribute to error_with_pos()

Merge branch 'for-linus' of git://git./linux/kernel/git/ebiederm/user-namespace

Pull timer fix from Eric Biederman:
 "This fixes an issue of confusing injected signals with the signals
  from posix timers that has existed since posix timers have been in the
  kernel.

  This patch is slightly simpler than my earlier version of this patch
  as I discovered in testing that I had misspelled "#ifdef
  CONFIG_POSIX_TIMERS". So I deleted that unnecessary test and made
  setting of resched_timer uncondtional.

  I have tested this and verified that without this patch there is a
  nasty hang that is easy to trigger, and with this patch everything
  works properly"

Thomas Gleixner dixit:
 "It fixes the problem at hand and covers the ptrace case as well, which
  I missed.

Reviewed-and-tested-by: Thomas Gleixner <tglx@linutronix.de>"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
  signal: Only reschedule timers on signals timers have sent

x86/mshyperv: Remove excess #includes from mshyperv.h

A recent commit included linux/slab.h in linux/irq.h. This breaks the build
of vdso32 on a 64-bit kernel.

The reason is that linux/irq.h gets included into the vdso code via
linux/interrupt.h which is included from asm/mshyperv.h. That makes the
32-bit vdso compile fail, because slab.h includes the pgtable headers for
64-bit on a 64-bit build.

Neither linux/clocksource.h nor linux/interrupt.h are needed in the
mshyperv.h header file itself - it has a dependency on <linux/atomic.h>.

Remove the includes and unbreak the build.

Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: devel@linuxdriverproject.org
Fixes: dee863b571b0 ("hv: export current Hyper-V clocksource")
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1706231038460.2647@nanos
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'powerpc-4.12-7' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Some more powerpc fixes for 4.12. Most of these actually came in last
  week but got held up for some more testing.

   - three fixes for kprobes/ftrace/livepatch interactions.

   - properly handle data breakpoints when using the Radix MMU.

   - fix for perf sampling of registers during call_usermodehelper().

   - properly initialise the thread_info on our emergency stacks

   - add an explicit flush when doing TLB invalidations for a process
     using NPU2.

  Thanks to: Alistair Popple, Naveen N. Rao, Nicholas Piggin, Ravi
  Bangoria, Masami Hiramatsu"

* tag 'powerpc-4.12-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/64: Initialise thread_info for emergency stacks
  powerpc/powernv/npu-dma: Add explicit flush when sending an ATSD
  powerpc/perf: Fix oops when kthread execs user process
  powerpc/64s: Handle data breakpoints in Radix mode
  powerpc/kprobes: Skip livepatch_handler() for jprobes
  powerpc/ftrace: Pass the correct stack pointer for DYNAMIC_FTRACE_WITH_REGS
  powerpc/kprobes: Pause function_graph tracing during jprobes handling

Merge tag 'acpi-4.12-rc7' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI fix from Rafael Wysocki:
 "This fixes the ACPI-based enumeration of some I2C and SPI devices
  broken in 4.11.

  Specifics:

   - I2C and SPI devices are expected to be enumerated by the I2C and
     SPI subsystems, respectively, but due to a change made during the
     4.11 cycle, in some cases the ACPI core marks them as already
     enumerated which causes the I2C and SPI subsystems to overlook
     them, so fix that (Jarkko Nikula)"

* tag 'acpi-4.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / scan: Fix enumeration for special SPI and I2C devices

Merge branch 'i2c/for-current-fixed' of git://git./linux/kernel/git/wsa/linux

Pull i2c fix from Wolfram Sang.

* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: imx: Use correct function to write to register

Merge tag 'gpio-v4.12-3' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fix from Linus Walleij:
 "A single GPIO patch fixing the compatible string for the MVEBU PWM
  controller embedded in the GPIO controller before we release v4.12.
  Hopefully"

* tag 'gpio-v4.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: mvebu: change compatible string for PWM support

Merge tag 'sound-4.12-rc7' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Nothing exciting here, just a few stable fixes:

   - suppress spurious kernel WARNING in PCM core

   - fix potential spin deadlock at error handling in firewire

   - HD-audio PCI ID addition / fixup"

* tag 'sound-4.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Apply quirks to Broxton-T, too
  ALSA: firewire-lib: Fix stall of process context at packet error
  ALSA: pcm: Don't treat NULL chmap as a fatal error
  ALSA: hda - Add Coffelake PCI ID

Merge tag 'drm-fixes-for-v4.12-rc7' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "A varied bunch of fixes, one for an API regression with connectors.

  Otherwise amdgpu and i915 have a bunch of varied fixes, the shrinker
  ones being the most important"

* tag 'drm-fixes-for-v4.12-rc7' of git://people.freedesktop.org/~airlied/linux:
  drm: Fix GETCONNECTOR regression
  drm/radeon: add a quirk for Toshiba Satellite L20-183
  drm/radeon: add a PX quirk for another K53TK variant
  drm/amdgpu: adjust default display clock
  drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
  drm/amdgpu: add Polaris12 DID
  drm/i915: Don't enable backlight at setup time.
  drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()
  drm/i915: Fix deadlock witha the pipe A quirk during resume
  drm/i915: Remove __GFP_NORETRY from our buffer allocator
  drm/i915: Encourage our shrinker more when our shmemfs allocations fails
  drm/i915: Differentiate between sw write location into ring and last hw read

Merge tag 'random_for_linus_stable' of git://git./linux/kernel/git/tytso/random

Pull random fixes from Ted Ts'o:
 "Fix some locking and gcc optimization issues from the most recent
  random_for_linus_stable pull request"

* tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  random: silence compiler warnings and fix race

Merge tag 'for-4.12/dm-fixes-4' of git://git./linux/kernel/git/device-mapper/linux-dm

Pull device mapper fixes from Mike Snitzer:

 - a revert of a DM mirror commit that has proven to make the code prone
   to crash

 - a DM io reference count fix that resolves a NULL pointer seen when
   issuing discards to a DM mirror target's device whose mirror legs do
   not all support discards

 - a couple DM integrity fixes

* tag 'for-4.12/dm-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm io: fix duplicate bio completion due to missing ref count
  dm integrity: fix to not disable/enable interrupts from interrupt context
  Revert "dm mirror: use all available legs on multiple failures"
  dm integrity: reject mappings too large for device

Merge branch 'akpm' (patches from Andrew)

Merge misc fixes from Andrew Morton:
 "8 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  fs/exec.c: account for argv/envp pointers
  ocfs2: fix deadlock caused by recursive locking in xattr
  slub: make sysfs file removal asynchronous
  lib/cmdline.c: fix get_options() overflow while parsing ranges
  fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
  autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
  mm/vmalloc.c: huge-vmap: fail gracefully on unexpected huge vmap mappings
  mm, thp: remove cond_resched from __collapse_huge_page_copy

fs/exec.c: account for argv/envp pointers

When limiting the argv/envp strings during exec to 1/4 of the stack limit,
the storage of the pointers to the strings was not included.  This means
that an exec with huge numbers of tiny strings could eat 1/4 of the stack
limit in strings and then additional space would be later used by the
pointers to the strings.

For example, on 32-bit with a 8MB stack rlimit, an exec with 1677721
single-byte strings would consume less than 2MB of stack, the max (8MB /
4) amount allowed, but the pointers to the strings would consume the
remaining additional stack space (1677721 * 4 == 6710884).

The result (1677721 + 6710884 == 8388605) would exhaust stack space
entirely.  Controlling this stack exhaustion could result in
pathological behavior in setuid binaries (CVE-2017-1000365).

[akpm@linux-foundation.org: additional commenting from Kees]
Fixes: b6a2fea39318 ("mm: variable length argument support")
Link: http://lkml.kernel.org/r/20170622001720.GA32173@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ocfs2: fix deadlock caused by recursive locking in xattr

Another deadlock path caused by recursive locking is reported.  This
kind of issue was introduced since commit 743b5f1434f5 ("ocfs2: take
inode lock in ocfs2_iop_set/get_acl()").  Two deadlock paths have been
fixed by commit b891fa5024a9 ("ocfs2: fix deadlock issue when taking
inode lock at vfs entry points").  Yes, we intend to fix this kind of
case in incremental way, because it's hard to find out all possible
paths at once.

This one can be reproduced like this.  On node1, cp a large file from
home directory to ocfs2 mountpoint.  While on node2, run
setfacl/getfacl.  Both nodes will hang up there.  The backtraces:

On node1:
  __ocfs2_cluster_lock.isra.39+0x357/0x740 [ocfs2]
  ocfs2_inode_lock_full_nested+0x17d/0x840 [ocfs2]
  ocfs2_write_begin+0x43/0x1a0 [ocfs2]
  generic_perform_write+0xa9/0x180
  __generic_file_write_iter+0x1aa/0x1d0
  ocfs2_file_write_iter+0x4f4/0xb40 [ocfs2]
  __vfs_write+0xc3/0x130
  vfs_write+0xb1/0x1a0
  SyS_write+0x46/0xa0

On node2:
  __ocfs2_cluster_lock.isra.39+0x357/0x740 [ocfs2]
  ocfs2_inode_lock_full_nested+0x17d/0x840 [ocfs2]
  ocfs2_xattr_set+0x12e/0xe80 [ocfs2]
  ocfs2_set_acl+0x22d/0x260 [ocfs2]
  ocfs2_iop_set_acl+0x65/0xb0 [ocfs2]
  set_posix_acl+0x75/0xb0
  posix_acl_xattr_set+0x49/0xa0
  __vfs_setxattr+0x69/0x80
  __vfs_setxattr_noperm+0x72/0x1a0
  vfs_setxattr+0xa7/0xb0
  setxattr+0x12d/0x190
  path_setxattr+0x9f/0xb0
  SyS_setxattr+0x14/0x20

Fix this one by using ocfs2_inode_{lock|unlock}_tracker, which is
exported by commit 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking logic
to avoid recursive cluster lock").

Link: http://lkml.kernel.org/r/20170622014746.5815-1-zren@suse.com
Fixes: 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
Signed-off-by: Eric Ren <zren@suse.com>
Reported-by: Thomas Voegtle <tv@lio96.de>
Tested-by: Thomas Voegtle <tv@lio96.de>
Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

slub: make sysfs file removal asynchronous

Commit bf5eb3de3847 ("slub: separate out sysfs_slab_release() from
sysfs_slab_remove()") made slub sysfs file removals synchronous to
kmem_cache shutdown.

Unfortunately, this created a possible ABBA deadlock between slab_mutex
and sysfs draining mechanism triggering the following lockdep warning.

  ======================================================
  [ INFO: possible circular locking dependency detected ]
  4.10.0-test+ #48 Not tainted
  -------------------------------------------------------
  rmmod/1211 is trying to acquire lock:
   (s_active#120){++++.+}, at: [<ffffffff81308073>] kernfs_remove+0x23/0x40

  but task is already holding lock:
   (slab_mutex){+.+.+.}, at: [<ffffffff8120f691>] kmem_cache_destroy+0x41/0x2d0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (slab_mutex){+.+.+.}:
 lock_acquire+0xf6/0x1f0
 __mutex_lock+0x75/0x950
 mutex_lock_nested+0x1b/0x20
 slab_attr_store+0x75/0xd0
 sysfs_kf_write+0x45/0x60
 kernfs_fop_write+0x13c/0x1c0
 __vfs_write+0x28/0x120
 vfs_write+0xc8/0x1e0
 SyS_write+0x49/0xa0
 entry_SYSCALL_64_fastpath+0x1f/0xc2

  -> #0 (s_active#120){++++.+}:
 __lock_acquire+0x10ed/0x1260
 lock_acquire+0xf6/0x1f0
 __kernfs_remove+0x254/0x320
 kernfs_remove+0x23/0x40
 sysfs_remove_dir+0x51/0x80
 kobject_del+0x18/0x50
 __kmem_cache_shutdown+0x3e6/0x460
 kmem_cache_destroy+0x1fb/0x2d0
 kvm_exit+0x2d/0x80 [kvm]
 vmx_exit+0x19/0xa1b [kvm_intel]
 SyS_delete_module+0x198/0x1f0
 entry_SYSCALL_64_fastpath+0x1f/0xc2

  other info that might help us debug this:

   Possible unsafe locking scenario:

 CPU0                    CPU1
 ----                    ----
    lock(slab_mutex);
 lock(s_active#120);
 lock(slab_mutex);
    lock(s_active#120);

   *** DEADLOCK ***

  2 locks held by rmmod/1211:
   #0:  (cpu_hotplug.dep_map){++++++}, at: [<ffffffff810a7877>] get_online_cpus+0x37/0x80
   #1:  (slab_mutex){+.+.+.}, at: [<ffffffff8120f691>] kmem_cache_destroy+0x41/0x2d0

  stack backtrace:
  CPU: 3 PID: 1211 Comm: rmmod Not tainted 4.10.0-test+ #48
  Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
  Call Trace:
   print_circular_bug+0x1be/0x210
   __lock_acquire+0x10ed/0x1260
   lock_acquire+0xf6/0x1f0
   __kernfs_remove+0x254/0x320
   kernfs_remove+0x23/0x40
   sysfs_remove_dir+0x51/0x80
   kobject_del+0x18/0x50
   __kmem_cache_shutdown+0x3e6/0x460
   kmem_cache_destroy+0x1fb/0x2d0
   kvm_exit+0x2d/0x80 [kvm]
   vmx_exit+0x19/0xa1b [kvm_intel]
   SyS_delete_module+0x198/0x1f0
   ? SyS_delete_module+0x5/0x1f0
   entry_SYSCALL_64_fastpath+0x1f/0xc2

It'd be the cleanest to deal with the issue by removing sysfs files
without holding slab_mutex before the rest of shutdown; however, given
the current code structure, it is pretty difficult to do so.

This patch punts sysfs file removal to a work item.  Before commit
bf5eb3de3847, the removal was punted to a RCU delayed work item which is
executed after release.  Now, we're punting to a different work item on
shutdown which still maintains the goal removing the sysfs files earlier
when destroying kmem_caches.

Link: http://lkml.kernel.org/r/20170620204512.GI21326@htj.duckdns.org
Fixes: bf5eb3de3847 ("slub: separate out sysfs_slab_release() from sysfs_slab_remove()")
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lib/cmdline.c: fix get_options() overflow while parsing ranges

When using get_options() it's possible to specify a range of numbers,
like 1-100500.  The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.

Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
Signed-off-by: Ilya V. Matveychikov <matvejchikov@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs/dax.c: fix inefficiency in dax_writeback_mapping_range()

dax_writeback_mapping_range() fails to update iteration index when
searching radix tree for entries needing cache flushing.  Thus each
pagevec worth of entries is searched starting from the start which is
inefficient and prone to livelocks.  Update index properly.

Link: http://lkml.kernel.org/r/20170619124531.21491-1-jack@suse.cz
Fixes: 9973c98ecfda3 ("dax: add support for fsync/sync")
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>