linux-kernel - Re: [PATCH v4 2/4] iio: imu: bmi270: Add scale and sampling frequency to BMI270 IMU

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241028201456.0cbfa75b@jic23-huawei>
Date: Mon, 28 Oct 2024 20:14:56 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Justin Weiss <justin@...tinweiss.com>, Alex Lanzano
 <lanzano.alex@...il.com>, Lars-Peter Clausen <lars@...afoo.de>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, "Derek J . Clark"
 <derekjohn.clark@...il.com>, Philip Müller
 <philm@...jaro.org>
Subject: Re: [PATCH v4 2/4] iio: imu: bmi270: Add scale and sampling
 frequency to BMI270 IMU

On Mon, 28 Oct 2024 11:32:55 +0200
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Sun, Oct 27, 2024 at 10:20:23AM -0700, Justin Weiss wrote:
> > Add read and write functions and create _available entries.  
> 
> ...
> 
> > +static int bmi270_set_scale(struct bmi270_data *data,
> > +			    int chan_type, int uscale)  
> 
> There is available space in the previous line, (And I would even join them
> despite being 83 characters long.)
> 
> ...
> 
> > +static int bmi270_get_scale(struct bmi270_data *bmi270_device,
> > +			    int chan_type, int *uscale)  
> 
> Ditto (for chan_type).
> 
> ...
> 
> > +static int bmi270_set_odr(struct bmi270_data *data, int chan_type,
> > +			  int odr, int uodr)  
> 
> Ditto.
> 
> ...
> 
> > +	for (i = 0; i < bmi270_odr_item.num; i++) {
> > +		if (bmi270_odr_item.tbl[i].odr != odr ||
> > +		    bmi270_odr_item.tbl[i].uodr != uodr)
> > +			continue;
> > +
> > +		return regmap_update_bits(data->regmap, reg, mask,
> > +					  bmi270_odr_item.vals[i]);
> > +	}
> > +
> > +	return -EINVAL;  
> 
> Wouldn't be better to use regular patterns, i.e. checking for errors first?

Hmm. This was my suggestion :(. For a simple case of match and do
something if true, this is a reasonably common pattern - particularly
in cases where there is a fallback option. I.e. you'd do something
after the loop only if there is no match.

Anyhow, given I suggested it I feel mean asking Justin to revert
to what he had in the first place.  I don't feel that strongly about it
though so if the two of you agree this is neater, send a follow up patch.

Tweaked the line wraps whilst applying.
> 
> 	for (i = 0; i < bmi270_odr_item.num; i++) {
> 		if (bmi270_odr_item.tbl[i].odr == odr ||
> 		    bmi270_odr_item.tbl[i].uodr == uodr)

That would be a bad idea && is fine though .

> 			break;
> 	}
> 	if (i == bmi270_odr_item.num)
> 		return -EINVAL;
> 
> 	return regmap_update_bits(data->regmap, reg, mask, bmi270_odr_item.vals[i]);
> 
> ...
> 
> > +static int bmi270_get_odr(struct bmi270_data *data, int chan_type,
> > +			  int *odr, int *uodr)  
> 
> As per above.
> 
> > +	for (i = 0; i < bmi270_odr_item.num; i++) {
> > +		if (val != bmi270_odr_item.vals[i])
> > +			continue;
> > +
> > +		*odr = bmi270_odr_item.tbl[i].odr;
> > +		*uodr = bmi270_odr_item.tbl[i].uodr;
> > +		return 0;
> > +	}
> > +
> > +	return -EINVAL;  
> 
> As per above.
>