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 99D603B19BA for ; Thu, 21 May 2026 13:20:13 +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=1779369616; cv=none; b=G/qDXKZk8LbXBWzQUx97Gh5lTZ4M3s6Ew/1y25a9RQQkAIGxMCB33oUxYmkZgGbUkOyVKAnkUEFpA/Q+2nMwXJ+zxBPj4JI07w7iLKXv7PKCmo1oDgWWrMuNHy4G9BSojDK54wfJvm9popaprolBoS/n3veOUrhhopf+jm5EOjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779369616; c=relaxed/simple; bh=nrsTgdOjEJeWw4i+oxKSJRFt6nK4yWJrSglLcq6KOZ0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rgH0l/5xqEGQgtyNcIcoG9gsRaIN+Aw+x/pcL8xsEvoq4tj/XsQjx4UcLi4S2xlabAq3vqFWkUOEBVuQz0PZ0TxAqe1s0/dx+GXpscF1/0WZ/QcQbuiJWKkd9aOE/o7Lq4BO9jR31GrCY05pVgvcxqwtXq1d6ivDvkXeOH7ogpM= 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=AX8e0yca; 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="AX8e0yca" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-488b3f8fa2bso55623375e9.1 for ; Thu, 21 May 2026 06:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779369612; x=1779974412; 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=/ui11/N3Y9C06bp42EyC03xisf2LgzZNi0LxtE5/p5o=; b=AX8e0ycaeseOb/Oz2Z5mG0RysGw4PW/98a4L6OmQdxxNrGkuCEdJhdgz9v7dzIKyfW iHo6WcHCNeEp6FX4PZR4PUpjcFIVPxgGQOfPwihAl+I5Jt76RNFwgzNdFAozIkfQsg/X VSGjXKJt0Anc4oJWW2btdeM1cwL/Ou5KtldldNusWFn+W1HK3AYPhQQdlkrVJwcfxY9V wFY0M9siR0vz9RwWy/Lk0KvLiXwSJxHqzOLcUjC6F54yRIDT42/W8m3yKSyBvHPsBecE zVon+jptpfzXNlW5++ns0nJhHOpURXP+eu+lveQL0KPu14+abHIuj1KJ5JEVmDlUfgR1 8gng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779369612; x=1779974412; 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=/ui11/N3Y9C06bp42EyC03xisf2LgzZNi0LxtE5/p5o=; b=QJnncHdarUM2IbRjcF/EnUUdrmgz5pbtsfdZtcS2uuveV44JZ1NWc9vuzXegD6PRvr ULW/jIse4ntub32uJTC26NVOv3dtu84GtJsv5MQIMNiBRQQT4OO/gOyNWi4BSx2a/vR5 se9N146wv2U0HayZM6tdMyUXBlH9FZkA108OOIaDXZUf3GNinse3aez8f9Ie2DN1O6C1 hrILyMHeANaER9YL6eVIKrxHxJ3+Lwp+J61bD5YqauQuzU8D1ZkIET/qdi5ZcDkFfTOb 8mWdfvwINJpFog7pZqA10/14QdbYxvf2y1H071lQY/q5c65maWyX5mAGDNnYm3RofsNo Ixhw== X-Forwarded-Encrypted: i=1; AFNElJ9HgdG1IkEdiS1tFZ/yF9+cglRuuY02F6SvjwEy8E9wh2+q2tMFGUq8+k9v8N3zxgamxOHTp5+5Vl8Dq3w=@vger.kernel.org X-Gm-Message-State: AOJu0YylQfIbTc7WfHiXkHbePz6m8fDdeKfpwHRSF8cX0yqJ+Y5SmqZb gjWoG/0YBKachBrfm1yKCfAKkDdvj412vyAJhZ0Qszcq2c/4Mx5RImm51g7EgeNWjd0= X-Gm-Gg: Acq92OFTr0cor6mPe6rmIX2CEAqv+Itiih+S3eYDItn1VXZ9bduGzC2xdGmz07QvBfo YD0Ba/T3OeoezsAbNTmcy9XF+Q44VZfFF1Lb2w4QtmayeSfjkFBsP3Mdz3VwESQ69gB48YLqWM+ 8UQbkBqgoFbuPZSC7IVLJkw+rfZ2vYubVb7zx01R7BcDVWO9GX0eQAKGxIeDolj+s5E76yCnjJR HQ5S5MXF7fb8SOttO1ADejW0ALpRj2SDA1vsmjqZyP+BmH8Jjmwu3zgRB3foNzi9AZNsyDRBYDr BsBcruz3/UIU8Dx8WyaIob3hLZ0Qqp4AHF6ZdM9mJzDeq+YPHHQrNDw6vZXZNEdVWG9gnpHjz0O TC6P2T3qahQg/vXuOQqGZr+8Rfm5ECyLDRsuQB2mBeGcQ3TOfsXIA1Um/7Ztq0SeCx9UsSoO5P1 Jf1tAOS4kUyFfEehZ3x0TnJrOF7mNuHNk0XDmu8Kbrn3VtBseGn0Mp0AhuSvuIJCC1H5YgXJTEX 5fGrqKUA+HFyxc= X-Received: by 2002:a05:600c:6b12:b0:488:7d5b:125d with SMTP id 5b1f17b1804b1-49035f2e4f2mr28581115e9.7.1779369611032; Thu, 21 May 2026 06:20:11 -0700 (PDT) Received: from localhost (p200300f65f47db0477b163ab18b6d155.dip0.t-ipconnect.de. [2003:f6:5f47:db04:77b1:63ab:18b6:d155]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-45eaa756d61sm2935233f8f.0.2026.05.21.06.20.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 06:20:10 -0700 (PDT) Date: Thu, 21 May 2026 15:20:09 +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> <20260521130444.197d2867@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="exkb54tmb3ufc4j3" Content-Disposition: inline In-Reply-To: <20260521130444.197d2867@jic23-huawei> --exkb54tmb3ufc4j3 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 Hello Jonathan, On Thu, May 21, 2026 at 01:04:44PM +0100, Jonathan Cameron wrote: > On Tue, 19 May 2026 21:51:20 +0200 > Uwe Kleine-K=C3=B6nig (The Capable Hub) wr= ote: > > 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) wrote: > > > =20 > > > > While being less compact, using named initializers allows to more e= asily > > > > see which members of the structs are assigned which value without h= aving > > > > 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 represent= ation > > > > 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 > > >=20 > > > I'd prefer it split into cases you care about (not just name) and the= name only ones. > > > That is unless I'm missing some potential change that breaks initiali= zing > > > 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 unle= ss > > > I'm missing something. =20 > >=20 > > 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. > >=20 > > > 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. =20 > >=20 > > 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). > >=20 > > But that isn't popular with most subsystem maintainers and so I went > > with one patch per subsystem. =F0=9F=A4=B7 >=20 > Meh. This is going to be painful whatever, so to have it as fresh > as possible I'll pick it up now as one giant patch. \o/, thanks. > Note there are already conflicts... Fixed up: > light/tsl2772.c (a couple more entries) > light/vcnl4000.c (data is now all pointers, not enum values). >=20 > Bunch of line changes in other drivers, but otherwise went in fine. I reproduced the issue, my conflict resolution (on top of next-20260521) looks as follows: diff --cc drivers/iio/light/tsl2772.c index 9ba8140c8bc1,1b1c704f1d6c..000000000000 --- a/drivers/iio/light/tsl2772.c +++ b/drivers/iio/light/tsl2772.c @@@ -1900,19 -1888,17 +1900,19 @@@ static int tsl2772_resume(struct devic } =20 static const struct i2c_device_id tsl2772_idtable[] =3D { - { "tsl2571", tsl2571 }, - { "tsl2671", tsl2671 }, - { "tmd2671", tmd2671 }, - { "tsl2771", tsl2771 }, - { "tmd2771", tmd2771 }, - { "tsl2572", tsl2572 }, - { "tsl2672", tsl2672 }, - { "tmd2672", tmd2672 }, - { "tsl2772", tsl2772 }, - { "tmd2772", tmd2772 }, - { "apds9900", apds9900 }, - { "apds9901", apds9900 }, - { "apds9930", apds9930 }, + { .name =3D "tsl2571", .driver_data =3D tsl2571 }, + { .name =3D "tsl2671", .driver_data =3D tsl2671 }, + { .name =3D "tmd2671", .driver_data =3D tmd2671 }, + { .name =3D "tsl2771", .driver_data =3D tsl2771 }, + { .name =3D "tmd2771", .driver_data =3D tmd2771 }, + { .name =3D "tsl2572", .driver_data =3D tsl2572 }, + { .name =3D "tsl2672", .driver_data =3D tsl2672 }, + { .name =3D "tmd2672", .driver_data =3D tmd2672 }, + { .name =3D "tsl2772", .driver_data =3D tsl2772 }, + { .name =3D "tmd2772", .driver_data =3D tmd2772 }, ++ { .name =3D "apds9900", .driver_data =3D apds9900 }, ++ { .name =3D "apds9901", .driver_data =3D apds9900 }, + { .name =3D "apds9930", .driver_data =3D apds9930 }, { } }; =20 diff --cc drivers/iio/light/vcnl4000.c index 88fc7424ae35,fc2161d5f3c7..000000000000 --- a/drivers/iio/light/vcnl4000.c +++ b/drivers/iio/light/vcnl4000.c @@@ -2039,18 -2142,6 +2039,18 @@@ static int vcnl4000_runtime_resume(stru static DEFINE_RUNTIME_DEV_PM_OPS(vcnl4000_pm_ops, vcnl4000_runtime_suspen= d, vcnl4000_runtime_resume, NULL); =20 +static const struct i2c_device_id vcnl4000_id[] =3D { - { "cm36672p", (kernel_ulong_t)&cm36672p_spec }, - { "cm36686", (kernel_ulong_t)&vcnl4040_spec }, - { "vcnl4000", (kernel_ulong_t)&vcnl4000_spec }, - { "vcnl4010", (kernel_ulong_t)&vcnl4010_spec }, - { "vcnl4020", (kernel_ulong_t)&vcnl4010_spec }, - { "vcnl4040", (kernel_ulong_t)&vcnl4040_spec }, - { "vcnl4200", (kernel_ulong_t)&vcnl4200_spec }, ++ { .name =3D "cm36672p", .driver_data =3D (kernel_ulong_t)&cm36672p_spec = }, ++ { .name =3D "cm36686", .driver_data =3D (kernel_ulong_t)&vcnl4040_spec }, ++ { .name =3D "vcnl4000", .driver_data =3D (kernel_ulong_t)&vcnl4000_spec = }, ++ { .name =3D "vcnl4010", .driver_data =3D (kernel_ulong_t)&vcnl4010_spec = }, ++ { .name =3D "vcnl4020", .driver_data =3D (kernel_ulong_t)&vcnl4010_spec = }, ++ { .name =3D "vcnl4040", .driver_data =3D (kernel_ulong_t)&vcnl4040_spec = }, ++ { .name =3D "vcnl4200", .driver_data =3D (kernel_ulong_t)&vcnl4200_spec = }, + { } +}; +MODULE_DEVICE_TABLE(i2c, vcnl4000_id); + static struct i2c_driver vcnl4000_driver =3D { .driver =3D { .name =3D VCNL4000_DRV_NAME, diff --git a/drivers/iio/adc/rtq6056.c b/drivers/iio/adc/rtq6056.c index e2b1da13c0d3..ae50fb27bac9 100644 --- a/drivers/iio/adc/rtq6056.c +++ b/drivers/iio/adc/rtq6056.c @@ -872,8 +872,8 @@ static const struct richtek_dev_data rtq6059_devdata = =3D { }; =20 static const struct i2c_device_id rtq6056_id[] =3D { - { "rtq6056", (kernel_ulong_t)&rtq6056_devdata }, - { "rtq6059", (kernel_ulong_t)&rtq6059_devdata }, + { .name =3D "rtq6056", .driver_data =3D (kernel_ulong_t)&rtq6056_devdata = }, + { .name =3D "rtq6059", .driver_data =3D (kernel_ulong_t)&rtq6059_devdata = }, { } }; MODULE_DEVICE_TABLE(i2c, rtq6056_id); The last hunk was made necessary by commit ce80292ead5bb42b50a6b63e44fd95c0edf9d334. And I'm pretty sure that the following is possible on top: static const struct of_device_id rtq6056_device_match[] =3D { - { .compatible =3D "richtek,rtq6056", .data =3D &rtq6056_devdata }, - { .compatible =3D "richtek,rtq6059", .data =3D &rtq6059_devdata }, + { .compatible =3D "richtek,rtq6056" }, + { .compatible =3D "richtek,rtq6059" }, { } }; MODULE_DEVICE_TABLE(of, rtq6056_device_match); > There are a few new instances in tree, though from a quick glance > maybe no i2c ones. Since you sent the first series I've been looking > out for this in reviews, but some stuff was a already queued. >=20 > Anyhow, new ones can be dealt with in follow up patches. There will more some more drivers I missed in other subsystems, so I'll have to reiterate anyhow. If you catch drivers before going in, that's great, but it's not a problem if you miss a few. Thanks for your cooperation, Uwe --exkb54tmb3ufc4j3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmoPBnwACgkQj4D7WH0S /k7DPgf9HjQKvhx202kbjhgSP/d1dU+25Ut5EULsIFMhCQ3zxf0AiGZY0C5GuoCy RCHet47pR/oglvtrQBoebwQb+ohzep35STOwP9jnhf9ickyPrktyN9AB6Skf7vHo 7sZhGr40khNOOLhXglURLHKjdYBhISDbNq4EVyC8OKeUW5V/SLPFagUkbjNbGMXE IUz5P6dJ+UFfqLU6GfidVBUciH17vOaKYFPNJQ/H4R7TFyR8tfsTpBiD7HO8V+Xa ck7YlbmBabHWjApQlWOj1uBy6NIvsBQwQVgVfHP1hRs8V5Ft4ADi+lBfDDrCCC39 ICZwHwFJXUH5y32MFdYBq1MHRUJiow== =lHNq -----END PGP SIGNATURE----- --exkb54tmb3ufc4j3--