Message-ID: <20250428-colossal-fiery-alpaca-8c5fee@houat>
Date: Mon, 28 Apr 2025 17:42:46 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
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()

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.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists