From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E1D9C001DF for ; Thu, 13 Jul 2023 09:06:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231782AbjGMJFx (ORCPT ); Thu, 13 Jul 2023 05:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234153AbjGMJFJ (ORCPT ); Thu, 13 Jul 2023 05:05:09 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4B133AAB; Thu, 13 Jul 2023 02:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689239039; x=1720775039; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=wpe6dsOBfDPS7D7Sq/hiKhbMpNSn/Y2A1D02VMmRxgw=; b=lNO2CmDfkySi5PYBlHpDlW1wdIciwKrhk4xFk/pjI48942N1c6Itc0T9 aiKwOG9XugymilO6br9ayLECAcn2ErjSo0etNnoCxVslvn5FugYrv6AjA I0/rfe6Uxv+PSgh6Rm29PLMHQnw/cIo0rPMQozEeLdy3Ik8OWZYucyGDB iddtXwXhzFrq7fSpXo/F7cSrLSL1ENNLwb1RYCCM/S6ND0jOSHFI18XMB Q1TMw8W2NfddYES3SwmVBS/tvfUAWcICJQZ+cS0DS1Ksv3TBWDdsBa4Ji h0vtJF9j0DdqGpofllAX3/G3MMPLMvwH1PoXMN4rP/J+EErkUV0CCqU8W Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="395935090" X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="395935090" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 02:03:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="715882508" X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="715882508" Received: from atadj-mobl1.amr.corp.intel.com (HELO localhost) ([10.252.50.30]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 02:03:08 -0700 From: Jani Nikula To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: Geert Uytterhoeven , Xinliang Liu , Tomi Valkeinen , Alexey Kodanev , dri-devel@lists.freedesktop.org, Vandita Kulkarni , Alim Akhtar , Anitha Chrisanthus , Marijn Suijten , Jonathan Hunter , Arun R Murthy , Jerome Brunet , Liu Shixin , linux-samsung-soc@vger.kernel.org, Samuel Holland , Matt Roper , Wenjing Liu , Javier Martinez Canillas , Stanislav Lisovskiy , Danilo Krummrich , NXP Linux Team , spice-devel@lists.freedesktop.org, Niranjana Vishwanathapura , linux-sunxi@lists.linux.dev, Stylon Wang , Tim Huang , Suraj Kandpal , =?utf-8?Q?A?= =?utf-8?Q?ndr=C3=A9?= Almeida , Andi Shyti , Yifan Zhang , Leo Li , Sascha Hauer , Lucas De Marchi , Hersen Wu , Jessica Zhang , Kamlesh Gurudasani , Bhawanpreet Lakha , =?utf-8?Q?=C5=81ukasz?= Bartosik , Radhakrishna Sripada , Andrew Jeffery , Seung-Woo Kim , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , kernel@pengutronix.de, Alex Deucher , freedreno@lists.freedesktop.org, Claudiu Beznea , Gerd Hoffmann , Alexandre Belloni , linux-aspeed@lists.ozlabs.org, nouveau@lists.freedesktop.org, Mitul Golani , =?utf-8?Q?Jos=C3=A9?= Roberto de Souza , virtualization@lists.linux-foundation.org, Thierry Reding , Yongqin Liu , Mario Limonciello , Fei Yang , David Lechner , Juha-Pekka Heikkila , "Jiri Slaby (SUSE)" , David Francis , Aaron Liu , Vinod Polimera , linux-rockchip@lists.infradead.org, Fangzhi Zuo , Aurabindo Pillai , VMware Graphics Reviewers , Ben Skeggs , Jouni =?utf-8?Q?H=C3=B6gander?= , Dave Airlie , linux-mips@vger.kernel.org, Maxime Coquelin , Gurchetan Singh , Martin Blumenstingl , linux-arm-msm@vger.kernel.org, Animesh Manna , linux-renesas-soc@vger.kernel.org, Maxime Ripard , Chaitanya Kumar Borah , Biju Das , linux-amlogic@lists.infradead.org, Evan Quan , Michal Simek , linux-arm-kernel@lists.infradead.org, Sean Paul , Neil Armstrong , Kai Vehmanen , Boris Brezillon , Chunyan Zhang , Qingqing Zhuo , Sandy Huang , Swati Sharma , John Stultz , Paul Kocialkowski , Kyungmin Park , Drew Davenport , Kevin Hilman , Hawking Zhang , Haneen Mohammed , Anusha Srivatsa , Dan Carpenter , Karol Herbst , linux-hyperv@vger.kernel.org, Melissa Wen , =?utf-8?Q?Ma=C3=ADra?= Canal , Luca Coelho , Laurent Pinchart , Andrzej Hajda , Likun Gao , Sam Ravnborg , Alain Volmat , Xinwei Kong , Jernej Skrabec , Deepak Rawat , Chen-Yu Tsai , Joel Stanley , Ankit Nautiyal , Sumit Semwal , Alan Liu , Philip Yang , intel-gfx@lists.freedesktop.org, Alison Wang , Wolfram Sang , Abhinav Kumar , Gustavo Sousa , Baolin Wang , Rodrigo Vivi , Mikko Perttunen , Tvrtko Ursulin , Rodrigo Siqueira , Tomi Valkeinen , Deepak R Varma , "Pan, Xinhui" , Konrad Dybcio , Kieran Bingham , Tian Tao , Shawn Guo , Christian =?utf-8?Q?K=C3=B6nig?= , Khaled Almahallawy , linux-stm32@st-md-mailman.stormreply.com, Emma Anholt , Chun-Kuang Hu , Liviu Dudau , Alexandre Torgue , Roman Li , Paul Cercueil , Hamza Mahfooz , Marek Vasut , Jiapeng Chong , xen-devel@lists.xenproject.org, Guchun Chen , Oleksandr Andrushchenko , Raphael Gallais-Pou , Rodrigo Siqueira , Russell King , Uma Shankar , Mika Kahola , Jiasheng Jiang , Srinivasan Shanmugam , Thomas Zimmermann , Vinod Govindapillai , linux-tegra@vger.kernel.org, Marek =?utf-8?B?T2zFocOhaw==?= , =?utf-8?Q?Joaqu=C3=ADn?= Ignacio =?utf-8?Q?Aramend=C3=ADa?= , Melissa Wen , Hans de Goede , linux-mediatek@lists.infradead.org, Laurentiu Palcu , Matthias Brugger , David Tadokoro , AngeloGioacchino Del Regno , Orson Zhai , amd-gfx@lists.freedesktop.org, Jyri Sarha , Yannick Fertre , Nicolas Ferre , Krzysztof Kozlowski , Philippe Cornu , Wayne Lin , Dmitry Baryshkov , Nirmoy Das , Lang Yu Subject: Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev In-Reply-To: <20230712161025.22op3gtzgujrhytb@pengutronix.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de> <87fs5tgpvv.fsf@intel.com> <20230712161025.22op3gtzgujrhytb@pengutronix.de> Date: Thu, 13 Jul 2023 12:03:05 +0300 Message-ID: <878rbkgp4m.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Wed, 12 Jul 2023, Uwe Kleine-K=C3=B6nig = wrote: > Hello Jani, > > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: >> On Wed, 12 Jul 2023, Uwe Kleine-K=C3=B6nig wrote: >> > Hello, >> > >> > while I debugged an issue in the imx-lcdc driver I was constantly >> > irritated about struct drm_device pointer variables being named "dev" >> > because with that name I usually expect a struct device pointer. >> > >> > I think there is a big benefit when these are all renamed to "drm_dev". >> > I have no strong preference here though, so "drmdev" or "drm" are fine >> > for me, too. Let the bikesheding begin! >> > >> > Some statistics: >> > >> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | u= niq -c | sort -n >> > 1 struct drm_device *adev_to_drm >> > 1 struct drm_device *drm_ >> > 1 struct drm_device *drm_dev >> > 1 struct drm_device *drm_dev >> > 1 struct drm_device *pdev >> > 1 struct drm_device *rdev >> > 1 struct drm_device *vdev >> > 2 struct drm_device *dcss_drv_dev_to_drm >> > 2 struct drm_device **ddev >> > 2 struct drm_device *drm_dev_alloc >> > 2 struct drm_device *mock >> > 2 struct drm_device *p_ddev >> > 5 struct drm_device *device >> > 9 struct drm_device * dev >> > 25 struct drm_device *d >> > 95 struct drm_device * >> > 216 struct drm_device *ddev >> > 234 struct drm_device *drm_dev >> > 611 struct drm_device *drm >> > 4190 struct drm_device *dev >> > >> > This series starts with renaming struct drm_crtc::dev to drm_dev. If >> > it's not only me and others like the result of this effort it should be >> > followed up by adapting the other structs and the individual usages in >> > the different drivers. >>=20 >> I think this is an unnecessary change. In drm, a dev is usually a drm >> device, i.e. struct drm_device *. > > Well, unless it's not. Prominently there is > > struct drm_device { > ... > struct device *dev; > ... > }; > > which yields quite a few code locations using dev->dev which is > IMHO unnecessary irritating: > > $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l > 1633 > > Also the functions that deal with both a struct device and a struct > drm_device often use "dev" for the struct device and then "ddev" for > the drm_device (see for example amdgpu_device_get_pcie_replay_count()). Why is specifically struct drm_device *dev so irritating to you? You lead us to believe it's an outlier in kernel, something that goes against common kernel style, but it's really not: $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn |= head -20 38494 struct device *dev 16388 struct net_device *dev 4184 struct drm_device *dev 2780 struct pci_dev *dev 1916 struct comedi_device *dev 1510 struct mlx5_core_dev *dev 1057 struct mlx4_dev *dev 894 struct b43_wldev *dev 762 struct input_dev *dev 623 struct usbnet *dev 561 struct mlx5_ib_dev *dev 525 struct mt76_dev *dev 465 struct mt76x02_dev *dev 435 struct platform_device *dev 431 struct usb_device *dev 411 struct mt7915_dev *dev 398 struct cx231xx *dev 378 struct mei_device *dev 363 struct ksz_device *dev 359 struct mthca_dev *dev A good portion of the above also have a dev member. Are you planning on changing all of the above too, or are you only annoyed by drm? I'm really not convinced at all. BR, Jani. --=20 Jani Nikula, Intel Open Source Graphics Center