Re: [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Sleeping function msleep() is called from CRTC atomic enable/disable callbacks, which execute in atomic context.
--

commit a2121d13cc86548614d1273c2a018211978e598e
Author: Roshan Kumar <roshaen09@gmail.com>

drm/pl111: drop alpha formats the hardware cannot scan out

The PL110/PL111 controller does not support alpha blending, so exposing alpha
formats causes issues when pixel blend mode properties are expected. This
patch drops alpha formats from all variant tables and format checking
switches so that alpha-picking clients fall back to XRGB/XBGR/RGB formats
instead.

Link: https://github.com/google/syzkaller/issues/7805

> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f6..e1b513d36c27c 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
[ ... ]
> @@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
>  		else
>  			cntl |= CNTL_BGR;
>  		break;
> -	case DRM_FORMAT_ABGR4444:
>  	case DRM_FORMAT_XBGR4444:
>  		cntl |= CNTL_LCDBPP16_444;
>  		if (priv->variant->st_bitmux_control)
>  			cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
>  		break;
> -	case DRM_FORMAT_ARGB4444:
>  	case DRM_FORMAT_XRGB4444:
>  		cntl |= CNTL_LCDBPP16_444;
>  		if (priv->variant->st_bitmux_control)

[Severity: High]
This is a pre-existing issue, but I noticed that msleep() is called
further down in pl111_display_enable():

	/*
	 * We expect this delay to stabilize the contrast
	 * voltage Vee as stipulated by the manual
	 */
	msleep(20);

There is also a similar msleep(20) call in pl111_display_disable()
in the same file (drivers/gpu/drm/pl111/pl111_display.c).

Since pl111_display_enable() and pl111_display_disable() serve as the
CRTC atomic enable and disable callbacks, they execute in atomic context
where sleeping is forbidden.

Can calling msleep() in these paths cause kernel warnings, system
instability, or potential deadlocks during modeset operations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910192526.137057-1-roshaen09@gmail.com?part=1