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

[Chris Morgan]

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.

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.