From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACB3AC6FD1F for ; Sat, 25 Mar 2023 19:11:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229805AbjCYTLN (ORCPT ); Sat, 25 Mar 2023 15:11:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229659AbjCYTLM (ORCPT ); Sat, 25 Mar 2023 15:11:12 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D00B9E050; Sat, 25 Mar 2023 12:11:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3967C60C95; Sat, 25 Mar 2023 19:11:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48324C433EF; Sat, 25 Mar 2023 19:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679771470; bh=Sr64iYwMmramkuXW283DFJe6tl6JGpQNQCfz+yCLHNA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pb5D9leq9LNy7YwchEndf1oiHONuZCSi5f5AZ6U2h4syr9r6dv2n0AAmIDpsmBO3m 9TMsqBmCQkZrv96JKeaaHSk8/3yzYnIUyG9gvTuhGYS9F+koiH/n7Hrf7Ce9pRDKeW oblb/Rox2Ce6YV/JNZ5/9+P3DqbKHWCyg1TeQrSHhV1XFW4SmuV9RvDs5C3gPgeSwr okG//XxruFTD7STSVn93gBd6Hwhdfimjtw41ecPCAe6fihRmJwRXYjc0jKKIKLqzO/ 85y4cm7AlFohxJa1r1fHR58QbJu4tF1qq2tIMGwVTYUpSbo8Kk5p4KHkofunxLmFID p9Zip7+HmQh5Q== Date: Sat, 25 Mar 2023 19:26:12 +0000 From: Jonathan Cameron To: Naresh Solanki Cc: Lars-Peter Clausen , Lee Jones , Patrick Rudolph , 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> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Thu, 23 Mar 2023 17:31:18 +0530 Naresh Solanki 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, ®_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, ®_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.