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

[David Lechner <dlechner@baylibre.com>]

On 8/7/26 12:10 PM, Rodrigo Gobbi wrote:
> 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.

Yes, this sounds like one of those cases where there isn't an obvious
correct binding and we should leave it until there is an actual use
case to make sure we get it right.

> 
> Tks and regards.
> 
> [1] https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf