linux-kernel - Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230919153251.000024d3@Huawei.com>
Date:   Tue, 19 Sep 2023 15:32:51 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>
CC:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        <ak@...klinger.de>, <andriy.shevchenko@...ux.intel.com>,
        <ang.iglesiasg@...il.com>, <bbara93@...il.com>,
        <conor+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <jic23@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <lars@...afoo.de>, <linux-iio@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <matti.vaittinen@...rohmeurope.com>, <robh+dt@...nel.org>
Subject: Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390


> >> +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.


> 
>