Re: [PATCH v6 1/6] dt-bindings: iio: imu: icm42600: Add ICM-42670-P

[Jonathan Cameron]

On Fri, 16 Oct 2026 07:18:49 +0000
Kanak Shilledar <Kanak.Shilledar@xxxxxxxx> wrote:

> Hi,
> > > >   
> [...]
> > > > That's misleading or confusing. Either the device works or does
> > > > not
> > > > without interrupt hooked up. Consult hardware datasheet if in
> > > > doubts.
> > > > 
> > > > Driver support is different thing here and you cannot make it
> > > > required
> > > > later, because that would be unjustified ABI break.  
> > > 
> > > I looked into icm42605 data sheet and saw no clear statement about
> > > the interrupts
> > > being required. The timing diagrams only show protocol specific
> > > lines and it
> > > looks like the interrupt sources can even be disabled (not routed
> > > out to any
> > > interrupt pin). Maybe I'm missing something and the interrupts are
> > > required for
> > > some sort of reset function or so? Otherwise, I don't see how the
> > > interrupts are
> > > required.
> > > 
> > > Kanak, do you have access to any of those other chips to test
> > > whether they work
> > > without interrupts? If possible, can you also check the data sheets
> > > for the other
> > > parts besides icm42370p and icm42605?
> > > 
> > > Maybe
> > >  - if:
> > >      properties:
> > >        compatible:
> > >          contains:
> > >            enum:
> > >              - invensense,icm42600
> > >              - invensense,icm42602
> > >              - invensense,icm42605
> > >              - invensense,icm42622
> > >              - invensense,icm42631
> > >              - invensense,icm42686
> > >              - invensense,icm42688
> > >    then:
> > >      required:
> > >        - interrupts
> > > was a documentation mistake?
> > > 
> > > With best regards,
> > > Marcelo
> > > 
> > >   
> > 
> > Hello,
> > 
> > I can confirm that all icm426xx chips can work without interrupt by
> > just polling
> > the data.
> > 
> > Interrupts were declared as required at the time only because the
> > driver doesn't
> > work without interrupt (probe will fails).
> > 
> > Hardware speaking only, this is indeed a documentation mistake.  
> 
> Thank you for confirming the requirement for interrupts. I will cleanup
> the documentation in a separate commit not part of this series and the
> driver should be updated to not fail if the interrupt property is
> absent in the devicetree.

Two different things.  
1) Update the DT to reflect hardware requirements and it is vanishingly
   rare for an IIO part to require interrupts.  The only case I can
   immediately think is comparators which don't have any other interface.
2) Possibly update the driver to support polling. Not a requirement as
   we can choose not to support particular DT in a driver - that has
   nothing to do with the binding which is documenting the hardware.

I'd put 1 as a precursor patch in your series simply because otherwise
we will get some fuzz due to stuff moving in the binding + maybe
forget to tidy this up!

Jonathan

> 
> Best Regards,
> Kanak Shilledar
>