linux-kernel - Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors

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]

Date:   Sat, 9 Jan 2021 19:01:33 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Jyoti Bhayana <jbhayana@...gle.com>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        cristian.marussi@....com, sudeep.holla@....com,
        egranata@...gle.com, mikhail.golubev@...nsynergy.com,
        Igor.Skalkin@...nsynergy.com, Peter.hilber@...nsynergy.com,
        ankitarora@...gle.com
Subject: Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based
 sensors

On Wed,  6 Jan 2021 21:23:53 +0000
Jyoti Bhayana <jbhayana@...gle.com> wrote:

> Hi Jonathan,
> 
> Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding IIO_VAL_FRACTIONAL_LONG
> or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can be different
> than the one used in resolution according to specification. 

That's somewhat 'odd'.  Given min/max are inherently values the sensor is supposed to
be able to return why give them different resolutions?  Can you point me at a specific
section of the spec?  The axis_min_range_low etc fields don't seem to have units specified
but I assumed they were in sensor units and so same scale factors?

> 
> I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using IIO_AVAIL_RANGE 
> and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution.
> Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 will use 4 values
> val_high,val_low,and val2_high and val2_low.

I'm not keen on the changing that internal kernel interface unless we absolutely
have to.  read_avail() is called from consumer drivers and they won't know anything
about this new variant.

> 
> Let me know if that is an acceptable solution.

Hmm. It isn't a standard use of the ABI given the value in the buffer is (I assume)
raw (needs scale applied).  However, it isn't excluded by the ABI docs.  Whether
a standard userspace is going to expect it is not clear to me.

I don't want to end up in a position where we end up with available being generally
added for processed when what most people care about is what the value range they
might get from a polled read is (rather than via a buffer).

So I'm not that keen on this solution but if we can find a way to avoid it.

Jonathan

> 
> 
> Thanks,
> Jyoti
>