From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FF4F38A71E for ; Fri, 22 May 2026 08:16:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779437807; cv=none; b=EU/hQQdN/tVWaacVBPjctgKnwwlOWgWcvrV43p23vJ748/HwNYqhJDpx2eRVTKMlhJ2LfYZ/MPTZJO5Y7nK/9L/8YmdZpSJzCRS9DDqvK8Sd4PETt1qGmhdE/YV9w1pkdTBRnEQwmlvFGu9TmgzborsNjO9XwgTm4Uj60An8xRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779437807; c=relaxed/simple; bh=4xr6TiUPW8v1GkJ2kQh+aF08s5fPR+TLtY9G5S+pan0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KR0pJOcpuUKzmTzruuNaH1XaykQmN0SChOEDfev9uNqeB2v7MrBAUVpIXdsz6fqJ4UxpCHA1rqKoVlptvexy3rSZQx+e8nOQtNXwEbOlFTpaMka/707Xb9nQeUwLXku7WilWkaPjGAizyzQ+7vy86g18Nr3zRvnYqozKu7Y6UrM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b=Z2kPyC+w; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre.com header.i=@baylibre.com header.b="Z2kPyC+w" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-488b0e1b870so96944055e9.2 for ; Fri, 22 May 2026 01:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779437803; x=1780042603; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3w5FjT/WZBxeuDvVvB7bWeB0eUVUUyftobEv50KkzpY=; b=Z2kPyC+wj+bezCgK81TqyXpH9deHhgbalx0zkveS5+3Ipm6yj4rVrvqaGlpDfX5HsU BIs7AznBPmj7fmQ6d/zMOXmSBOVt0TKK+Y57PneGFax1hs69ZfyfXcT1BpvH/cVKRnc/ xM6XwDUdRR6wjaFInRJa4wcjVQP+JI4I4xybyWAegZTfG1E6vqc4aC4h00kqUU76vJRr XkCIGURQNTj55w2K1YuGsi1qruMUx3hmYXBQd+0RtEy3p2cUcG8CD6NEoFE88mpdH3CD x20LaDub6E/6JNlQXzzq7P/s+RdWhuZMPWrPHNos0g//dnbC6+RFvo6Cf7eVo8p7tyif g1PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779437803; x=1780042603; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3w5FjT/WZBxeuDvVvB7bWeB0eUVUUyftobEv50KkzpY=; b=cRYPuEisLE/G2G5XYzFHPc8X7uIlXBZTTZH4+nnim1m/E5tBdZcq+iqUmiM+d3oMeS olSgOk9/FRE7XB0xucUdcClDFBE3mS7XDXKOjE31YKMrtcQuqOsR1sd+7hFwgTPyMeF6 HhgXqPJdCuT7HasYsiCxw9RlY/TTbqJWqnfQz4mBfswcxLUlU/D5E+Qo1+JFmosNGH39 wujiSoE8Ozh+vsAODUfkfJlZOTujT7kdWRBo5Q85uV0uVY5Owq93mVhG/BuhpohCP9ow uuHyZDeCBds97uz5qbHjmeeXAXnppjmWgrKY17Ce4aQ0K1L24uUPGGAjLriycg40VOqp k/Fw== X-Forwarded-Encrypted: i=1; AFNElJ/TlV2r/C4hXK55SZo2ImV03CUc3HXPCg0Czm5JLnQh9D6mdAbHNbfI3w3I2tsOzHKhXOJDgp8KtAkKvnA=@vger.kernel.org X-Gm-Message-State: AOJu0YwegQp160LqiUvx+hvIro4ZviJUI++W/fM0JYnqeMnZ1vEAzmB4 jeSeHzDiJvO3HYyqZnr4tu26o9R9+grn6XpJxcY62e5y28REzqufjN/nzH+qWDEMluM= X-Gm-Gg: Acq92OE+slYJrE/WUvw7cqVBCHqX1sFZ7IxoFdfEriB8H2KNiy8Q1CaVKM+p72MW9Xa xKEHt4/t0II2jqNUGhm5XlWBQ0VICJk9GDLtlw21nVIznl4PA604muYd85ydFgsCUKQgFdRnSjF R1yg/vncI2EG4oYqYNJZsRrK7QYc6GfxbOvF7rtJPuJ09rZKyY/Kv7CefoZC5KFcxAPJWjFJ9EA R3ZJzXteyES8+QUvaUJDdpOy7uHEd3224CViHLiCj5aVUWBso1F/AgxtSBZIO1hKgo9JUNojs0/ BR9bo8ka6fjecthupbgVyC7G7rVXVXpVmJGakmWJAUaYSz+b9Ukv/Hvy8oOpldeCrVz+4HZb1Sz SV83wsBb7pZdzuYQl10uYVAPaidWDfDpSXQox8F4g1ETS2sPJqd1eynM5vRDPOK8TfDuI47teid cNCNvvcd3LRW4KRTLmEKXzIFtgSyS9XAik+9NYM4hmRzeJG2GbqRNo/sYYOVUVO81yzvz+CVMVb CC3JHHxCdTxqJhf5Gg4y1PC2Q== X-Received: by 2002:a05:600c:a402:b0:488:a882:c7 with SMTP id 5b1f17b1804b1-490426ddc0fmr22001735e9.25.1779437802772; Fri, 22 May 2026 01:16:42 -0700 (PDT) Received: from localhost (p200300f65f47db041c3ec60b7ac1bfbb.dip0.t-ipconnect.de. [2003:f6:5f47:db04:1c3e:c60b:7ac1:bfbb]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-49042af0ac1sm10569715e9.31.2026.05.22.01.16.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 01:16:40 -0700 (PDT) Date: Fri, 22 May 2026 10:16:39 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= To: Jarkko Sakkinen Cc: Peter Huewe , Jason Gunthorpe , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] tpm: Use named initializers for arrays of i2c_device_data Message-ID: References: <20260518134035.644762-2-u.kleine-koenig@baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ureockz27qr6vm2b" Content-Disposition: inline In-Reply-To: --ureockz27qr6vm2b Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] tpm: Use named initializers for arrays of i2c_device_data MIME-Version: 1.0 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=F6nig (The Capable= Hub) wrote: > > The union added to struct i2c_device_id enables further cleanups like: > >=20 > > 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 =3D {10, 4= , 0, 120000}; > >=20 > > static const struct i2c_device_id ad5398_id[] =3D { > > - { .name =3D "ad5398", .driver_data =3D (kernel_ulong_t)&df_10_4_120 = }, > > - { .name =3D "ad5821", .driver_data =3D (kernel_ulong_t)&df_10_4_120 = }, > > + { .name =3D "ad5398", .driver_data_ptr =3D &df_10_4_120 }, > > + { .name =3D "ad5821", .driver_data_ptr =3D &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 =3D dev_get_platdata(&client->= dev); > > struct regulator_config config =3D { }; > > struct ad5398_chip_info *chip; > > - const struct ad5398_current_data_format *df =3D > > - (struct ad5398_current_data_format *)id->driver_data; > > + const struct ad5398_current_data_format *df =3D id->driver_data_ptr; > >=20 > > chip =3D 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.] =20 > > 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.) > >=20 > > 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. >=20 > 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 soo= n, 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. Best regards Uwe --ureockz27qr6vm2b Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmoQENsACgkQj4D7WH0S /k45kAgAqkAkvJVYFJvmCb/Ow6OtCLbDmgMC4pHbX+AFjY//4ZasznV3eliwAL0U JO2SE9QCUPVHR3X2kJ5vHU8M9O3tH5UTd3sIoCClyfAvAvHznK1aNc5tL3EMkZs+ //OcE3tbopZobdoqZk5TW/zG1NO9JD+RELeeG0bZSFIjoxCxb6u4CK6e9RnkZpfZ yICl5zzDrpjm0/DZCz3Te4S2CTgSm0Bnt9QqBaQLLyzu3KpdI8zzwC2O+hrJRY38 TCabhRp55hin4KsVspCZoyGvf36029DKTSeN+LlFZfjuecW43z6eh9YJL3rurCAu bOM3HPSHoo/xqjKlSmLHKx1hXwks9Q== =ePXN -----END PGP SIGNATURE----- --ureockz27qr6vm2b--