Re: [PATCH] leds: Use named initializers for arrays of i2c_device_data

["Sverdlin, Alexander" <alexander.sverdlin@siemens.com>]

Hi Uwe,

On Fri, 2026-05-15 at 18:33 +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 and commas.
> 
> 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>

LGTM,
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.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..dfb0b07500a7 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;
> 	
> 	 	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 led driver 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.
> 
> Best regards
> Uwe
> 
>  drivers/leds/flash/leds-as3645a.c |  2 +-
>  drivers/leds/flash/leds-lm3601x.c |  4 ++--
>  drivers/leds/leds-an30259a.c      |  2 +-
>  drivers/leds/leds-aw200xx.c       | 10 +++++-----
>  drivers/leds/leds-bd2802.c        |  2 +-
>  drivers/leds/leds-blinkm.c        |  4 ++--
>  drivers/leds/leds-is31fl319x.c    | 22 +++++++++++-----------
>  drivers/leds/leds-is31fl32xx.c    | 18 +++++++++---------
>  drivers/leds/leds-lm3530.c        |  4 ++--
>  drivers/leds/leds-lm3532.c        |  4 ++--
>  drivers/leds/leds-lm355x.c        |  6 +++---
>  drivers/leds/leds-lm3642.c        |  4 ++--
>  drivers/leds/leds-lm3692x.c       |  4 ++--
>  drivers/leds/leds-lm3697.c        |  2 +-
>  drivers/leds/leds-lp3944.c        |  4 ++--
>  drivers/leds/leds-lp3952.c        |  4 ++--
>  drivers/leds/leds-lp50xx.c        | 12 ++++++------
>  drivers/leds/leds-lp5521.c        |  2 +-
>  drivers/leds/leds-lp5523.c        |  4 ++--
>  drivers/leds/leds-lp5562.c        |  2 +-
>  drivers/leds/leds-lp5569.c        |  2 +-
>  drivers/leds/leds-lp8501.c        |  2 +-
>  drivers/leds/leds-lp8860.c        |  2 +-
>  drivers/leds/leds-lp8864.c        |  4 ++--
>  drivers/leds/leds-pca9532.c       |  8 ++++----
>  drivers/leds/leds-pca955x.c       | 12 ++++++------
>  drivers/leds/leds-pca963x.c       |  8 ++++----
>  drivers/leds/leds-pca995x.c       |  8 ++++----
>  drivers/leds/leds-st1202.c        |  2 +-
>  drivers/leds/leds-tca6507.c       |  2 +-
>  drivers/leds/leds-tlc591xx.c      |  6 +++---
>  drivers/leds/leds-turris-omnia.c  |  2 +-
>  drivers/leds/rgb/leds-ktd202x.c   |  6 +++---
>  33 files changed, 90 insertions(+), 90 deletions(-)

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com