On 11/30/16 11:03, Laurent Pinchart wrote: >>> This would require combining lookup and attach in all cases. I'm not sure >>> > > that would be very convenient for drivers. Keeping the two operations >>> > > separate would be more flexible. >> > >> > That could be avoided if of_drm_find_bridge() would copy the content of >> > bridge object, in stead of providing a pointer. > /me shivers > >> > The attach call could then search for the bridge object again before >> > continuing. But still in the end the impact to individual drivers would be >> > equal to adding a simple drm_bridge_put() call. Probably better to go >> > forward with your suggestion. > Please :-) > Ok :). But first I'll make a pull request of all accumulated tilcdc patches, as all problems I have found in them are to be fixed outside tilcdc. >> > Even adding the drm_bridge_put() would not be necessary in most cases if >> > we would add a devm version of getting the bridge object. In 99% of >> > cases the device probe will fail if the bridge attach fails, and bridge >> > object refcount would return to zero automatically. > devm_* is evil in most cases, especially the devm_kzalloc() function as it > ties object lifetime to devices, releasing memory at unbind time when the > object can still be referenced elsewhere. Regarding bridges, a > devm_of_drm_find_bridge() might make sense as the bridge seems at first glance > to (nearly) always be a resource that can be released at DRM unbind time. But the devm is not at all as evil when the object is refcounted, because every piece of code that wants to keep a reference to the object can keep it. Cheers, Jyri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
