linux-kernel - Re: [PATCH v3 1/2] dt-bindings: iio: temperature: add support for MCP998X

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: <791e34a5-8670-48a2-9c26-782a7682f7cc@baylibre.com>
Date: Tue, 29 Jul 2025 11:27:20 -0500
From: David Lechner <dlechner@...libre.com>
To: Victor.Duicu@...rochip.com, robh@...nel.org, krzk+dt@...nel.org,
 jic23@...nel.org, nuno.sa@...log.com, conor+dt@...nel.org, andy@...nel.org
Cc: Marius.Cristea@...rochip.com, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: iio: temperature: add support for
 MCP998X

On 7/28/25 8:01 AM, Victor.Duicu@...rochip.com wrote:
> Hi everyone,
> 
> I am writing this message to ask your opinions regarding the placement
> of temperature range property from the MCP998X/XD family in the
> devicetree.
> 
> The reason why I am bringing back this topic is due to a limitation of
> the chips. When the moving average filter is enabled, the old readings
> are kept and new readings are added to the average. This is a problem
> when changing the range of temperatures. The raw temperature values
> change based on the range so the mixed values will give erroneous
> results during averaging.
> 
> One possible workaround for this behavior is to set the temperature
> range before runtime, to not allow the user to change it.

It looks like it is just a an average of the last 8 samples at most.
So if there isn't a way to reset the chip memory that holds those 8
samples, we could just read 8 samples and throw away the values before
giving data to userspace any time we start sampling.

Even without changing the temperature range, we would still have old
values and possibly the same issue of stale data possibly influencing
the measurements any time we stop sampling and start again. So I'm not
seeing that this temperature range setting should be a special case.
It still sounds like something better suited to be set at runtime.

> 
> Initially, in the first patch, I have placed the property
> microchip,extended-temp-range in the devicetree.
> At that point I mistakenly did not include Conor, Krzysztof and Rob in
> the discussion and I would like to ask for comments.
>