[PATCH V8 02/10] dt-bindings: iio: imu: icm42600: Add icm42607 binding

[Jonathan Cameron]

On Thu, 21 May 2026 21:08:07 +0100
Conor Dooley <conor at kernel.org> wrote:

> On Thu, May 21, 2026 at 12:43:09PM -0500, Chris Morgan wrote:
> > On Thu, May 21, 2026 at 05:44:21PM +0100, Conor Dooley wrote:  
> > > On Wed, May 20, 2026 at 05:42:17PM +0100, Jonathan Cameron wrote:  
> > > > On Mon, 18 May 2026 15:05:17 -0500
> > > > Chris Morgan <macroalpha82 at gmail.com> wrote:
> > > >   
> > > > > From: Chris Morgan <macromorgan at hotmail.com>
> > > > > 
> > > > > Add devicetree binding for the Invensense ICM42607 and Invensense
> > > > > ICM42607P inertial measurement unit. This unit is a combined
> > > > > accelerometer, gyroscope, and thermometer available via I2C or SPI.
> > > > > 
> > > > > This device is functionally very similar to the icm42600 series with a
> > > > > very different register layout.
> > > > > 
> > > > > Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
> > > > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>  
> > > > Note that Sashiko has highlighted that the binding this being added to
> > > > has a potential problem.
> > > > 
> > > > interrupts are required but interrupt-names are not.
> > > > That would be fine but the binding doesn't say there is a default
> > > > ordering for the interrupts - so if we don't have names we have no
> > > > idea which interrupt it is.
> > > > 
> > > > This needs fixing - probably by adding a default  
> > > 
> > > Worth pointing out that this isn't an issue with this particular patch,
> > > the problem exists in mainline.  
> > 
> > The driver I lovingly borrowed this code from seems to have fallback
> > logic, basically picking the first interrupt if it couldn't find one
> > named "INT1". I was told early on not to do this that way, so in my
> > case the interrupt-names would be required (but not for the existing
> > driver because of this fallback).
> > 
Ah, so it  has a default that we've elected not to document.
I can't remember the history of that - probably similar discussion about
there being no right default when there are two (near?) identical operating interrupt
pins.

> > Should I make the requirement conditional just to my compatible
> > strings?  
> 
> Sure, sounds like a good idea to me

Agreed - that closes this for this part without spitting lots of warnings
for the older one.

J