Re: [PATCH v9 3/9] drm/bridge: fsl-ldb: Add support for i.MX94

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Pre-existing use of usleep_range() in an atomic commit callback (fsl_ldb_atomic_enable).
--

commit e14b3dd6d0171a77b5885d6c520dacd31270636e
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>

drm/bridge: fsl-ldb: Add support for i.MX94

i.MX94 series LDB controller shares the same LDB and LVDS control
registers as i.MX8MP and i.MX93 but supports a higher maximum clock
frequency.

Add a 'max_clk_khz' member to the fsl_ldb_devdata structure in order to
be able to set different max frequencies for other platforms.

> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index bd03c36ee696c..b4959f654f2ac 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
issue in fsl_ldb_atomic_enable() which executes as part of the atomic commit
modeset phase:

drivers/gpu/drm/bridge/fsl-ldb.c:fsl_ldb_atomic_enable() {
    ...
	if (fsl_ldb->use_termination_resistor)
		reg |= LVDS_CTRL_HS_EN;
	regmap_write(fsl_ldb->regmap, fsl_ldb->devdata->lvds_ctrl, reg);

	/* Wait for VBG to stabilize. */
	usleep_range(15, 20);

	reg |=	(fsl_ldb->ch0_enabled ? LVDS_CTRL_CH0_EN : 0) |
		(fsl_ldb->ch1_enabled ? LVDS_CTRL_CH1_EN : 0);
    ...
}

Are sleeping functions permitted in this context?

Because fsl_ldb_atomic_enable() acts as an encoder atomic enable callback,
it runs in an atomic context where sleeping delays like usleep_range()
are forbidden.

Could this lead to kernel warnings, system instability, or deadlocks?

Should this be replaced with a non-sleeping delay like udelay()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-dcif-upstreaming-v9-0-8d0ff89aa3c5@oss.nxp.com?part=3