From: Lars-Peter Clausen <lars@metafoo.de>
To: Jonathan Cameron <jic23@kernel.org>, Matt Ranostay <mranostay@gmail.com>
Cc: linux-iio@vger.kernel.org, Marek Vasut <marex@denx.de>,
Matt Porter <mporter@konsulko.com>,
Daniel Baluta <daniel.baluta@intel.com>,
Peter Meerwald <pmeerw@pmeerw.net>
Subject: Re: [PATCH v3] iio: temperature: add support for Maxim thermocouple chips
Date: Mon, 27 Jun 2016 13:30:57 +0200 [thread overview]
Message-ID: <57710E71.3000603@metafoo.de> (raw)
In-Reply-To: <4f1a2f3f-fea0-8d14-dcea-ff2bd51dca63@kernel.org>
On 06/26/2016 05:13 PM, Jonathan Cameron wrote:
> On 22/06/16 09:02, Lars-Peter Clausen wrote:
>> On 06/11/2016 06:48 PM, Jonathan Cameron wrote:
>>> On 03/06/16 13:33, Jonathan Cameron wrote:
>>>> On 30/05/16 02:37, Matt Ranostay wrote:
>>>>> Add initial driver support for MAX6675, and MAX31885 thermocouple chips.
>>>>>
>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>> Cc: Matt Porter <mporter@konsulko.com>
>>>>> Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>>>> I'm going to let this sit for a sort while as I'd like some discussion
>>>> of the invalidate buffer bit.
>>>>
>>>> Cc'd a few more people for views.
>>> Hmm. Deadly silence.
>>>
>>> Daniel, Lars, Peter - this is a fairly fundamental abi question.
>>>
>>> What do we do to signify an 'invalid reading' in the buffer.
>>>
>>> Here the part is driven by a software trigger - and if we skip
>>> a reading we are obviously out of sync.
>>>
>>> Old and nasty trick we used in some (possibly only one)
>>> early driver was to set an invalid state for these cases.
>>>
>>> Anyone have a better idea?
>>
>> Ideally the driver would leave the data including the status bit intact and
>> not replace it with a magic constant that way an application that is aware
>> of the way the chip behaves could handle that.
>
> In response to what I'd misunderstood this as:
>
> It's tricky as the status bit is not in general in the same register as the
> value. We would need to add a meta data element to the buffer to handle this.
>
> I'm inclined to go with the magic value as the best 'general purpose' option
> we have right now... I don't like it, but adding meta data is also somewhat
> hideous as most usecases and devices wouldn't use it.
The thing is the application needs to be aware of the magic value and its
meaning for this particular driver anyway. So we might as well just expose
the raw value without doing any processing. From an applications point of
view there is no difference and application that is aware of it can handle
it, an application that is not can't.
next prev parent reply other threads:[~2016-06-27 11:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 1:37 [PATCH v3] iio: temperature: add support for Maxim thermocouple chips Matt Ranostay
2016-05-30 13:00 ` Marek Vasut
2016-06-03 12:33 ` Jonathan Cameron
2016-06-11 16:48 ` Jonathan Cameron
2016-06-22 7:27 ` Matt Ranostay
2016-06-22 8:02 ` Lars-Peter Clausen
2016-06-26 15:13 ` Jonathan Cameron
2016-06-27 7:09 ` Matt Ranostay
2016-06-27 11:30 ` Lars-Peter Clausen [this message]
2016-06-27 23:42 ` Matt Ranostay
2016-06-30 19:45 ` Jonathan Cameron
2016-06-22 8:06 ` Lars-Peter Clausen
2016-06-22 9:01 ` Matt Ranostay
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=57710E71.3000603@metafoo.de \
--to=lars@metafoo.de \
--cc=daniel.baluta@intel.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=mporter@konsulko.com \
--cc=mranostay@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.