Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

From: Luben Tuikov <luben.tuikov@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Maxime Ripard" <mripard@kernel.org>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Xinliang Liu" <xinliang.liu@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Alexey Kodanev" <aleksei.kodanev@bell-sw.com>,
	dri-devel@lists.freedesktop.org,
	"Vandita Kulkarni" <vandita.kulkarni@intel.com>,
	"Alim Akhtar" <alim.akhtar@samsung.com>,
	"Anitha Chrisanthus" <anitha.chrisanthus@intel.com>,
	"Marijn Suijten" <marijn.suijten@somainline.org>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Arun R Murthy" <arun.r.murthy@intel.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	linux-samsung-soc@vger.kernel.org,
	"Samuel Holland" <samuel@sholland.org>,
	"Matt Roper" <matthew.d.roper@intel.com>,
	"Wenjing Liu" <wenjing.liu@amd.com>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Stanislav Lisovskiy" <stanislav.lisovskiy@intel.com>,
	"Danilo Krummrich" <dakr@redhat.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	spice-devel@lists.freedesktop.org,
	"Niranjana Vishwanathapura" <niranjana.vishwanathapura@intel.com>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	linux-sunxi@lists.linux.dev,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Stylon Wang" <stylon.wang@amd.com>,
	"Tim Huang" <Tim.Huang@amd.com>,
	"Suraj Kandpal" <suraj.kandpal@intel.com>,
	"André Almeida" <andrealmeid@igalia.com>,
	"Mika Kahola" <mika.kahola@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Inki Dae" <inki.dae@samsung.com>,
	"Hersen Wu" <hersenxs.wu@amd.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Kamlesh Gurudasani" <kamlesh.gurudasani@gmail.com>,
	"Bhawanpreet Lakha" <Bhawanpreet.Lakha@amd.com>,
	"Łukasz Bartosik" <lb@semihalf.com>,
	"Radhakrishna Sripada" <radhakrishna.sripada@intel.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	kernel@pengutronix.de, "Alex Deucher" <alexander.deucher@amd.com>,
	freedreno@lists.freedesktop.org,
	"Claudiu Beznea" <claudiu.beznea@microchip.com>,
	"Zack Rusin" <zackr@vmware.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	linux-aspeed@lists.ozlabs.org, nouveau@lists.freedesktop.org,
	"Mitul Golani" <mitulkumar.ajitkumar.golani@intel.com>,
	"José Roberto de Souza" <jose.souza@intel.com>,
	virtualization@lists.linux-foundation.org,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Yongqin Liu" <yongqin.liu@linaro.org>,
	"Mario Limonciello" <mario.limonciello@amd.com>,
	"Fei Yang" <fei.yang@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Juha-Pekka Heikkila" <juhapekka.heikkila@gmail.com>,
	"Chunyan Zhang" <zhang.lyra@gmail.com>,
	"David Francis" <David.Francis@amd.com>,
	"Vinod Govindapillai" <vinod.govindapillai@intel.com>,
	"Aaron Liu" <aaron.liu@amd.com>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	"Vinod Polimera" <quic_vpolimer@quicinc.com>,
	linux-rockchip@lists.infradead.org,
	"Fangzhi Zuo" <jerry.zuo@amd.com>,
	"Aurabindo Pillai" <aurabindo.pillai@amd.com>,
	"VMware Graphics Reviewers"
	<linux-graphics-maintainer@vmware.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Jouni Högander" <jouni.hogander@intel.com>,
	"Jessica Zhang" <quic_jesszhan@quicinc.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	linux-arm-msm@vger.kernel.org,
	"Animesh Manna" <animesh.manna@intel.com>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Chaitanya Kumar Borah" <chaitanya.kumar.borah@intel.com>,
	"Tian Tao" <tiantao6@hisilicon.com>,
	"Biju Das" <biju.das.jz@bp.renesas.com>,
	linux-amlogic@lists.infradead.org,
	"Evan Quan" <evan.quan@amd.com>,
	"Michal Simek" <michal.simek@amd.com>,
	linux-arm-kernel@lists.infradead.org,
	"Sean Paul" <sean@poorly.run>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Boris Brezillon" <bbrezillon@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Qingqing Zhuo" <qingqing.zhuo@amd.com>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Swati Sharma" <swati2.sharma@intel.com>,
	linux-renesas-soc@vger.kernel.org,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Hawking Zhang" <Hawking.Zhang@amd.com>,
	"Haneen Mohammed" <hamohammed.sa@gmail.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Anusha Srivatsa" <anusha.srivatsa@intel.com>,
	"Dan Carpenter" <error27@gmail.com>,
	"Karol Herbst" <kherbst@redhat.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	linux-hyperv@vger.kernel.org, "Stefan Agner" <stefan@agner.ch>,
	"Melissa Wen" <melissa.srw@gmail.com>,
	"Maíra Canal" <mairacanal@riseup.net>,
	"Luca Coelho" <luciano.coelho@intel.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Likun Gao" <Likun.Gao@amd.com>,
	"Jiri Slaby (SUSE)" <jirislaby@kernel.org>,
	"Emma Anholt" <emma@anholt.net>,
	"Alain Volmat" <alain.volmat@foss.st.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Deepak Rawat" <drawat.floss@gmail.com>,
	"Xinwei Kong" <kong.kongxinwei@hisilicon.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Orson Zhai" <orsonzhai@gmail.com>,
	"Ankit Nautiyal" <ankit.k.nautiyal@intel.com>,
	"Harry Wentland" <harry.wentland@amd.com>,
	"Chia-I Wu" <olvaffe@gmail.com>, "Alan Liu" <haoping.liu@amd.com>,
	"Philip Yang" <Philip.Yang@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Alison Wang" <alison.wang@nxp.com>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Gustavo Sousa" <gustavo.sousa@intel.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Tomi Valkeinen" <tomi.valkeinen+renesas@ideasonboard.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Mikko Perttunen" <mperttunen@nvidia.com>,
	"Yifan Zhang" <yifan1.zhang@amd.com>,
	"Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
	"Tomi Valkeinen" <tomba@kernel.org>,
	"Deepak R Varma" <drv@mailo.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Julia Lawall" <Julia.Lawall@inria.fr>,
	"Kieran Bingham" <kieran.bingham+renesas@ideasonboard.com>,
	"John Stultz" <jstultz@google.com>, "Roman Li" <roman.li@amd.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Khaled Almahallawy" <khaled.almahallawy@intel.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
	"Imre Deak" <imre.deak@intel.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Liu Shixin" <liushixin2@huawei.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	"Hamza Mahfooz" <hamza.mahfooz@amd.com>,
	"David Airlie" <airlied@gmail.com>, "Marek Vasut" <marex@denx.de>,
	"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
	"Lang Yu" <Lang.Yu@amd.com>,
	xen-devel@lists.xenproject.org,
	"Guchun Chen" <guchun.chen@amd.com>,
	"Oleksandr Andrushchenko" <oleksandr_andrushchenko@epam.com>,
	"Raphael Gallais-Pou" <raphael.gallais-pou@foss.st.com>,
	"Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Leo Li" <sunpeng.li@amd.com>,
	"Uma Shankar" <uma.shankar@intel.com>,
	"Andi Shyti" <andi.shyti@linux.intel.com>,
	"Jiasheng Jiang" <jiasheng@iscas.ac.cn>,
	"Srinivasan Shanmugam" <srinivasan.shanmugam@amd.com>,
	"David Lechner" <david@lechnology.com>,
	"Jiapeng Chong" <jiapeng.chong@linux.alibaba.com>,
	"Marek Olšák" <marek.olsak@amd.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Joaquín Ignacio Aramendía" <samsagax@gmail.com>,
	"Melissa Wen" <mwen@igalia.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	linux-mediatek@lists.infradead.org,
	"Fabio Estevam" <festevam@gmail.com>,
	"Laurentiu Palcu" <laurentiu.palcu@oss.nxp.com>,
	linux-tegra@vger.kernel.org,
	"David Tadokoro" <davidbtadokoro@usp.br>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	amd-gfx@lists.freedesktop.org,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Yannick Fertre" <yannick.fertre@foss.st.com>,
	linux-mips@vger.kernel.org, "Rob Clark" <robdclark@gmail.com>,
	"Philippe Cornu" <philippe.cornu@foss.st.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Wayne Lin" <Wayne.Lin@amd.com>,
	"Drew Davenport" <ddavenport@chromium.org>,
	"Nirmoy Das" <nirmoy.das@intel.com>,
	"Jyri Sarha" <jyri.sarha@iki.fi>,
	"Lucas Stach" <l.stach@pengutronix.de>
Subject: Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Date: Wed, 12 Jul 2023 20:06:58 -0400	[thread overview]
Message-ID: <83bba180-faac-e2a9-e7d3-c5fdf5df2303@amd.com> (raw)
In-Reply-To: <603f0b69-71d3-ad8f-4b5e-53b63a6fd521@amd.com>

On 2023-07-12 09:53, Christian König wrote:
> Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
>> Hello Maxime,
>>
>> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
>>>>> Background is that this makes merge conflicts easier to handle and detect.
>>>> Really?
>>> FWIW, I agree with Christian here.
>>>
>>>> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
>>>> unless I'm missing something you don't get less or easier conflicts by
>>>> doing it all in a single patch. But you gain the freedom to drop a
>>>> patch for one driver without having to drop the rest with it.
>>> Not really, because the last patch removed the union anyway. So you have
>>> to revert both the last patch, plus that driver one. And then you need
>>> to add a TODO to remove that union eventually.
>> Yes, with a single patch you have only one revert (but 194 files changed,
>> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
>> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
>> bigger). (And maybe you get away with just reverting the last patch.)
>>
>> With a single patch the TODO after a revert is "redo it all again (and
>> prepare for a different set of conflicts)" while with the split series
>> it's only "fix that one driver that was forgotten/borked" + reapply that
>> 10 line patch.
> 
> Yeah, but for a maintainer the size of the patches doesn't matter. 
> That's only interesting if you need to manually review the patch, which 
> you hopefully doesn't do in case of something auto-generated.
> 
> In other words if the patch is auto-generated re-applying it completely 
> is less work than fixing things up individually.
> 
>>   As the one who gets that TODO, I prefer the latter.
> 
> Yeah, but your personal preferences are not a technical relevant 
> argument to a maintainer.
> 
> At the end of the day Dave or Daniel need to decide, because they need 
> to live with it.
> 
> Regards,
> Christian.
> 
>>
>> So in sum: If your metric is "small count of reverted commits", you're
>> right. If however your metric is: Better get 95% of this series' change
>> in than maybe 0%, the split series is the way to do it.
>>
>> With me having spend ~3h on this series' changes, it's maybe
>> understandable that I did it the way I did.
>>
>> FTR: This series was created on top of v6.5-rc1. If you apply it to
>> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
>> be the responsible maintainer who applies this series, I like being able
>> to just do git am --skip then.
>>
>> FTR#2: In drm-misc-next is a new driver
>> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
>> now might indeed be a good idea.
>>
>>>> So I still like the split version better, but I'm open to a more
>>>> verbose reasoning from your side.
>>> You're doing only one thing here, really: you change the name of a
>>> structure field. If it was shared between multiple maintainers, then
>>> sure, splitting that up is easier for everyone, but this will go through
>>> drm-misc, so I can't see the benefit it brings.
>> I see your argument, but I think mine weights more.

I'm with Maxime and Christian on this--a single action necessitates a single patch.
One single movement. As Maxime said "either 0 or 100."

As to the name, perhaps "drm_dev" is more descriptive than just "drm".
What is "drm"? Ah it's a "dev", as in "drm dev"... Then why not rename it
to "drm_dev"? You are renaming it from "dev" to something more descriptive
after all. "dev" --> "drm" is no better, but "dev" --> "drm_dev" is just
right.
-- 
Regards,
Luben