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 <[email protected]> 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/[email protected]?part=10
