Re: [PATCH 1/2] dt-bindings: iio: imu: icm42600: add icm42630
From: Jorijn van der Graaf
Date: Tue Jul 21 2026 - 13:24:29 EST
On Tue, Jul 21, 2026 at 05:01:26PM +0100, Conor Dooley wrote:
> On Mon, Jul 20, 2026 at 07:34:10PM +0200, Jorijn van der Graaf wrote:
> > The TDK InvenSense ICM-42630 is a 6-axis IMU of the ICM-42600 family,
> > found e.g. in the Fairphone 6. Document its compatible.
> >
> > A fallback compatible to a sibling is not usable: the part reports its
> > own WHOAMI register value, which software validates against the
> > compatible.
>
> Why does software do this? If the whoami is the only difference, the
> software should stop checking it.
Whether the whoami is the only difference is exactly what I cannot
establish: the part has no public datasheet. What I can establish is
driver-visible: the unmodified driver has been tested to drive it
correctly, and Jean-Baptiste confirmed the chip is "similar" to the
ICM-42631 and "can be supported by inv_icm42600 driver without any
modification". That is short of knowing the parts are identical (the
family has precedent for real differences behind the same register
layout: ICM-42686, different full-scale ranges), so I did not want
to claim full compatibility with a sibling.
As for the check: it is not mine - inv_icm42600 has returned -ENODEV
on a whoami mismatch since its 2020 introduction (and per-part config
does differ within the family, see above). Since every released
kernel enforces it, a fallback would not probe on any kernel already
out there regardless of what we change now; and even if the check
were relaxed, a fallback-matched part would bind with icm42631 as
its ABI-visible name - so the dedicated compatible is needed either
way. Whether the check should become a warning is
Jean-Baptiste's call, as a behavior change for all parts the driver
supports; I did not want to gate a trivial ID addition on it, but am
happy to send that as a follow-up if wanted.
The commit message led with the driver check where the real reason
is the identity uncertainty above; I will reword that in a v2 if one
is needed.
Thanks,
Jorijn