linux-kernel - Re: [PATCH v6 2/2] iio: adc: ad7173: add AD7173 driver

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: <20231123190936.51f61b8d@jic23-huawei>
Date:   Thu, 23 Nov 2023 19:09:36 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andy@...nel.org>
Cc:     mitrutzceclan <mitrutzceclan@...il.com>, linus.walleij@...aro.org,
        brgl@...ev.pl, linux-gpio@...r.kernel.org,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Michael Walle <michael@...le.cc>,
        Arnd Bergmann <arnd@...db.de>,
        ChiaEn Wu <chiaen_wu@...htek.com>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        Leonard Göhrs <l.goehrs@...gutronix.de>,
        Mike Looijmans <mike.looijmans@...ic.nl>,
        Haibo Chen <haibo.chen@....com>,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        Ceclan Dumitru <dumitru.ceclan@...log.com>,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] iio: adc: ad7173: add AD7173 driver


> 
> ...
> 
> > +	return vref / (MICRO/MILLI);  
> 
> Wouldn't MILLI in the denominator just suffice?

Just a quick comment here. Given this is converting from micro to milli units
I'd consider the maths here be acting as documentation of that which would be lost if
/MILLI only used.  Need spaces around the / though


> 
> ...
> 
> > +	case IIO_CHAN_INFO_SAMP_FREQ:
> > +		reg = st->channels[chan->address].cfg.odr;
> > +
> > +		*val = st->info->sinc5_data_rates[reg] / MILLI;
> > +		*val2 = (st->info->sinc5_data_rates[reg] % MILLI) * (MICRO/MILLI);
> > +
> > +		return IIO_VAL_INT_PLUS_MICRO;
> > +	}  
> 
> > +		ret = fwnode_property_read_string(child, "adi,reference-select", &ref_label);
> > +		if (!ret) {
> > +			for (i = 0; i < ARRAY_SIZE(ad7173_ref_sel_str); i++)
> > +				if (strcmp(ref_label, ad7173_ref_sel_str[i]) == 0) {
> > +					ref_sel = i;
> > +					break;
> > +				}  
> 
> > +			if (i == ARRAY_SIZE(ad7173_ref_sel_str))
> > +				return dev_err_probe(dev, -EINVAL, "Invalid channel reference name %s", ref_label);  
> 
> Too long line.
> 
> > +		} else if (ret != -EINVAL) {
> > +			return dev_err_probe(dev, ret, "Invalid channel reference value");
> > +		}  
> 
> 
> Use standard pattern and it will be easier to see that 'else' is redundant.
> 
> 		if (ret == -EINVAL) // However I don't like this handling of
> 				    // properties, but up to you and maintainer

Personally I'd check for existence of property first and only try reading if it
exists.  Avoid dance with resetting ret to 0.

> 			ret = 0;
> 		if (ret)
> 			return dev_err_probe(...);
> 
> 
> BUT. Isn't it a home grown variant of fwnode_property_match_property_string()?

true enough...  I'd still add an existence check first given this one is optional.

Jonathan