[PATCH v16 02/10] dt-bindings: iio: imu: icm42600: Remove interrupts from required

[Jonathan Cameron]

On Mon, 20 Jul 2026 12:16:46 -0500
Chris Morgan <macromorgan at hotmail.com> wrote:

> On Sun, Jul 19, 2026 at 12:19:00AM +0100, Jonathan Cameron wrote:
> > On Wed, 15 Jul 2026 15:34:53 -0500
> > Chris Morgan <macromorgan at hotmail.com> wrote:
> >   
> > > On Wed, Jul 15, 2026 at 08:29:44PM +0200, Krzysztof Kozlowski wrote:  
> > > > On 15/07/2026 16:52, Chris Morgan wrote:    
> > > > > On Wed, Jul 15, 2026 at 07:52:52AM +0200, Krzysztof Kozlowski wrote:    
> > > > >> On Mon, Jul 13, 2026 at 04:58:32PM -0500, Chris Morgan wrote:    
> > > > >>> From: Chris Morgan <macromorgan at hotmail.com>
> > > > >>>
> > > > >>> Interrupts are almost never required for IIO devices per upstream
> > > > >>> maintainers. Remove interrupt as a required parameter for the
> > > > >>> devicetree binding.    
> > > > >>
> > > > >> That's an odd statement. We do require interrupts when the hardware
> > > > >> requires them. We do not require interrupts, not because we have such
> > > > >> policy, but because hardware does not require them.
> > > > >>
> > > > >> Plus, we do require interrupts when software implementing ABI requires
> > > > >> them.
> > > > >>
> > > > >> Above commit msg is simply inaccurate and misleading. Instead, please
> > > > >> use actual hardware arguments or how ABI is actually used. You must not
> > > > >> introduce changes to ABI just "because" while for example making that
> > > > >> ABI conflicting with existing implementation.    
> > > > > 
> > > > > I will defer then to Jonathan on the specifics of this, but from what I
> > > > > can tell:
> > > > > 
> > > > > 1) The icm42600 devices don't need an interrupt for operation other
> > > > > than for buffered mode or wake on movement. One-shot should work
> > > > > without it.
> > > > > 
> > > > > 2) The existing icm42600 driver does require an interrupt however, and
> > > > > refuses to bind without it. The driver could in theory be modified to
> > > > > not require an interrupt though and skip using buffered mode and WoM
> > > > > when no interrupt is present; however I don't plan on making these
> > > > > changes at this time.
> > > > > 
> > > > > 3) The new icm42607 driver I'm trying to upstream does not use an
> > > > > interrupt, because on my current test device it's not even wired up.
> > > > > On future devices that I have with this chip I may pursue using an
> > > > > interrupt, but it will never be required.
> > > > > 
> > > > > So should I go back to requiring the interrupt for all devices except
> > > > > for the new driver then?    
> > > > 
> > > > You mentioned two drivers, I don't know how does this relate to them. In
> > > > any case your commit msg is inaccurate and not a correct reason to make
> > > > a change.
> > > > 
> > > > Best regards,
> > > > Krzysztof    
> > > 
> > > I'm confused, so again should I just go back to the way things were?
> > > 
> > > This binding is to describe the hardware for devices using two distinct
> > > drivers, the inv_icm42600 and the new (that I am trying to finish)
> > > inv_icm42607 driver. The hardware requires an interrupt if you want to
> > > use features such as wake-on-motion or hardware buffers. The existing
> > > driver inv_icm42600 always assumes an interrupt is present and thus
> > > fails to probe if one is not (making it a "requirement"). The new
> > > driver I'm writing does not use the interrupt, because I don't have
> > > one.  
> > 
> > For dt-bindings, look at it from the question of 'is the hardware useful
> > without this interrupt?'  Answer is yes for vast majority of sensors as we
> > can either reduce features but still have some useful ones, or use another
> > approach such as polling a ready flag to replace doing it with an interrupt.
> > It is very common for boards to come out where none of the interrupts are
> > wired.
> > 
> > The only time I've seen that they are actually required for IIO stuff is
> > for very simple devices where the interrupt is the data - e.g. stand alone
> > threshold detectors with no ADC like functionality.
> > 
> > All this is independent of the driver working without the interrupt.
> > It is fully allowed to refuse to probe because it relies on something
> > optional in the DT-binding.
> > 
> > Jonathan
> >   
> 
> At this point (if it's okay with you) I'll just make sure the interrupt
> is not required for the new chips supported, as the distinction between
> whether the hardware needs it versus the driver is a bit lost on me;
> however for now the driver will fail on all the older chips if the
> interrupt isn't present.

Ok. We can leave relaxing the requirement for the older devices for now.

Jonathan

> 
> Thank you,
> Chris
> 
> >   
> > > 
> > > I'm thinking I'll just go back to the way it was previously, unless
> > > Jonathan disagrees. The interrupt will be listed as required for all
> > > devices using the inv_icm42600 driver, and not required for devices
> > > using the inv_icm42607 driver.
> > > 
> > > Thank you.
> > >   
> >   
>