linux-kernel - Re: [PATCH v1 15/15] iio: adc: ad7768-1: add filter type and decimation rate attributes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4XAN+aVJwChONzQ@JSANTO12-L01.ad.analog.com>
Date: Mon, 13 Jan 2025 22:39:03 -0300
From: Jonathan Santos <jonath4nns@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: David Lechner <dlechner@...libre.com>,
	Jonathan Santos <Jonathan.Santos@...log.com>,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, lars@...afoo.de,
	Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, marcelo.schmitt1@...il.com,
	PopPaul2021 <paul.pop@...log.com>
Subject: Re: [PATCH v1 15/15] iio: adc: ad7768-1: add filter type and
 decimation rate attributes

On 01/12, Jonathan Cameron wrote:
> On Tue, 7 Jan 2025 17:50:56 -0600
> David Lechner <dlechner@...libre.com> wrote:
> 
> > On 1/7/25 9:27 AM, Jonathan Santos wrote:
> > > Separate filter type and decimation rate from the sampling frequency
> > > attribute. The new filter type attribute enables SINC3 and WIDEBAND
> > > filters, which were previously unavailable.  
> > 
> > See related comments in my reply to the documentation patches about wideband vs.
> > FIR and decimation rate vs. -3dB cutoff.
> > 
> > > 
> > > Previously, combining decimation and MCLK divider in the sampling
> > > frequency obscured performance trade-offs. Lower MCLK divider
> > > settings increase power usage, while lower decimation rates reduce
> > > precision by decreasing averaging. By creating a decimation attribute,
> > > users gain finer control over performance.  
> > 
> > It seems like we would also want a power_mode attribute. We already have an
> > attribute for this for used by accelerometers so there is some precedent for
> > such an attribute.
> 
> I'm not sure that attribute was ever a good idea :(
> So would prefer we don't use it again unless we are really really stuck.
> 
> Usual assumption tends to be if anyone wants to reduce power they
> should be able to do so with other controls (i.e. reduce sampling rate or
> oversampling). Those are easier to interpret than magic low power mode
> attributes.
> 
> Jonathan
> 

I tend do agree with Jonathan in this one. the power mode is directly linked to
MCLK divider, which is under sampling frequency now. Basicly, we assume
that higher sample rates lead to an increase in power usage.
Even oversampling does not affect the power mode. 

Configuring an inadequate power mode, depending on the mclk divider, may
result in malfunction.

> 
> > 
> > > 
> > > The addition of those attributes allows a wider range of sampling
> > > frequencies and more access to the device features.  
> > 
> > 
>