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: <20250112124552.4eec878f@jic23-huawei>
Date: Sun, 12 Jan 2025 12:45:52 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Jonathan Santos <jonath4nns@...il.com>
Cc: 61060bc2-6450-4309-8e57-3d1bb32d3ab6@...libre.com, 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, Sergiu Cuciurean
 <sergiu.cuciurean@...log.com>, lars@...afoo.de,
 Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, marcelo.schmitt1@...il.com
Subject: Re: [PATCH v1 10/15] iio: adc: ad7768-1: Add support for variable
 VCM

On Sat, 11 Jan 2025 23:37:29 -0300
Jonathan Santos <jonath4nns@...il.com> wrote:

> On 01/07, David Lechner wrote:
> > On 1/7/25 9:26 AM, Jonathan Santos wrote:  
> > > From: Sergiu Cuciurean <sergiu.cuciurean@...log.com>
> > > 
> > > The VCM output voltage can be used as a common-mode voltage within the
> > > amplifier preconditioning circuits external to the AD7768-1.
> > > 
> > > This change exports the VCM as an iio attribute and makes it available
> > > for configuration.  
> > 
> > We model common mode voltage inputs as a regulator consumer (e.g. vcm-supply in
> > DT), so should we make this a regulator provider instead?
> > 
> > It could be used with "regulator-output" to be able to control it from sysfs
> > or if the amplifier ends up in the devicetree for other reasons, the amplifier
> > driver could control the regulator instead of requiring it to by done in sysfs.
> >  
> 
> Ok, that is an interesting approach, I will try this. It makes sense to
> have it in the devicetree. 

I'd be a bit surprised if this ended up being varied in real systems.
So maybe start with a solution that has DT provide a value suitable to the
amplifier (ideally because the amplifier requests it) and we can figure
more dynamic stuff out later if needed.

Jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ