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;
From:   Dmitry Rokosov <DDRokosov@sberdevices.ru>
To:     Jonathan Cameron <jic23@kernel.org>
CC:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "stano.jakubek@gmail.com" <stano.jakubek@gmail.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "lars@metafoo.de" <lars@metafoo.de>,
        "stephan@gerhold.net" <stephan@gerhold.net>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        kernel <kernel@sberdevices.ru>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/3] iio: add MEMSensing MSA311 3-axis accelerometer
 driver
Thread-Topic: [PATCH v3 2/3] iio: add MEMSensing MSA311 3-axis accelerometer
 driver
Thread-Index: AQHYgW2+up0uMWdZgUWEAW/5cCPkBq1RwVQAgABPMQCABGtkAIAS5cEA
Date:   Fri, 1 Jul 2022 13:06:17 +0000
Message-ID: <20220701130642.pjwucd2cvbr4uq3x@CAB-WSD-L081021.sigma.sbrf.ru>
References: <20220616104211.9257-1-ddrokosov@sberdevices.ru>
 <20220616104211.9257-3-ddrokosov@sberdevices.ru>
 <CAHp75Vc0+ckNnm2tzLMPrjeFRjwoj3zy0C4koNShFRG3kP8b6w@mail.gmail.com>
 <20220616170218.dihjli46spimozeg@CAB-WSD-L081021.sigma.sbrf.ru>
 <20220619133142.0ca36d2e@jic23-huawei>
In-Reply-To: <20220619133142.0ca36d2e@jic23-huawei>
Accept-Language: ru-RU, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <51848E1B2B9D0449A68E08E1587CF7D1@sberdevices.ru>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

On Sun, Jun 19, 2022 at 01:31:42PM +0100, Jonathan Cameron wrote:
> On Thu, 16 Jun 2022 17:02:08 +0000
> Dmitry Rokosov <DDRokosov@sberdevices.ru> wrote:
>=20
>=20
>=20
> > > > +       err =3D -EINVAL;
> > > > +       mutex_lock(&msa311->lock);
> > > > +       for (odr =3D 0; odr < ARRAY_SIZE(msa311_odr_table); ++odr)
> > > > +               if (val =3D=3D msa311_odr_table[odr].val &&
> > > > +                   val2 =3D=3D msa311_odr_table[odr].val2) {
> > > > +                       err =3D msa311_set_odr(msa311, odr); =20
> > >  =20
> > > > +                       if (err) {
> > > > +                               dev_err(dev, "cannot update freq (%=
d)\n", err);
> > > > +                               goto failed;
> > > > +                       } =20
> > >=20
> > > Why is this inside the loop and more important under lock? Also you
> > > may cover the initial error code by this message when moving it out o=
f
> > > the loop and lock.
> > >=20
> > > Ditto for other code snippets in other function(s) where applicable.
> > >  =20
> >=20
> > Yes, I can move dev_err() outside of loop. But all ODR search loop
> > should be under lock fully, because other msa311 operations should not
> > be executed when we search proper ODR place.
>=20
> I don't see why?  The search itself is for a match of the input to const =
data.
> That can occur before taking the lock to do the actual write.
>=20
> I don't see any additional race beyond the one that is always there of
> a thread updating ODR whilst another is accessing the device.  Which orde=
r
> those events happen in is not controlled by the driver, but the output
> will be consistent with one or other order of those two accesses.
>=20
> Jonathan

Agreed, will be changed in the v4.

--=20
Thank you,
Dmitry=