On 26.03.2019 11:31, Tomi Valkeinen wrote:
> In tc_bridge_mode_set callback, we store the pointer to the given
> drm_display_mode, and use the mode later. Storing a pointer in such a
> way looks very suspicious to me, and I have observed odd issues where
> the timings were apparently (at least mostly) zero.
>
> Do a copy of the drm_display_mode instead to ensure we don't refer to
> freed/modified data.


Why not tc->bridge.encoder->crtc->state->adjusted_mode or

tc->bridge.encoder->crtc->state->mode ?


They should exists if the mode is set.


Regards

Andrzej


>
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 114d535c296b..8732d5b05453 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -205,7 +205,7 @@ struct tc_data {
>       /* display edid */
>       struct edid             *edid;
>       /* current mode */
> -     const struct drm_display_mode   *mode;
> +     struct drm_display_mode mode;
>  
>       u32                     rev;
>       u8                      assr;
> @@ -1021,12 +1021,12 @@ static int tc_stream_enable(struct tc_data *tc)
>       /* PXL PLL setup */
>       if (tc_test_pattern) {
>               ret = tc_pxl_pll_en(tc, clk_get_rate(tc->refclk),
> -                                 1000 * tc->mode->clock);
> +                                 1000 * tc->mode.clock);
>               if (ret)
>                       goto err;
>       }
>  
> -     ret = tc_set_video_mode(tc, tc->mode);
> +     ret = tc_set_video_mode(tc, &tc->mode);
>       if (ret)
>               goto err;
>  
> @@ -1166,7 +1166,7 @@ static void tc_bridge_mode_set(struct drm_bridge 
> *bridge,
>  {
>       struct tc_data *tc = bridge_to_tc(bridge);
>  
> -     tc->mode = mode;
> +     tc->mode = *mode;
>  }
>  
>  static int tc_connector_get_modes(struct drm_connector *connector)


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to