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

[Andy Shevchenko]

On Sun, Aug 23, 2026 at 02:33:19AM +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. Otherwise the probe outcome
> on mismatch changes for all parts the driver supports. The check sits
> before the mismatch comparison; it does not depend on hw->whoami, since
> no supported part uses either value (the WHOAMI values the driver
> defines span 0x40-0x5C). inv_icm45600 carries the same guard nested in
> its mismatch branch.
> 
> 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.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>

...

> +	/*
> +	 * SPI interface has no ack mechanism.
> +	 * 0xFF or 0x00 whoami means no response from the device.
> +	 */
> +	if (val == U8_MAX || val == 0)

Not sure if U8_MAX is better or worse than simple 0xff, but either work for me.

> +		return dev_err_probe(dev, -ENODEV,
> +				     "invalid whoami %#04x expected %#04x (%s)\n",
> +				     val, hw->whoami, hw->name);

-- 
With Best Regards,
Andy Shevchenko