Re: [PATCH v4] dt-bindings: iio: proximity: move LIDAR-Lite out of trivial-devices

[Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>]

On 7/14/26 19:44, David Lechner wrote:
> 
> interrupts:
>   description: 
>     Mode control pin can be used as a status output to provide interrupt.
>   maxItems: 1
> 
> Mode control pin can also be clock output, so we could add:
> 
> '#clock-cells':
>   const: 0
> 
> if:
>   required:
>     interrupts
> then:
>   '#clock-cells': false
> 
> I only checked Lidar Lite v3 docs, so we should see if these are available
> on v2 as well.
David, quick pushback on the #clock-cells suggestion:

The oscillator-output mode, per the Garmin datasheet, page 8 reg 0x4 from [1], isn't really
meant to supply a clock for another device's logic. As I understand it, it exists so the host
can measure it against its own reference and compute a compensation factor for the device's
own distance readings, since the on-chip oscillator is only rated to ~1% accuracy.

That seems like a different relationship than what #clock-cells models: a provider is
expected to report a rate that a consumer just uses to drive its own logic. Here it's the
opposite — the rate itself is what's untrustworthy and needs an external measurement, and
there's no consumer that would actually want to clock anything off of it.

Given that, maybe it's better to just describe this rather than model it as a clock property,
or leave it out of the binding entirely for now until there's an actual consumer for it? My
point is more about whether #clock-cells is the right semantics for potential consumers here.

Tks and regards.

[1] https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf