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

["Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

Hello Jarkko,

On Fri, May 22, 2026 at 03:44:05PM +0300, Jarkko Sakkinen wrote:
> On Fri, May 22, 2026 at 10:16:39AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On Fri, May 22, 2026 at 12:43:23AM +0300, Jarkko Sakkinen wrote:
> > > 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.

I also disagree here. If a patch improves something (be it security,
runtime behaviour or maintainability) that should be reason enough to
accept it. If it's created by AI (or a by a newbie with the help of AI)
that's a reason to make sure the patch has the intended effect, but
that's essentially the same for any patch.

I agree that AI might get problematic if it floods maintainers and
effectively becomes a DOS attack to maintainer resources. But that
doesn't necessarily makes the patches it proposes bad.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]