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

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Wed, 15 Jul 2026 15:34:53 -0500
Chris Morgan <macromorgan@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@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


> 
> 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.
>