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 <[email protected]> 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/[email protected]?part=3
