Received-SPF: pass (google.com: domain of linux-kernel+bounces-197983-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 1 Jun 2024 19:43:28 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: Nuno =?UTF-8?B?U8Oh?= <noname.nuno@gmail.com>
Cc: David Lechner <dlechner@baylibre.com>, "Ceclan, Dumitru" 
 <mitrutzceclan@gmail.com>, dumitru.ceclan@analog.com, Lars-Peter Clausen
 <lars@metafoo.de>, Michael Hennerich <Michael.Hennerich@analog.com>, Rob
 Herring <robh@kernel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/6] iio: adc: ad7173: Add support for AD411x devices
Message-ID: <20240601194328.6c28f743@jic23-huawei>
In-Reply-To: <d3c2496deb6a1764d06a63592b416d30d43fcc47.camel@gmail.com>
References: <20240527-ad4111-v3-0-7e9eddbbd3eb@analog.com>
	<20240527-ad4111-v3-5-7e9eddbbd3eb@analog.com>
	<6f18184de4a37993baedc15b44ecf0a6834a24d1.camel@gmail.com>
	<917bc1d9-fbdc-4ca2-a156-813b57c8201e@gmail.com>
	<30192c2a-5275-41ac-bc20-aa5f436846a3@baylibre.com>
	<d3c2496deb6a1764d06a63592b416d30d43fcc47.camel@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, 30 May 2024 08:19:57 +0200
Nuno S=C3=A1 <noname.nuno@gmail.com> wrote:

> On Wed, 2024-05-29 at 15:59 -0500, David Lechner wrote:
> > On 5/29/24 9:03 AM, Ceclan, Dumitru wrote: =20
> > > On 29/05/2024 15:46, Nuno S=C3=A1 wrote: =20
> > > > On Mon, 2024-05-27 at 20:02 +0300, Dumitru Ceclan via B4 Relay wrot=
e: =20
> > > > > From: Dumitru Ceclan <dumitru.ceclan@analog.com> =20
> > >=20
> > > ...
> > >  =20
> > > > > =C2=A0static const struct ad7173_device_info ad7173_device_info[]=
 =3D {
> > > > > +	[ID_AD4111] =3D {
> > > > > +		.name =3D "ad4111",
> > > > > +		.id =3D AD7173_AD4111_AD4112_AD4114_ID,
> > > > > +		.num_voltage_inputs_with_divider =3D 8,
> > > > > +		.num_channels =3D 16,
> > > > > +		.num_configs =3D 8,
> > > > > +		.num_voltage_inputs =3D 8,
> > > > > +		.num_gpios =3D 2,
> > > > > +		.higher_gpio_bits =3D true,
> > > > > +		.has_temp =3D true,
> > > > > +		.has_vcom_input =3D true,
> > > > > +		.has_input_buf =3D true,
> > > > > +		.has_current_inputs =3D true,
> > > > > +		.has_int_ref =3D true,
> > > > > +		.clock =3D 2 * HZ_PER_MHZ,
> > > > > +		.sinc5_data_rates =3D ad7173_sinc5_data_rates,
> > > > > +		.num_sinc5_data_rates =3D ARRAY_SIZE(ad7173_sinc5_data_rates),
> > > > > +	}, =20
> > > >=20
> > > > At some point it would be nice to drop the ad7173_device_info array=
...
> > > >  =20
> > > What are good alternatives to this? =20
> >=20
> > Drivers like ad7091r8 have individual static struct ad7091r_init_info
> > instead of putting them all in an array. I like doing it that
> > way because it makes less code to read compared to having the
> > array.
> >=20
> > It would let us get rid of enum ad7173_ids, have one level less
> > indent on each static const struct ad7173_device_info and=20
> >=20
> > { .compatible =3D "adi,ad7172-2", .data =3D &ad7173_device_info },
> >=20
> > would now fit on one line since we no longer need the array
> > index.
> >  =20
>=20
> Exactly... But up to you to do it now or defer it to a later patch.
>=20
Agreed - the array pattern for this is not a good idea as it
also encourages people to assign meaning to the enum values leaving
stuff expressed as code that should be a flag or value inside these
device_info structures.

Some of those where mistakes of a younger me ;(

Jonathan

> - Nuno S=C3=A1