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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, May 22, 2026 at 10:16:39AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello Jarkko,
> 
> On Fri, May 22, 2026 at 12:43:23AM +0300, Jarkko Sakkinen wrote:
> > On Mon, May 18, 2026 at 03:40:35PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > 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_ptr;
> > > 
> > > 	 	chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
> > > 	 	if (!chip)
> 
> [redacted the example as it didn't compile as presented, added "_ptr" on
> last hunk's + line.]
>  
> > > 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 tpm 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.
> > 
> > I don't understand why any of this should be merged to be honest and
> > why I should care about CHERI when reviewing mainline patches.
> 
> While I think and hope that CHERI will become relevant for the industry soon,
> it's ok to not care about CHERI today and I mostly mentioned it to be
> transparent about *my* motivation.
> 
> Our eventual goal is to bring CHERI support to mainline linux so my team
> mates and I have to find a way to get patches like that in. In my eyes
> this compares well to PREEMPT RT: With that you have to follow more
> rules in some situations and implementing these and running an RT kernel
> makes bugs pop up that also affect mainline.
> 
> So I claim that working on CHERI is obviously beneficial to folks who
> have CHERI hardware, but also helps those who don't as CHERI is a way to
> easily spot a relevant set of bugs.
> 
> > Clean up can be side-effect but not a purpose.
> 
> Oh, I disagree. Having code in a state where you can easily see what
> happens helps to concentrate on the parts that are more complicated. So
> it's a win for maintenance and lowering the entry bar for people who are
> not used to Linux kernel code. There are parts in the kernel that are
> complicated, and we won't get rid of them, because operating systems are
> complicated. But my POV here is that making it easier where it's
> possible is a good thing and a reason for itself. You might call that a
> paper cut only, but these add up.
> 
> Also with the union in i2c_device_id the compiler warns you if some code
> is lacking a "const". So it becomes harder to make mistakes, this is
> also a reason that in my book is good enough for itself.

Actually what I said is more important than ever before given AI agents.

If I start to accept pure cleanups from humans it's like invitiation for
slop. This is actually an area where it would be advicable for any
maintainer to tighten the acceptance criteria.

> 
> Best regards
> Uwe

BR, Jarkko