Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390
From: Jonathan Cameron
Date: Tue Sep 19 2023 - 10:32:59 EST
> >> +static int bm1390_read_raw(struct iio_dev *idev,
> >> + struct iio_chan_spec const *chan,
> >> + int *val, int *val2, long mask)
> >> +{
> >> + struct bm1390_data *data = iio_priv(idev);
> >> + int ret;
> >> +
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_SCALE:
> >> + if (chan->type == IIO_TEMP) {
> >> + *val = 31;
> >> + *val2 = 250000;
> >> +
> >> + return IIO_VAL_INT_PLUS_MICRO;
> >> + } else if (chan->type == IIO_PRESSURE) {
> >> + *val = 0;
> >> + /*
> >> + * pressure in hPa is register value divided by 2048.
> >> + * This means kPa is 1/20480 times the register value,
> >> + * which equals to 48828.125 * 10 ^ -9
> >> + * This is 48828.125 nano kPa.
> >> + *
> >> + * When we scale this using IIO_VAL_INT_PLUS_NANO we
> >> + * get 48828 - which means we lose some accuracy. Well,
> >> + * let's try to live with that.
> >> + */
> >> + *val2 = 48828;
> >> +
> >> + return IIO_VAL_INT_PLUS_NANO;
> >> + }
> >> +
> >> + return -EINVAL;
> >> + case IIO_CHAN_INFO_RAW:
> >> + ret = iio_device_claim_direct_mode(idev);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = bm1390_read_data(data, chan, val, val2);
> >> + iio_device_release_direct_mode(idev);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + return IIO_VAL_INT;
> >> + default:
> >> + return -EINVAL;
> >
> > Certainly useless, but should we break and return -EINVAL after the
> > switch, so that it is more explicit that bm1390_read_raw() always
> > returns a value?
>
> I think there is also opposite opinions on this. For my eyes the return
> at the end of the function would also be clearer - but I think I have
> been asked to drop the useless return when I've been working with other
> sensors in IIO domain :) My personal preference would definitely be:
>
> int ret;
>
> switch (foo)
> {
> case BAR:
> ret = func1();
> if (ret)
> break;
>
> ret = func2();
> if (ret)
> break;
>
> ...
> break;
>
> case BAZ:
> ret = -EINVAL;
> break;
> }
>
> return ret;
>
> - but I've learned to think this is not the IIO preference.
Some static analyzers get confused (probably when there is a little
bit more going on after the function) by that and moan that some
cases are not considered in the switch. I got annoyed enough with the
noise they were generating to advocate always having explicit defaults.
>
>