From: David Lechner <dlechner@baylibre.com>
To: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
krzk+dt@kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org,
~lkcamp/patches@lists.sr.ht
Subject: Re: [PATCH] dt-bindings: trivial-devices: Add Garmin lidar-lite-v3
Date: Thu, 17 Jul 2025 17:47:05 -0500 [thread overview]
Message-ID: <240f464a-5f99-4bef-a811-3bbc083e7f20@baylibre.com> (raw)
In-Reply-To: <20250717223153.159878-1-rodrigo.gobbi.7@gmail.com>
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.
next prev parent reply other threads:[~2025-07-17 22:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 22:30 Rodrigo Gobbi
2025-07-03 21:26 ` David Lechner
2025-07-17 22:24 ` Rodrigo Gobbi
2025-07-17 22:47 ` David Lechner [this message]
2025-07-04 7:59 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=240f464a-5f99-4bef-a811-3bbc083e7f20@baylibre.com \
--to=dlechner@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=rodrigo.gobbi.7@gmail.com \
--cc=~lkcamp/patches@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®