public inbox for linux-aspeed@lists.ozlabs.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: linux-aspeed@lists.ozlabs.org
Subject: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Date: Thu, 13 Jul 2023 12:03:05 +0300	[thread overview]
Message-ID: <878rbkgp4m.fsf@intel.com> (raw)
In-Reply-To: <20230712161025.22op3gtzgujrhytb@pengutronix.de>

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> 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 | uniq -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.
>> 
>> 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->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.


-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2023-07-13  9:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12  9:46 [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Uwe Kleine-König
2023-07-12  9:46 ` [PATCH RFC v1 06/52] drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev Uwe Kleine-König
2023-07-12 10:13 ` [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Paul Kocialkowski
2023-07-12 10:19 ` Thomas Zimmermann
2023-07-12 10:54   ` Uwe Kleine-König
2023-07-12 10:46 ` Christian König
2023-07-12 11:02   ` Uwe Kleine-König
2023-07-12 11:07     ` Julia Lawall
2023-07-12 12:52     ` Maxime Ripard
2023-07-12 13:38       ` Uwe Kleine-König
2023-07-12 13:53         ` Maxime Ripard
2023-07-12 13:53         ` Christian König
2023-07-13  0:06           ` Luben Tuikov
2023-07-12 14:34 ` Jani Nikula
2023-07-12 16:10   ` Uwe Kleine-König
2023-07-13  6:52     ` Geert Uytterhoeven
2023-07-13 10:03       ` Uwe Kleine-König
2023-07-13  7:47     ` Thomas Zimmermann
2023-07-13  9:03     ` Jani Nikula [this message]
2023-07-13  9:29       ` Geert Uytterhoeven
2023-07-13  9:54       ` Uwe Kleine-König
2023-07-12 18:31   ` [Freedreno] " Sean Paul
2023-07-12 19:22     ` Krzysztof Kozlowski
2023-07-13  7:48     ` Thomas Zimmermann
2023-07-13 13:03     ` Uwe Kleine-König
2023-07-13 14:41       ` Sean Paul
2023-07-13 15:09         ` Thomas Zimmermann
2023-07-13 15:14           ` Tvrtko Ursulin
2023-07-13 15:30             ` Maxime Ripard
2023-07-14  7:38             ` Thomas Zimmermann
2023-07-13 15:39         ` Uwe Kleine-König
2023-07-13  7:54 ` Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rbkgp4m.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=linux-aspeed@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox