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] [day] [month] [year] [list]
Message-ID: <20191027164420.2a1aa82c@archlinux>
Date:   Sun, 27 Oct 2019 16:44:20 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Rishi Gupta <gupt21@...il.com>
Cc:     knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
        gregkh@...uxfoundation.org, tglx@...utronix.de,
        allison@...utok.net, alexios.zavras@...el.com, angus@...ea.ca,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] iio: documentation: light: Add veml6030 sysfs
 documentation

On Tue, 22 Oct 2019 18:41:27 +0530
Rishi Gupta <gupt21@...il.com> wrote:

> The driver for veml6030 light sensor provides sysfs
> entries like configuring cutoff for interrupt. This
> commit document them.
> 
> Signed-off-by: Rishi Gupta <gupt21@...il.com>
> ---
> Changes in v5:
> * Use ABI/testing/sysfs-bus-iio to document sysfs files for veml6030
> 
> Changes in v4:
> * None
> 
> Changes in v3:
> * Updated Date from September to October
> * Updated KernelVersion from 5.3.1 to 5.4
> * in_illuminance_period_available is now in events directory
> 
> Changes in v2:
> * None
> 
>  Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 6804516..a26d532 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -753,6 +753,8 @@ What:		/sys/.../events/in_illuminance0_thresh_falling_value
>  what:		/sys/.../events/in_illuminance0_thresh_rising_value
>  what:		/sys/.../events/in_proximity0_thresh_falling_value
>  what:		/sys/.../events/in_proximity0_thresh_rising_value
> +What:		/sys/.../events/in_illuminance_thresh_rising_value
> +What:		/sys/.../events/in_illuminance_thresh_falling_value
>  KernelVersion:	2.6.37
>  Contact:	linux-iio@...r.kernel.org
>  Description:
> @@ -972,6 +974,7 @@ What:		/sys/.../events/in_activity_jogging_thresh_rising_period
>  What:		/sys/.../events/in_activity_jogging_thresh_falling_period
>  What:		/sys/.../events/in_activity_running_thresh_rising_period
>  What:		/sys/.../events/in_activity_running_thresh_falling_period
> +What:		/sys/.../events/in_illuminance_thresh_either_period
>  KernelVersion:	2.6.37
>  Contact:	linux-iio@...r.kernel.org
>  Description:
> @@ -1715,3 +1718,12 @@ Description:
>  		Mass concentration reading of particulate matter in ug / m3.
>  		pmX consists of particles with aerodynamic diameter less or
>  		equal to X micrometers.
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/events/in_illuminance_period_available
> +Date:		October 2019
> +KernelVersion:	5.4
> +Contact:	linux-iio@...r.kernel.org
> +Description:
> +		List of valid values available in multiples of integration time
> +		for which the light intensity must be above the threshold level
> +		before interrupt is asserted. This refers to persistence values.

This doesn't match with in_illuminance_period (which is correct).  The period values
a are in seconds, not multiples of the integration time.  The reason is that firstly
integration time may not be related to sampling frequency (which actually matters here)
and secondly it's much easier for userspace to set these period values to say something
is true for 0.1 seconds rather than having to work out the relationship with the devices
internal sampling rates.


Thanks,

Jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ