Re: [PATCH v16 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver

[Mohit Dsor <mohit.dsor@oss.qualcomm.com>]

On Tue, Sep 15, 2026 at 07:03:36PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] drm/bridge: premature bridge registration causes UAF on probe failure
> - [High] drm/bridge: missing HDMI formats and max_bpc initialization causes display failure
> --
> 
> commit 845a14001f40c5c49616eeff3efbd5f04313cc72
> Author: Sunyun Yang <syyang@lontium.com>
> 
> drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
> 
> This commit introduces the DRM bridge driver for the Lontium
> LT9611C(EX/UXD) MIPI DSI to HDMI converter chips. It supports single or
> dual MIPI DSI and I2S signals to HDMI output.
> 
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> > new file mode 100644
> > index 0000000000000..54ae535339f74
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> [ ... ]
> > @@ -1160,20 +1160,20 @@
> [ ... ]
> > +	lt9611c->bridge.of_node = client->dev.of_node;
> > +	lt9611c->bridge.ops = DRM_BRIDGE_OP_DETECT |
> > +			DRM_BRIDGE_OP_EDID |
> > +			DRM_BRIDGE_OP_HPD |
> > +			DRM_BRIDGE_OP_HDMI |
> > +			DRM_BRIDGE_OP_HDMI_AUDIO;
> 
> [Severity: High]
> Will setting the DRM_BRIDGE_OP_HDMI flag here cause connector initialization
> to fail?
> 
> It looks like the bridge.supported_formats and bridge.max_bpc fields are not
> initialized before this is set. When drm_bridge_connector_init() calls the
> core helper drm_connector_hdmi_init(), it strictly validates these parameters.
> Because they are implicitly zero-initialized, drm_connector_hdmi_init() will
> return -EINVAL, which would deterministically fail the connector creation and
> render the display driver non-functional.
> 
> Should these HDMI capabilities be explicitly set before enabling the HDMI ops
> flag?
drm_bridge_connector_init() uses safe defaults when bridge->supported_formats and bridge->max_bpc are zero — it defaults to
BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) and 8bpc respectively (see drm_bridge_connector.c lines 826-827). The bridge fields are
only used as overrides when non-zero (lines 911-914). No explicit initialization is needed and connector creation will
succeed.
> 
> > +	lt9611c->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > +
> > +	lt9611c->bridge.vendor = "Lontium";
> > +	lt9611c->bridge.product = "LT9611C";
> > +
> > +	lt9611c->bridge.hdmi_audio_dev = dev;
> > +	lt9611c->bridge.hdmi_audio_max_i2s_playback_channels = 8;
> > +	lt9611c->bridge.hdmi_audio_dai_port = 2;
> > +
> > +	drm_bridge_add(&lt9611c->bridge);
> > +
> > +	/* Attach primary DSI */
> > +	dsi = lt9611c_attach_dsi(lt9611c, dsi0_node);
> > +	if (IS_ERR(dsi)) {
> > +		ret = PTR_ERR(dsi);
> > +		goto err_remove_bridge;
> > +	}
> 
> [Severity: High]
> Can this sequence lead to a use-after-free if the DSI attachment fails?
> 
> Because drm_bridge_add() makes the bridge globally visible on the bridge_list,
> another KMS driver could concurrently discover and attach to it during this
> window. If the subsequent lt9611c_attach_dsi() call fails (for example,
> returning -EPROBE_DEFER), the driver calls drm_bridge_remove() and returns an
> error, which triggers devres to free the memory backing the bridge.
> 
> Could the concurrent KMS driver be left holding a dangling pointer to
> devres-freed memory? Should drm_bridge_add() be deferred until all resources
> are successfully acquired?
the DSI attach path requires the bridge to already be registered for endpoint discovery. The window where a concurrent KMS drivercould attach is extremely narrow and bounded by probe completion. We'll leave the current order as-is.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260916-lt9611c-v7-v16-0-c65042fcd245@oss.qualcomm.com?part=2