From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753344AbcDRRBN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 Apr 2016 13:01:13 -0400
Received: from hqemgate14.nvidia.com ([216.228.121.143]:6445 "EHLO
	hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751548AbcDRRBK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 Apr 2016 13:01:10 -0400
X-PGP-Universal: processed;
	by hqnvupgp07.nvidia.com on Mon, 18 Apr 2016 09:58:13 -0700
Message-ID: <57151023.8010505@nvidia.com>
Date: Mon, 18 Apr 2016 22:19:39 +0530
From: Laxman Dewangan <ldewangan@nvidia.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Jonathan Cameron <jic23@kernel.org>, <robh@kernel.org>,
        <edubezval@gmail.com>, <rui.zhang@intel.com>, <mark.rutland@arm.com>,
        <pawel.moll@arm.com>, <ijc+devicetree@hellion.org.uk>
CC: <linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>
Subject: Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor
 driver
References: <1460644878-19943-1-git-send-email-ldewangan@nvidia.com> <1460644878-19943-2-git-send-email-ldewangan@nvidia.com> <57136B7C.6030204@kernel.org>
In-Reply-To: <57136B7C.6030204@kernel.org>
X-Originating-IP: [10.19.65.30]
X-ClientProxiedBy: DRHKMAIL103.nvidia.com (10.25.59.17) To
 bgmail102.nvidia.com (10.25.59.11)
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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?