Messages in this thread | | | Date | Wed, 8 Jun 2022 17:50:15 +0200 | From | Daniel Vetter <> | Subject | Re: [PATCH v3 3/4] drm/bridge: Add devm_drm_bridge_add() |
| |
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@linaro.org> > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > 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@ffwll.ch>
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
| |