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
next prev 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