Hi Chris,

On Tue, 2026-09-15 at 12:20 -0500, Chris Morgan wrote:
> [Some people who received this message don't often get email from
> macromorgan@hotmail.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Mon, Sep 07, 2026 at 02:54:51AM +0100, Jonathan Cameron wrote:
> > > Update the function formatting for the
> > > inv_icm42607_odr_to_period_us
> > > function. This enhances the readability of the function and drop
> > > the
> > > unnecessary comments in the array elements.
> > The description doesn't mention the change I don't think is
> > beneficial.  Which makes it even easier to drop that change.
> > 
> > Thanks,
> > 
> > Jonathan
> > 
> > > 
> > > Signed-off-by: Kanak Shilledar <kanak.shilledar@axis.com>
> > > 
> > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > index 4d51b0da1aa1..fa85cf738cc0 100644
> > > --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > @@ -62,16 +62,16 @@ enum inv_icm42607_accel_fs {
> > >  /* ODR values  - Note Gyro does not support ODR less than 12.5Hz
> > > */
> > >  enum inv_icm42607_odr {
> > >     INV_ICM42607_ODR_1600HZ = 5,
> > > -   INV_ICM42607_ODR_800HZ = 6,
> > > -   INV_ICM42607_ODR_400HZ = 7,
> > > -   INV_ICM42607_ODR_200HZ = 8,
> > > -   INV_ICM42607_ODR_100HZ = 9,
> > > -   INV_ICM42607_ODR_50HZ = 10,
> > > -   INV_ICM42607_ODR_25HZ = 11,
> > > -   INV_ICM42607_ODR_12_5HZ = 12,
> > > -   INV_ICM42607_ODR_6_25HZ_LP = 13,
> > > -   INV_ICM42607_ODR_3_125HZ_LP = 14,
> > > -   INV_ICM42607_ODR_1_5625HZ_LP = 15,
> > 
> > Why?  We often put all the values when they are mapping to hardware
> > register values simply because it makes them easier to compare to
> > a datasheet.
> > 
> > --
> > Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> 
> Just to provide context, the only reason I chose the byte order I did
> is because that's how the existing icm42600 driver did it. I'm not
> opposed to changing it especially if it simplifies things or makes
> sense, but if we're going to do it now's the time (as the only
> current
> consumer of this driver is the rk3568 based anbernic-rg-ds and the
> rk3576 based anbernic-vita-pro).

I have dropped this change in my upcoming v4 of this patchset. It can
be fixed, but I think it should done be in a separate patch not part of
this series.

Thanks and Regards,
Kanak Shilledar