From: Jonathan Cameron <jic23@cam.ac.uk>
To: guenter.roeck@ericsson.com
Cc: Urs Fleisch <urs.fleisch@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
LM Sensors <lm-sensors@lm-sensors.org>,
Jean Delvare <khali@linux-fr.org>
Subject: Re: [PATCH] hwmon: driver for Sensirion SHT21 humidity and temperature sensor
Date: Tue, 04 Jan 2011 12:13:04 +0000 [thread overview]
Message-ID: <4D230ED0.8060008@cam.ac.uk> (raw)
In-Reply-To: <1294078159.9786.9.camel@groeck-laptop>
On 01/03/11 18:09, Guenter Roeck wrote:
> On Mon, 2011-01-03 at 06:06 -0500, Jonathan Cameron wrote:
>> On 01/03/11 07:14, Urs Fleisch wrote:
>>> Hi Jonathan,
>> When posting an updated driver, use the form
>> [PATCH V2] hwmon: driver...
>>
>> That way it will be obvious to people that it isn't just a repost of the
>> previous code.
>>>
>>> Thanks for reviewing the patch. I have fixed the issues you reported and the
>>> style problems.
>>>
>>>> Sorry, but this isn't going to be acceptable. Classic case of magic numbers.
>>>> This needs to be broken up into several different attributes.
>>>> We have:
>>>> * control over the measurement resolution (which is somewhat fiddly
>>>> on this device)
>>>> * Battery voltage threshold > 2.25V
>>>> * Enable on chip heater
>>>
>>>> So this one is the only one I have problem with. Other two attributes are
>>>> standard (well humidity is pretty unusual but no one ever complained about
>>>> the sht15 afaik!)
>>>
> I have been thinking about this, and would like to get Jean's input.
>
> Humidity doesn't really sound like "hardware monitoring"; more like
> environmental monitoring. But on the other side, even though humidity
> doesn't really monitor the HW, it does monitor operational conditions,
> and its reported values may have impact on system operation (eg cause a
> shutdown if humidity is too high, to prevent HW damage).
That was my original argument when I proposed the sht15 driver. No idea
if anyone actually does this though!
>
> So question is if hwmon should include explicit environmental monitoring
> attributes or not, and if hwmon and environmental monitoring can and
> should be separated to start with (for example, what if any is the
> difference between environment temperature and hw monitoring
> temperature ?).
>
> Thoughts, anyone ?
I wondered exactly this when we added the sht15 driver. Never really
came to a firm conclusion though. If you and Jean decide these shouldn't
be in hwmon, I'm happy to take them both in IIO. Given our scope is much
broader and we already have things like light sensors (also sometimes environment
monitoring devices), that would work for me. There are a few sht15 users
out there I know of beyond the imote2 sensor boards (which is how I encountered
them). The imote2 users should be fine as I maintain the platform and most of
the tools anyway, the others maybe have more issues with a move.
Uses I know of are indeed more general environment monitoring.
Not seen one of these in conventional hardware monitoring but could be wrong.
I guess, Urs will have a better idea of where these tend to be used?
Obviously there is an argument for an 'environment' monitoring subsystem, but
my guess in Linus won't pull based on exactly the same issue he had with ALS
when we proposed that. Linus won't take small subsystems for sensors given
he wants them all in the same one. Actually he mostly wanted them to be in input
but Dmitry quite rightly pushed back hard against that for exactly the reason
you are wondering whether they ought to be in hwmon, avoidance of scope spread.
>
> Guenter
>
>
>
next prev parent reply other threads:[~2011-01-04 12:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-29 12:45 [PATCH] hwmon: driver for Sensirion SHT21 humidity and temperature sensor Urs Fleisch
2010-12-31 15:02 ` Jonathan Cameron
2011-01-03 7:14 ` Urs Fleisch
2011-01-03 11:06 ` Jonathan Cameron
2011-01-03 14:01 ` [PATCH V3] " Urs Fleisch
2011-01-03 15:12 ` Guenter Roeck
2011-01-03 14:53 ` [PATCH] " Guenter Roeck
2011-01-03 18:09 ` Guenter Roeck
2011-01-04 12:13 ` Jonathan Cameron [this message]
2011-01-04 15:28 ` Guenter Roeck
2011-01-04 19:00 ` Urs Fleisch
2011-01-04 19:42 ` Guenter Roeck
2011-01-06 7:43 ` [PATCH V4] " Urs Fleisch
2011-01-06 10:58 ` Jonathan Cameron
2011-01-06 15:21 ` Guenter Roeck
2011-01-06 15:56 ` Guenter Roeck
2011-01-07 7:15 ` [PATCH V5] " Urs Fleisch
2011-01-07 11:55 ` Guenter Roeck
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=4D230ED0.8060008@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=guenter.roeck@ericsson.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=urs.fleisch@gmail.com \
/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