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

[Krzysztof Kozlowski]

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