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

On Wed, Jul 15, 2026 at 03:42:55PM +0800, Sunyun Yang wrote:
> <[email protected]> 于2026年7月15日周三 10:06写道：
> >
> > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> > - [High] Missing cleanup of `output_bridge` in `mipi_dsi_host_detach` prevents DSI device rebinds and causes use-after-free.
> 
> Intentional design, consistent with cdns-dsi-core.c cdns_dsi_detach()
> (lines 1082-1091) which does not clear output->dev. Clearing
> output_bridge would allow re-attach, causing devm_drm_of_get_bridge()
> to allocate new devres without freeing the previous one, resulting in
> a real memory leak. The DRM bridge framework does not support dynamic
> bridge chain reconfiguration. No use-after-free: the -EBUSY guard
> returns before dereferencing output_bridge, and bridge_attach is not
> called by the SoC encoder after drm_bridge_remove().

Luca is working on supporting (more) dynamic bridge chains. Don't make
his work harder. So far:


- Let the DSI sync be detached and then reattached. There might be
  reasons for that (e.g. big DSI panels which use two DSI hosts). Ignore
  devm_drm_of_get_bridge for now (though I thought Luca has provided a
  better API for that).

- Use next_bridge provided to you by the framework.

> 
> > - [High] Sysfs attribute `lt7911exc_firmware` is accessible before the driver has finished initialization in `probe`, leading to a kernel panic.
> 
> False positive. The driver core creates dev_groups sysfs attributes
> AFTER probe() returns successfully. In drivers/base/dd.c
> really_probe(), call_driver_probe() (line 706) executes before
> device_add_groups(dev, drv->dev_groups) (line 725). By the time the
> sysfs file is visible to userspace, all mutexes, workqueue, and regmap
> are fully initialized. There is no window where userspace can access
> the sysfs attribute before initialization completes.
> 
> > - [High] Asynchronous firmware upgrade worker accesses `bridge.dev` without holding a reference, causing a Use-After-Free if the DRM display controller unbinds.
> 
> This is a known DRM bridge framework limitation, not specific to this
> driver. drm_bridge_remove() does not clear bridge.dev, so all bridge
> drivers calling drm_kms_helper_hotplug_event() share this risk. A
> proper fix requires framework-level bridge-to-drm_device lifetime
> tracking. Triggering requires root sysfs access to start firmware
> upgrade while simultaneously unbinding the DRM master driver — an
> administrator operation outside normal usage.

I'd say, I don't have strong opinion here.

> 
> > - [Medium] Driver illegitimately mutates the state of a downstream bridge object by explicitly modifying `pre_enable_prev_first`.
> 
> Hardware constraint. The DSI output stream (register 0xe0b0) must be
> enabled after the panel is powered on. The override is safe because
> transfer() is a stub — panel DCS commands are silently discarded and
> panel initialization is handled entirely by the chip's internal
> firmware. The panel driver's prepare_prev_first preference is
> therefore irrelevant for this chip. The comment above the assignment
> documents this rationale.

Commented in the driver review.

> 
> > - [Low] The `lt7911exc->removed` flag is read without a lock or memory barrier in the firmware upgrade work, leading to a data race.
> 
> Valid.

Should be fixed.


-- 
With best wishes
Dmitry