linux-kernel - Re: [PATCH 1/3] dt-bindings: iio: adc: ltc2497: add docs for LTC2495

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGgmJFtdnq5WgewdJYwW5+K-KTQ4yU1AKrXpov_QieJWqEKrnA@mail.gmail.com>
Date: Mon, 18 Aug 2025 18:26:05 +0200
From: Alper Bilgin <y.alperbilgin@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: krzk@...nel.org, Michael.Hennerich@...log.com, andy@...nel.org, 
	conor+dt@...nel.org, devicetree@...r.kernel.org, dlechner@...libre.com, 
	krzk+dt@...nel.org, lars@...afoo.de, liambeguin@...il.com, 
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, nuno.sa@...log.com, 
	robh@...nel.org
Subject: Re: [PATCH 1/3] dt-bindings: iio: adc: ltc2497: add docs for LTC2495

Hi Jonathan and Krzysztof,

Thank you for the detailed guidance on the fallback compatible.

On Sat, Aug 16, 2025 at 12:23 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> Is that second byte optional?  Figure 3b seems to suggest so but I haven't
> taken the time to read the rest of the data sheet.
> If it is never written does this new device function as backwards compatible
> with the LTC2497?
>
> If so a fallback compatible is appropriate.  This is used when we have
> new newer DT against an older driver that doesn't support new features.
>
> A newer kernel will match on the new ID and hence provide these extended
> features you have here.
>
The second I2C command byte is indeed optional. If it is not sent, the
LTC2495 defaults to its standard mode and functions as
backwards-compatible with the LTC2497 for basic voltage readings.

The new "lltc,ltc2495" compatible is therefore needed only to allow
the updated driver to identify the chip and enable the temperature
channel.

I will rework the patch series to reflect this.

> Note this discussion should have happened before you posted v2, let alone v3 and v4!

My apologies for the extra revisions and discussion on this topic.

Best regards,

Alper