On 2024-06-02 08:54, Jonathan Cameron wrote:
> On Sat, 1 Jun 2024 20:49:25 +0100
> Conor Dooley <conor@xxxxxxxxxx> wrote:
>
>> On Sun, Jun 02, 2024 at 12:56:41AM +0530, Kaustabh Chakraborty wrote:
>> > diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
>> > index fd3749871121..329a4d6fb2ec 100644
>> > --- a/drivers/iio/accel/st_accel_i2c.c
>> > +++ b/drivers/iio/accel/st_accel_i2c.c
>> > @@ -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,
>>
>> > diff --git a/drivers/iio/accel/st_accel_spi.c b/drivers/iio/accel/st_accel_spi.c
>> > index f72a24f45322..825adab37105 100644
>> > --- a/drivers/iio/accel/st_accel_spi.c
>> > +++ b/drivers/iio/accel/st_accel_spi.c
>> > @@ -64,6 +64,10 @@ static const struct of_device_id st_accel_of_match[] = {
>> > .compatible = "st,lis2dh12-accel",
>> > .data = LIS2DH12_ACCEL_DEV_NAME,
>> > },
>> > + {
>> > + .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
>
> At the moment the st_sensors core 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.
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?
I'll make sure to rewrite the description more accurately in v4.
> 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.
> 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
>
>
>>
>> Thanks,
>> Conor.
>>
