Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/bridge: ti-sn65dsi83: missing refcount increment in get_next_bridge --
commit cea7189b53e4a71deaaf15ff6f56ed70a0d97448 Author: Luca Ceresoli <[email protected]> drm/bridge: ti-sn65dsi83: implement .get_next_bridge This commit adds the get_next_bridge callback to expose the next bridge in the chain for the ti-sn65dsi83 driver. > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > index eb5b249cc43c7..76fc0ca8cd196 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -295,6 +295,13 @@ static struct sn65dsi83 *bridge_to_sn65dsi83(struct > drm_bridge *bridge) > return container_of(bridge, struct sn65dsi83, bridge); > } > > +static struct drm_bridge *sn65dsi83_get_next_bridge(struct drm_bridge > *bridge) > +{ > + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); > + > + return ctx->panel_bridge ?: ERR_PTR(-ENODEV); > +} [Severity: High] Does this need to increment the refcount of the returned panel bridge? The API contract for the get_next_bridge callback in include/drm/drm_bridge.h states that it must return a bridge with its refcount incremented, as callers are expected to invoke drm_bridge_put() when they are done. Since ctx->panel_bridge is returned directly without calling drm_bridge_get(), could a caller traversing the chain cause a refcount underflow? This could potentially lead to a use-after-free of the panel bridge object when the caller drops its reference. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=20
