linux-kernel - Re: [PATCH v2 3/4] iio: accel: wsen-itds accel documentation

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: <20200503130103.16a92131@archlinux>
Date:   Sun, 3 May 2020 13:01:03 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Saravanan Sekar <saravanan@...umiz.com>
Cc:     robh+dt@...nel.org, knaack.h@....de, lars@...afoo.de,
        pmeerw@...erw.net, broonie@...nel.org, lgirdwood@...il.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 3/4] iio: accel: wsen-itds accel documentation

On Wed, 29 Apr 2020 15:39:42 +0200
Saravanan Sekar <saravanan@...umiz.com> wrote:

> Add documentation about device operating mode and output data range
> supported according to operating mode
> 
> Signed-off-by: Saravanan Sekar <saravanan@...umiz.com>
> ---
>  .../ABI/testing/sysfs-bus-iio-wsen-itds       | 23 +++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-wsen-itds
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-wsen-itds b/Documentation/ABI/testing/sysfs-bus-iio-wsen-itds
> new file mode 100644
> index 000000000000..5979f2b8aa1a
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-wsen-itds
> @@ -0,0 +1,23 @@
> +What:		/sys/bus/iio/devices/iio\:device0/in_accel_samp_freq_available
> +KernelVersion:	5.7
> +Contact:	linux-iio@...r.kernel.org
> +Description:
> +		Reading gives range of sample frequencies available for current operating mode
> +		after one data has generated.

This is standard ABI so should be the main docs, not here.
It also takes absolute precedence over the power modes (as mentioned below, no
standard userspace will be able to use those).  So if the frequency is
only available in high perf mode, then we change to high perf mode.

> +
> +		Access: Read
> +		Valid values: represented in Hz
> +		- range [12.5, 1600] for high permormance mode
> +		- range [1.6, 200] for normal/low power mode
> +
> +What:		/sys/bus/iio/devices/iio\:device0/operating_mode
> +KernelVersion:	5.7
> +Contact:	linux-iio@...r.kernel.org
> +Description:
> +		Represents the device operating mode. High performance mode gives high output
> +		data rate and low noise compared to normal mode. Normal mode consumes less
> +		current.  In single shot device enters to lowpower after one data has
> +		generated.
> +
> +		Access: Read, Write
> +		Valid values: "lowpower", "normal", "high_perf", "single_shot"

The issue with these sort of 'mode' interface is almost no userspace will ever use them.
They are too unpredictable across different types of devices.

Some of these should also not be exposed to userspace anyway as they are about 'how'
you are using the driver.  For example, if you aren't doing triggered capture then
single_shot is almost always the correct option. Annoyingly I see high performance
mode gives lower noise...

So no need to expose single_shot to userspace.

For the others we are just looking at different power vs speed and accuracy trade offs.
Those are better exposed by what they effect.  Here the big control for that is
sampling frequency.

So if we assume the user is never going to touch this control (if it's even there)
then we probably want to assume they want the best possible accuracy for whatever
frequency they are running at.  So transition across the modes to provide that.

Should we ever support low power mode?  It sounds nice on paper, but in reality
userspace won't use so I suspect we should just drop it - certainly in an initial
patch submission (as it will hold up acceptance).  Even if we did support
it, as mentioned above ABI controls will take precedence so we are looking
at a 'hint' not a control of mode.

ABI is a pain, and we will put a lot of effort into not expanding it unless
there is a good usecase plus no way of mapping to existing ABI.

Jonathan