linux-kernel - Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

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: <D84D2ED7-81D4-4635-8244-4017D66C6A3B@jic23.retrosnub.co.uk>
Date:	Mon, 18 Apr 2016 18:31:36 +0100
From:	Jonathan Cameron <jic23@...23.retrosnub.co.uk>
To:	Laxman Dewangan <ldewangan@...dia.com>,
	Jonathan Cameron <jic23@...nel.org>, robh@...nel.org,
	edubezval@...il.com, rui.zhang@...el.com, mark.rutland@....com,
	pawel.moll@....com, ijc+devicetree@...lion.org.uk
CC:	linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver



On 18 April 2016 17:49:39 BST, Laxman Dewangan <ldewangan@...dia.com> wrote:
>
>On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote:
>> On 14/04/16 15:41, Laxman Dewangan wrote:
>> +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti,
>int *val)
>> +{
>> +	int ret;
>> +
>> +	ret = iio_read_channel_processed(gti->channel, val);
>> +	if (ret < 0)
>> +		ret = iio_read_channel_raw(gti->channel, val);
>> Is this case actually useful given it means the scaling of the adc
>> isn't known?
>>
>> I suppose you might have defined the table in terms of raw readings,
>> but then when someone comes along and 'fixes' the ADC driver to
>output
>> it's scale your table will be wrong.
>>
>
>Yes, that may be possible if someone just move the implementation of 
>processed read to raw read.
>I assumed that some of adc driver implemented as raw and some of 
>implemented as processed and so fallback.
>
>However, if adc driver has processed implementation then it should not 
>move to raw and deprecate the processed.
>
>It seems raw as default should be better option. We can have two option
>now:
>
>- Support raw only, not to processed.
>
>- Or support the raw as default and processed as the optional from DT.
>if (!processed)
>     read_raw()
>else
>   read_processed()
>
>
>Your opinion?
Processed only. It will compute the right value if raw and scale are provided by the
 device (which they should be for an ADC). The read_processed function does
 the maths if needed.

 The only time devices should
 supply raw without scale is if their is no direct transform ( e.g. an infrared
 intensity measure where only known transform involves combining it with
 another signal) or their is an external unknown (e.g. proximity sensors where
 you have to know what they were close to in order to know the scaling!)

If there is a conventional ADC driver not providing either processed directly or
 both raw and scale let us know and we will fix it!

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.