From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jonathan Cameron <jic23@cam.ac.uk>
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, 4 Jan 2011 07:28:37 -0800 [thread overview]
Message-ID: <20110104152837.GA32138@ericsson.com> (raw)
In-Reply-To: <4D230ED0.8060008@cam.ac.uk>
On Tue, Jan 04, 2011 at 07:13:04AM -0500, Jonathan Cameron wrote:
> 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.
>
If I take off my hwmon hat for a minute, I would argue that hwmon is a bad term
to start with, and that it should have been envmon to start with. That is how
it was handled at companies I worked for previously, and how it makes sense to me.
Reason is that the term tends to define the scope of a subsystem - if hwmon was named
envmon, we would not even have this discussion.
Also, it would be desirable to have a linux kernel subsystem to map the scope of RFC 3433,
the Entity Sensor MIB. That MIB does include humidity sensors. The hwmon subsystem
seems to be the best fit for it.
So, in one sentence, for me it makes a lot of sense to explicitly include environmental
monitoring in the scope of the hwmon subsystem.
Now, that is my personal opinion. I'd definitely like to get input from Jean on this.
Guenter
next prev parent reply other threads:[~2011-01-04 15:29 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
2011-01-04 15:28 ` Guenter Roeck [this message]
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=20110104152837.GA32138@ericsson.com \
--to=guenter.roeck@ericsson.com \
--cc=jic23@cam.ac.uk \
--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