Re: [PATCH v2 10/14] drm/solomon: ssd16xx: Expose session management as plane properties

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] drm/solomon: stale plane properties used in CRTC hooks due to sync ordering
- [Medium] drm/solomon: unprotected concurrent access to global device properties
--

commit 16a8f4fa23daecbcef4ac45581fba368964d7807
Author: Devarsh Thakkar <devarsht@ti.com>

drm/solomon: ssd16xx: Expose session management as plane properties

This commit adds DRM plane properties for session management flags,
allowing userspace to control automatic display clear/refresh behavior
at lifecycle transitions.

> diff --git a/drivers/gpu/drm/solomon/ssd16xx.c b/drivers/gpu/drm/solomon/ssd16xx.c
> index 3815af0cee5c5..6331f367d8649 100644
> --- a/drivers/gpu/drm/solomon/ssd16xx.c
> +++ b/drivers/gpu/drm/solomon/ssd16xx.c
[ ... ]
> @@ -1588,6 +1670,10 @@ static void ssd16xx_plane_atomic_update(struct drm_plane *plane,
>  
>  	device->refresh_mode = new_ssd->refresh_mode;
>  	device->color_mode = new_ssd->color_mode;
> +	device->clear_on_init = new_ssd->clear_on_init;
> +	device->clear_on_close = new_ssd->clear_on_close;
> +	device->clear_on_disable = new_ssd->clear_on_disable;
> +	device->refresh_mode_init = new_ssd->refresh_mode_init;

[Severity: Medium]
Since ssd16xx_plane_atomic_update() returns early if there is no framebuffer:

static void ssd16xx_plane_atomic_update(...)
{
        ...
        if (!fb)
                return;

Will these device property assignments be skipped entirely when the plane
is being disabled?

Additionally, doesn't drm_atomic_helper_commit_tail_rpm() call the CRTC
enable and disable hooks before the plane update? If a user submits an
atomic commit that updates clear_on_disable and disables the CRTC at
the same time, won't ssd16xx_crtc_atomic_disable() read the stale global
device property before this plane update has a chance to synchronize the
new atomic state?

[Severity: Medium]
Is it safe to write to global device properties like device->clear_on_close
here? This code executes under DRM modeset locks, but if another client
closes its DRM file descriptor, wouldn't ssd16xx_drm_master_drop() read
these same properties under drm_device->master_mutex?

Since they don't share locks, could this lead to a data race where the
master drop path reads torn or stale values while an atomic commit is
processing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927182329.4193961-1-devarsht@ti.com?part=10