Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically

[Luca Ceresoli]

On Wed Jun 24, 2026 at 5:34 PM CEST, Luca Ceresoli wrote:
> Hi Maxime,
>
> thanks for the feedback.
>
> On Wed Jun 24, 2026 at 1:48 PM CEST, Maxime Ripard wrote:
>> On Fri, Jun 12, 2026 at 02:44:43PM +0200, Luca Ceresoli wrote:
>>> On Mon Jun 8, 2026 at 1:46 PM CEST, Maxime Ripard wrote:
>>> > On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
>>> >> Currently the drm_bridge_connector has an embedded drm_connector, so their
>>> >> allocation lifetimes are tied to each other. This is insufficient to
>>> >> support DRM bridge hotplugging, which requires the connector to be added
>>> >> and removed dynamically at runtime multiple times based on hotplug/unplug
>>> >> events while the drm_bridge_connector is persistent.
>>> >>
>>> >> Moreover the drm_connector is exposed to user space and thus an ongoing
>>> >> operation (e.g. an ioctl) might last for an arbitrarily long time even
>>> >> after the hardware gets removed. This means a new connector might have to
>>> >> be added when the previous one is still referenced by user space.
>>> >>
>>> >> In preparation to handle hotplug, allocate the drm-connector dynamically,
>>> >> to allow:
>>> >>
>>> >>  * creating and destroying a connector multiple times during a single
>>> >>    drm_bridge_connector lifetime
>>> >>  * creating a new connector even though the previous one is still in use
>>> >>    and thus still refcounted and not yet freed
>>> >>
>>> >> This commit does not introduce the actions in the two bullets (it will
>>> >> happen in a later commit), it only moves to dynamic APIs for connector
>>> >> allocation and init.
>>> >>
>>> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
>>> >
>>> > I think this patch should be split in half, with the switch to using
>>> > destroy first, and then the actual move to the dynamically allocated
>>> > connector API.
>>>
>>> Is it doable? drm_connector_dynamic_init() mandates a .destroy callback,
>>> drm_connector_init() forbids it.
>>
>> drmm_connector_init forbids it. drm_connector_init mandates it.
>
> Something bogus in my reply, sorry. :)
>
> So you mean splitting in:
>
>  * first patch: move from drmm_connector[_hdmi]_init() to
>    drm_connector[_hdmi]_init() and add a .destroy
>  * second patch: move from drm_connector[_hdmi]_init() to
>    drm_connector[_hdmi]_dynamic_init() +
>    drm_connector_dynamic_register/unregister()

Ah, no, there's an annoyance here. drm_connector_hdmi_init() does not
exist, so it'd have to be created just for the sake of splitting this
patch, sitting unused after the second patch.

I don't think it's worth implementing (and maybe deleting) it just for
that, so I'm leaving this patch as is unless you have counteraguments.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com