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

From: Andy Shevchenko

Date: Mon Aug 10 2026 - 15:45:46 EST


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.

...

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

> + 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);
> }

--
With Best Regards,
Andy Shevchenko