Re: [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge

Luca Ceresoli
2025-12-16T16:36:26Z

Hi Maxime,

On Tue Dec 16, 2025 at 2:49 PM CET, Maxime Ripard wrote:
[...]
>> Not sure why, but it's taking a while before I grasp your ideas about this
>> series and meld them with mine. I hopefully got a clear POV now, so based
>> on it my plan is to rework this series to:
>>
>> * keep drm_of_find_bridge() but renamed to of_drm_get_bridge(), and keep
>> patches 1-5 (with the changes suggested by you and Louis, nothing big
>> and all already sent in v2)
>
> I don't think we should use that name, but on principle, yes.

OK about the rename. I just had sent this email before you requested the
rename. v3 is in the works with the of_drm_find_and_get_bridge() name.

>> * not add devm_drm_of_find_bridge()
>
> Yep.
>
>> * add next_bridge pointer to struct drm_bridge and call
>> drm_bridge_put(bridge->next_bridge) in __drm_bridge_free, document it
>
> We don't have to at this point, you can add next_bridge to the
> drm_bridge pointer if you want, but I don't consider it a prerequisite.
> If we don't we would have to create drm_bridge_funcs->destroy
> implemnentations to give up the driver pointer reference though. Your
> call.

There's a destroy finc already, so I'm adding the next_bridge pointer in v3
along with some driver conversions, including one where the destroy hook is
needed.

>> * convert patches 7-26 to use bridge->next_bridge where applicable,
>> or to do something different when needed
>
> Depending on your decision above, we'd need to either convert them to
> use drm_bridge->next_bridge or create a destroy hook for them. Either
> way is fine for me.
>
>> * maybe remove part of patches 7-26 just to reduce spam and rework effort
>> in case of further iterations, to send them separately once the approach
>> is accepted
>>
>> Does it look OK?

Cool, thanks for acking. v3 is just a testing round away from being sent.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering