Message-ID: <20250428183358.4d28ca6a@booty>
Date: Mon, 28 Apr 2025 18:33:58 +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>, Anusha Srivatsa <asrivats@...hat.com>, Paul
 Kocialkowski <paulk@...-base.io>, Dmitry Baryshkov <lumag@...nel.org>, 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, Adam Ford <aford173@...il.com>,
 Adrien Grassein <adrien.grassein@...il.com>, Aleksandr Mishin
 <amishin@...rgos.ru>, Andy Yan <andy.yan@...k-chips.com>, AngeloGioacchino
 Del Regno <angelogioacchino.delregno@...labora.com>, Benson Leung
 <bleung@...omium.org>, Biju Das <biju.das.jz@...renesas.com>, Christoph
 Fritz <chf.fritz@...glemail.com>, Cristian Ciocaltea
 <cristian.ciocaltea@...labora.com>, Detlev Casanova
 <detlev.casanova@...labora.com>, Dharma Balasubiramani
 <dharma.b@...rochip.com>, Guenter Roeck <groeck@...omium.org>, Heiko
 Stuebner <heiko@...ech.de>, Jani Nikula <jani.nikula@...el.com>, Janne
 Grunau <j@...nau.net>, Jerome Brunet <jbrunet@...libre.com>, Jesse Van
 Gavere <jesseevg@...il.com>, Kevin Hilman <khilman@...libre.com>, Kieran
 Bingham <kieran.bingham+renesas@...asonboard.com>, Liu Ying
 <victor.liu@....com>, Manikandan Muralidharan <manikandan.m@...rochip.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>, Matthias Brugger
 <matthias.bgg@...il.com>, Philipp Zabel <p.zabel@...gutronix.de>, Phong LE
 <ple@...libre.com>, Sasha Finkelstein <fnkl.kernel@...il.com>, Sugar Zhang
 <sugar.zhang@...k-chips.com>, Sui Jingfeng <sui.jingfeng@...ux.dev>, Tomi
 Valkeinen <tomi.valkeinen+renesas@...asonboard.com>, Vitalii Mordan
 <mordan@...ras.ru>, Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>, Bryan O'Donoghue
 <bryan.odonoghue@...aro.org>, Hans de Goede <hdegoede@...hat.com>, Uwe
 Kleine-König <u.kleine-koenig@...libre.com>, Dmitry
 Baryshkov <dmitry.baryshkov@....qualcomm.com>, "Rob Herring (Arm)"
 <robh@...nel.org>, Hsin-Te Yuan <yuanhsinte@...omium.org>, Pin-yen Lin
 <treapking@...omium.org>, Xin Ji <xji@...logixsemi.com>, Aradhya Bhatia
 <a-bhatia1@...com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Ian
 Ray <ian.ray@...com>, Martyn Welch <martyn.welch@...labora.co.uk>, Peter
 Senna Tschudin <peter.senna@...il.com>, Russell King
 <linux@...linux.org.uk>, Herve Codina <herve.codina@...tlin.com>, Alim
 Akhtar <alim.akhtar@...sung.com>, Inki Dae <inki.dae@...sung.com>, Kyungmin
 Park <kyungmin.park@...sung.com>, Seung-Woo Kim <sw0312.kim@...sung.com>,
 Linus Walleij <linus.walleij@...aro.org>, Abhinav Kumar
 <quic_abhinavk@...cinc.com>, Bjorn Andersson <quic_bjorande@...cinc.com>,
 Marijn Suijten <marijn.suijten@...ainline.org>, Rob Clark
 <robdclark@...il.com>, Sean Paul <sean@...rly.run>, Helge Deller
 <deller@....de>, Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
 Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, Alexandre
 Torgue <alexandre.torgue@...s.st.com>, Maxime Coquelin
 <mcoquelin.stm32@...il.com>, Philippe Cornu <philippe.cornu@...s.st.com>,
 Raphael Gallais-Pou <raphael.gallais-pou@...s.st.com>, Yannick Fertre
 <yannick.fertre@...s.st.com>, Maíra Canal
 <mcanal@...lia.com>, Dave Stevenson <dave.stevenson@...pberrypi.com>,
 Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>, Alain Volmat
 <alain.volmat@...s.st.com>, Raphael Gallais-Pou <rgallaispou@...il.com>,
 Michal Simek <michal.simek@....com>
Subject: Re: [PATCH v2 00/34] drm: convert all bridges to
 devm_drm_bridge_alloc()

Hi Maxime,

On Mon, 28 Apr 2025 17:42:46 +0200
Maxime Ripard <mripard@...nel.org> wrote:

> On Mon, Apr 28, 2025 at 05:24:57PM +0200, Luca Ceresoli wrote:
> > Hi Maxime, other DRM maintainers,
> > 
> > On Thu, 24 Apr 2025 20:59:07 +0200
> > Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> >   
> > > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
> > > bridge, and the only one supported from now on. It is also necessary for
> > > implementing reference counting and thus needed to support removal of
> > > bridges from a still existing DRM pipeline without use-after-free.
> > > 
> > > This series converts all DRM bridges to the new API.
> > > 
> > > Patch 1 uses a coccinelle semantic patch to mass-convert some of those
> > > drivers -- thanks Maxime for having suggested the patch that served as a
> > > starting point for me. I was unable to come up with a better patch
> > > converting more drivers though, so I converted all others manually. Most of
> > > them were trivial. I left the non-trivial ones at the end of the series to
> > > help reviewers know where to look at more carefully.
> > > 
> > > Due to the large number of touched files, the list of recipients generated
> > > by get_maintainers (b4 actually) was huge, 60~70 people (not counting
> > > mailing lists), so I took the liberty of trimming the list as reasonably as
> > > I could to DRM maintainers and frequent contributors, and added all other
> > > recipients individually per-patch. I hope this is fine. Don't hesitate to
> > > suggest more people which should be Cc-ed in a future series, or a better
> > > Cc policy.
> > > 
> > > Current plan and status of the DRM bridge refcounting work:
> > > 
> > >  A. ✔ add new alloc API and refcounting -> (now in drm-misc-next)
> > >  B. ➜ convert all bridge drivers to new API (this series)
> > >  C. … documentation, kunit tests, debugfs improvements (v1 under discussion)
> > >  D. after (B), add get/put to drm_bridge_add/remove() + attach/detech()
> > >  E. after (B), convert accessors; this is a large work and can be done
> > >     in chunks  
> >
> > Maintaining this long series is quite painful. Do you think at least
> > patches with a R-by or T-by tag could be merged before I send v3, so
> > we can relieve the maintenance effort, mail servers, and everybody's
> > inboxes?  
> 
> Yes?
> 
> What's stopping you though? You have at least a colleague that can apply
> them, and you could just as well apply for commit rights yourself.

OK, thanks. Will do.

The reason I haven't done it is this policy in DRM still appears a bit
unusual to me, but if it works for DRM I'm OK with it. Only, in case of
doubt, I didn't want to risk abusing of the commit rights.

Best regards,
Luca

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

Powered by blists - more mailing lists