linux-kernel - Re: [PATCH v2] iio: adc: ad7124: change setup reg allocation strategy

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: <20250927192551.2b81d838@jic23-huawei>
Date: Sat, 27 Sep 2025 19:25:51 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: David Lechner <dlechner@...libre.com>, Michael Hennerich 
 <Michael.Hennerich@...log.com>, Nuno Sá 
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iio: adc: ad7124: change setup reg allocation
 strategy

On Fri, 26 Sep 2025 13:27:00 +0100
Nuno Sá <noname.nuno@...il.com> wrote:

> On Tue, 2025-09-23 at 16:48 -0500, David Lechner wrote:
> > Change the allocation strategy of the 8 SETUP registers from a least-
> > recently-used (LRU) to a first-come-first-served basis.
> > 
> > The AD7124 chips can have up to 16 channels enabled at a time in the
> > sequencer for buffered reads, but only have 8 SETUP configurations
> > (namely the OFFSET, GAIN, CONFIG and FILTER registers) that must be
> > shared among the 16 channels.  This means some of the channels must use
> > the exact same configuration parameters so that they can share a single
> > SETUP group of registers.  The previous LRU strategy did not keep track
> > of how many different configurations were requested at the same time,
> > so if there were more than 8 different configurations requested, some
> > channels would end up using the incorrect configuration because the slot
> > assigned to them would also be assigned to a different configuration
> > that wrote over it later.
> > 
> > Adding such tracking to solve this would make an already complex
> > algorithm even more complex.  Instead we can replace it with a simpler
> > first-come-first-serve strategy.  This makes it easy to track how many
> > different configurations are being requested at the same time.  This
> > comes at the expense of slightly longer setup times for buffered reads
> > since all setup registers must be written each time when a buffered read
> > is enabled.  But this is generally not considered a hot path where
> > performance is critical, so should be acceptable.
> > 
> > This new strategy also makes hardware debugging easier since SETUPs are
> > now assigned in a deterministic manner and in a logical order.
> > 
> > Signed-off-by: David Lechner <dlechner@...libre.com>
> > ---  
> 
> Hi David,
> 
> LGTM
> 
Agreed.
> Reviewed-by: Nuno Sá <nuno.sa@...log.com>
Applied to the testing branch of iio.git.