linux-kernel - Re: [PATCH 5/6] drm/exynos: hdmi: convert to of_drm_find_and_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFJ4MHZJ1DTL.10AMTN5NW6VGS@bootlin.com>
Date: Thu, 08 Jan 2026 11:13:33 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Maxime Ripard" <mripard@...nel.org>
Cc: "Andrzej Hajda" <andrzej.hajda@...el.com>, "Neil Armstrong"
 <neil.armstrong@...aro.org>, "Robert Foss" <rfoss@...nel.org>, "Laurent
 Pinchart" <Laurent.pinchart@...asonboard.com>, "Jonas Karlman"
 <jonas@...boo.se>, "Jernej Skrabec" <jernej.skrabec@...il.com>, "Maarten
 Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Thomas Zimmermann"
 <tzimmermann@...e.de>, "David Airlie" <airlied@...il.com>, "Simona Vetter"
 <simona@...ll.ch>, "Kevin Hilman" <khilman@...libre.com>, "Jerome Brunet"
 <jbrunet@...libre.com>, "Martin Blumenstingl"
 <martin.blumenstingl@...glemail.com>, "Philipp Zabel"
 <p.zabel@...gutronix.de>, "Shawn Guo" <shawnguo@...nel.org>, "Sascha Hauer"
 <s.hauer@...gutronix.de>, "Pengutronix Kernel Team"
 <kernel@...gutronix.de>, "Fabio Estevam" <festevam@...il.com>, "Chun-Kuang
 Hu" <chunkuang.hu@...nel.org>, "Matthias Brugger" <matthias.bgg@...il.com>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 "Inki Dae" <inki.dae@...sung.com>, "Seung-Woo Kim"
 <sw0312.kim@...sung.com>, "Kyungmin Park" <kyungmin.park@...sung.com>,
 "Krzysztof Kozlowski" <krzk@...nel.org>, "Alim Akhtar"
 <alim.akhtar@...sung.com>, "Laurent Pinchart"
 <laurent.pinchart+renesas@...asonboard.com>, "Tomi Valkeinen"
 <tomi.valkeinen+renesas@...asonboard.com>, "Kieran Bingham"
 <kieran.bingham+renesas@...asonboard.com>, "Geert Uytterhoeven"
 <geert+renesas@...der.be>, "Magnus Damm" <magnus.damm@...il.com>, "Hui Pu"
 <Hui.Pu@...ealthcare.com>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>, <dri-devel@...ts.freedesktop.org>,
 <linux-kernel@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
 <linux-arm-kernel@...ts.infradead.org>, <imx@...ts.linux.dev>,
 <linux-mediatek@...ts.infradead.org>, <linux-samsung-soc@...r.kernel.org>,
 <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH 5/6] drm/exynos: hdmi: convert to
 of_drm_find_and_get_bridge()

Hi Maxime,

On Thu Jan 8, 2026 at 9:14 AM CET, Maxime Ripard wrote:
> On Wed, Jan 07, 2026 at 05:22:03PM +0100, Luca Ceresoli wrote:
>> of_drm_find_bridge() is deprecated. Move to its replacement
>> of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
>> is put when done.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>
>
> Why can't we use next_bridge for this one?

Because this device is not a bridge, so we have no struct drm_bridge.

>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 01813e11e6c6..bfcf2fa62fe1 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1779,7 +1779,7 @@ static int hdmi_bridge_init(struct hdmi_context *hdata)
>>  		return -EINVAL;
>>  	}
>>
>> -	hdata->bridge = of_drm_find_bridge(np);
>> +	hdata->bridge = of_drm_find_and_get_bridge(np);
>>  	of_node_put(np);
>>
>>  	if (!hdata->bridge)
>> @@ -2096,6 +2096,8 @@ static void hdmi_remove(struct platform_device *pdev)
>>
>>  	put_device(&hdata->ddc_adpt->dev);
>>
>> +	drm_bridge_put(hdata->bridge);
>> +
>>  	mutex_destroy(&hdata->mutex);
>>  }
>
> Same story than in your part 2 series, it should be dropped in destroy.

hdata->bridge is only used for drm_bridge_attach(), it won't be referenced
after that. So this is safe, unless I'm missing something.

Also as we don't have a struct drm_bridge (as mentioned above) we have no
bridge destroy. We have the encoder destroy, but that will never be called
on bridge hotplug.

Luca

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