On Tue, 4 Jun 2024 08:53:27 -0500 David Lechner <dlechner@xxxxxxxxxxxx> wrote: > On 6/4/24 1:47 AM, Krzysztof Kozlowski wrote: > > On 03/06/2024 21:59, David Lechner wrote: > >> On 6/2/24 8:21 PM, Kim Seer Paller wrote: > >>> Add documentation for ltc2672. > >>> > >>> Reported-by: Rob Herring (Arm) <robh@xxxxxxxxxx> > >>> Closes: https://lore.kernel.org/all/171643825573.1037396.2749703571529285460.robh@xxxxxxxxxx/ > >>> Co-developed-by: Michael Hennerich <michael.hennerich@xxxxxxxxxx> > >>> Signed-off-by: Michael Hennerich <michael.hennerich@xxxxxxxxxx> > >>> Signed-off-by: Kim Seer Paller <kimseer.paller@xxxxxxxxxx> > >>> --- > >>> .../bindings/iio/dac/adi,ltc2672.yaml | 158 ++++++++++++++++++ > >>> MAINTAINERS | 1 + > >>> 2 files changed, 159 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml > >>> new file mode 100644 > >>> index 000000000000..d143a9db7010 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml > >>> @@ -0,0 +1,158 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2672.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: Analog Devices LTC2672 DAC > >>> + > >>> +maintainers: > >>> + - Michael Hennerich <michael.hennerich@xxxxxxxxxx> > >>> + - Kim Seer Paller <kimseer.paller@xxxxxxxxxx> > >>> + > >>> +description: | > >>> + Analog Devices LTC2672 5 channel, 16 bit, 300mA DAC > >>> + https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2672.pdf > >>> + > >>> +properties: > >>> + compatible: > >>> + enum: > >>> + - adi,ltc2672 > >> > >> The linked datasheet describes 12-bit and 16-bit versions, so should we have > >> two compatibles here? adi,ltc2672-12, adi,ltc2672-16 > > > > Is their programming model different? > > > > I replied to myself already with the answer. After looking at it more it > does not appear that is the case. > For a DAC, this is an interesting question. The wrong impressions of precision might be a problem if someone is trying to tune the value. Say they set it to +15 and look at some other sensor for the affect. They expect to see something but get no change at all. They might assume the circuit is broken. So I think yes the programming model is different and that should be discoverable (ideally from hardware, but if not from the compatible) To take an extreme example of extending the logic of these being the 'same' from a programming model point of view, would we consider a regulator that did 0 and 3V only different from one that did 0V, 1V, 2V, 3V just because the second bit in the register was ignored? I think in that case we'd consider them to have an obviously different programming model. We have a few cases where we do paper over similar differences in resolution, but within one part with different settings rather than between devices (so that's a driver limitation, not a DT thing). So I might be persuaded no one cares, but in my view the programming model is different in a significant way. Jonathan
