Re: [PATCH v3 0/8] Add support for InvenSense ICM-42370-P accelerometer

[Andy Shevchenko]

On Tue, Sep 01, 2026 at 04:35:53PM +0200, Kanak Shilledar wrote:
> InvenSense ICM42370P is a high performance MEMS MotionTracking 3-axis
> accelerometer. It supports I2C, I3C and SPI protocols. It has a 2.25kB
> FIFO and two programmable interrupts with support for ultra-low-power
> wake-on-motion support. It has a built-in temperature sensor. This
> patch series adds basic support for the sensor with functionality of
> performing raw reads and writes via the I2C interface.
> 
> This device contains 4 register banks for configuring the device called
> MREG0, MREG1, MREG2 and MREG3. Unlike other devices from the same
> vendor, this contains a very different way of accessing the register
> banks apart from the default user bank 0 (MREG0). The register bank access
> procedure is mentioned in the datasheet Section 13. This is very
> similar to the existing InvenSense, ICM-42607-P driver. Thus, it
> improves the existing driver support and adds the ICM-42370-P device to
> it.
> 
> While adding the support for new device, I tried to perform some fixes
> to the existing driver which were pointed out in the v2 of this patch
> series.
> 
> The buffer support will be added in another patch series.
> 
> Note: The datasheet for InvenSense, ICM-42607-P could not be found on the 
> official https://www.invensense.tdk.com/en-us website. Thus, I am 
> using the datasheet available at https://www.lcsc.com.
> 
> Question to the reviewers:
> * There is no entry for drivers/iio/imu/inv_icm42607 in the MAINTAINERS
>   file, should a new MAINTAINERS entry be created for the inv_icm42607
>   driver with the original author as the maintainer? Currently
>   `get_maintainers.pl` is able to add the original author to the
>   recipients list, but `b4 prep --auto-to-cc` is not able to add.

Only if you have (or will have for sure) the confirmation from them.
Otherwise it's you most likely...

> * As per the comments in v2 from @Jonathan regarding splitting the
>   driver into multiple files, should we still have the driver as
>   multiple files or should it be merged into a single file?

It depends on the factors like busses to support.

> * As per the comments in v2 regarding the formatting of
>   headerfile with the positioning of macros, enums and function
>   prototypes, as well as indentation of in the register values, also the
>   all the enum values are numbered which seems unnecessary, should these
>   be implemented here as well?

-- 
With Best Regards,
Andy Shevchenko