On 9/19/23 17:32, Jonathan Cameron wrote:
+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.
Oh, yes. I see I omitted the default from the example - but this was not
what I tried to highlight ;) With a bit more thought I would've added:
default:
ret = -EINVAL;
break;
As you probably guess, what I was after is that for a simple (not deeply
nested) cases like this, I would rather use a variable for return value
and a single point of exit at the end of the function - instead of
having returns in the switch-case. That'd suit better _my_ taste.
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
