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:   Thu, 17 Sep 2020 18:42:56 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Gene Chen <gene.chen.richtek@...il.com>
Cc:     matthias.bgg@...il.com, knaack.h@....de, lars@...afoo.de,
        pmeerw@...erw.net, linux-iio@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        gene_chen@...htek.com, Wilma.Wu@...iatek.com,
        shufan_lee@...htek.com, cy_huang@...htek.com,
        benjamin.chao@...iatek.com, Cristian Pop <cristian.pop@...log.com>
Subject: Re: [PATCH v4 2/3] Documentation: ABI: testing: mt6360: Add ADC
 sysfs guideline

On Wed, 16 Sep 2020 01:36:08 +0800
Gene Chen <gene.chen.richtek@...il.com> wrote:

> From: Gene Chen <gene_chen@...htek.com>
> 
> Add ABI documentation for mt6360 ADC sysfs interfaces.
> 
> Signed-off-by: Gene Chen <gene_chen@...htek.com>
Would you consider using the proposed label attribute for channels?

https://lore.kernel.org/linux-iio/20200916132115.81795-1-cristian.pop@analog.com/T/#u

I'm hoping that will remove the need to have ext name used in the majority of
cases and would like to know if it would work for you?
It may not work for this particular case of course.

Other comments inline.

> ---
>  Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 | 83 ++++++++++++++++++++++
>  1 file changed, 83 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360
> new file mode 100644
> index 0000000..4b1c270
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360
> @@ -0,0 +1,83 @@
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_USBID_input


The mixture of case is a bit ugly.  Could we do 
in_voltage_usbin_input?

> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 USBID ADC which connected to connector ID pin.
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_VBUSDIV5_input

> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 VBUS ADC with high accuracy
> +		Reading returns voltage in uV

Why would we ever read the low accuracy version?  

> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_VBUSDIV2_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 VBUS ADC with low accuracy
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_VSYS_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 VSYS ADC
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_VBAT_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 VBAT ADC
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_current_IBUS_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 IBUS ADC
> +		Reading returns current in uA
Given voltage and current are already clear from the channel type,
could we avoid the repetition?

in_current_bus_input perhaps?

> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_current_IBAT_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 IBAT ADC
> +		Reading returns current in uA
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_CHG_VDDP_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 CHG_VDDP ADC
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_temp_TEMP_JC_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 IC junction temperature
> +		Reading returns temperature in degree
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_VREF_TS_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 VREF_TS ADC
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_TS_input
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 TS ADC
> +		Reading returns voltage in uV
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/timestamp
> +KernelVersion:	5.8.0
> +Contact:	gene_chen@...htek.com
> +Description:
> +		Indicated MT6360 timestamp
> +		Reading returns current timestamp in ms

That's an odd bit of ABI.  Why would we want to read the current timestamp from
sysfs?  Timestamps in IIO also tend to be in nano seconds.




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ