linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org, Peter Rosin <peda@axentia.se>,
	Chris Lesiak <chris.lesiak@licor.com>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	linux-iio <linux-iio@vger.kernel.org>
Subject: Re: [PATCH] hwmon: (ntc_thermistor): try reading processed
Date: Wed, 23 Dec 2020 13:42:28 -0800	[thread overview]
Message-ID: <d990e08f-6f18-836d-89a5-01102a4faa45@roeck-us.net> (raw)
In-Reply-To: <CACRpkdZTVAoDbbJqTJbxv1ZDyAMsB_h9TAdKKbxqBYGp4-b_jg@mail.gmail.com>

On 12/23/20 1:08 PM, Linus Walleij wrote:
> On Mon, Dec 21, 2020 at 5:15 PM Guenter Roeck <linux@roeck-us.net> wrote:
> 
>>> -     ret = iio_convert_raw_to_processed(channel, raw, &uv, 1000);
>>> -     if (ret < 0) {
>>> -             /* Assume 12 bit ADC with vref at pullup_uv */
>>> -             uv = (pdata->pullup_uv * (s64)raw) >> 12;
>>> +             /*
>>> +              * FIXME: This fallback to using a raw read and then right
>>> +              * out assume the ADC is 12 bits and hard-coding scale
>>> +              * to 1000 seems a bit dangerous. Should it simply be
>>> +              * deleted?
>>> +              */
>>
>> The hwmon ABI specifically supports unscaled values, which can then be
>> scaled in userspace using the sensors configuration file.
>> Given that we return the pseudo-scaled value to userspace today,
>> it seems to me that it would do more harm to change that instead of just
>> leaving it in place.
> 
> I see.
> 
> I tried to drill down and see the history of the driver and in the
> original commit all values are scaled with the function
> get_temp_mC() which indicates that the driver has always
> intended to return millicentigrades, not unscaled values (as
> far as I can tell).
> 

Sure. That isn't the problem. I didn't say that the value reported
to userspace _shall_ be unscaled, I said that the ABI supports it.

We are not discussing your patch here, just the comment. You don't
answer the basic question: What should the driver do if the iio
subsystem only delivers raw values ? I suggested we should just keep
the current assumption in this case, ie do the fixed conversion,
and let userspace handle any necessary adjustments. You seem to object.
With your patch, we get a comment in the driver suggesting that some
code should be removed. In my opinion, such a comment comment does
not add any value. Ether we drop the code or we don't, and I dislike
removing it.

That results in my usual fallback: When in doubt, do nothing.

Guenter

  reply	other threads:[~2020-12-23 21:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-19 22:41 [PATCH] hwmon: (ntc_thermistor): try reading processed Linus Walleij
2020-12-21 16:15 ` Guenter Roeck
2020-12-23 21:08   ` Linus Walleij
2020-12-23 21:42     ` Guenter Roeck [this message]
2020-12-24  0:47       ` Linus Walleij
2020-12-23 22:39     ` Chris Lesiak
     [not found]     ` <SN6PR08MB5565DD42F17BA93D362DB95B9ADE0@SN6PR08MB5565.namprd08.prod.outlook.com>
2020-12-24  0:39       ` Linus Walleij

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=d990e08f-6f18-836d-89a5-01102a4faa45@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=chris.lesiak@licor.com \
    --cc=jdelvare@suse.com \
    --cc=jic23@cam.ac.uk \
    --cc=linus.walleij@linaro.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=peda@axentia.se \
    /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;
as well as URLs for NNTP newsgroup(s).