linux-kernel - Re: [PATCH v2 1/2] iio: core: introduce IIO_CHAN_INFO

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: <56DDDFFC.5010100@metafoo.de>
Date:	Mon, 7 Mar 2016 21:09:32 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Ludovic Desroches <ludovic.desroches@...el.com>, jic23@...nel.org
Cc:	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, nicolas.ferre@...el.com
Subject: Re: [PATCH v2 1/2] iio: core: introduce IIO_CHAN_INFO_SIGNED

On 03/07/2016 03:29 PM, Ludovic Desroches wrote:
> The same channel can be used to perform a signed or an unsigned
> conversion. Add a new infomask element to be able to select the type of
> conversion wanted: a raw one or a signed raw one.

If this is the difference between offset binary and two's complement then it
makes no sense to expose this at this level. Both are the same number just
in a different representation and converting between them is cheap. A few
magnitudes cheaper than reading the result over sysfs. So, if your device
supports both, just pick one.

For the buffered interface it may make sense to expose this, since the per
sample overhead is a lot lower. But still doing the conversion should be
cheap enough that it does not really matter. Before this is implemented I'd
like to see hard performance numbers that this actually makes a difference.

- Lars