On Sat, May 21, 2022 at 11:17:51AM +0200, Maxime Ripard wrote: > Hi, > > On Tue, May 10, 2022 at 12:29:43PM -0700, Douglas Anderson wrote: > > This adds a devm managed version of drm_bridge_add(). Like other > > "devm" function listed in drm_bridge.h, this function takes an > > explicit "dev" to use for the lifetime management. A few notes: > > * In general we have a "struct device" for bridges that makes a good > > candidate for where the lifetime matches exactly what we want. > > * The "bridge->dev->dev" device appears to be the encoder > > device. That's not the right device to use for lifetime management. > > > > Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > > If we are to introduce more managed helpers, I think it'd be wiser to > introduce them as DRM-managed, and not device managed. > > Otherwise, you'll end up in a weird state when a device has been removed > but the DRM device is still around. Top-level post since I didn't see any good place to reply in the thread below: - devm is for device stuff, which drm_bridge is (it's not uapi visible in any way or fasion) - drmm is for uapi visible stuff (like drm_encoder) Yes the uapi-visible stuff can outlive the device-related pieces. The way to handle this is: - drm_dev_unplug() when the device disappears underneath you (or just a part, I guess the infra for that doesn't exist yet and maybe we should add it). - drm_dev_enter/exit wrapped around the device related parts. Iow, this patch here I think is the right direction, and gets my Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> But also, it's definitely not a complete solution as the discussion in the thread here points out. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
