The compatible grmn,lidar-lite-v3 is managed by the same
driver of pulsedlight,lidar-lite-v2, which is a trivial device.

Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
Fixes: b257c1a45e99 ("iio: pulsedlight-lidar-lite-v2: add lidar-lite-v3 property")
---
 Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 8da408107e55..cd9d7d5eec51 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -107,6 +107,8 @@ properties:
           - fsl,mpl3115
             # MPR121: Proximity Capacitive Touch Sensor Controller
           - fsl,mpr121
+            # Optical Distance Measurement Sensor
+          - grmn,lidar-lite-v3
             # Honeywell Humidicon HIH-6130 humidity/temperature sensor
           - honeywell,hi6130
             # IBM Common Form Factor Power Supply Versions (all versions)
-- 
2.48.1

On 02/07/2025 00:30, 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.

Nothing here explain the bug you are fixing. You need to be specific,
what is missing, what are you doing. Apparently you are documenting
existing ABI, but nothing in commit msg told me that.

As David pointed out, this is not a trivial device.

> 
> Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
> Fixes: b257c1a45e99 ("iio: pulsedlight-lidar-lite-v2: add lidar-lite-v3 property")

SoB goes the last.


Best regards,
Krzysztof

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.

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

> 
> Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
> Fixes: b257c1a45e99 ("iio: pulsedlight-lidar-lite-v2: add lidar-lite-v3 property")
> ---
>  Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 8da408107e55..cd9d7d5eec51 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -107,6 +107,8 @@ properties:
>            - fsl,mpl3115
>              # MPR121: Proximity Capacitive Touch Sensor Controller
>            - fsl,mpr121
> +            # Optical Distance Measurement Sensor
> +          - grmn,lidar-lite-v3
>              # Honeywell Humidicon HIH-6130 humidity/temperature sensor
>            - honeywell,hi6130
>              # IBM Common Form Factor Power Supply Versions (all versions)

> 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.

Looks like I`ve failed to double-check the datasheet here, sorry for that,
I`ll try to remember that in future occasions.

> 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.

Agree, actually, I was wondering here if the lidar-lite-v2 ref that I`ve found
when adding the grmn,lidar-lite-v3 is actually a trivial. 
It was originally added as trivial over txt file at [1] and then converted to yaml but
it looks like it is also not a trivial considering some refs at [2] and [3] (not official docs).
At those refs, I can see the same enable/mode pins.

Should we also move that out of trivial in a dedicated binding or should we keep as is
considering those docs are not official/device is very old?
Tks and regards!

[1] https://github.com/torvalds/linux/commit/12280bd3d5d7e1ba1dd60ba0bd4412f4056fc028
[2] https://www.electrokit.com/upload/product/41013/41013964/lidarlite2DS.pdf
[3] https://www.14core.com/wp-content/uploads/2017/03/LIDAR-Lite-v2-Datasheet.pdf

On 7/17/25 5:24 PM, Rodrigo Gobbi wrote:
>> 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.
> 
> Looks like I`ve failed to double-check the datasheet here, sorry for that,
> I`ll try to remember that in future occasions.
> 
>> 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.
> 
> Agree, actually, I was wondering here if the lidar-lite-v2 ref that I`ve found
> when adding the grmn,lidar-lite-v3 is actually a trivial. 
> It was originally added as trivial over txt file at [1] and then converted to yaml but
> it looks like it is also not a trivial considering some refs at [2] and [3] (not official docs).
> At those refs, I can see the same enable/mode pins.
> 
> Should we also move that out of trivial in a dedicated binding or should we keep as is
> considering those docs are not official/device is very old?
> Tks and regards!
> 
> [1] https://github.com/torvalds/linux/commit/12280bd3d5d7e1ba1dd60ba0bd4412f4056fc028
> [2] https://www.electrokit.com/upload/product/41013/41013964/lidarlite2DS.pdf
> [3] https://www.14core.com/wp-content/uploads/2017/03/LIDAR-Lite-v2-Datasheet.pdf
> 

I only looked at [3], but it looks reliable enough. It also looks (at a
quick glance) pin-compatible with v3, so I would make v3 have a fallback
compatible string to v2. And yeah, put both in the same file since they
are pretty much the same hardware.