[PATCH V3 0/9] Add Invensense ICM42607

[Chris Morgan]

On Tue, Mar 31, 2026 at 02:25:54PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 02:58:44PM -0500, Chris Morgan wrote:
> 
> > Add support for the ICM42607 IMU. This sensor shares the same
> > functionality but a different register layout with the existing
> > ICM42600.
> > 
> > This driver should work with the ICM42607 and ICM42607P over both I2C
> > and SPI, however only the ICM42607P over I2C could be tested.
> > 
> > Changes Since V1:
> >  - Instead of creating a new driver, merged with the existing inv_icm42600
> >    driver. This necessitated adding some code to the existing driver to
> >    permit using a different register layout for the same functionality.
> >  - Split changes up a bit more to decrease the size of the individual
> >    patches. Note that patch 0004 is still pretty hefty; if I need to split
> >    further I may need to create some temporary stub functions.
> >  - Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
> >    per Jonathan's recommendations.
> > 
> > Changes Since V2:
> >  - Went back to using a new driver on advice from Invensense engineer.
> 
> Okay, but this should be elaborated in the cover letter. If I followed
> previous discussion correctly, the problem is the indirect subset of
> registers that are absent on the 42600 series. But would be nice to have
> the summary of what vendor engineers told you.

Sorry, I should have elaborated you are correct. The information the
engineer said was that the 42607 chips use an indirect register access
method using IREG specific registers. As a result it did not make sense
to have the 42600 and 42607 drivers combined.

That said, the driver in question here does not use any of those specific
IREG registers (but it's possible other future 42607 devices could).
Specifically, I only have the 42607P (via I2C) to test with, which does
not have those registers only ones that can be directly accessed.

I hope this clears that up, I'll try to include that information in the
next patch. I also want to make sure with this revision that I'm "in the
ballpark" for breaking this down into digestable chunks.

Thank you,
Chris 

> 
> >  - Further split changes up into smaller chunks of functionality. Note
> >    still that the largest patch is approximately 900 lines, and that while
> >    the driver compiles cleanly at each commit it is not able to drive the
> >    hardware until the commit that adds the Interrupt (as it also adds the
> >    Makefile).
> >  - Change the error to a warning when the devicetree binding does not match
> >    the hardware ID.
> >  - Dropped the ack on the devicetree bindings, as I am creating a new file
> >    (for a new driver) instead of modifying the existing one.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>