Re: [PATCH v6 1/3] iio: temperature: mlx90632 Add runtime powermanagement modes

From: Jonathan Cameron
Date: Sun Oct 09 2022 - 12:35:53 EST


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

> On Sun, 2 Oct 2022 at 18:09, Christophe JAILLET
> <christophe.jaillet@xxxxxxxxxx> wrote:
> >
> > Le 22/09/2022 à 10:13, cmo-fc6wVz46lShBDgjK7y7TUQ@xxxxxxxxxxxxxxxx a écrit :
> > > From: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@xxxxxxxxxxxxxxxx>
> > > measurements in lower power mode (SLEEP_STEP), with the lowest refresh
> > > rate (2 seconds).
> >
> > Hi,
> >
> > should there be a v7, a few nitpick below.
> >
> 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

>
> > >
> > > + ret = regmap_read_poll_timeout(data->regmap, MLX90632_REG_STATUS,
> > > + reg_status,
> > > + (reg_status & MLX90632_STAT_BUSY) == 0,
> > > + 10000, 100 * 10000);
> > > + if (ret < 0) {
> > > + dev_err(&data->client->dev, "data not ready");
> > > + return -ETIMEDOUT;
> >
> > Why not "return ret;"?
> >
> If you came to this point there were already several i2c reads, so I
> think it is more important to convert those to timeout.
>
> > > mutex_lock(&data->lock);
> > > - measurement = mlx90632_perform_measurement(data);
> > > - if (measurement < 0) {
> > > - ret = measurement;
> > > + ret = mlx90632_set_meas_type(data, MLX90632_MTYP_MEDICAL);
> > > + if (ret < 0)
> > > + goto read_unlock;
> > > +
> > > + switch (data->powerstatus) {
> > > + case MLX90632_PWR_STATUS_CONTINUOUS:
> > > + measurement = mlx90632_perform_measurement(data);
> >
> > ret = mlx90632_perform_measurement(data);
> > and
> > measurement = 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.
> >
> 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.