Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 25 Mar 2023 19:26:12 +0000
From:   Jonathan Cameron <jic23@kernel.org>
To:     Naresh Solanki <naresh.solanki@9elements.com>
Cc:     Lars-Peter Clausen <lars@metafoo.de>, Lee Jones <lee@kernel.org>,
        Patrick Rudolph <patrick.rudolph@9elements.com>,
        linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/2] iio: max597x: Add support for max597x
Message-ID: <20230325192612.6181b07e@jic23-huawei>
In-Reply-To: <34756312-8a25-5a10-4ea5-59aeeb9e199b@9elements.com>
References: <20230322124316.2147143-1-Naresh.Solanki@9elements.com>
        <826f5de9-3aeb-6f7a-59e6-0504f8e92180@metafoo.de>
        <34756312-8a25-5a10-4ea5-59aeeb9e199b@9elements.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, 23 Mar 2023 17:31:18 +0530
Naresh Solanki <naresh.solanki@9elements.com> wrote:

> Hi,
>=20
> On 22-03-2023 09:28 pm, Lars-Peter Clausen wrote:
> > Hi,
> >=20
> > This looks really good. A few minor comments inline.
> >=20
> > On 3/22/23 05:43, Naresh Solanki wrote: =20
> >> [...]
> >> +static int max597x_iio_read_raw(struct iio_dev *iio_dev,
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 struct iio_chan_spec const *chan,
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 int *val, int *val2, long info)
> >> +{
> >> +=C2=A0=C2=A0=C2=A0 int ret;
> >> +=C2=A0=C2=A0=C2=A0 struct max597x_iio *data =3D iio_priv(iio_dev);
> >> +=C2=A0=C2=A0=C2=A0 unsigned int reg_l, reg_h;
> >> +
> >> +=C2=A0=C2=A0=C2=A0 switch (info) {
> >> +=C2=A0=C2=A0=C2=A0 case IIO_CHAN_INFO_RAW:
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D regmap_read(data->=
regmap, chan->address, &reg_l);
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (ret < 0)
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn ret;
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D regmap_read(data->=
regmap, chan->address - 1, &reg_h);
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (ret < 0)
> >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
turn ret; =20
> > Is there any chance of a race condition of getting inconsistent data=20
> > when splitting this over two reads? I.e. registers being updated with=20
> > new values in between the two reads. =20
> yes, reg_l holds lower 2 bits. due to latency in reads, value may differ.

Normally there is a way to avoid the tearing via a bulk read of some type.
Is that not possible here?  If not, there are various tricks such as
repeated reads until stable that can be used.


Looks like the device has a block read format that might work.