Re: [PATCH v13 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] AB-BA / self-deadlock between the bridge's ocm_lock and DRM modeset locks during hotplug notification.
- [High] Freeing the panel bridge in lt7911exc_dsi_host_detach while it is still attached to the DRM bridge chain causes a Use-After-Free.
--

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

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

This commit adds support for the Lontium LT7911EXC bridge chip which converts
eDP input to MIPI DSI output. It provides DRM bridge integration, MIPI DSI
host interface, firmware upgrade mechanism, and GPIO/regulator management.

> diff --git a/drivers/gpu/drm/bridge/lontium-lt7911exc.c b/drivers/gpu/drm/bridge/lontium-lt7911exc.c
> new file mode 100644
> index 0000000000000..8401b7357b327
> --- /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);

[ ... ]

> +	mutex_lock(&lt7911exc->ocm_lock);
> +	lt7911exc_hw_mcu_run(lt7911exc);
> +	lt7911exc->fw_version = lt7911exc_read_version(lt7911exc);
> +	/* Notify DRM framework that hardware state changed/needs a modeset */
> +	if (lt7911exc->bridge.dev)
> +		drm_kms_helper_hotplug_event(lt7911exc->bridge.dev);

[Severity: High]
Will this result in a self-deadlock when the hotplug event triggers a modeset?

The driver holds ocm_lock here, and drm_kms_helper_hotplug_event() notifies
user-space and triggers the in-kernel fbdev client to restore the display
mode. This leads to a synchronous atomic commit that invokes bridge
callbacks such as lt7911exc_atomic_pre_enable().

Looking at lt7911exc_atomic_pre_enable():

static void lt7911exc_atomic_pre_enable(...)
{
	struct lt7911exc *lt7911exc = bridge_to_lt7911exc(bridge);

	guard(mutex)(&lt7911exc->ocm_lock);
	...
}

Since the mutex is already held by this exact same worker thread, and
mutexes aren't recursive, won't this permanently hang the worker thread?

> +
> +	mutex_unlock(&lt7911exc->ocm_lock);

[ ... ]

> +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;
> +
> +	if (lt7911exc->output.panel && lt7911exc->output.bridge)
> +		drm_panel_bridge_remove(lt7911exc->output.bridge);

[Severity: High]
Can this cause a use-after-free during subsequent DRM operations?

In lt7911exc_bridge_attach(), the panel bridge is linked into the DRM
encoder's bridge chain. If the downstream DSI device is unbound at
runtime and calls this detach function, drm_panel_bridge_remove() will
free the panel bridge memory.

However, the bridge is not removed from the encoder's bridge chain
(the chain_node list). Won't subsequent DRM operations like modesets,
display disabling, or device teardown iterate over the encoder's
bridge chain and dereference the freed memory?

> +
> +	lt7911exc->output.bridge = NULL;
> +	lt7911exc->output.panel = NULL;
> +	lt7911exc->output.dev = NULL;
> +
> +	return 0;
> +}

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