Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

On 16-01-18, 15:22, Viresh Kumar wrote:
> This extends the sysfs interface for thermal cooling devices and exposes
> some pretty useful statistics. These statistics have proven to be quite
> useful specially while doing benchmarks related to the task scheduler,
> where we want to make sure that nothing has disrupted the test,
> specially the cooling device which may have put constraints on the CPUs.
> The information exposed here tells us to what extent the CPUs were
> constrained by the thermal framework.

@Eduardo/Zhang: Are you going to merge this for 4.17 ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] iio: chemical: sgp30: Support Sensirion SGPxx sensors

[Jonathan Cameron]

On Sat, 10 Mar 2018 23:07:30 +0100
Andreas Brauchli  wrote:

> Support Sensirion SGP30 and SGPC3 multi-pixel I2C gas sensors
> 
> Supported Features:
> 
> * Indoor Air Quality (IAQ) concentrations for
>   - tVOC (in_concentration_voc_input)
>   - CO2eq (in_concentration_co2_input) - SGP30 only
>   IAQ concentrations are periodically read out by a background thread
>   to allow the sensor to maintain its internal baseline.
> * Baseline support for IAQ (in_iaq_baseline, set_iaq_baseline)
> * Gas concentration signals
>   - Ethanol (in_concentration_ethanol_raw)
>   - H2 (in_concentration_h2_raw) - SGP30 only
> * On-chip self test (in_selftest)
> * Sensor interface version (in_feature_set_version)
> * Sensor serial number (in_serial_id)
> * Humidity compensation
>   With the help of an external humidity signal, the gas signals can be
>   humidity-compensated. The sensor performs the compensation on-chip.
> * Power mode switching between low power mode (1/2Hz) and
>   ultra low power mode (1/30Hz) sampling - SGPC3 only
> * Checksummed I2C communication
> 
> For all features, refer to the data sheet or the documentation in
> Documentation/iio/chemical/sgp30.txt for more details.
> 
> The ABI is documented in
> Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp30
> 
> Signed-off-by: Andreas Brauchli 
Hi Andreas,

This is a fairly superficial review still as we still need to pin down
some of the userspace ABI elements rather more.
Find details in the code can wait for a later revision.

Jonathan
> ---
>  .../ABI/testing/sysfs-bus-iio-chemical-sgp30   |   62 ++
>  .../bindings/iio/chemical/sensirion,sgp30.txt  |   15 +
>  Documentation/iio/chemical/sgp30.txt   |   97 ++
>  drivers/iio/chemical/Kconfig   |   13 +
>  drivers/iio/chemical/Makefile  |1 +
>  drivers/iio/chemical/sgp30.c   | 1120 
> 
>  6 files changed, 1308 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp30
>  create mode 100644 
> Documentation/devicetree/bindings/iio/chemical/sensirion,sgp30.txt
>  create mode 100644 Documentation/iio/chemical/sgp30.txt
>  create mode 100644 drivers/iio/chemical/sgp30.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp30 
> b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp30
> new file mode 100644
> index ..3b97c0bd5878
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp30
> @@ -0,0 +1,62 @@
> +what:/sys/bus/iio/devices/iio:devicex/in_featureset_version
> +date:March 2018
> +kernelversion:   4.17
> +contact: andreas brauchli 
> +description:
> + Retrieve the sensor interface version. The sensor-interface 
> should
> + remain forward-compatible across minor versions.
I'm really not keen on this.  What features are available should be apparent
from the userspace interface.

We are always interested in being able to use generic userspace code.
As such anything that requires checking a version number will inherently
mean we can't do generic code.

> +
> +what:/sys/bus/iio/devices/iio:devicex/in_iaq_baseline
> +date:March 2018
> +kernelversion:   4.17
> +contact: andreas brauchli 
> +description:
> + Retrieve the on-chip iaq baseline state. the baseline is an 
> internal
> + state that should not be modified.
Please indicate what use this is (becomes somewhat apparent from the below).

> +
> +What:/sys/bus/iio/devices/iio:deviceX/set_iaq_baseline
> +Date:March 2018
> +KernelVersion:   4.17
> +Contact: Andreas Brauchli 
> +Description:
> + Restore the on-chip IAQ baseline state to a previous state. 
> Useful for
> + fast-resuming after a restart. A baseline is valid for one week 
> when the
> + sensor is not operated.
Why separate attributes to set this from that used to read it?  Just have one 
and
call it simply iaq_baseline.

> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_selftest
> +Date:March 2018
> +KernelVersion:   4.17
> +Contact: Andreas Brauchli 
> +Description:
> + Run the on-chip self test. Output values:
> + * OK
> + * FAILED
Usual approach on this is to do it on module probe and not otherwise.
The advantage is that we don't have a userspace interface that is difficult
for userspace applications to interpret (self tests are extremely varied
in what the return).   If there is a strong reason to do this during
normal use then let use know.
Also, it's not an input channel so selftest would be the correct name.

> +
> +What: