Re: [PATCH v4 12/13] drm/bridge: tc358762: Set DE_POL and DCLK_POL properly

[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 in an atomic context path (bridge enable callback).
--

commit 12b0c322f22c1997a91fce2069aabdcb2f3f31cf
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

drm/bridge: tc358762: Set DE_POL and DCLK_POL properly

This commit updates the tc358762 bridge driver to dynamically set the
LCDCTRL_DCLK_POL and LCDCTRL_DE_POL polarities. Instead of hardcoding these
values, it now reads them from the output bus configuration flags to match
the panel's requirements.

> diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c
> index ad3a2620ce476..25b719cd66fec 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -186,12 +186,15 @@ static void tc358762_enable(struct drm_bridge *bridge,
>  {
>  	struct tc358762 *ctx = bridge_to_tc358762(bridge);
>  	struct drm_connector_state *conn_state;
> +	struct drm_bridge_state *bridge_state;

[Severity: High]
This isn't a bug introduced by this patch, but does this function sleep in
atomic context?

Looking at tc358762_enable() in drivers/gpu/drm/bridge/tc358762.c, there are
two instances where msleep() is called:

drivers/gpu/drm/bridge/tc358762.c:tc358762_enable() {
    ...
    tc358762_write(ctx, SYSCTRL,
                   FIELD_PREP(SYSCTRL_DPIDATA_IO_MASK, SYSCTRL_DPIDATA_IO_4MA) |
                   FIELD_PREP(SYSCTRL_DPISTB_IO_MASK, SYSCTRL_DPISTB_IO_4MA) |
                   FIELD_PREP(SYSCTRL_PCLKDIV_MASK, SYSCTRL_PCLKDIV_DIV_3));

    msleep(100);
    ...
    tc358762_write(ctx, PPI_STARTPPI, PPI_STARTPPI_STARTPPI);
    tc358762_write(ctx, DSI_STARTDSI, DSI_STARTDSI_STARTDSI);

    msleep(100);
    ...
}

This function is registered as the bridge's atomic enable callback. According
to DRM subsystem guidelines, encoder and bridge atomic enable callbacks run in
atomic context during non-blocking commits where sleeping is forbidden.

Can calling msleep() from this atomic context cause kernel warnings, system
instability, or potential deadlocks when the display pipeline is enabled?

>  	struct drm_crtc_state *crtc_state;
>  	struct drm_connector *connector;
>  	struct drm_display_mode *mode;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-tc358762-fixes-v4-0-e3fc3ab5cd83@ideasonboard.com?part=12