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
