From: Jonathan Cameron <jic23@kernel.org>
To: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Eugene Zalkonnikov <ez@norphonic.com>,
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 v7 1/2] Driver for TI HDC20x0 humidity and temperature sensors
Date: Sat, 2 May 2020 19:21:27 +0100 [thread overview]
Message-ID: <20200502192127.25c77aa5@archlinux> (raw)
In-Reply-To: <7482ee6f-eedb-8482-d30e-7fa8e9b0fd47@norphonic.com>
On Mon, 27 Apr 2020 09:57:49 +0200
Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com> wrote:
> Hi Peter,
>
>
> On 27.04.2020 00:35, Peter Meerwald-Stadler wrote:
> >> +{
> >> + struct i2c_client *client = data->client;
> >> + s32 ret;
> >> +
> >> + ret = i2c_smbus_read_byte_data(client,
> >> + hdc2010_reg_translation[chan->address].peak);
> >> +
> >> + if (ret < 0)
> >> + dev_err(&client->dev, "Could not read sensor data\n");
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static int hdc2010_get_heater_status(struct hdc2010_data *data)
> > return value should be bool?
>
> No idea. It is an int in hdc100x hdc heater sysfs and I try to stick to existing practices.
>
> Should those be bools?
Locally it would make sense, but then we write them into an int where
they are used, so little point. Probably best to leave them as they are.
>
> >
> >> + 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_peak_measurement_byte(data, chan);
> >> + mutex_unlock(&data->lock);
> >> + iio_device_release_direct_mode(indio_dev);
> >> + if (ret < 0)
> >> + return ret;
> >> + /* Scaling up the value so we can use same offset as RAW */
> >> + *val = ret * 256;
> > I'd rather have different _SCALEs for peak and raw
>
> They are made shared per Jonathan's suggestion early on, as the offsets for the channels don't match.
Yup. There is no standard ABI to deal with different scales for peak and
raw and I wasn't keen that we introduce it for this relatively rare
corner case.
Jonathan
>
>
> Regards,
>
> Eugene.
>
next prev parent reply other threads:[~2020-05-02 18:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-26 22:18 [PATCH v7 1/2] Driver for TI HDC20x0 humidity and temperature sensors Eugene Zalkonnikov
2020-04-26 22:26 ` [PATCH v7 2/2] dt-bindings " Eugene Zalkonnikov
2020-04-26 22:35 ` [PATCH v7 1/2] Driver " Peter Meerwald-Stadler
2020-04-27 7:57 ` Eugene Zaikonnikov
2020-05-02 18:21 ` Jonathan Cameron [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-05-18 19:13 Eugene Zalkonnikov
2020-05-19 6:24 ` Eugene Zaikonnikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200502192127.25c77aa5@archlinux \
--to=jic23@kernel.org \
--cc=development@norphonic.com \
--cc=eugene.zaikonnikov@norphonic.com \
--cc=ez@norphonic.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox