Received-SPF: pass (google.com: domain of linux-kernel+bounces-176506-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Sat, 11 May 2024 12:29:55 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>, Alisa-Dariana Roman
 <alisadariana@gmail.com>, michael.hennerich@analog.com,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org, alexandru.tachici@analog.com,
 lars@metafoo.de, robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
 conor+dt@kernel.org, lgirdwood@gmail.com, broonie@kernel.org,
 andy@kernel.org, nuno.sa@analog.com, marcelo.schmitt@analog.com,
 bigunclemax@gmail.com, okan.sahin@analog.com, fr0st61te@gmail.com,
 alisa.roman@analog.com, marcus.folkesson@gmail.com, schnelle@linux.ibm.com,
 liambeguin@gmail.com
Subject: Re: [PATCH v7 5/6] dt-bindings: iio: adc: ad7192: Add AD7194
 support
Message-ID: <20240511122955.2372f56e@jic23-huawei>
In-Reply-To: <20240510-figure-cotton-1edeb2b92bbd@spud>
References: <20240430162946.589423-1-alisa.roman@analog.com>
	<20240430162946.589423-6-alisa.roman@analog.com>
	<20240430-winnings-wrongness-32328ccfe3b5@spud>
	<73365049-670b-4068-a159-fbdd0539f5a9@gmail.com>
	<d5b8b193-0694-4e65-9b0a-64fa689ed344@baylibre.com>
	<20240510-figure-cotton-1edeb2b92bbd@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 10 May 2024 22:26:22 +0100
Conor Dooley <conor@kernel.org> wrote:

> On Fri, May 10, 2024 at 09:21:37AM -0500, David Lechner wrote:
> > On 5/10/24 5:05 AM, Alisa-Dariana Roman wrote: =20
> > > On 30.04.2024 20:21, Conor Dooley wrote: =20
> > >> On Tue, Apr 30, 2024 at 07:29:45PM +0300, Alisa-Dariana Roman wrote:=
 =20
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 diff-channels:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Both inputs=
 can be connected to pins AIN1 to AIN16 by choosing the
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 appropriate=
 value from 1 to 16.
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 items:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minimum: 1
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 maximum: 16
> > >>> +
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 single-channel:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Positive in=
put can be connected to pins AIN1 to AIN16 by choosing the
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 appropriate=
 value from 1 to 16. Negative input is connected to AINCOM.
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 items:
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minimum: 1
> > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 maximum: 16=
 =20
> > >>
> > >> Up to 16 differential channels and 16 single-ended channels, but onl=
y 16
> > >> pins? Would the number of differential channels not max out at 8? =20
> > >=20
> > > Hello, Conor! I really appreciate the feedback!
> > >=20
> > > The way I thought about it, the only thing constraining the number of=
 channels is the reg number (minimum: 0, maximum: 271). 272 channels cover =
all possible combinations (16*16 differential and 16 single ended) and I th=
ought there is no need for anything stricter. I added items: minimum:1 maxi=
mum:16 to make sure the numbers are from 1 to 16, corresponding to AIN1-AIN=
16.
> > >=20
> > > Please let me know what should be improved!
> > >=20
> > > Kind regards,
> > > Alisa-Dariana Roman.
> > >  =20
> >=20
> > Having looked at the datasheet for this and other similar chips, I agree
> > that this reasoning makes sense. Some of the similar chips that have fi=
xed
> > channel assignments still have, e.g. a channel where + and - are both
> > AIN2 (I assume for diagnostics). So I think it makes sense to allow for
> > doing something similar here even if the most common use cases will
> > probably have at most 16 channels defined in the .dts. =20
>=20
> Actually, I think there were a bunch of whiffs on this one by either
> misreading the property in question (me) or not realising that I had done
> that and trying to explain what the possible combinations are.
> Looking at it now, I dunno wtf I was smoking because there's no way that
> this would be a functional binding if the min/max in the quote above
> constraining the number of channels. I can hardly blame y'all for that
> though, I am supposed to know how bindings work after all...

Me too :(  I also failed to register this doesn't constrain
channel counts at all.

Anyhow, all's well that ends well!

J