linux-kernel - Re: [PATCH 0/2] add AD8460 DAC driver

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: <20240628193954.2f3dfc55@jic23-huawei>
Date: Fri, 28 Jun 2024 19:39:54 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: "Tinaco, Mariel" <Mariel.Tinaco@...log.com>
Cc: David Lechner <dlechner@...libre.com>, "linux-iio@...r.kernel.org"
 <linux-iio@...r.kernel.org>, "devicetree@...r.kernel.org"
 <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, Lars-Peter Clausen <lars@...afoo.de>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>, Mark
 Brown <broonie@...nel.org>, "Hennerich, Michael"
 <Michael.Hennerich@...log.com>, Marcelo Schmitt
 <marcelo.schmitt1@...il.com>, Dimitri Fedrau <dima.fedrau@...il.com>,
 Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 0/2] add AD8460 DAC driver


> >   
> > > >   * Programmable quiescent current (optional)  
> > Could probably figure out a suitable control for this, but I'm not entirely sure
> > what it is :)  
> 
> Thinking about it, wouldn't the raw attribute be a suitable control for this? This 
> Value is relative to nominal supply current and acts as a "monotonic but nonlinear"
> multiplier. 
> A register value maps to a current level from 0 to 2 times the nominal
> current supplied. I also thought that it could be hardware gain but the gain
> computation wasn't explicitly indicated in the datasheet and there is not yet
> "current_hardwaregain" attribute available in the ABI. So I settled with raw. 

I don't entirely understand what is actually for, but a raw current output
might be appropriate.

>I
> Think there would only be an issue of we expose the "processed" attribute
> Because it has a particular computation. But I'm not planning to expose the 
> Processed attribute

Is there any reason someone might in future though?

> 
> > > >   * Thermal monitoring is done by measuring voltage on TMP pin
> > > > (unlikely to be included)  
> >
> > If you did want to, the usual trick for these is to include an optional use as a
> > consumer of an IIO provider which would be a separate ADC.  
> 
> I included this in my current revision, thanks for the idea. Although the optional use
> Isn’t yet available in the consumer API. My question is, in case the ADC channel to read
> The TMP pin is not available, should I still make the temp raw value available and
> Set to 0? Or should the temp raw attribute be unavailable or unlisted completely from
> IIO Info.
If no ADC channel then remove it from the chan_spec.  That probably means you
need separate arrays of struct iio_chan_spec for the two case.

Jonathan

> > > >  
> > >
> > > Adding myself to the cc: here since I'm interested to see what
> > > Jonathan (or anyone else) has to say about the fault monitoring.  
> > 
> > Jonathan