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

[Maxime Ripard]

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?

*Especially* if we're using overlays for this, I'd expect everything
 after the first hotplugged bridge to be destroyed, no?

Maxime

Attachment: signature.asc
Description: PGP signature