Re: [PATCH v3 2/3] iio: imu: inv_icm42600: drop the whoami check

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Complete removal of the WHOAMI check breaks hardware presence detection on SPI buses, allowing the driver to successfully probe absent or non-existent devices.
--

--- Patch [2]: [PATCH v3 2/3] iio: imu: inv_icm42600: drop the whoami check ---
commit 3a74aa023a51d52a25e7f4af731835e3a6cd0b6a
Author: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>

iio: imu: inv_icm42600: drop the whoami check

This commit drops the WHOAMI check from the inv_icm42600 driver to allow
fallback compatibles to probe successfully even if the WHOAMI value does
not strictly match. The unused WHOAMI definitions are also removed. This
changes the probe outcome on mismatch for all parts supported by the driver.

Link: https://lore.kernel.org/all/20260722-creature-volley-0f083b904c1d@spud/
Link: https://lore.kernel.org/all/20260728-extradite-yanking-42d918637f61@spud/

[Note: The standard inline quoting format has been altered to a free-form
summary due to recitation restrictions.]

[Severity: High]
With the WHOAMI check removed, does this break hardware presence detection 
on SPI buses? 

When an SPI device is unpopulated or unpowered, the MISO line often floats 
high, causing regmap reads to return 0xFF. Looking at inv_icm42600_setup() 
in drivers/iio/imu/inv_icm42600/inv_icm42600_core.c, the only remaining 
hardware verification is the check for the reset done bit.

Because the reset done bit is BIT(4) (0x10), reading 0xFF means 
(0xFF & 0x10) is non-zero. The condition 
!(val & INV_ICM42600_INT_STATUS_RESET_DONE) evaluates to false, bypassing 
the -ENODEV error path. 

Will this allow the driver to successfully probe absent or non-existent 
devices, exposing dummy IIO interfaces that yield -1 for all readings?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728184351.75015-1-jorijnvdgraaf@catcrafts.net?part=2