Hi,
the thing is, the only reason the different compatible is needed at all
is that the chip presents a different WHOAMI, and the invensense,icm20608
compatible seems to imply the non-D WHOAMI value.
I'm not sure how the driver would react to both compatibles being present,
and looking at the driver code, it seems that icm20608d is not the only
fully icm20608-compatible (to the extent of features supported by
the driver, and excluding the WHOAMI value) invensense IC, yet none
of these other ICs add the invensense,icm20608 compatible, so I guess I
don't see a good reason to do something different.
Regards,
Michael
On 10. 03. 22 17:34, Krzysztof Kozlowski wrote:
On 10/03/2022 14:39, michael.srba@xxxxxxxxx wrote:
From: Michael Srba <Michael.Srba@xxxxxxxxx>
ICM-20608-D differs from the other ICM-20608 variants by having
a DMP (Digital Motion Processor) core tacked on.
Despite having a different WHOAMI register, this variant is
completely interchangeable with the other ICM-20608 variants
by simply pretending the DMP core doesn't exist.
I wonder now why not using generic invensense,icm20608 compatible as
fallback? Why only having one specific compatible?
Signed-off-by: Michael Srba <Michael.Srba@xxxxxxxxx>
---
.../devicetree/bindings/iio/imu/invensense,mpu6050.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
index d69595a524c1..6784cc140323 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
@@ -17,6 +17,7 @@ properties:
enum:
- invensense,iam20680
- invensense,icm20608
+ - invensense,icm20608d
- invensense,icm20609
- invensense,icm20689
- invensense,icm20602
Best regards,
Krzysztof
