This updates the binding documentation for LTC2497 to include LTC2495.

Signed-off-by: Yusuf Alper Bilgin <y.alperbilgin@gmail.com>
---
 Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
index 5cc6a96840778473895f436b7e2627d6240b254b..2a3e3dcc6ca7a48a0fccb88d8d42fee34efcff73 100644
--- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
@@ -17,11 +17,13 @@ description: |
 
     https://www.analog.com/media/en/technical-documentation/data-sheets/2309fd.pdf
 
+  LTC2495:
   LTC2497:
   LTC2499:
     16bit ADC supporting up to 16 single ended or 8 differential inputs.
     I2C interface.
 
+    https://www.analog.com/media/en/technical-documentation/data-sheets/2495fe.pdf
     https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
     https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
 
@@ -29,6 +31,7 @@ properties:
   compatible:
     enum:
       - lltc,ltc2309
+      - lltc,ltc2495
       - lltc,ltc2497
       - lltc,ltc2499
 

-- 
2.43.0

On 12/08/2025 19:04, Yusuf Alper Bilgin wrote:
> This updates the binding documentation for LTC2497 to include LTC2495.

What are the differences, why it cannot be made compatible with 2497
(fallback)?

If there is going to be any new version:
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

> 
> Signed-off-by: Yusuf Alper Bilgin <y.alperbilgin@gmail.com>
> ---
>  Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 



Best regards,
Krzysztof

Hi Krzysztof,

Thank you for the review and guidance.

On Tue, Aug 12, 2025 at 07:04:00PM +0200, Krzysztof Kozlowski wrote:
> What are the differences, why it cannot be made compatible with 2497
> (fallback)?

The LTC2495 offers a more advanced feature set compared to the LTC2497,
including:

- Adjustable input gain
- A selectable 50Hz/60Hz lowpass filter to reject line frequency noise
- Selectable speed modes
- An internal temperature sensor

All of these features are configured via a second I2C command byte
(listed in Table 4 of:
https://www.analog.com/media/en/technical-documentation/data-sheets/2495fe.pdf),
which changes the driver's communication protocol compared to the
single-byte commands of the LTC2497.

This patch series begins to support reading the internal temperature
sensor by implementing driver logic for the two-byte I2C command format
and exposing the IIO temperature channel. Therefore, I added a new
binding. Without the support for the temperature sensor and this
different command structure, a simple fallback would be sufficient.

Let me know if you agree with the reasoning to add the binding. If so, I
will update the commit messages in v2 to include this justification and
ensure they follow the imperative mood convention.

Best regards,

Alper

On 13/08/2025 10:44, Yusuf Alper Bilgin wrote:
> Hi Krzysztof,
> 
> Thank you for the review and guidance.
> 
> On Tue, Aug 12, 2025 at 07:04:00PM +0200, Krzysztof Kozlowski wrote:
>> What are the differences, why it cannot be made compatible with 2497
>> (fallback)?
> 
> The LTC2495 offers a more advanced feature set compared to the LTC2497,
> including:
> 
> - Adjustable input gain
> - A selectable 50Hz/60Hz lowpass filter to reject line frequency noise
> - Selectable speed modes
> - An internal temperature sensor

"More advanced" does not mean it is not compatible. If old device (less
advanced) features are working the same, it is the exact meaning of
compatible devices.


Best regards,
Krzysztof

On Wed, 13 Aug 2025 10:44:44 +0200
Yusuf Alper Bilgin <y.alperbilgin@gmail.com> wrote:

> Hi Krzysztof,
> 
> Thank you for the review and guidance.
> 
> On Tue, Aug 12, 2025 at 07:04:00PM +0200, Krzysztof Kozlowski wrote:
> > What are the differences, why it cannot be made compatible with 2497
> > (fallback)?  
> 
> The LTC2495 offers a more advanced feature set compared to the LTC2497,
> including:
> 
> - Adjustable input gain
> - A selectable 50Hz/60Hz lowpass filter to reject line frequency noise
> - Selectable speed modes
> - An internal temperature sensor
> 
> All of these features are configured via a second I2C command byte
> (listed in Table 4 of:
> https://www.analog.com/media/en/technical-documentation/data-sheets/2495fe.pdf),
> which changes the driver's communication protocol compared to the
> single-byte commands of the LTC2497.
> 
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.

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

Jonathan

> This patch series begins to support reading the internal temperature
> sensor by implementing driver logic for the two-byte I2C command format
> and exposing the IIO temperature channel. Therefore, I added a new
> binding. Without the support for the temperature sensor and this
> different command structure, a simple fallback would be sufficient.
> 
> Let me know if you agree with the reasoning to add the binding. If so, I
> will update the commit messages in v2 to include this justification and
> ensure they follow the imperative mood convention.
> 
> Best regards,
> 
> Alper

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