linux-kernel - Re: [PATCH v2] dt-bindings: iio: proximity: Add Lidar-lite-v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250824102324.427517-1-wbg@kernel.org>
Date: Sun, 24 Aug 2025 19:23:22 +0900
From: William Breathitt Gray <wbg@...nel.org>
To: Jonathan Cameron <jic23@...nel.org>
Cc: William Breathitt Gray <wbg@...nel.org>,
	Rodrigo Gobbi <rodrigo.gobbi.7@...il.com>,
	robh@...nel.org,
	krzk+dt@...nel.org,
	dlechner@...libre.com,
	nuno.sa@...log.com,
	andy@...nel.org,
	conor+dt@...nel.org,
	mranostay@...il.com,
	~lkcamp/patches@...ts.sr.ht,
	linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v2] dt-bindings: iio: proximity: Add Lidar-lite-v2

On Sat, Aug 02, 2025 at 12:12:38PM +0100, Jonathan Cameron wrote:
> > On 7/3/25 18:26, David Lechner wrote:
> > > On 7/1/25 5:30 PM, Rodrigo Gobbi wrote:  
> > >> The compatible grmn,lidar-lite-v3 is managed by the same
> > >> driver of pulsedlight,lidar-lite-v2, which is a trivial device.  
> > > 
> > > As a general rule of thumb, using the driver as justification for
> > > dt-bindings is never a good reason. The bindings describe the hardware,
> > > not the driver.
> > > 
> > > Assuming I found the correct datasheet [1], I see a power enable pin
> > > and a mode control pin, so I would say that this isn't a trivial device.
> > > Therefore this will need it's own new file. We could at least add
> > > power-gpios and power-supply properties. How to handle the mode pin
> > > isn't so clear to me though, so might omit that for now.  
> > About the mode control pin and the data being returned within PWM, it`s also
> > unclear to me how to describe that here. Looking other kind of existing iio
> > devices, couldn`t find a reference for it so I`ve not described that.
> 
> So far we've never supported a sensor with a PWM output.  Needs some capture logic
> and whilst there is some supported in the kernel, I don't think we have the
> infrastructure to describe the sensor beyond it. It relies on an odd combination
> of triggering via a light pull low that the device then drives high.  To make
> that work with a standard capture unit is probably a case of wiring multiple pins
> or some external components.
> 
> +CC counters subsystem maintainer William.
> 
> https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf
> for reference

So how does this look from the monitor pin side; a low level for some
amount of time followed by a high for a set duration, where distance can
then be derived from the amount of time spanning between falling edge
and rising edge?

In theory this could be represented as a counter device (in the context
of the Generic Counter paradigm the monitor pin would serve as the
"Signal"), then Counter events could be defined for the edge
transitions, and finally distance can be derived by userspace by
capturing the edge transition events and comparing the timestamps.

However, while that approach works in a technical sense, it definitely
feels clunky. On a conceptual level, a remote detection instrument
like a lidar isn't really a counter device: it's purpose isn't to track
the progression of a count.

I think it would be more appropriate for us first to properly define an
abstract representation for these kind of range-finding devices. For
example, these devices are going to have some sort of trigger (whether a
pin polarity or command sequence), some sort
of transmission signal (involving a particular strength, frequency, and
duration), and some sort of reception interpretation (perhaps involving
noise filtration, multiple previous record averaging, and timestamping).

Once the general abstract representation of these types of devices is
adequately defined, the DT-binding design will naturally arise from it
and subsequently a proper driver interface.

> However, I'm also in agreement with others that this is an unusual case where
> we are very likely to missdesign a DT-binding without having explored what the
> driver stack looks like and so are best just leaving a gap for now.
> 
> Even if we did describe the mode stuff it would be optional so not describing it
> for now should be fine.

I second this as well for now. There may be other devices that we will
encounter with similar mode pins and such that would help us figure out
the best way to introduce these to a DT-binding in the future.

William Breathitt Gray