[PATCH V3 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607

[Andy Shevchenko]

On Tue, Apr 28, 2026 at 09:01:12AM -0500, Chris Morgan wrote:
> On Fri, Apr 10, 2026 at 05:59:05PM -0500, David Lechner wrote:
> > On 3/30/26 2:58 PM, Chris Morgan wrote:

...

> > > +/* IIO format int + nano */
> > 
> > Usually we make these 2-D arrays for readability and then cast to int * if needed.
> > 
> > > +static const int inv_icm42607_accel_scale[] = {
> > > +	/* +/- 16G => 0.004788403 m/s-2 */
> > > +	[2 * INV_ICM42607_ACCEL_FS_16G] = 0,
> > > +	[2 * INV_ICM42607_ACCEL_FS_16G + 1] = 4788403,
> > > +	/* +/- 8G => 0.002394202 m/s-2 */
> > > +	[2 * INV_ICM42607_ACCEL_FS_8G] = 0,
> > > +	[2 * INV_ICM42607_ACCEL_FS_8G + 1] = 2394202,
> > > +	/* +/- 4G => 0.001197101 m/s-2 */
> > > +	[2 * INV_ICM42607_ACCEL_FS_4G] = 0,
> > > +	[2 * INV_ICM42607_ACCEL_FS_4G + 1] = 1197101,
> > > +	/* +/- 2G => 0.000598550 m/s-2 */
> > > +	[2 * INV_ICM42607_ACCEL_FS_2G] = 0,
> > > +	[2 * INV_ICM42607_ACCEL_FS_2G + 1] = 598550,
> > > +};
> 
> I've gone through and implemented all of the changes everyone suggested, though
> this is one of the few on which I had a question. Obviously this driver was
> cobbled together from 2 different sources and checked to the best of my ability
> and tested/validated against the data sheet, but there are a few bits I'm not
> fully clear on such as this.

> What's the correct way to represent this data? Since it looks like one of the
> values is always 0, should I just assume it's always 0 and only represent the
> values that change in this scale?

Isn't the comment is clear about that? The first one is integer, the second one
is fraction. So, no, your assumption is wrong strictly speaking.

-- 
With Best Regards,
Andy Shevchenko