mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-26 06:33:19 -04:00
drm/dp/mst: close deadlock in connector destruction.
I've only seen this once, and I failed to capture the lockdep backtrace, but I did some investigations. If we are calling into the MST layer from EDID probing, we have the mode_config mutex held, if during that EDID probing, the MST hub goes away, then we can get a deadlock where the connector destruction function in the driver tries to retake the mode config mutex. This offloads connector destruction to a workqueue, and avoid the subsequenct lock ordering issue. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit is contained in:
parent
8b72ce158c
commit
6b8eeca65b
3 changed files with 44 additions and 2 deletions
|
|
@ -743,6 +743,8 @@ struct drm_connector {
|
|||
uint8_t num_h_tile, num_v_tile;
|
||||
uint8_t tile_h_loc, tile_v_loc;
|
||||
uint16_t tile_h_size, tile_v_size;
|
||||
|
||||
struct list_head destroy_list;
|
||||
};
|
||||
|
||||
/**
|
||||
|
|
|
|||
|
|
@ -463,6 +463,10 @@ struct drm_dp_mst_topology_mgr {
|
|||
struct work_struct work;
|
||||
|
||||
struct work_struct tx_work;
|
||||
|
||||
struct list_head destroy_connector_list;
|
||||
struct mutex destroy_connector_lock;
|
||||
struct work_struct destroy_connector_work;
|
||||
};
|
||||
|
||||
int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr, struct device *dev, struct drm_dp_aux *aux, int max_dpcd_transaction_bytes, int max_payloads, int conn_base_id);
|
||||
|
|
|
|||
Loading…
Reference in a new issue