All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liu Ying <victor.liu@nxp.com>
To: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Lyude Paul <lyude@redhat.com>, Danilo Krummrich <dakr@kernel.org>,
	Marcus Folkesson <marcus.folkesson@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Adrien Grassein <adrien.grassein@gmail.com>,
	Peter Senna Tschudin <peter.senna@gmail.com>,
	Ian Ray <ian.ray@ge.com>,
	Martyn Welch <martyn.welch@collabora.co.uk>,
	Russell King <linux@armlinux.org.uk>,
	Douglas Anderson <dianders@chromium.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
	Manikandan Muralidharan <manikandan.m@microchip.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Andy Yan <andy.yan@rock-chips.com>, Xin Ji <xji@analogixsemi.com>,
	Loic Poulain <loic.poulain@oss.qualcomm.com>,
	Fei Shao <fshao@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Kees Cook <kees@kernel.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	nouveau@lists.freedesktop.org
Subject: Re: [PATCH] drm: Use named initializers for arrays of i2c_device_data
Date: Thu, 11 Jun 2026 10:15:36 +0800	[thread overview]
Message-ID: <aioaSKDk9LJYD6i3@raspi> (raw)
In-Reply-To: <20260518100401.631351-2-u.kleine-koenig@baylibre.com>

On Mon, May 18, 2026 at 12:04:01PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
> 
> The mentioned robustness is relevant for a planned change to struct
> i2c_device_id that replaces .driver_data by an anonymous union.
> 
> While touching all these arrays, unify usage of whitespace in the list
> terminator and drop trailing commas there.
> 
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> the mentioned change to i2c_device_id is the following:
> 
> 	diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> 	index 23ff24080dfd..aebd3a5e90af 100644
> 	--- a/include/linux/mod_devicetable.h
> 	+++ b/include/linux/mod_devicetable.h
> 	@@ -477,7 +477,11 @@ struct rpmsg_device_id {
> 	 
> 	 struct i2c_device_id {
> 		char name[I2C_NAME_SIZE];
> 	-	kernel_ulong_t driver_data;	/* Data private to the driver */
> 	+	union {
> 	+		/* Data private to the driver */
> 	+		kernel_ulong_t driver_data;
> 	+		const void *driver_data_ptr;
> 	+	};
> 	 };
> 	 
> 	 /* pci_epf */
> 
> and this requires that .driver_data is assigned via a named initializer
> for static data. This requirement isn't a bad one because named
> initializers are also much better readable than list initializers.
> 
> The union added to struct i2c_device_id enables further cleanups like:
> 
> 	diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
> 	index 0123ca8157a8..84272ba65d08 100644
> 	--- a/drivers/regulator/ad5398.c
> 	+++ b/drivers/regulator/ad5398.c
> 	@@ -207,8 +207,8 @@ struct ad5398_current_data_format {
> 	 static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
> 	 
> 	 static const struct i2c_device_id ad5398_id[] = {
> 	-	{ .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> 	-	{ .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> 	+	{ .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
> 	+	{ .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
> 		{ }
> 	 };
> 	 MODULE_DEVICE_TABLE(i2c, ad5398_id);
> 	@@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
> 		struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
> 		struct regulator_config config = { };
> 		struct ad5398_chip_info *chip;
> 	-	const struct ad5398_current_data_format *df =
> 	-			(struct ad5398_current_data_format *)id->driver_data;
> 	+	const struct ad5398_current_data_format *df = id->driver_data_ptr;
> 	 
> 		chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
> 		if (!chip)
> 
> that are an improvement for readability (again!) and it keeps some
> properties of the pointers (here: being const) without having to pay
> attention for that. (I didn't find a nice driver below drivers/gpu that
> benefits, so this is "only" a regulator driver example.)
> 
> My additional motivation for this effort is CHERI[1]. This is a hardware
> extension that uses 128 bit pointers but unsigned long is still 64 bit.
> So with CHERI you cannot store pointers in unsigned long variables.
> 
> I was unsure if I should split the patch. I guess doing all of
> drivers/gpu/drm/bridge together is fine, please tell if I should split
> off drivers/gpu/drm/nouveau/ and/or drivers/gpu/drm/sitronix/.
> 
> Best regards
> Uwe
> 
> [1] https://cheri-alliance.org/discover-cheri/
>     https://lwn.net/Articles/1037974/
> 
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c           | 10 +++++-----
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c     |  2 +-
>  drivers/gpu/drm/bridge/analogix/anx7625.c              |  4 ++--
>  drivers/gpu/drm/bridge/chipone-icn6211.c               |  4 ++--
>  drivers/gpu/drm/bridge/chrontel-ch7033.c               |  2 +-
>  drivers/gpu/drm/bridge/ite-it6263.c                    |  2 +-

Reviewed-by: Liu Ying <victor.liu@nxp.com> # ite-it6263.c

-- 
Regards,
Liu Ying

WARNING: multiple messages have this Message-ID (diff)
From: Liu Ying <victor.liu@nxp.com>
To: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Marcus Folkesson <marcus.folkesson@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Adrien Grassein <adrien.grassein@gmail.com>,
	Peter Senna Tschudin <peter.senna@gmail.com>,
	Ian Ray <ian.ray@ge.com>,
	Martyn Welch <martyn.welch@collabora.co.uk>,
	Russell King <linux@armlinux.org.uk>,
	Douglas Anderson <dianders@chromium.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
	Manikandan Muralidharan <manikandan.m@microchip.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Andy Yan <andy.yan@rock-chips.com>, Xin Ji <xji@analogixsemi.com>,
	Loic Poulain <loic.poulain@oss.qualcomm.com>,
	Fei Shao <fshao@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Kees Cook <kees@kernel.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	nouveau@lists.freedesktop.org
Subject: Re: [PATCH] drm: Use named initializers for arrays of i2c_device_data
Date: Thu, 11 Jun 2026 10:15:36 +0800	[thread overview]
Message-ID: <aioaSKDk9LJYD6i3@raspi> (raw)
In-Reply-To: <20260518100401.631351-2-u.kleine-koenig@baylibre.com>

On Mon, May 18, 2026 at 12:04:01PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
> 
> The mentioned robustness is relevant for a planned change to struct
> i2c_device_id that replaces .driver_data by an anonymous union.
> 
> While touching all these arrays, unify usage of whitespace in the list
> terminator and drop trailing commas there.
> 
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> the mentioned change to i2c_device_id is the following:
> 
> 	diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> 	index 23ff24080dfd..aebd3a5e90af 100644
> 	--- a/include/linux/mod_devicetable.h
> 	+++ b/include/linux/mod_devicetable.h
> 	@@ -477,7 +477,11 @@ struct rpmsg_device_id {
> 	 
> 	 struct i2c_device_id {
> 		char name[I2C_NAME_SIZE];
> 	-	kernel_ulong_t driver_data;	/* Data private to the driver */
> 	+	union {
> 	+		/* Data private to the driver */
> 	+		kernel_ulong_t driver_data;
> 	+		const void *driver_data_ptr;
> 	+	};
> 	 };
> 	 
> 	 /* pci_epf */
> 
> and this requires that .driver_data is assigned via a named initializer
> for static data. This requirement isn't a bad one because named
> initializers are also much better readable than list initializers.
> 
> The union added to struct i2c_device_id enables further cleanups like:
> 
> 	diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
> 	index 0123ca8157a8..84272ba65d08 100644
> 	--- a/drivers/regulator/ad5398.c
> 	+++ b/drivers/regulator/ad5398.c
> 	@@ -207,8 +207,8 @@ struct ad5398_current_data_format {
> 	 static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
> 	 
> 	 static const struct i2c_device_id ad5398_id[] = {
> 	-	{ .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> 	-	{ .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
> 	+	{ .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
> 	+	{ .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
> 		{ }
> 	 };
> 	 MODULE_DEVICE_TABLE(i2c, ad5398_id);
> 	@@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
> 		struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
> 		struct regulator_config config = { };
> 		struct ad5398_chip_info *chip;
> 	-	const struct ad5398_current_data_format *df =
> 	-			(struct ad5398_current_data_format *)id->driver_data;
> 	+	const struct ad5398_current_data_format *df = id->driver_data_ptr;
> 	 
> 		chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
> 		if (!chip)
> 
> that are an improvement for readability (again!) and it keeps some
> properties of the pointers (here: being const) without having to pay
> attention for that. (I didn't find a nice driver below drivers/gpu that
> benefits, so this is "only" a regulator driver example.)
> 
> My additional motivation for this effort is CHERI[1]. This is a hardware
> extension that uses 128 bit pointers but unsigned long is still 64 bit.
> So with CHERI you cannot store pointers in unsigned long variables.
> 
> I was unsure if I should split the patch. I guess doing all of
> drivers/gpu/drm/bridge together is fine, please tell if I should split
> off drivers/gpu/drm/nouveau/ and/or drivers/gpu/drm/sitronix/.
> 
> Best regards
> Uwe
> 
> [1] https://cheri-alliance.org/discover-cheri/
>     https://lwn.net/Articles/1037974/
> 
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c           | 10 +++++-----
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c     |  2 +-
>  drivers/gpu/drm/bridge/analogix/anx7625.c              |  4 ++--
>  drivers/gpu/drm/bridge/chipone-icn6211.c               |  4 ++--
>  drivers/gpu/drm/bridge/chrontel-ch7033.c               |  2 +-
>  drivers/gpu/drm/bridge/ite-it6263.c                    |  2 +-

Reviewed-by: Liu Ying <victor.liu@nxp.com> # ite-it6263.c

-- 
Regards,
Liu Ying

  parent reply	other threads:[~2026-06-11  2:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 10:04 [PATCH] drm: Use named initializers for arrays of i2c_device_data Uwe Kleine-König (The Capable Hub)
2026-05-18 10:04 ` Uwe Kleine-König (The Capable Hub)
2026-05-18 10:09 ` Laurent Pinchart
2026-05-18 10:09   ` Laurent Pinchart
2026-05-18 10:12 ` Danilo Krummrich
2026-05-18 10:12   ` Danilo Krummrich
2026-05-18 16:57 ` Luca Ceresoli
2026-05-18 16:57   ` Luca Ceresoli
2026-06-10 17:15 ` Uwe Kleine-König (The Capable Hub)
2026-06-10 17:15   ` Uwe Kleine-König (The Capable Hub)
2026-06-22 14:50   ` Luca Ceresoli
2026-06-22 16:15     ` Uwe Kleine-König (The Capable Hub)
2026-06-22 16:15       ` Uwe Kleine-König (The Capable Hub)
2026-06-11  2:15 ` Liu Ying [this message]
2026-06-11  2:15   ` Liu Ying
  -- strict thread matches above, loose matches on Subject: below --
2026-05-18 10:14 Uwe Kleine-König (The Capable Hub)
2026-05-18 11:07 ` Uwe Kleine-König (The Capable Hub)
2026-05-22  9:41   ` Greg Kroah-Hartman
2026-05-22 13:29     ` Uwe Kleine-König (The Capable Hub)

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=aioaSKDk9LJYD6i3@raspi \
    --to=victor.liu@nxp.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=adrien.grassein@gmail.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.yan@rock-chips.com \
    --cc=arnd@arndb.de \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=dakr@kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fshao@chromium.org \
    --cc=ian.ray@ge.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=luca.ceresoli@bootlin.com \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=manikandan.m@microchip.com \
    --cc=marcus.folkesson@gmail.com \
    --cc=martyn.welch@collabora.co.uk \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=peter.senna@gmail.com \
    --cc=rfoss@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tommaso.merciai.xr@bp.renesas.com \
    --cc=tzimmermann@suse.de \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=xji@analogixsemi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.