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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3637 bytes --]

On Thu, Jun 11, 2026 at 02:06:40PM +0100, Jonathan Cameron wrote:
> 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?

Actually, there's more than one user in arm, but there's a mix of
compatibles and properties used. Probably not really viable unless these
are all unique compatible + property combinations. FWIW, there's more
compatibles used than those documented, that fall back to the documented
ones.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]