Re: [PATCH v4 2/3] iio: imu: inv_icm42600: log whoami mismatch instead of failing probe

[Jonathan Cameron]

On Mon, 10 Aug 2026 22:45:28 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Mon, Aug 10, 2026 at 09:11:56PM +0200, Jorijn van der Graaf wrote:
> > A WHOAMI value differing from the one the compatible implies aborts
> > probe with -ENODEV, which prevents a register-compatible part described
> > with a fallback compatible from probing at all.
> > 
> > The devicetree compatible is authoritative for which part is fitted:
> > log the mismatch at info level and continue. The message keeps a
> > breadcrumb for anyone seeing an unexpected part change on their device
> > versus the devicetree; tmp117 takes the same trade at the same level
> > for its fallback matches.
> > 
> > A whoami of 0x00 or 0xff still fails probe: SPI has no transfer-level
> > ack, so those values mean nothing answered; this is the same
> > no-response guard inv_icm45600 carries. Otherwise the probe outcome on
> > mismatch changes for all parts the driver supports.
> > 
> > Tested via a backport to a Fairphone 6 running a 7.1-based kernel: its
> > ICM-42630 (WHOAMI 0x0C), described with an icm42631 fallback compatible
> > and matched as icm42631, probes with the one informational line, and
> > accelerometer, gyroscope and temperature reads work.
> > 
> > Suggested-by: Conor Dooley <conor@xxxxxxxxxx>
> > Suggested-by: Jonathan Cameron <jic23@xxxxxxxxxx>  
> 
> > Link: https://lore.kernel.org/all/20260722-creature-volley-0f083b904c1d@spud/
> > Link: https://lore.kernel.org/all/20260728222015.6a62b287@jic23-huawei/
> > Link: https://lore.kernel.org/all/20260801032310.18f5f16d@jic23-huawei/
> > Link: https://lore.kernel.org/all/20260804-scarily-hacker-651df3eafea9@spud/  
> 
> What are those links for? I haven't seen references in the above text.
Yup. That needs tidying up or the links dropping.
> 
> ...
> 
> >  	if (val != hw->whoami) {
> > -		dev_err(dev, "invalid whoami %#02x expected %#02x (%s)\n",
> > -			val, hw->whoami, hw->name);
> > -		return -ENODEV;
> > +		/*
> > +		 * SPI interface has no ack mechanism.
> > +		 * 0xFF or 0x00 whoami means no response from the device.
> > +		 */
> > +		if (val == U8_MAX || val == 0)  
> 
> This is strange to be here. If hw->whoami happens to be 0x00 or 0xff (let's
> assume some hypothetical future case), this check will become invalid for them.
> 
> If it's guaranteed to be not the case for any HW (including the future variants)
> this check should be outside, no?

Hmm. This one has both worked in favour of finding connection trouble
and bitten us in the past. I vaguely recall a device that indeed
had a WHOAMI of 0 (though it might have been a hardware bug) and
tripped on such a check.

Personally I'm not that fixed either way on this. If the device isn't
there we should know the moment we try to get any data anyway.

> 
> > +			return dev_err_probe(dev, -ENODEV,
> > +					     "invalid whoami %#04x expected %#04x (%s)\n",
> > +					     val, hw->whoami, hw->name);
> > +
> > +		dev_info(dev,
> > +			 "device id %#04x is not the %#04x associated with the FW-specified device (%s), probably using a valid fallback compatible\n",
> > +			 val, hw->whoami, hw->name);
> >  	}  
>