Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/bridge: refcount underflow in sn65dsi86_get_next_bridge() --
commit ed254bdda2bfa941d8761ef842227d71a55ce971 Author: Luca Ceresoli <[email protected]> drm/bridge: ti-sn65dsi86: implement .get_next_bridge This commit adds a get_next_callback function to expose the next bridge in the ti-sn65dsi86 driver. > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 48b83df9aed61..e981d98a39b96 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -743,6 +743,13 @@ static int ti_sn_attach_host(struct auxiliary_device > *adev, struct ti_sn65dsi86 > return devm_mipi_dsi_attach(&adev->dev, dsi); > } > > +static struct drm_bridge *sn65dsi86_get_next_bridge(struct drm_bridge > *bridge) > +{ > + struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge); > + > + return pdata->next_bridge ?: ERR_PTR(-ENODEV); [Severity: High] Does this callback need to call drm_bridge_get() on the next bridge before returning it? The get_next_bridge API expects the returned bridge to have an incremented reference count. Callers of drm_bridge_get_next() will clean up the returned bridge using drm_bridge_put(). Because this function returns the pointer directly without acquiring a reference, the subsequent put operation will decrement a reference that was never acquired. Could this lead to a regression involving a use-after-free of the next_bridge structure during pipeline initialization or hotplug events? > +} > + [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=21
