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:   Sun, 9 Oct 2022 17:36:06 +0100
From:   Jonathan Cameron <jic23@kernel.org>
To:     Crt Mori <cmo@melexis.com>
Cc:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        andy.shevchenko@gmail.com, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/3] iio: temperature: mlx90632 Add runtime
 powermanagement modes
Message-ID: <20221009173606.5b8e5661@jic23-huawei>
In-Reply-To: <CAKv63ut4DJCLQP8ckOsC+K4DGy+v2Y5ghfoTjQoyg4CvditW6Q@mail.gmail.com>
References: <cover.1663834141.git.cmo@melexis.com>
        <be405068f081f2d518843897b13cd0289c280b5d.1663834141.git.cmo@melexis.com>
        <a11b83a9-9e25-bbb5-2556-f5244119e3dc@wanadoo.fr>
        <CAKv63ut4DJCLQP8ckOsC+K4DGy+v2Y5ghfoTjQoyg4CvditW6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 3 Oct 2022 10:20:18 +0200
Crt Mori <cmo@melexis.com> wrote:

> On Sun, 2 Oct 2022 at 18:09, Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> wrote:
> >
> > Le 22/09/2022 =C3=A0 10:13, cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org=
 a =C3=A9crit : =20
> > > From: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
> > > measurements in lower power mode (SLEEP_STEP), with the lowest refresh
> > > rate (2 seconds). =20
> >
> > Hi,
> >
> > should there be a v7, a few nitpick below.
> > =20
> It was already applied, but I can spin a new patch for the suggested
> changes (the s32 is mostly there because before this patch it was
> returning value for further bit manipulation).

Follow on patch welcome!

Thanks,

Jonathan

>=20
> > >
> > > +     ret =3D regmap_read_poll_timeout(data->regmap, MLX90632_REG_STA=
TUS,
> > > +                                    reg_status,
> > > +                                    (reg_status & MLX90632_STAT_BUSY=
) =3D=3D 0,
> > > +                                    10000, 100 * 10000);
> > > +     if (ret < 0) {
> > > +             dev_err(&data->client->dev, "data not ready");
> > > +             return -ETIMEDOUT; =20
> >
> > Why not "return ret;"?
> > =20
> If you came to this point there were already several i2c reads, so I
> think it is more important to convert those to timeout.
>=20
> > >       mutex_lock(&data->lock);
> > > -     measurement =3D mlx90632_perform_measurement(data);
> > > -     if (measurement < 0) {
> > > -             ret =3D measurement;
> > > +     ret =3D mlx90632_set_meas_type(data, MLX90632_MTYP_MEDICAL);
> > > +     if (ret < 0)
> > > +             goto read_unlock;
> > > +
> > > +     switch (data->powerstatus) {
> > > +     case MLX90632_PWR_STATUS_CONTINUOUS:
> > > +             measurement =3D mlx90632_perform_measurement(data); =20
> >
> >    ret =3D mlx90632_perform_measurement(data);
> > and
> >    measurement =3D ret;
> > on success would be less verbose (no need for {}, and save 1 LoC) and
> > more in line with mlx90632_calculate_dataset_ready_time() above.
> > =20
> I wanted to change as few lines as possible to avoid clogging the
> patch with unrelated changes. Also in most cases, we will be
> in-success here, so limiting the number of variable copies in the
> success path should be the priority.