[PATCH v4 0/3] iio: imu: inv_icm42600: add support for icm42630

[PATCH v4 0/3] iio: imu: inv_icm42600: add support for icm42630

[Jorijn van der Graaf]

The TDK InvenSense ICM-42630 is a 6-axis IMU of the ICM-42600 family,
used in the Fairphone 6. It needs no part-specific driver code: TDK
confirmed it can be supported by inv_icm42600 without modification.

The binding documents the new compatible with an invensense,icm42631
fallback, and a WHOAMI mismatch no longer fails probe, so that a
fallback-matched part can probe; one informational line records the
mismatch, and a whoami of 0x00/0xff (no response) still fails. No
driver id entries are added: the part binds through the fallback.

Tested on the Fairphone 6 with the fallback pair in the devicetree,
via a backport to its 7.1-based kernel: matched as icm42631 through
the fallback, the part probes with the one informational line, and
accelerometer, gyroscope and temperature reads work.

Changes in v4:
- patch 2 (retitled): keep the WHOAMI read and log the mismatch at
  info level, following the wording Jonathan proposed, instead of
  deleting the check and the whoami definitions (Jonathan, Conor)
- patch 2: add a no-response guard, whoami 0x00/0xff still fails
  probe, matching inv_icm45600; both prints use %#04x so the two ids
  render at equal width
- patch 3: rebased over the icm42607 and mount-matrix binding changes;
  the conditional interrupts requirement added with the icm42607
  covers the ICM-42630 through its icm42631 fallback. Added Conor's
  Acked-by
- rebased onto current iio/togreg

v3: https://lore.kernel.org/all/20260728184351.75015-1-jorijnvdgraaf@catcrafts.net/
v2: https://lore.kernel.org/all/20260724202708.128267-1-jorijnvdgraaf@catcrafts.net/
v1: https://lore.kernel.org/all/20260720173411.82979-1-jorijnvdgraaf@catcrafts.net/

Jorijn van der Graaf (3):
  iio: imu: inv_icm42600: sort device id tables numerically
  iio: imu: inv_icm42600: log whoami mismatch instead of failing probe
  dt-bindings: iio: imu: icm42600: add icm42630

 .../bindings/iio/imu/invensense,icm42600.yaml | 24 +++++++++++--------
 .../iio/imu/inv_icm42600/inv_icm42600_core.c  | 16 ++++++++++---
 .../iio/imu/inv_icm42600/inv_icm42600_i2c.c   | 16 ++++++-------
 .../iio/imu/inv_icm42600/inv_icm42600_spi.c   | 16 ++++++-------
 4 files changed, 43 insertions(+), 29 deletions(-)


base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425
-- 
2.55.0

[PATCH v4 1/3] iio: imu: inv_icm42600: sort device id tables numerically

[Jorijn van der Graaf]

The I2C, SPI and OF device id tables list the parts in the chip enum's
declaration order, which is neither numeric nor alphabetical. Sort the
entries numerically by part number so new entries have an unambiguous
position.

Suggested-by: Jonathan Cameron <jic23@kernel.org>
Link: https://lore.kernel.org/all/20260724012505.02029e51@jic23-huawei/
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
No changes in v4.

 drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 16 ++++++++--------
 drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 16 ++++++++--------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
index 28552d2db91d..e44ed6dcde02 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
@@ -77,10 +77,10 @@ static const struct i2c_device_id inv_icm42600_id[] = {
 	{ .name = "icm42600", .driver_data = INV_CHIP_ICM42600 },
 	{ .name = "icm42602", .driver_data = INV_CHIP_ICM42602 },
 	{ .name = "icm42605", .driver_data = INV_CHIP_ICM42605 },
-	{ .name = "icm42686", .driver_data = INV_CHIP_ICM42686 },
 	{ .name = "icm42622", .driver_data = INV_CHIP_ICM42622 },
-	{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
 	{ .name = "icm42631", .driver_data = INV_CHIP_ICM42631 },
+	{ .name = "icm42686", .driver_data = INV_CHIP_ICM42686 },
+	{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, inv_icm42600_id);
@@ -95,18 +95,18 @@ static const struct of_device_id inv_icm42600_of_matches[] = {
 	}, {
 		.compatible = "invensense,icm42605",
 		.data = (void *)INV_CHIP_ICM42605,
-	}, {
-		.compatible = "invensense,icm42686",
-		.data = (void *)INV_CHIP_ICM42686,
 	}, {
 		.compatible = "invensense,icm42622",
 		.data = (void *)INV_CHIP_ICM42622,
-	}, {
-		.compatible = "invensense,icm42688",
-		.data = (void *)INV_CHIP_ICM42688,
 	}, {
 		.compatible = "invensense,icm42631",
 		.data = (void *)INV_CHIP_ICM42631,
+	}, {
+		.compatible = "invensense,icm42686",
+		.data = (void *)INV_CHIP_ICM42686,
+	}, {
+		.compatible = "invensense,icm42688",
+		.data = (void *)INV_CHIP_ICM42688,
 	},
 	{ }
 };
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
index faf743bc6444..3e2f4eb42e97 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
@@ -74,10 +74,10 @@ static const struct spi_device_id inv_icm42600_id[] = {
 	{ .name = "icm42600", .driver_data = INV_CHIP_ICM42600 },
 	{ .name = "icm42602", .driver_data = INV_CHIP_ICM42602 },
 	{ .name = "icm42605", .driver_data = INV_CHIP_ICM42605 },
-	{ .name = "icm42686", .driver_data = INV_CHIP_ICM42686 },
 	{ .name = "icm42622", .driver_data = INV_CHIP_ICM42622 },
-	{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
 	{ .name = "icm42631", .driver_data = INV_CHIP_ICM42631 },
+	{ .name = "icm42686", .driver_data = INV_CHIP_ICM42686 },
+	{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
 	{ }
 };
 MODULE_DEVICE_TABLE(spi, inv_icm42600_id);
@@ -92,18 +92,18 @@ static const struct of_device_id inv_icm42600_of_matches[] = {
 	}, {
 		.compatible = "invensense,icm42605",
 		.data = (void *)INV_CHIP_ICM42605,
-	}, {
-		.compatible = "invensense,icm42686",
-		.data = (void *)INV_CHIP_ICM42686,
 	}, {
 		.compatible = "invensense,icm42622",
 		.data = (void *)INV_CHIP_ICM42622,
-	}, {
-		.compatible = "invensense,icm42688",
-		.data = (void *)INV_CHIP_ICM42688,
 	}, {
 		.compatible = "invensense,icm42631",
 		.data = (void *)INV_CHIP_ICM42631,
+	}, {
+		.compatible = "invensense,icm42686",
+		.data = (void *)INV_CHIP_ICM42686,
+	}, {
+		.compatible = "invensense,icm42688",
+		.data = (void *)INV_CHIP_ICM42688,
 	},
 	{ }
 };
-- 
2.55.0

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

[Jorijn van der Graaf]

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@kernel.org>
Suggested-by: Jonathan Cameron <jic23@kernel.org>
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/
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
v4: keep the whoami read and log the mismatch at info level,
following the wording Jonathan proposed (Jonathan, Conor), instead
of deleting the check and the whoami definitions; add
inv_icm45600's no-response guard - whoami 0x00/0xff still fails
probe; both prints use %#04x so the two ids render at equal width;
retested on the device.
v3 dropped the check and the whoami definitions entirely.
New in v2, as a demotion of the error to a warning.

 drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
index dc97d8a274e3..8ceaf825f124 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
@@ -8,6 +8,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/kernel.h>
+#include <linux/limits.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/pm_runtime.h>
@@ -510,9 +511,18 @@ static int inv_icm42600_setup(struct inv_icm42600_state *st,
 	if (ret)
 		return ret;
 	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)
+			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);
 	}
 	st->name = hw->name;
 
-- 
2.55.0

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

[Andy Shevchenko]

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@kernel.org>
> Suggested-by: Jonathan Cameron <jic23@kernel.org>

> 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

[PATCH v4 3/3] dt-bindings: iio: imu: icm42600: add icm42630

[Jorijn van der Graaf]

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 with the
ICM-42631 as fallback: TDK confirmed the part is similar to the
ICM-42631 and driven by the same driver without modification. The
dedicated compatible records the exact part so a difference can still
be handled if one surfaces (the part has no public datasheet).

Link: https://lore.kernel.org/all/BE1P281MB1426D6579C0E2709574549B6CEC22@BE1P281MB1426.DEUP281.PROD.OUTLOOK.COM/
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
v4: rebased over the icm42607 and mount-matrix changes to this file
(no content change); added Conor's Acked-by.
No changes in v3.
v2: restructured to the icm42631 fallback form; Jean-Baptiste's v1
Acked-by lapsed with the rework.

 .../bindings/iio/imu/invensense,icm42600.yaml | 24 +++++++++++--------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 81b6e85decd5..9e22b603d47f 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -26,16 +26,20 @@ description: |
 
 properties:
   compatible:
-    enum:
-      - invensense,icm42600
-      - invensense,icm42602
-      - invensense,icm42605
-      - invensense,icm42607
-      - invensense,icm42607p
-      - invensense,icm42622
-      - invensense,icm42631
-      - invensense,icm42686
-      - invensense,icm42688
+    oneOf:
+      - enum:
+          - invensense,icm42600
+          - invensense,icm42602
+          - invensense,icm42605
+          - invensense,icm42607
+          - invensense,icm42607p
+          - invensense,icm42622
+          - invensense,icm42631
+          - invensense,icm42686
+          - invensense,icm42688
+      - items:
+          - const: invensense,icm42630
+          - const: invensense,icm42631
 
   reg:
     maxItems: 1
-- 
2.55.0