iio: accel: st_accel: add LIS2DS12
Quoted 62 lines · Jonathan Cameron
Quoted 44 lines · On Thu, 06 Jun 2024 10:12:11 +0000 kauschluss <[email protected]> wrote:
Quoted 38 lines · Jonathan Cameron
Quoted 26 lines · On Sat, 1 Jun 2024 20:49:25 +0100 Conor Dooley <[email protected]> wrote:
Quoted 25 lines · Kaustabh Chakraborty
drivers/iio/accel/st_accel_i2c.c +4
-0@@ -102,6 +102,10 @@ static const struct of_device_id st_accel_of_match[] = { .compatible = "st,lis2de12", .data = LIS2DE12_ACCEL_DEV_NAME, }, + { + .compatible = "st,lis2ds12", + .data = LIS2DS12_ACCEL_DEV_NAME, + }, { .compatible = "st,lis2hh12", .data = LIS2HH12_ACCEL_DEV_NAME,drivers/iio/accel/st_accel_spi.c +1
-0@@ -64,6 +64,10 @@ static const struct of_device_id st_accel_of_match[] = { .compatible = "st,lis2dh12-accel", .data = LIS2DH12_ACCEL_DEV_NAME, }, + {Quoted 8 lines
drivers/iio/accel/st_accel_spi.c static const struct of_device_id st_accel_of_match[] = { · line 73
Quoted 6 lines
drivers/iio/accel/st_accel_spi.c +3
-0+ .compatible = "st,lis2ds12", + .data = LIS2DS12_ACCEL_DEV_NAME, + }, { .compatible = "st,lis3l02dq", .data = LIS3L02DQ_ACCEL_DEV_NAME,Any new compatibles need to be documented in st,st-sensors.yaml
Quoted 4 lines
At the moment the
st_sensorscore is doing hard matching against whoami values which isn't good. That should ideally be fixed and the binding for this device should use a fallback compatible if the statement about compatibility is accurate.Quoted 5 lines
I apologize for not wording the description accurately. By "compatibility", I mean that the sensor settings of LIS2DE12 (such as the gain values) seem to be well-suited for LIS2DS12, as per my experimentation. Both devices are manufactured by ST and have no correlation regarding compatibility whatsoever. In that case, a fallback compatible isn't required, right?
If only the Who Am I value prevents it working if you give the compatible as lisde12 then even though ST rarely if ever identifies it in datasheets, they are software compatible. In that case we should allow for a fallback compatible.
+ fix the driver not to fail on the whoami mismatch.
Note we don't care if they have totally different packages as long as the driver doesn't need to know that. If they have different numbers of interrupts though or power supplies, then they aren't compatible and we shouldn't provide a fallback.
Quoted 2 lines
Roughly speaking you have to compare datahsheet sections for pins (not which but what) and register maps.
I've thoroughly checked the registers, and indeed, a lot of registers addresses and other settings are different. Although the sensor settings of LIS2DE12 "work", they are technically incorrect.
I've fixed it, and will send it with v4 in a day or two.
Thank you!
Quoted 26 lines
That applies even if the current driver will fail to probe (for now)
Quoted 9 lines
I'll make sure to rewrite the description more accurately in v4.
Quoted 3 lines
It may just be a case of relaxing the check in
st_sensors_verify_id()to printing a warning not an error message and not returning an error code (reserving error returns in that function for bus error etc.I agree, if you want I may send a patch for that after I'm done with this one.
Thanks,
Jonathan
Quoted 12 lines
Quoted 12 lines
That doesn't need to be in this patch though. Just have the fallback stuff in the binding and for now we can rely on matching the more precise compatible.
Jonathan
Quoted 4 lines
Thanks,
Conor.