Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

2018-09-20 Thread Harry Wentland
On 2018-09-18 07:06 PM, Lyude Paul wrote: > Currently the way that we prevent userspace from performing new modesets > on MST connectors that have just been destroyed is rather broken. > There's nothing in the actual DRM DP MST topology helpers that checks > whether or not a connector still

Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

2018-09-20 Thread Dan Carpenter
Hi Lyude, Thank you for the patch! Perhaps something to improve: url: https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes-with-MST/20180919-203434 base: git://anongit.freedesktop.org/drm-intel for-linux-next smatch warnings:

Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)

2018-09-19 Thread Lyude Paul
oh, good catch! will fix and respin in just a little bit On Wed, 2018-09-19 at 22:38 +0200, Julia Lawall wrote: > Hello, > > I don't think you can update the loop index variable in > list_for_each_entry, because the mcro uses th index variable to get to the > next element. Perhaps

Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() (fwd)

2018-09-19 Thread Julia Lawall
Hello, I don't think you can update the loop index variable in list_for_each_entry, because the mcro uses th index variable to get to the next element. Perhaps list_for_each_entry_safe would be more suitable? julia -- Forwarded message -- Date: Thu, 20 Sep 2018 04:30:13 +0800

[Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

2018-09-18 Thread Lyude Paul
Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own,