Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] The driver calls sleeping functions (usleep_range, msleep, spi_write) 
from CRTC atomic_enable/atomic_disable and Plane atomic_update callbacks, which 
are designated as atomic context paths by the DRM subsystem guidelines where 
sleeping is strictly forbidden.
--

commit a9d5c4bd0a5df0b653500203f8b4425d59185b78
Author: Maxime Ripard <[email protected]>

drm/sitronix: st7920: Convert to atomic_create_state

The st7920 crtc implementation provides a custom reset hook. However,
this hook only allocates the state, initializes it with
__drm_atomic_helper_crtc_reset(), and warns if there's a previous state.
It does not perform any hardware reset.

Since this is exactly what the atomic_create_state hook is meant to
do, minus the old state cleanup which the caller handles, convert the
implementation to use atomic_create_state with
__drm_atomic_helper_crtc_state_init() instead.

> diff --git a/drivers/gpu/drm/sitronix/st7920.c 
> b/drivers/gpu/drm/sitronix/st7920.c
> index 0a75e9319080f..9887ed746cebd 100644
> --- a/drivers/gpu/drm/sitronix/st7920.c
> +++ b/drivers/gpu/drm/sitronix/st7920.c
> @@ -575,17 +575,17 @@ static void st7920_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>  }

[Severity: High]
This is a pre-existing issue, but does this driver incorrectly call sleeping
functions from atomic context paths?

A display modeset or screen update triggers DRM callbacks like
st7920_crtc_atomic_enable(), st7920_crtc_atomic_disable(), and
st7920_primary_plane_atomic_update() in drivers/gpu/drm/sitronix/st7920.c,
which are designated as atomic contexts where sleeping is strictly forbidden.

However, they internally call functions that can sleep:

st7920_crtc_atomic_enable() (at line 553):
  st7920_hw_reset()
    usleep_range(15, 20);
    msleep(40);

st7920_crtc_atomic_disable():
  st7920_power_off()
    spi_write()

st7920_primary_plane_atomic_update():
  st7920_fb_blit_rect()
    spi_write()

Could this lead to "scheduling while atomic" kernel warnings or deadlocks
when userspace triggers screen updates?

[ ... ]

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=11

Reply via email to