Re: [PATCH v5 0/3] iio: adc: add support for the MAX34417 Four-Channel High Dynamic Range Power Accumulator

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 9 Nov 2026 10:52:22 +0100
Neil Armstrong <neil.armstrong@linaro.org> wrote:

> On 11/8/26 00:09, Jonathan Cameron wrote:
> > On Wed, 4 Nov 2026 09:45:02 +0100
> > Neil Armstrong <neil.armstrong@linaro.org> wrote:  
> 
> <snip>
> 
> >> But for the other reports:
> >> - [Medium] iio: adc: max34417: shared accumulators clobbered on CAM power/energy read
> >>
> >> This is a tough one, today if either we read power or energy, we erase the accumulated
> >> power+count in the context, the context accumulator is only here to make sure we don't
> >> loose data from other channels, like if we had a single HW channel.
> >> This simulates this, if we had a single HW channel, at each UPDATE we would get back
> >> to 0 in hardware anyway if we did read the power or energy.  
> > 
> > 
> > I'm only half understanding this.  Let me see...
> > 
> > I'd expect userspace to see accumulated values since we enabled the channel
> > rather than since last read.  I think that's the final suggestion from
> > sashiko.  
> 
> Oh this changes quite a lot of things.
> How do we handle overflow in this case ? we disable the channel and enable again to reset the state ?

Is it possible to accumulate into a sufficiently large type that overflow won't happen in a feasible
timescale?  Anything else is going to be a but unpredictable for userspace if it
is expecting an accumulated number.   The other things that accumulate in IIO tend to be
moderately small so it's never been an issue (things like step counters).

Jonathan