Re: [PATCH v3 1/2] Driver for TI HDC20x0 humidity and temperature sensors

From: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
To: Jonathan Cameron <jic23@kernel.org>,
	Eugene Zalkonnikov <ez@norphonic.com>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"development@norphonic.com" <development@norphonic.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] Driver for TI HDC20x0 humidity and temperature sensors
Date: Tue, 21 Jan 2020 08:45:21 +0000	[thread overview]
Message-ID: <9d866c18-6643-f76f-df7e-6f29f01274da@norphonic.com> (raw)
In-Reply-To: <20191223171627.1179f88b@archlinux>

Hi Jonathan,

On 23.12.2019 18:16, Jonathan Cameron wrote:
>
> As below. Why change the existing return value?
>
>> +		}
>> +		return ret;
>> +	}
>> +	case IIO_CHAN_INFO_PEAK: {
>> +		int ret;
>> +
>> +		ret = iio_device_claim_direct_mode(indio_dev);
>> +		if (ret)
>> +			return ret;
>> +		mutex_lock(&data->lock);
>> +		ret = hdc2010_get_measurement_byte(data, chan);
>> +		mutex_unlock(&data->lock);
>> +		iio_device_release_direct_mode(indio_dev);
>> +		if (ret >= 0) {
>> +		  /* Scaling up the value so we can use same offset as RAW */
>> +			*val = ret * 256;
>> +			ret = IIO_VAL_INT;
>> +		} else
> Why overwrite ret?  That might provide better information
> on what went wrong.

As with the other stylistic notes before, no good reason other than how it was handled in other drivers in the tree. So I assumed it was the practice. Will tidy up later this week I hope and send a new patchset.

--
  Eugene