Re: [PATCH v3 2/2] drm/tiny: add support for PIXPAPER 4.26 monochrome e-ink panel

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `pixpaper_plane_atomic_update` function executes blocking operations and sleeps, which violates DRM atomic context constraints.
--

commit 430b1d964958c07f88c16103075446b46aaf5cb1
Author: LiangCheng Wang <zaq14760@gmail.com>

drm/tiny: add support for PIXPAPER 4.26 monochrome e-ink panel

Introduce a DRM driver for the Mayqueen Pixpaper 4.26 monochrome e-ink
display panel, which is controlled via SPI. The driver supports an
800x480 display with XRGB8888 framebuffer input.

> diff --git a/drivers/gpu/drm/tiny/pixpaper-426m.c b/drivers/gpu/drm/tiny/pixpaper-426m.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/pixpaper-426m.c
[ ... ]
> +static void pixpaper_plane_atomic_update(struct drm_plane *plane,
> +					 struct drm_atomic_state *state)
> +{
[ ... ]
> +		dst = pixpaper_prepare_buffer(vaddr, fb, &dst_pitch, &err);
> +		if (err.errno_code) {
> +			drm_err_once(drm, "Failed to allocate temporary buffer\n");
> +			goto update_cleanup;
> +		}
> +
> +		dst_len = dst_pitch * fb->height;
> +		pixpaper_write_image(panel, dst, dst_len, &err);
> +		if (err.errno_code)
> +			goto update_cleanup;
> +
> +		pixpaper_trigger_update(panel, &err);

[Severity: High]
Does this code sleep in an atomic context?

According to the DRM subsystem guidelines, plane atomic update callbacks
execute in atomic context where sleeping is strictly forbidden.

This function calls pixpaper_prepare_buffer(), which performs a sleeping
memory allocation:

pixpaper_prepare_buffer()
    kzalloc(..., GFP_KERNEL);

It also drives the SPI panel update through pixpaper_write_image() and 
pixpaper_trigger_update(). These functions internally invoke blocking
operations like usleep_range(), spi_write(), and gpiod_get_value_cansleep().

Furthermore, pixpaper_wait_for_panel() polls the panel for up to 10 seconds
using usleep_range().

Executing blocking functions from an atomic context will result in scheduling
while atomic kernel panics.

Should the hardware screen update logic be deferred to a worker thread, and
memory allocations handled in the non-atomic prepare_fb callback?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529-bar-v3-0-5c2ac1c751ee@gmail.com?part=2