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] [day] [month] [year] [list]
Message-ID: <20250424171838.21a95d80@booty>
Date: Thu, 24 Apr 2025 17:18:38 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter
 <simona@...ll.ch>, 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>, Jagan Teki
 <jagan@...rulasolutions.com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
 <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Douglas Anderson
 <dianders@...omium.org>, Chun-Kuang Hu <chunkuang.hu@...nel.org>, Krzysztof
 Kozlowski <krzk@...nel.org>, Dmitry Baryshkov
 <dmitry.baryshkov@...aro.org>, Anusha Srivatsa <asrivats@...hat.com>, Paul
 Kocialkowski <paulk@...-base.io>, Dmitry Baryshkov <lumag@...nel.org>,
 Hervé Codina <herve.codina@...tlin.com>, Hui Pu
 <Hui.Pu@...ealthcare.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 dri-devel@...ts.freedesktop.org, asahi@...ts.linux.dev,
 linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, linux-amlogic@...ts.infradead.org,
 linux-renesas-soc@...r.kernel.org, platform-driver-x86@...r.kernel.org,
 linux-samsung-soc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 freedreno@...ts.freedesktop.org, linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH 34/34] drm/bridge: panel: convert to
 devm_drm_bridge_alloc() API

Hi Maxime,

On Tue, 8 Apr 2025 17:51:08 +0200
Maxime Ripard <mripard@...nel.org> wrote:

> Hi,
> 
> On Mon, Apr 07, 2025 at 05:27:39PM +0200, Luca Ceresoli wrote:
> > This is the new API for allocating DRM bridges.
> > 
> > The devm lifetime management of this driver is peculiar. The underlying
> > device for the panel_bridge is the panel, and the devm lifetime is tied the
> > panel device (panel->dev). However the panel_bridge allocation is not
> > performed by the panel driver, but rather by a separate entity (typically
> > the previous bridge in the encoder chain).
> > 
> > Thus when that separate entoty is destroyed, the panel_bridge is not
> > removed automatically by devm, so it is rather done explicitly by calling
> > drm_panel_bridge_remove(). This is the function that does devm_kfree() the
> > panel_bridge in current code, so update it as well to put the bridge
> > reference instead.
> > 
> > Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>

[...]

> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -287,15 +287,14 @@ struct drm_bridge *drm_panel_bridge_add_typed(struct drm_panel *panel,
> >  	if (!panel)
> >  		return ERR_PTR(-EINVAL);
> >  
> > -	panel_bridge = devm_kzalloc(panel->dev, sizeof(*panel_bridge),
> > -				    GFP_KERNEL);
> > -	if (!panel_bridge)
> > -		return ERR_PTR(-ENOMEM);
> > +	panel_bridge = devm_drm_bridge_alloc(panel->dev, struct panel_bridge, bridge,
> > +					     &panel_bridge_bridge_funcs);
> > +	if (IS_ERR(panel_bridge))
> > +		return (void *)panel_bridge;
> >  
> >  	panel_bridge->connector_type = connector_type;
> >  	panel_bridge->panel = panel;
> >  
> > -	panel_bridge->bridge.funcs = &panel_bridge_bridge_funcs;
> >  	panel_bridge->bridge.of_node = panel->dev->of_node;
> >  	panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> >  	panel_bridge->bridge.type = connector_type;
> > @@ -327,7 +326,7 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
> >  	panel_bridge = drm_bridge_to_panel_bridge(bridge);
> >  
> >  	drm_bridge_remove(bridge);
> > -	devm_kfree(panel_bridge->panel->dev, bridge);
> > +	devm_drm_put_bridge(panel_bridge->panel->dev, bridge);
> >  }
> >  EXPORT_SYMBOL(drm_panel_bridge_remove);  
> 
> I'm fine with it on principle, but as a temporary measure.
> 
> Now that we have the panel allocation function in place, we can just
> allocate a bridge for each panel and don't need drm_panel_bridge_add_*
> at all.
> 
> As I was saying before, it doesn't need to happen right now, or before
> the rest of your work for hotplug goes in. But this needs to be tackled
> at some point.

I totally agree this needs to be handled eventually, and also to get
there in steps.

The current status of this driver is not ideal, so I paid attention to
not make it unnecessarily worse when writing this patch. Do you think
the current patch is OK for the next step? I'm going to send v2 in a
few hours, so don't hesitate to mention any improvements you deem
necessary.

Luca

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ