From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 975433AD50E for ; Tue, 19 May 2026 19:51:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779220287; cv=none; b=DNvEWJpkw6Acgx4xJ2YvRWIeFkGikEwTDtx7FOjfGFx2LEukDoG6mPqSYdIflwTTGawqaUfk/mQSyDqCms3Cjc5qYAp/WTsJlOeTNvvdaQ5jhBIN7Ut1jaNaeMEKO8PyR2DTN+IX4XhL0h0pgPkZ0agl/Ed/9DjriJfeD1GWKI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779220287; c=relaxed/simple; bh=0TaKRAnKnNwqy74i/sb/1XJBkSa4AsHKFyv20tLHTtk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kP10t4od9gGGWBzAdoKDoRXu5ABJX72CQvKT0Gm/Jr6BEWAZurnFOi5axPTFCKPr22Cwu2I9dkn3PbYfU/6mluz6EZ+HdJkhVl6VeMfIsD5Sz06/4a3Lqaj/sigK8TNrvF/CdoxS2YmefM6Ncu/RmP1MyWHn8iTEzQE8p9n3aqI= 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=WTfsASQr; arc=none smtp.client-ip=209.85.128.53 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="WTfsASQr" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-488d2079582so39156195e9.2 for ; Tue, 19 May 2026 12:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779220283; x=1779825083; 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=v9NBzb9aKlIq7Sd0DoDjattmaS8U7WMC1EqfiH19BzM=; b=WTfsASQr0Jq//3xmbSc3jbIgkQemnsI6NupcoBHfIP16hIulj5bLUr+6z3Oc560XJq Jk+AdpZk6FTbhHZQaZyrEEign8WAMm6o6koWu80b5QwffSufZ8wKzFJH5bg2SE8fouv/ XytLDv6dbCDzdIn3l1SqghCAHG7F6xF3ghpqUqzCBakdVfs4DpnUhkJJIJviGldp8Iql RB+lKGZtd/VnwGIuZNq05OMlaOB3rj8iKbiBau69ba2lbaFoTFDHB+5Lg6++LZg3pglG opJRLNhpvN730jNVR2QnuUeB9uV2Dr2SVxWnX6TzJev2z11u5mtkkyPSvn1j3Pt/6EyP eZxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779220283; x=1779825083; 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=v9NBzb9aKlIq7Sd0DoDjattmaS8U7WMC1EqfiH19BzM=; b=l3wbopRvB2s3ujdiOJXq0lF2DG9rPgibmYCc8tlFLYRn1IlN1j3846ZXEcuoIXXRZM Cx8xGA2q0F8usB24ispUR20rVX0riMF7tDLUnLmomvAx3DHWFaZ5NgqpLf2M4dslK3Iq paXmGKGAB5ZmemTdHim79XI0/7KK+2DYCIs+YrnGgFdx7vo3naFCmuCA4nf8UaqoUba7 2lvQcPZYuSMCh8p2mE6AwFUcmjTVjWcCHKGFt4l+AablB9DiOG3f9P8D9m8/uFJmvRCd TYhRY8KXl5GlzKS3D+sGcpAdhq1CAWdjJx5O+Pw0WR4fj/mE5LAXcNUEI0x1rHU1mrQS LIMA== X-Forwarded-Encrypted: i=1; AFNElJ+yB91FIxXuCsm/8FwIQ3lUkCV092sOMM3MrJw8RwZiOYENEE6MZK6Xlma37/eq03eOYe29LfH44TYkgbg=@vger.kernel.org X-Gm-Message-State: AOJu0YyC1/AESKeCUwIAKHQu2dudm7ioqyFrtJHuRRdmKFfYKt3WB0iw sWJ58tbOJw2wsxJqXebv4mm39UO1ZRH7w/S5+KXP2ZvvmGQyjlc2bWIsaxdo8YQC0zo= X-Gm-Gg: Acq92OFzHLIJWAnOkNmXv0nnlZOoYQITfok72yfT2t8Mf1yFXeEOV3+WaVA1KXWMcsx rudES52PFOavKa/mDPzEfEmJIxSfrd2VoEIhpSvkLJlGZXXSTe9I4/uGnhRAebndWaQD34ZW413 uauGolYpAuxHtZFShfNY8a90Rjo5CBDD5iYxHNYt1WdBfJGyelHNeLh7bwEzxyYFZtkdcdAR51M IJ06+spBeLAdyNMFvx/TAPfovxEnfssp0NhIx1GD4ybRdyPIr7P9+VcJMaGIVVRvdWjwz8cZO/8 52trem4MG3r50QIP2Y0jC8OlKEPCAIHnAKS1DJQvB1kV8Ufj6XUXVWCmEfOW7PqrZlsq2qlvSo7 sC77cb5a0EknHg6EQUT2F94eE2sjaMh+FHP5RjL6EM/hIc3vRVz+C/VK9xlF/hUuwRo9/08zoq1 chwVSZTLvM7YR+BMxPVni17iIckjkt X-Received: by 2002:a05:600d:c:b0:48a:56de:d62a with SMTP id 5b1f17b1804b1-48fe60eca75mr296779745e9.11.1779220282884; Tue, 19 May 2026 12:51:22 -0700 (PDT) Received: from localhost ([2a02:8071:56d1:2de0:1d24:d58d:2b65:c291]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-48fe53ab6aasm372620935e9.2.2026.05.19.12.51.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 12:51:22 -0700 (PDT) Date: Tue, 19 May 2026 21:51:20 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= To: Jonathan Cameron Cc: Lars-Peter Clausen , Michael Hennerich , David Lechner , Nuno =?utf-8?B?U8Oh?= , Andy Shevchenko , Puranjay Mohan , Marcelo Schmitt , Antoniu Miclaus , Ramona Gradinariu , Petre Rodan , Dan Robertson , Herve Codina , Matti Vaittinen , Francesco Dolcini , =?utf-8?Q?Jo=C3=A3o_Paulo_Gon=C3=A7alves?= , Hugo Villeneuve , Anshul Dalal , Gustavo Silva , Andreas Klinger , Tomasz Duszynski , Ariana Lazar , Rui Miguel Silva , Linus Walleij , Javier Carrasco , Li peiyu <579lpy@gmail.com>, Lorenzo Bianconi , Alex Lanzano , Jagath Jog J , Jean-Baptiste Maneyrol , Remi Buisson , Christian Eggers , Mudit Sharma , Kevin Tsai , =?utf-8?Q?Ond=C5=99ej?= Jirman , Dixit Parmar , Gerald Loacker , Akhilesh Patil , Eddie James , Petar Stoykov , Song Qiang , Siratul Islam , Crt Mori , Waqar Hameed , Sebastian Andrzej Siewior , Gustavo Vaz , Sakari Ailus , Marcus Folkesson , Guenter Roeck , Bartosz Golaszewski , Chuang Zhu , Kyle Hsieh , Giorgi Tchankvetadze , Chen-Yu Tsai , Oleksij Rempel , Romain Gantois , Sander Vanheule , David Jander , Andrew Davis , chuguangqing , Shrikant Raskar , Kurt Borja , Denis Benato , Ethan Tidmore , Tomas Borquez , Srinivas Pandruvada , Shi Hao , Xichao Zhao , Erikas Bitovtas , Aldo Conte , Colin Ian King , Gabriel Almeida , Gabriela Victor , Beatriz Viana Costa , Frank Li , Adrian Fluturel , Antoni Pokusinski , Yasin Lee , Felix Gu , Ben Collins , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 7/7] iio: Initialize i2c_device_id arrays using member names Message-ID: References: <4b6ea3483356d758a90bfb8970ed0f1df2f31cfc.1779136001.git.u.kleine-koenig@baylibre.com> <20260519193913.6466630b@jic23-huawei> 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="lct2h5a7d7neno6s" Content-Disposition: inline In-Reply-To: <20260519193913.6466630b@jic23-huawei> --lct2h5a7d7neno6s Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 7/7] iio: Initialize i2c_device_id arrays using member names MIME-Version: 1.0 [Dropped one recipient who's email address isn't valid any more] Hello Jonathan, On Tue, May 19, 2026 at 07:39:13PM +0100, Jonathan Cameron wrote: > On Tue, 19 May 2026 10:13:09 +0200 > Uwe Kleine-K=C3=B6nig (The Capable Hub) wr= ote: >=20 > > 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. > >=20 > > The mentioned robustness is relevant for a planned change to struct > > i2c_device_id that replaces .driver_data by an anonymous union. > >=20 > > This patch doesn't modify the compiled arrays, only their representation > > in source form benefits. The former was confirmed with x86 and arm64 > > builds. > >=20 > > Signed-off-by: Uwe Kleine-K=C3=B6nig (The Capable Hub) >=20 > I'd prefer it split into cases you care about (not just name) and the nam= e only ones. > That is unless I'm missing some potential change that breaks initializing > just the first element and hence not the union you plan to add. >=20 > It's a lot of churn and the name one isn't enabling anything new unless > I'm missing something. Today all hunks are about using named initializers to improve readability, so the split into only .name vs. .name+.driver_data feels very artificial to me. But if you think that's the compromise to use, I'll adapt. > We also get fixes in these annoyingly often so chances are this will mess > up backports. Might even be worth splitting it up into directories > just to reduce that backport mess. In my opinion this is the reason to do this kind of cleanup with one patch per driver. This doesn't only make backports easier, it also allows to better record who reviewed and acked what, it reduces merge conflicts (because if one driver is updated in your tree already since my base, with one subsystem patch you get a merge conflict which makes the whole patch unapplicable, with one patch per driver only one out of (here) 208 fails). But that isn't popular with most subsystem maintainers and so I went with one patch per subsystem. =F0=9F=A4=B7 > Also, have you done a checkpatch check for this? Nice to not being fight= ing > it for ever. No, but that's on my agenda. Best regards Uwe --lct2h5a7d7neno6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmoMvzUACgkQj4D7WH0S /k5vLwgAiL6CW2R+kMxHjrhDUR7VIhFCG2wMBKLz5WbkBWU5squkTN/1qVtoWWar vci9CmfyXf4DAHwPE5VxqFdI/2hnHkZGY+9HdlZ5rCA0eE9uRtLRXpmagLU8vP7G qwGeXmdRXcSleK+2+J6mG2vC4TJ0UzR8V/2gwYk1Blpah9QGIHAWS3MlOHQpkatg qVvkxhTS+BBYcEf5Anqk+X2GoX5yM1BAJxN3ruPTt0kSKHs4IS5hDeorUgfadCD2 Sh1f5bn07i2pkm8es6dISs5b5wruLTNr8sUXdDy3nFpOcTFl2esGEFYyc2F+QwWJ s9hr9xBFuzUzOyfUryv2POEO1qXSEg== =P7dV -----END PGP SIGNATURE----- --lct2h5a7d7neno6s--