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

On Wed, 22 Jul 2026 17:59:42 +0100
Conor Dooley <[email protected]> wrote:

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

Yup.  I was convinced (probably by you ;) that whoami hard checks should
go.  There are quite a lot left from before that time and this probably
one of those.

If it does turn out there is a difference then that is what the specific
compatible allows us to handle

So dt-binding wise, please go with the fallback route for this new part.
For old kernels that just means backporting relaxing that constraint and given
a backport is required either way it doesn't matter.

At least a first glance all that is needed is to drop the error return?

Thanks,

Jonathan

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