Re: [PATCH v3] iio: accel: st_accel: add LIS2DS12

[kauschluss <kauschluss@disroot.org>]

On 2024-06-02 08:54, Jonathan Cameron wrote:
> On Sat, 1 Jun 2024 20:49:25 +0100
> Conor Dooley <conor@kernel.org> 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.
>>