Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction

[Maxime Ripard]

On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> > Hi,x
> >
> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> connector from different code paths.
> >> >
> >> > Same story here, explaining what you need later on that calls for that
> >> > change would be nice.
> >>
> >> Here's a more verbose version:
> >>
> >>     Currently drm_bridge_connector_init() does two things:
> >>
> >>      * allocate and initialize the drm_bridge_connector
> >>        (which embeds a drm_connector)
> >>      * initialize and register the embedded drm_connector
> >>
> >>     For bridge hotplug we need to separate these two actions:
> >>
> >>      * the drm_connector needs to be added and removed at any time based on
> >>        hotplug events
> >>      * the drm_bridge_connector is designated to create and remove the
> >>        drm_connector, so it must be persistent for the card lifetime
> >>
> >>     As the lifetimes of drm_bridge_connector and drm_connector become
> >>     different, we need to create them in different moments.
> >>
> >>     In preparation to support that, split out from
> >>     drm_bridge_connector_init() the code adding the drm_connector into a
> >>     dedicated function. No functional changes, just moving code around for
> >>     now. A future commit will make the drm_connector be created based on
> >>     hotplug events.
> >>
> >> Looks good?
> >
> > The message itself, yes, thanks.
> >
> > However, I have questions now :)
> >
> > Do we really expect drm_bridge_connector to stick around when a bridge
> > gets unplugged? If so, how does it cope with having, say, an HDMI
> > connector, and then swapping out the hotplugged part for an LVDS one?
> > Does the HDMI connector sticks around indefinitely?
> 
> In your example, the HDMI drm_connector would be unregistered and put on
> hotunplug. Its allocation will stick around until the last put but that's
> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> drm_connector will be created and registered.
>
> > *Especially* if we're using overlays for this, I'd expect everything
> >  after the first hotplugged bridge to be destroyed, no?
> 
> As said, it would be unregistered immediately but might be freed later on
> if still refcounted.
> 
> This is visible in patches 36+15, the path to follow is:
> 
>  drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
>  -> drm_bridge_connector_dynconn_release()                      [patch 15]
> 
> Does this solve your concern?

Not really, I'm talking about drm_bridge_connector. The fact that
bridges are destroyed make sense to me. The fact that
drm_bridge_connector sticks around doesn't. It's supposed to be a
connector for bridges. If you don't have bridges because they got
destroyed, and connector, drm_bridge_connector doesn't have a reason to
exist anymore, unless it's drm_bridge_hotplug in a trench coat :)

Maxime

Attachment: signature.asc
Description: PGP signature