Hi Dmitry, On Fri, 7 Feb 2025 21:57:30 +0200 Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > On Fri, Feb 07, 2025 at 11:44:01AM +0100, Luca Ceresoli wrote: > > On Fri, 7 Feb 2025 05:17:43 +0200 > > Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > > On Thu, Feb 06, 2025 at 07:14:30PM +0100, Luca Ceresoli wrote: > > > > Add a devm/drmm action to these functions so the bridge reference is > > > > dropped automatically when the caller is removed. > > > > > > I think the get() should go to the underlying of_drm_bridge_find() function. > > > > It is done in the following patch. > > > > Indeed I could swap patches 15 and 16 for clarity. Or I could squash > > together patches 14+15+16, as they are various parts or the refcounted > > bridge implementation, but I felt like keeping them separated would > > help reviewing. > > I think most of refcounting should be introduced as a single patch, > otherwise you risk having memory leaks or disappearing bridges. In principle there is no need to add all of this atomically in a single commit, provided that all patches adding refcounting in the infrastructure code is applied before patches to drivers using refcounting. > > > Also it really feels like it's an overkill to keep the wrappers. After > > > getting bridge being handled by the panel code would it be possible to > > > drop all of them? > > > > Do you mean having only drm_of_get_bridge_by_node(), without any devm > > or drmm variant? I'm not sure it is a good idea. Most DRM code (well, > > all of it, technically) is currently unable of working with refcounted > > bridges, but if they use the devm variant they will put the ref when > > they disappear. > > > > > Then this patch might introduce one new devm_ > > > function? Or are drmm_ functions actually being used to store data in > > > the drmm-managed memory? > > > > Which devm function are you thinking about? Sorry, I'm not following > > here. > > drmm_of_get_bridge() / devm_of_get_bridge(). I have a feeling (which of > course might be wrong), that they were used somewhat randomly in some > cases. Again not sure I get you, sorry. What's wrong in devm_drm_of_get_bridge(), and what would the new function you proposed be doing? I think a couple lines of pseudocode would clarify this. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
