1. 27 4月, 2016 2 次提交
    • L
      drm/dp/mst: Restore primary hub guid on resume · 9dc0487d
      Lyude 提交于
      Some hubs are forgetful, and end up forgetting whatever GUID we set
      previously after we do a suspend/resume cycle. This can lead to
      hotplugging breaking (along with probably other things) since the hub
      will start sending connection notifications with the wrong GUID. As
      such, we need to check on resume whether or not the GUID the hub is
      giving us is valid.
      Signed-off-by: NLyude <cpaul@redhat.com>
      Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9dc0487d
    • C
      drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() · 263efde3
      cpaul@redhat.com 提交于
      We can thank KASAN for finding this, otherwise I probably would have spent
      hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
      while enabling MST where the port we were currently updating the payload on
      would have all of it's refs dropped before we finished what we were doing:
      
      ==================================================================
      BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
      Read of size 4 by task Xorg/973
      =============================================================================
      BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
      	___slab_alloc+0x472/0x490
      	__slab_alloc+0x20/0x40
      	kmem_cache_alloc_trace+0x151/0x190
      	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
      	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
      	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
      	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
      	__slab_free+0x17f/0x2d0
      	kfree+0x169/0x180
      	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
      	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      
      which on this T460s, would eventually lead to kernel panics in somewhat
      random places later in intel_mst_enable_dp() if we got lucky enough.
      Signed-off-by: NLyude <cpaul@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      263efde3
  2. 22 4月, 2016 8 次提交
  3. 21 4月, 2016 1 次提交
  4. 18 4月, 2016 13 次提交
  5. 14 4月, 2016 2 次提交
  6. 12 4月, 2016 7 次提交
  7. 07 4月, 2016 5 次提交
    • J
    • B
      drm/i915: fix deadlock on lid open · 42bf7b46
      Bjørn Mork 提交于
      commit e2c8b870 moved modeset locking inside resume/suspend
      functions, but missed a code path only executed on lid close/open
      on older hardware. The result was a deadlock when closing and
      opening the lid without suspending on such hardware:
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.6.0-rc1 #385 Not tainted
       ---------------------------------------------
       kworker/0:3/88 is trying to acquire lock:
        (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
      
       but task is already holding lock:
        (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&dev->mode_config.mutex);
         lock(&dev->mode_config.mutex);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       7 locks held by kworker/0:3/88:
        #0:  ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
        #1:  ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
        #2:  ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
        #3:  (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
        #4:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
        #5:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
        #6:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]
      
       stack backtrace:
       CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
       Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       Workqueue: kacpi_notify acpi_os_execute_deferred
        0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
        ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
        000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
       Call Trace:
        [<ffffffff8124af06>] dump_stack+0x67/0x90
        [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
        [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
        [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb
        [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
        [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
        [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
        [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
        [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
        [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
        [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
        [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
        [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
        [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b
        [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
        [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
        [<ffffffff81068f17>] process_one_work+0x265/0x50b
        [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd
        [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
        [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
        [<ffffffff8106e2d6>] kthread+0xe0/0xe8
        [<ffffffff8107bc47>] ? local_clock+0x19/0x22
        [<ffffffff81484f42>] ret_from_fork+0x22/0x40
        [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5
      
      Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.")
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
      (cherry picked from commit 9f54d4bd)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      42bf7b46
    • D
      drm/radeon: use helper for mst connector dpms. · f3d58dcc
      Dave Airlie 提交于
      I noticed my monitor didn't power off when it should,
      this should fix it.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f3d58dcc
    • D
      drm/radeon/mst: port some MST setup code from DAL. · 4b814aac
      Dave Airlie 提交于
      This ports the DAL timeouts and MST rate calculations
      for the hw from the DAL codebase.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      4b814aac
    • C
  8. 06 4月, 2016 2 次提交