Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 10 Jun 2026 17:40:04 +0100
Conor Dooley <conor@kernel.org> wrote:

> On Wed, Jun 10, 2026 at 04:56:40PM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 14:00:51 +0300
> > Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> >   
> > > Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
> > > tree binding from plain text format to YAML schema format.
> > > 
> > > The binding covers two variants matched via their respective bus drivers:
> > > - SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
> > > - I2C: st,lis3lv02d   (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
> > > 
> > > Document all vendor-specific properties read by the driver via
> > > of_property_read_*(), including click detection, IRQ routing, free-fall/
> > > wake-up engines, high-pass filtering, axis remapping, output data rate,
> > > and self-test limits.
> > > 
> > > Also correct the click threshold property names: the driver reads
> > > "st,click-threshold-{x,y,z}" but the old .txt documented them as
> > > "st,click-thresh-{x,y,z}".
> > > 
> > > Validated with: make dt_binding_check   DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> > > 
> > > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>  
> > 
> > Hi.
> > 
> > So the conundrum here is whether we want to keep carrying this binding
> > as it dates to a previous era.
> > 
> > The driver never made it to IIO and is still in drivers/misc.
> > The majority of what is the text document should never have been
> > in DT in the first place. I'll guess this dates all the way back
> > to the wild west days before we had regular binding review.  
> 
> I'd say this should be treated like a staging binding but for the fact
> that this has a user in arm. Problem of course is that it's probably
> impossible to get that board and so doing any rework is probably not
> realistic for this submitter?
> Is there a general policy for iio devices in misc? Do they get reworked
> to be moved?

It is tricky if we have upstream users because the ABI will change on them.

I'm not sure how easy this would be to add to the existing st sensors driver
as these are very early parts.  If we could maybe we'd do so and just deal
with the mess of having to disable one or other driver. 

My gut feeling here is ancient part, let it get dropped in a year or
two and not worry about adding support to a standard IIO driver unless
anyone actually has hardware and wants to do it.

> 
> The user funnily enough has the binding's click-thresh properties:
> 		st,click-single-x;
> 		st,click-single-y;
> 		st,click-single-z;
> 		st,click-thresh-x = <10>;
> 		st,click-thresh-y = <10>;
> 		st,click-thresh-z = <10>;
> 		st,irq1-click;
> 		st,irq2-click;
> 		st,wakeup-x-lo;
> 		st,wakeup-x-hi;
> 		st,wakeup-y-lo;
> 		st,wakeup-y-hi;
> 		st,wakeup-z-lo;
> 		st,wakeup-z-hi;
> Dunno what that ultimately means in terms of which should be used
> though.
Set those as defaults in the driver if all upstream users have those
values and then drop reading them from dt?