Re: [PATCH 1/2] dt-bindings: iio: imu: icm42600: add icm42630

[Conor Dooley]

On Tue, Jul 21, 2026 at 07:16:47PM +0200, Jorijn van der Graaf wrote:
> 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

Is that really problematic? It's not problematic for any of the dozens
of other IIO devices that use fallbacks, is there something that would
make this one different?

> 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 check should be deleted since it prevent using fallbacks.
IMO, delete the check and add the fallback rather than retain it and
propagate the issue. Even if you think having a fallback is a bad idea
because you cannot be 101% sure that there are no programming model
differences, delete the check. Personally I think that given the
testing, patches and quote from JeanBaptiste, a fallback is suitable
here.

I think Jonathan has sorta changed his stance "recently" on the
correctness of checking whoami values versus the compatible, so what was
done in 2020 doesn't represent what's the current guidance and I am
always a proponent of removing these checks whenever I become aware of
one preventing use of fallbacks.

Cheers,
Conor.

> 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

Attachment: signature.asc
Description: PGP signature