[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250816112307.642ea373@jic23-huawei>
Date: Sat, 16 Aug 2025 11:23:07 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Yusuf Alper Bilgin <y.alperbilgin@...il.com>
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
On Wed, 13 Aug 2025 10:44:44 +0200
Yusuf Alper Bilgin <y.alperbilgin@...il.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
Powered by blists - more mailing lists