linux-kernel - Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 25 Mar 2018 17:44:01 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     John Syne <john3909@...il.com>
Cc:     Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
        devel@...verdev.osuosl.org, Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Hartmut Knaack <knaack.h@....de>, daniel.baluta@....com
Subject: Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces
 IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

On Sat, 24 Mar 2018 16:06:17 -0700
John Syne <john3909@...il.com> wrote:

This thread is becoming unmanageable so I am cropping this down to just
the questions that remain open.

> >> Probably easier to copy and paste this table into a spreadsheet. Let me know if there is anything I got wrong. Thank you again for all your help.  
> > Yeah, we need to shrink this if we do it again.  
> I’ll send an updated copy after this e-mail. Can you accept a spreadsheet 
> attachment or a CSV file?
We need to keep the discussion visible on list so it needs to stay in
plain text.  Just need to drop any columns we aren't caring about to make
it easier to read.
> > 
...
> >> 0x439C	CVAROS	in_powerreactive0_phaseC_offset		in	powerreactive	0	phaseC	offset	R/W	24	32 ZPSE	S	0x000000	Phase C total reactive power offset adjust (ADE7858, ADE7868, and ADE7878).
> >> 0x439D	AFWGAIN	in_power0_phaseA_fundamental_scale		in	power	0	phaseA_fundamental	scale	R/W	24	32 ZPSE	S	0x000000	Phase A fundamental active power gain adjust. Location reserved for ADE7854, ADE7858, and ADE7868.  
> > Hmm. Fundamental needs to be represented using a separate channel index
> > and description of the frequency filters applied.  That should map it
> > a generic way.  
> How do I do this?
Define additional channels with different index and for them
use the the infomask elements
IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY,
IIO_CHAN_INFO_HIGH_PASS_FILTER_3DB_FREQUENCY
and provide suitable values from the read_raw callbacks for that
channel.

...
> >> 0x43C0	AIRMS	in_current0_phaseA_rms		in	current	0	phaseA_rms		R	24	32 ZP	S	N/A4	Phase A current rms value.  
> > in_current0_phaseA_rms_raw as otherwise we don't know we need to apply
> > in_current0_phaseA_rms_scale to it (or the shared value that maps to that).  
> Yeah, this is still confusion to me. This should read in_current0_phaseA_rms_gain 
> as it directly affects the value in_current0_phaseA_rms_raw. We still have to apply
> a scale value to turn this cryptic number into something meaningful. 
So I'm a little lost. We have variable gain fine.
Does it effect the necessary scale factor to go from raw to real value or not?
1) Yes it does - then roll it as appropriate into the _scale attribute. 
   It should not be separated.  This often requires some interesting maths
   but is a onetime thing as the value isn't changing dynamically.

2) No it doesn't - then it is calibgain as it represents a necessary
   parameter to change the incoming circuit to compensate for external effects.

It is possible you have a mixture of the two and hence need both but that
is normally only the case with devices where the calibgain is about fixing
the factory calibration.

...