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

[Jonathan Cameron]

On 2026-09-02 08:30:07+03:00, Andy Shevchenko wrote:
> 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...

Chris only just got this one merged so let us wait to here from him.
> 
> > * 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.
It is fine to have it split given it's an existing driver and supports
more complex hardware.

Jonathan