On Fri, Jun 26, 2026 at 2:53 PM Maxime Ripard <[email protected]> wrote: > > On Fri, Jun 26, 2026 at 02:03:26PM +0200, Albert Esteve wrote: > > of_drm_find_panel() and drm_of_find_panel_or_bridge() now return a > > counted reference that the caller must release with drm_panel_put(). > > > > For bridge drivers that immediately wrap the panel in a panel_bridge > > (which acquires its own reference), release the lookup reference right > > after the bridge creation call. > > > > For analogix-anx6345, which stores the panel for direct use, release > > the reference in the i2c remove path. > > > > For platform drivers using analogix_dp_core with a component lifecycle > > (exynos_dp, rockchip analogix_dp), release the lookup reference in the > > platform remove() function. The panel_bridge created during bind() holds > > a separate reference that devm cleanup releases after remove() returns. > > > > Also fix devm_drm_of_get_bridge() and drmm_of_get_bridge() in > > bridge/panel.c itself: both call drm_of_find_panel_or_bridge() and > > then pass the panel to devm/drmm_panel_bridge_add(), which acquires > > its own reference via drm_panel_bridge_add_typed(). The lookup > > reference was never released; add drm_panel_put() after each bridge > > creation call. > > > > Assisted-by: Claude:claude-opus-4-6 > > Signed-off-by: Albert Esteve <[email protected]> > > I think this one should be either split into one patch per driver, or > merged with the of_drm_find_panel patch. I'm still not quite sure which > would be the best, maybe the latter?
I have spent some time myself thinking about how to approach this. Initially I thought about doing one patch per driver as you suggested, but since there are many similar fixes that are mostly one-liners, In the end I decided that grouping them would make the review easier and result in a less inflated series. Maybe merging with of_drm_find_panel patch makes sense to avoid having one patch introducing a transient reference leak (even if it is fixed right after and is bisectable). But that will also create a giant patch (harder to review?). Another option could be to merge patches 4 and 5, which basically update all callers, and keep the API update separated. Either way, I am happy with whatever you decide is better. I will take note of this for v2. > > Maxime
