Re: [PATCH v11 2/2] drm/bridge: Add Lontium LT7911EXC eDP to MIPI DSI bridge

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing drm_panel_bridge_remove() in lt7911exc_dsi_host_detach() causes bridge list corruption and Use-After-Free.
- [Medium] The fast `ocm_lock` is held during a 420ms hardware reset sequence, causing severe latency stalls for concurrent DRM and DSI operations.
--

commit 7a7cfdfb50c450205bc811aedab79e9db1683754
Author: Sunyun Yang <syyang@lontium.com>

drm/bridge: Add Lontium LT7911EXC eDP to MIPI DSI bridge

Add support for the Lontium LT7911EXC bridge chip, which converts
eDP input to MIPI DSI output using an internal firmware-controlled
pipeline.

> diff --git a/drivers/gpu/drm/bridge/lontium-lt7911exc.c b/drivers/gpu/drm/bridge/lontium-lt7911exc.c
> new file mode 100644
> index 0000000000000..1aec60f02f913
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/lontium-lt7911exc.c
[ ... ]
> +static void lt7911exc_firmware_upgrade_work(struct work_struct *work)
> +{
> +	struct lt7911exc *lt7911exc = container_of(work, struct lt7911exc, work);
> +	struct device *dev = lt7911exc->dev;
[ ... ]
> +	mutex_lock(&lt7911exc->upgrade_lock);
> +
> +	mutex_lock(&lt7911exc->ocm_lock);
> +	lt7911exc_reset(lt7911exc);

[Severity: Medium]
Since lt7911exc_reset() sleeps for 420ms (due to msleep calls), does holding
the fast ocm_lock here unnecessarily stall concurrent DRM and DSI operations?

It looks like the upgrade_lock already serializes firmware upgrades. Can the
ocm_lock be acquired after the reset sequence?

> +	lt7911exc_hw_mcu_halt(lt7911exc);
> +	mutex_unlock(&lt7911exc->ocm_lock);
> +
> +	ret = lt7911exc_block_erase(lt7911exc);
[ ... ]
> +	ret = lt7911exc_write_crc(lt7911exc, crc32, FW_SIZE - 4);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to write firmware crc\n");
> +		goto out_unlock;
> +	}
> +
> +	mutex_lock(&lt7911exc->ocm_lock);
> +	lt7911exc_reset(lt7911exc);

[Severity: Medium]
Similarly, does holding the ocm_lock during this second reset sequence cause
severe latency stalls for other display operations?

> +	mutex_unlock(&lt7911exc->ocm_lock);
> +
> +	ret = lt7911exc_upgrade_result(lt7911exc, crc32);
[ ... ]
> +static int lt7911exc_dsi_host_detach(struct mipi_dsi_host *host, struct mipi_dsi_device *dev)
> +{
> +	struct lt7911exc *lt7911exc = dsi_host_to_lt7911exc(host);
> +
> +	if (!lt7911exc->output.dev)
> +		return 0;
> +
> +	lt7911exc->output.dev = NULL;

[Severity: High]
Should drm_panel_bridge_remove() be called here?

When the panel is unbound, its device is destroyed and the devres cleanup
frees the bridge memory. If the bridge isn't properly removed here, the freed
bridge remains linked in the global DRM bridge_list, potentially causing a
use-after-free on subsequent list traversals.

> +
> +	return 0;
> +}
[ ... ]
> +static void lt7911exc_remove(struct i2c_client *client)
> +{
> +	struct lt7911exc *lt7911exc = i2c_get_clientdata(client);
[ ... ]
> +	mipi_dsi_host_unregister(&lt7911exc->dsi_host);
> +	drm_bridge_remove(&lt7911exc->bridge);
> +
> +	if (lt7911exc->output.panel && lt7911exc->output.bridge)
> +		drm_panel_bridge_remove(lt7911exc->output.bridge);

[Severity: High]
Can this dereference a freed pointer?

Since mipi_dsi_host_unregister() triggers panel detachment, and
lt7911exc_dsi_host_detach() doesn't remove the panel bridge, the bridge memory
could be freed during the detachment. Calling drm_panel_bridge_remove() here
would then lead to a use-after-free.

> +
> +	gpiod_set_value_cansleep(lt7911exc->reset_gpio, 1);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522015735.2833-1-syyang@lontium.com?part=2