[lm-sensors] [RFC v2] Support of chassis intrusion detection

[lm-sensors] [RFC v2] Support of chassis intrusion detection

[Jean Delvare]

Hi all,

A number of users have asked us to support the chassis intrusion
detection feature which some hardware monitoring chip have. I've
created a ticket for this:
http://www.lm-sensors.org/ticket/2370

I have made a first proposal 3 weeks ago, and got a number of
interesting comments about it. Here comes a second version hopefully
addressing all the concerns that had been raised. Changes include:
* Handle multiple intrusion detection switches.
* Let the user control whether chassis intrusion should result in
  system beeping or not. At least the Winbond W83793G supports this, and
  probably other chips as well.


sysfs interface
=======
intrusion[0-*]_alarm
		Chassis intrusion detection
		0: OK
		1: intrusion detected
		RW
		Contrary to regular alarm flags which clear themselves
		automatically when read, this one sticks until cleared by
		the user. This is done by writing 0 to the file. Writing
		other values is unsupported.

intrusion[0-*]_beep
		Chassis intrusion beep
		0: disable
		1: enable
		RW

drivers
===
Drivers adm9240, w83792d and w83793 implement this feature in
non-standard ways. They should be converted to the new, standard
interface.

libsensors
=====

SENSORS_FEATURE_INTRUSION = 0x19
SENSORS_SUBFEATURE_INTRUSION_ALARM = (SENSORS_FEATURE_INTRUSION << 8) | 0x80
SENSORS_SUBFEATURE_INTRUSION_BEEP = SENSORS_SUBFEATURE_INTRUSION_ALARM + 1 

sensors
===
Reading the value of the chassis intrusion alarm and beep subfeatures
is done like for any other subfeature. Likewise for writing to the beep
subfeature.

Writing to the alarm subfeature, OTOH, can't be handled the same as
writing limits, because we certainly don't want to clear the flag
automatically at lm_sensors start or restart time. So we could add a
dedicated flag to clear the intrusion detection flag (e.g. "sensors
--clear-intrusion").


If anyone has objections or comments, please speak up.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Fred .]

I don't know anything about anything.
But sounds good to me. Looks solid, I think.

Add support in Fintek f71882fg too.

On Tue, Mar 10, 2009 at 5:03 PM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi all,
>
> A number of users have asked us to support the chassis intrusion
> detection feature which some hardware monitoring chip have. I've
> created a ticket for this:
> http://www.lm-sensors.org/ticket/2370
>
> I have made a first proposal 3 weeks ago, and got a number of
> interesting comments about it. Here comes a second version hopefully
> addressing all the concerns that had been raised. Changes include:
> * Handle multiple intrusion detection switches.
> * Let the user control whether chassis intrusion should result in
>  system beeping or not. At least the Winbond W83793G supports this, and
>  probably other chips as well.
>
>
> sysfs interface
> =======>
> intrusion[0-*]_alarm
>                Chassis intrusion detection
>                0: OK
>                1: intrusion detected
>                RW
>                Contrary to regular alarm flags which clear themselves
>                automatically when read, this one sticks until cleared by
>                the user. This is done by writing 0 to the file. Writing
>                other values is unsupported.
>
> intrusion[0-*]_beep
>                Chassis intrusion beep
>                0: disable
>                1: enable
>                RW
>
> drivers
> ===>
> Drivers adm9240, w83792d and w83793 implement this feature in
> non-standard ways. They should be converted to the new, standard
> interface.
>
> libsensors
> =====
>
> SENSORS_FEATURE_INTRUSION = 0x19
> SENSORS_SUBFEATURE_INTRUSION_ALARM = (SENSORS_FEATURE_INTRUSION << 8) | 0x80
> SENSORS_SUBFEATURE_INTRUSION_BEEP = SENSORS_SUBFEATURE_INTRUSION_ALARM + 1
>
> sensors
> ===>
> Reading the value of the chassis intrusion alarm and beep subfeatures
> is done like for any other subfeature. Likewise for writing to the beep
> subfeature.
>
> Writing to the alarm subfeature, OTOH, can't be handled the same as
> writing limits, because we certainly don't want to clear the flag
> automatically at lm_sensors start or restart time. So we could add a
> dedicated flag to clear the intrusion detection flag (e.g. "sensors
> --clear-intrusion").
>
>
> If anyone has objections or comments, please speak up.
>
> --
> Jean Delvare
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> A number of users have asked us to support the chassis intrusion
> detection feature which some hardware monitoring chip have. I've
> created a ticket for this:
> http://www.lm-sensors.org/ticket/2370
> 
> I have made a first proposal 3 weeks ago, and got a number of
> interesting comments about it. Here comes a second version hopefully
> addressing all the concerns that had been raised. Changes include:
> * Handle multiple intrusion detection switches.
> * Let the user control whether chassis intrusion should result in
>   system beeping or not. At least the Winbond W83793G supports this, and
>   probably other chips as well.
> 
> 
> sysfs interface
> =======> 
> intrusion[0-*]_alarm
> 		Chassis intrusion detection
> 		0: OK
> 		1: intrusion detected
> 		RW
> 		Contrary to regular alarm flags which clear themselves
> 		automatically when read, this one sticks until cleared by
> 		the user. This is done by writing 0 to the file. Writing
> 		other values is unsupported.
> 
> intrusion[0-*]_beep
> 		Chassis intrusion beep
> 		0: disable
> 		1: enable
> 		RW
> 
> drivers
> ===> 
> Drivers adm9240, w83792d and w83793 implement this feature in
> non-standard ways. They should be converted to the new, standard
> interface.
> 
> libsensors
> =====
> 
> SENSORS_FEATURE_INTRUSION = 0x19
> SENSORS_SUBFEATURE_INTRUSION_ALARM = (SENSORS_FEATURE_INTRUSION << 8) | 0x80
> SENSORS_SUBFEATURE_INTRUSION_BEEP = SENSORS_SUBFEATURE_INTRUSION_ALARM + 1 
> 
> sensors
> ===> 
> Reading the value of the chassis intrusion alarm and beep subfeatures
> is done like for any other subfeature. Likewise for writing to the beep
> subfeature.
> 
> Writing to the alarm subfeature, OTOH, can't be handled the same as
> writing limits, because we certainly don't want to clear the flag
> automatically at lm_sensors start or restart time. So we could add a
> dedicated flag to clear the intrusion detection flag (e.g. "sensors
> --clear-intrusion").
> 
> 
> If anyone has objections or comments, please speak up.
> 


Looks good to me.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Matt Roberds]

On Tue, 10 Mar 2009, Jean Delvare wrote:
> If anyone has objections or comments, please speak up.

Looks good to me.

Matt Roberds


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Fred .]

http://www.lm-sensors.org/ticket/2370
Ticket says the interface definition is now upstream.

http://www.lm-sensors.org/wiki/ProjectInformation
However the Project Information page says it still is not standardized yet.

Why is this? Which is right? Perhaps the Project Information page
isn't updated? Or am I missing something?

Also, has there been any more progress.

Since the interface definition is upstreams, why have not support been
added to libsensors and sensors?

On Fri, Mar 13, 2009 at 2:44 PM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Jean Delvare wrote:
>>
>> Hi all,
>>
>> A number of users have asked us to support the chassis intrusion
>> detection feature which some hardware monitoring chip have. I've
>> created a ticket for this:
>> http://www.lm-sensors.org/ticket/2370
>>
>> I have made a first proposal 3 weeks ago, and got a number of
>> interesting comments about it. Here comes a second version hopefully
>> addressing all the concerns that had been raised. Changes include:
>> * Handle multiple intrusion detection switches.
>> * Let the user control whether chassis intrusion should result in
>>  system beeping or not. At least the Winbond W83793G supports this, and
>>  probably other chips as well.
>>
>>
>> sysfs interface
>> =======>>
>> intrusion[0-*]_alarm
>>                Chassis intrusion detection
>>                0: OK
>>                1: intrusion detected
>>                RW
>>                Contrary to regular alarm flags which clear themselves
>>                automatically when read, this one sticks until cleared by
>>                the user. This is done by writing 0 to the file. Writing
>>                other values is unsupported.
>>
>> intrusion[0-*]_beep
>>                Chassis intrusion beep
>>                0: disable
>>                1: enable
>>                RW
>>
>> drivers
>> ===>>
>> Drivers adm9240, w83792d and w83793 implement this feature in
>> non-standard ways. They should be converted to the new, standard
>> interface.
>>
>> libsensors
>> =====
>>
>> SENSORS_FEATURE_INTRUSION = 0x19
>> SENSORS_SUBFEATURE_INTRUSION_ALARM = (SENSORS_FEATURE_INTRUSION << 8) |
>> 0x80
>> SENSORS_SUBFEATURE_INTRUSION_BEEP = SENSORS_SUBFEATURE_INTRUSION_ALARM + 1
>> sensors
>> ===>>
>> Reading the value of the chassis intrusion alarm and beep subfeatures
>> is done like for any other subfeature. Likewise for writing to the beep
>> subfeature.
>>
>> Writing to the alarm subfeature, OTOH, can't be handled the same as
>> writing limits, because we certainly don't want to clear the flag
>> automatically at lm_sensors start or restart time. So we could add a
>> dedicated flag to clear the intrusion detection flag (e.g. "sensors
>> --clear-intrusion").
>>
>>
>> If anyone has objections or comments, please speak up.
>>
>
>
> Looks good to me.
>
> Regards,
>
> Hans
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Guenter Roeck]

On Thu, Oct 07, 2010 at 08:55:46AM -0400, Fred . wrote:
> http://www.lm-sensors.org/ticket/2370
> Ticket says the interface definition is now upstream.
> 
It is.

> http://www.lm-sensors.org/wiki/ProjectInformation
> However the Project Information page says it still is not standardized yet.
> 
> Why is this? Which is right? Perhaps the Project Information page
> isn't updated? Or am I missing something?
> 
> Also, has there been any more progress.
> 
> Since the interface definition is upstreams, why have not support been
> added to libsensors and sensors?
> 
Browsing through the drivers, it seems that none have been converted
to use the new interface. I would guess that until that has been done,
it does not make sense to add untestable support for it to libsensors.

Please keep in mind that most of the work done in the linux kernel is voluntary.
Especially work like this, which is a bit out of mainstream. You are always
invited to make a contribution yourself, modify the drivers as needed, and
submit your patches. Including, of course, libsensors.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Fred .]

On Thu, Oct 7, 2010 at 4:33 PM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
> On Thu, Oct 07, 2010 at 08:55:46AM -0400, Fred . wrote:
>> http://www.lm-sensors.org/ticket/2370
>> Ticket says the interface definition is now upstream.
>>
> It is.
Since it is, then I suppose its a good time to add support for this in
the user-space tools.

>> Since the interface definition is upstreams, why have not support been
>> added to libsensors and sensors?
>>
> Browsing through the drivers, it seems that none have been converted
> to use the new interface. I would guess that until that has been done,
> it does not make sense to add untestable support for it to libsensors.
Which came first, the chicken or the egg?
Time to implement support for this in the user-space tools.
Hopefully support in drivers will follow.

> Please keep in mind that most of the work done in the linux kernel is voluntary.
> Especially work like this, which is a bit out of mainstream. You are always
> invited to make a contribution yourself, modify the drivers as needed, and
> submit your patches. Including, of course, libsensors.
Unfortunately, I am not technical enough to be able to contribute.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Guenter Roeck]

On Sun, Oct 10, 2010 at 06:42:27PM -0400, Fred . wrote:
> On Thu, Oct 7, 2010 at 4:33 PM, Guenter Roeck
> <guenter.roeck@ericsson.com> wrote:
> > On Thu, Oct 07, 2010 at 08:55:46AM -0400, Fred . wrote:
> >> http://www.lm-sensors.org/ticket/2370
> >> Ticket says the interface definition is now upstream.
> >>
> > It is.
> Since it is, then I suppose its a good time to add support for this in
> the user-space tools.
> 
> >> Since the interface definition is upstreams, why have not support been
> >> added to libsensors and sensors?
> >>
> > Browsing through the drivers, it seems that none have been converted
> > to use the new interface. I would guess that until that has been done,
> > it does not make sense to add untestable support for it to libsensors.
> Which came first, the chicken or the egg?
> Time to implement support for this in the user-space tools.
> Hopefully support in drivers will follow.
> 
This is not a matter of chicken and egg. Driver support must come first,
to be able to test the user space tools. Besides, tools support w/o kernel
support doesn't provide any value at all, untested or not.

Since you state yourself that you don't have the technical knowledge to make 
any contribution yourself, it might be a good idea to listen to those who _do_
have the technical knowledge when it comes to deciding what must come first.
You can not both claim technical knowledge good enough to determine what
comes first, but then claim to not have the knowledge to actually do the work.

Frankly, I think you are shooting yourself into the foot here. You keep
making requests without providing anything. If you had asked a bit more
friendly and at the very least offered to help with testing, people might
be more willing to support you. But all we get is your demands and a statement
that you will not (be able to) contribute yourself. Not really a good start.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Fred .]

I am sorry tha I do not have the nescesary equipment nor skill set in
order to be able to help test
or contribute with code.

Now since the interface definition is upstreams, I hope that someone
may implement the feature
in at least one of the drivers.

On Mon, Oct 11, 2010 at 12:59 AM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
> On Sun, Oct 10, 2010 at 06:42:27PM -0400, Fred . wrote:
>> On Thu, Oct 7, 2010 at 4:33 PM, Guenter Roeck
>> <guenter.roeck@ericsson.com> wrote:
>> > On Thu, Oct 07, 2010 at 08:55:46AM -0400, Fred . wrote:
>> >> http://www.lm-sensors.org/ticket/2370
>> >> Ticket says the interface definition is now upstream.
>> >>
>> > It is.
>> Since it is, then I suppose its a good time to add support for this in
>> the user-space tools.
>>
>> >> Since the interface definition is upstreams, why have not support been
>> >> added to libsensors and sensors?
>> >>
>> > Browsing through the drivers, it seems that none have been converted
>> > to use the new interface. I would guess that until that has been done,
>> > it does not make sense to add untestable support for it to libsensors.
>> Which came first, the chicken or the egg?
>> Time to implement support for this in the user-space tools.
>> Hopefully support in drivers will follow.
>>
> This is not a matter of chicken and egg. Driver support must come first,
> to be able to test the user space tools. Besides, tools support w/o kernel
> support doesn't provide any value at all, untested or not.
>
> Since you state yourself that you don't have the technical knowledge to make
> any contribution yourself, it might be a good idea to listen to those who _do_
> have the technical knowledge when it comes to deciding what must come first.
> You can not both claim technical knowledge good enough to determine what
> comes first, but then claim to not have the knowledge to actually do the work.
>
> Frankly, I think you are shooting yourself into the foot here. You keep
> making requests without providing anything. If you had asked a bit more
> friendly and at the very least offered to help with testing, people might
> be more willing to support you. But all we get is your demands and a statement
> that you will not (be able to) contribute yourself. Not really a good start.
>
> Guenter
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Jean Delvare]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Hi Fred,

Please don't top-post.

On Tue, 12 Oct 2010 09:15:03 +0200, Fred . wrote:
> I am sorry tha I do not have the nescesary equipment nor skill set in
> order to be able to help test
> or contribute with code.
> 
> Now since the interface definition is upstreams, I hope that someone
> may implement the feature
> in at least one of the drivers.

This is done now: the new w83795 hardware monitoring driver implements
the standard intrusion detection interface.

I have written user-space code to use that interface. I have two
patches, one for libsensors, one for sensors, both apply on top of
lm-sensors SVN, if anyone wants to give them a try. I've attached them.
They work OK for me, I'll commit them soon unless someone finds and
reports a problem with them.

Then we will have to convert the remaining drivers. I found 3 drivers
which need to be converted: adm9240, w83792d and w83793. If there are
more, please let me know.

-- 
Jean Delvare

[-- Attachment #2: libsensors-add-intrusion-detection-support.patch --]
[-- Type: text/x-patch, Size: 4374 bytes --]

Add support for intrusion detection to libsensors.

---
 doc/libsensors-API.txt |    6 ++++++
 lib/Module.mk          |    2 +-
 lib/sensors.h          |    4 ++++
 lib/sysfs.c            |   14 +++++++++++---
 4 files changed, 22 insertions(+), 4 deletions(-)

--- lm-sensors.orig/lib/sensors.h	2010-11-02 12:59:04.000000000 +0100
+++ lm-sensors/lib/sensors.h	2010-11-02 13:00:26.000000000 +0100
@@ -141,6 +141,7 @@ typedef enum sensors_feature_type {
 	SENSORS_FEATURE_ENERGY		= 0x04,
 	SENSORS_FEATURE_CURR		= 0x05,
 	SENSORS_FEATURE_VID		= 0x10,
+	SENSORS_FEATURE_INTRUSION	= 0x11,
 	SENSORS_FEATURE_BEEP_ENABLE	= 0x18,
 	SENSORS_FEATURE_UNKNOWN		= INT_MAX,
 } sensors_feature_type;
@@ -198,6 +199,9 @@ typedef enum sensors_subfeature_type {
 
 	SENSORS_SUBFEATURE_VID = SENSORS_FEATURE_VID << 8,
 
+	SENSORS_SUBFEATURE_INTRUSION_ALARM = SENSORS_FEATURE_INTRUSION << 8,
+	SENSORS_SUBFEATURE_INTRUSION_BEEP,
+
 	SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_BEEP_ENABLE << 8,
 
 	SENSORS_SUBFEATURE_UNKNOWN = INT_MAX,
--- lm-sensors.orig/lib/sysfs.c	2010-11-02 12:59:04.000000000 +0100
+++ lm-sensors/lib/sysfs.c	2010-11-02 13:00:26.000000000 +0100
@@ -137,14 +137,14 @@ static int sysfs_foreach_busdev(const ch
 char sensors_sysfs_mount[NAME_MAX];
 
 #define MAX_MAIN_SENSOR_TYPES	6
-#define MAX_OTHER_SENSOR_TYPES	1
+#define MAX_OTHER_SENSOR_TYPES	2
 #define MAX_SENSORS_PER_TYPE	24
 #define MAX_SUBFEATURES		8
 #define FEATURE_SIZE		(MAX_SUBFEATURES * 2)
 #define FEATURE_TYPE_SIZE	(MAX_SENSORS_PER_TYPE * FEATURE_SIZE)
 
-/* Room for all 6 main types (in, fan, temp, power, energy, current) and 1
-   other type (VID) with all their subfeatures + misc features */
+/* Room for all 6 main types (in, fan, temp, power, energy, current) and 2
+   other types (VID, intrusion) with all their subfeatures + misc features */
 #define SUB_OFFSET_OTHER	(MAX_MAIN_SENSOR_TYPES * FEATURE_TYPE_SIZE)
 #define SUB_OFFSET_MISC		(SUB_OFFSET_OTHER + \
 				 MAX_OTHER_SENSOR_TYPES * FEATURE_TYPE_SIZE)
@@ -190,6 +190,7 @@ char *get_feature_name(sensors_feature_t
 	case SENSORS_FEATURE_POWER:
 	case SENSORS_FEATURE_ENERGY:
 	case SENSORS_FEATURE_CURR:
+	case SENSORS_FEATURE_INTRUSION:
 		underscore = strchr(sfname, '_');
 		name = strndup(sfname, underscore - sfname);
 		if (!name)
@@ -289,6 +290,11 @@ static const struct subfeature_type_matc
 	{ NULL, 0 }
 };
 
+static const struct subfeature_type_match intrusion_matches[] = {
+	{ "alarm", SENSORS_SUBFEATURE_INTRUSION_ALARM },
+	{ "beep", SENSORS_SUBFEATURE_INTRUSION_BEEP },
+	{ NULL, 0 }
+};
 static struct feature_type_match matches[] = {
 	{ "temp%d%c", temp_matches },
 	{ "in%d%c", in_matches },
@@ -297,6 +303,7 @@ static struct feature_type_match matches
 	{ "power%d%c", power_matches },
 	{ "curr%d%c", curr_matches },
 	{ "energy%d%c", energy_matches },
+	{ "intrusion%d%c", intrusion_matches },
 };
 
 /* Return the subfeature type and channel number based on the subfeature
@@ -411,6 +418,7 @@ static int sensors_read_dynamic_chip(sen
 		   sorted table */
 		switch (ftype) {
 		case SENSORS_FEATURE_VID:
+		case SENSORS_FEATURE_INTRUSION:
 			i = SUB_OFFSET_OTHER +
 			    (ftype - SENSORS_FEATURE_VID) * FEATURE_TYPE_SIZE +
 			    nr * FEATURE_SIZE + (sftype & 0xFF);
--- lm-sensors.orig/doc/libsensors-API.txt	2010-10-10 20:20:31.000000000 +0200
+++ lm-sensors/doc/libsensors-API.txt	2010-11-02 13:01:58.000000000 +0100
@@ -6,6 +6,12 @@ over time. This document summarizes thes
 authors can quickly figure out how to test for the availability of a
 given new feature.
 
+0x431	lm-sensors SVN
+* Added support for intrusion detection
+  enum sensors_feature_type SENSORS_FEATURE_INTRUSION
+  enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_ALARM
+  enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_BEEP
+
 0x430	lm-sensors 3.2.0
 * License changed from GPL to LGPL
 
--- lm-sensors.orig/lib/Module.mk	2010-10-10 20:03:08.000000000 +0200
+++ lm-sensors/lib/Module.mk	2010-11-02 13:02:18.000000000 +0100
@@ -33,7 +33,7 @@ LIBMAN5FILES := $(MODULE_DIR)/sensors.co
 # changed in a backward incompatible way.  The interface is defined by
 # the public header files - in this case they are error.h and sensors.h.
 LIBMAINVER := 4
-LIBMINORVER := 3.0
+LIBMINORVER := 3.1
 LIBVER := $(LIBMAINVER).$(LIBMINORVER)
 
 # The static lib name, the shared lib name, and the internal ('so') name of

[-- Attachment #3: sensors-add-intrusion-detection-support.patch --]
[-- Type: text/x-patch, Size: 1809 bytes --]

Add support for intrusion detection to sensors.

---
 prog/sensors/chips.c |   26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

--- lm-sensors.orig/prog/sensors/chips.c	2010-11-02 13:37:40.000000000 +0100
+++ lm-sensors/prog/sensors/chips.c	2010-11-02 13:38:10.000000000 +0100
@@ -2,7 +2,7 @@
     chips.c - Part of sensors, a user-space program for hardware monitoring
     Copyright (C) 1998-2003  Frodo Looijaard <frodol@dds.nl> and
                              Mark D. Studebaker <mdsxyz123@yahoo.com>
-    Copyright (C) 2007       Jean Delvare <khali@linux-fr.org>
+    Copyright (C) 2007-2010  Jean Delvare <khali@linux-fr.org>
 
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
@@ -661,6 +661,27 @@ static void print_chip_curr(const sensor
 	printf("\n");
 }
 
+static void print_chip_intrusion(const sensors_chip_name *name,
+				 const sensors_feature *feature,
+				 int label_size)
+{
+	char *label;
+	const sensors_subfeature *subfeature;
+	double alarm;
+
+	subfeature = sensors_get_subfeature(name, feature,
+					    SENSORS_SUBFEATURE_INTRUSION_ALARM);
+	if (!subfeature)
+		return;
+
+	if ((label = sensors_get_label(name, feature))
+	 && !sensors_get_value(name, subfeature->number, &alarm)) {
+		print_label(label, label_size);
+		printf("%s\n", alarm ? "ALARM" : "OK");
+	}
+	free(label);
+}
+
 void print_chip(const sensors_chip_name *name)
 {
 	const sensors_feature *feature;
@@ -695,6 +716,9 @@ void print_chip(const sensors_chip_name
 		case SENSORS_FEATURE_CURR:
 			print_chip_curr(name, feature, label_size);
 			break;
+		case SENSORS_FEATURE_INTRUSION:
+			print_chip_intrusion(name, feature, label_size);
+			break;
 		default:
 			continue;
 		}

[-- Attachment #4: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Guenter Roeck]

On Tue, Nov 02, 2010 at 09:21:02AM -0400, Jean Delvare wrote:
> Hi Fred,
> 
> Please don't top-post.
> 
> On Tue, 12 Oct 2010 09:15:03 +0200, Fred . wrote:
> > I am sorry tha I do not have the nescesary equipment nor skill set in
> > order to be able to help test
> > or contribute with code.
> > 
> > Now since the interface definition is upstreams, I hope that someone
> > may implement the feature
> > in at least one of the drivers.
> 
> This is done now: the new w83795 hardware monitoring driver implements
> the standard intrusion detection interface.
> 
> I have written user-space code to use that interface. I have two
> patches, one for libsensors, one for sensors, both apply on top of
> lm-sensors SVN, if anyone wants to give them a try. I've attached them.
> They work OK for me, I'll commit them soon unless someone finds and
> reports a problem with them.
> 
> Then we will have to convert the remaining drivers. I found 3 drivers
> which need to be converted: adm9240, w83792d and w83793. If there are
> more, please let me know.
> 
Reminds me. I have a set of patches for those almost ready for submission.
Hope you didn't do the same work ;).

Code below looks ok.

Guenter

> -- 
> Jean Delvare

> Add support for intrusion detection to libsensors.
> 
> ---
>  doc/libsensors-API.txt |    6 ++++++
>  lib/Module.mk          |    2 +-
>  lib/sensors.h          |    4 ++++
>  lib/sysfs.c            |   14 +++++++++++---
>  4 files changed, 22 insertions(+), 4 deletions(-)
> 
> --- lm-sensors.orig/lib/sensors.h	2010-11-02 12:59:04.000000000 +0100
> +++ lm-sensors/lib/sensors.h	2010-11-02 13:00:26.000000000 +0100
> @@ -141,6 +141,7 @@ typedef enum sensors_feature_type {
>  	SENSORS_FEATURE_ENERGY		= 0x04,
>  	SENSORS_FEATURE_CURR		= 0x05,
>  	SENSORS_FEATURE_VID		= 0x10,
> +	SENSORS_FEATURE_INTRUSION	= 0x11,
>  	SENSORS_FEATURE_BEEP_ENABLE	= 0x18,
>  	SENSORS_FEATURE_UNKNOWN		= INT_MAX,
>  } sensors_feature_type;
> @@ -198,6 +199,9 @@ typedef enum sensors_subfeature_type {
>  
>  	SENSORS_SUBFEATURE_VID = SENSORS_FEATURE_VID << 8,
>  
> +	SENSORS_SUBFEATURE_INTRUSION_ALARM = SENSORS_FEATURE_INTRUSION << 8,
> +	SENSORS_SUBFEATURE_INTRUSION_BEEP,
> +
>  	SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_BEEP_ENABLE << 8,
>  
>  	SENSORS_SUBFEATURE_UNKNOWN = INT_MAX,
> --- lm-sensors.orig/lib/sysfs.c	2010-11-02 12:59:04.000000000 +0100
> +++ lm-sensors/lib/sysfs.c	2010-11-02 13:00:26.000000000 +0100
> @@ -137,14 +137,14 @@ static int sysfs_foreach_busdev(const ch
>  char sensors_sysfs_mount[NAME_MAX];
>  
>  #define MAX_MAIN_SENSOR_TYPES	6
> -#define MAX_OTHER_SENSOR_TYPES	1
> +#define MAX_OTHER_SENSOR_TYPES	2
>  #define MAX_SENSORS_PER_TYPE	24
>  #define MAX_SUBFEATURES		8
>  #define FEATURE_SIZE		(MAX_SUBFEATURES * 2)
>  #define FEATURE_TYPE_SIZE	(MAX_SENSORS_PER_TYPE * FEATURE_SIZE)
>  
> -/* Room for all 6 main types (in, fan, temp, power, energy, current) and 1
> -   other type (VID) with all their subfeatures + misc features */
> +/* Room for all 6 main types (in, fan, temp, power, energy, current) and 2
> +   other types (VID, intrusion) with all their subfeatures + misc features */
>  #define SUB_OFFSET_OTHER	(MAX_MAIN_SENSOR_TYPES * FEATURE_TYPE_SIZE)
>  #define SUB_OFFSET_MISC		(SUB_OFFSET_OTHER + \
>  				 MAX_OTHER_SENSOR_TYPES * FEATURE_TYPE_SIZE)
> @@ -190,6 +190,7 @@ char *get_feature_name(sensors_feature_t
>  	case SENSORS_FEATURE_POWER:
>  	case SENSORS_FEATURE_ENERGY:
>  	case SENSORS_FEATURE_CURR:
> +	case SENSORS_FEATURE_INTRUSION:
>  		underscore = strchr(sfname, '_');
>  		name = strndup(sfname, underscore - sfname);
>  		if (!name)
> @@ -289,6 +290,11 @@ static const struct subfeature_type_matc
>  	{ NULL, 0 }
>  };
>  
> +static const struct subfeature_type_match intrusion_matches[] = {
> +	{ "alarm", SENSORS_SUBFEATURE_INTRUSION_ALARM },
> +	{ "beep", SENSORS_SUBFEATURE_INTRUSION_BEEP },
> +	{ NULL, 0 }
> +};
>  static struct feature_type_match matches[] = {
>  	{ "temp%d%c", temp_matches },
>  	{ "in%d%c", in_matches },
> @@ -297,6 +303,7 @@ static struct feature_type_match matches
>  	{ "power%d%c", power_matches },
>  	{ "curr%d%c", curr_matches },
>  	{ "energy%d%c", energy_matches },
> +	{ "intrusion%d%c", intrusion_matches },
>  };
>  
>  /* Return the subfeature type and channel number based on the subfeature
> @@ -411,6 +418,7 @@ static int sensors_read_dynamic_chip(sen
>  		   sorted table */
>  		switch (ftype) {
>  		case SENSORS_FEATURE_VID:
> +		case SENSORS_FEATURE_INTRUSION:
>  			i = SUB_OFFSET_OTHER +
>  			    (ftype - SENSORS_FEATURE_VID) * FEATURE_TYPE_SIZE +
>  			    nr * FEATURE_SIZE + (sftype & 0xFF);
> --- lm-sensors.orig/doc/libsensors-API.txt	2010-10-10 20:20:31.000000000 +0200
> +++ lm-sensors/doc/libsensors-API.txt	2010-11-02 13:01:58.000000000 +0100
> @@ -6,6 +6,12 @@ over time. This document summarizes thes
>  authors can quickly figure out how to test for the availability of a
>  given new feature.
>  
> +0x431	lm-sensors SVN
> +* Added support for intrusion detection
> +  enum sensors_feature_type SENSORS_FEATURE_INTRUSION
> +  enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_ALARM
> +  enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_BEEP
> +
>  0x430	lm-sensors 3.2.0
>  * License changed from GPL to LGPL
>  
> --- lm-sensors.orig/lib/Module.mk	2010-10-10 20:03:08.000000000 +0200
> +++ lm-sensors/lib/Module.mk	2010-11-02 13:02:18.000000000 +0100
> @@ -33,7 +33,7 @@ LIBMAN5FILES := $(MODULE_DIR)/sensors.co
>  # changed in a backward incompatible way.  The interface is defined by
>  # the public header files - in this case they are error.h and sensors.h.
>  LIBMAINVER := 4
> -LIBMINORVER := 3.0
> +LIBMINORVER := 3.1
>  LIBVER := $(LIBMAINVER).$(LIBMINORVER)
>  
>  # The static lib name, the shared lib name, and the internal ('so') name of

> Add support for intrusion detection to sensors.
> 
> ---
>  prog/sensors/chips.c |   26 +++++++++++++++++++++++++-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> --- lm-sensors.orig/prog/sensors/chips.c	2010-11-02 13:37:40.000000000 +0100
> +++ lm-sensors/prog/sensors/chips.c	2010-11-02 13:38:10.000000000 +0100
> @@ -2,7 +2,7 @@
>      chips.c - Part of sensors, a user-space program for hardware monitoring
>      Copyright (C) 1998-2003  Frodo Looijaard <frodol@dds.nl> and
>                               Mark D. Studebaker <mdsxyz123@yahoo.com>
> -    Copyright (C) 2007       Jean Delvare <khali@linux-fr.org>
> +    Copyright (C) 2007-2010  Jean Delvare <khali@linux-fr.org>
>  
>      This program is free software; you can redistribute it and/or modify
>      it under the terms of the GNU General Public License as published by
> @@ -661,6 +661,27 @@ static void print_chip_curr(const sensor
>  	printf("\n");
>  }
>  
> +static void print_chip_intrusion(const sensors_chip_name *name,
> +				 const sensors_feature *feature,
> +				 int label_size)
> +{
> +	char *label;
> +	const sensors_subfeature *subfeature;
> +	double alarm;
> +
> +	subfeature = sensors_get_subfeature(name, feature,
> +					    SENSORS_SUBFEATURE_INTRUSION_ALARM);
> +	if (!subfeature)
> +		return;
> +
> +	if ((label = sensors_get_label(name, feature))
> +	 && !sensors_get_value(name, subfeature->number, &alarm)) {
> +		print_label(label, label_size);
> +		printf("%s\n", alarm ? "ALARM" : "OK");
> +	}
> +	free(label);
> +}
> +
>  void print_chip(const sensors_chip_name *name)
>  {
>  	const sensors_feature *feature;
> @@ -695,6 +716,9 @@ void print_chip(const sensors_chip_name
>  		case SENSORS_FEATURE_CURR:
>  			print_chip_curr(name, feature, label_size);
>  			break;
> +		case SENSORS_FEATURE_INTRUSION:
> +			print_chip_intrusion(name, feature, label_size);
> +			break;
>  		default:
>  			continue;
>  		}


-- 
Guenter Roeck
Distinguished Engineer
PDU IP Systems

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Jean Delvare]

On Tue, 2 Nov 2010 07:04:56 -0700, Guenter Roeck wrote:
> On Tue, Nov 02, 2010 at 09:21:02AM -0400, Jean Delvare wrote:
> > Hi Fred,
> > 
> > Please don't top-post.
> > 
> > On Tue, 12 Oct 2010 09:15:03 +0200, Fred . wrote:
> > > I am sorry tha I do not have the nescesary equipment nor skill set in
> > > order to be able to help test
> > > or contribute with code.
> > > 
> > > Now since the interface definition is upstreams, I hope that someone
> > > may implement the feature
> > > in at least one of the drivers.
> > 
> > This is done now: the new w83795 hardware monitoring driver implements
> > the standard intrusion detection interface.
> > 
> > I have written user-space code to use that interface. I have two
> > patches, one for libsensors, one for sensors, both apply on top of
> > lm-sensors SVN, if anyone wants to give them a try. I've attached them.
> > They work OK for me, I'll commit them soon unless someone finds and
> > reports a problem with them.
> > 
> > Then we will have to convert the remaining drivers. I found 3 drivers
> > which need to be converted: adm9240, w83792d and w83793. If there are
> > more, please let me know.
> > 
> Reminds me. I have a set of patches for those almost ready for submission.
> Hope you didn't do the same work ;).

I just did :( I should have read my mail earlier. Well at least we'll
see if we agree on what needs to be done and how to do it.

> 
> Code below looks ok.

Thanks for the review.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Guenter Roeck]

On Tue, Nov 02, 2010 at 10:29:23AM -0400, Jean Delvare wrote:
[ ... ]
> > Reminds me. I have a set of patches for those almost ready for submission.
> > Hope you didn't do the same work ;).
> 
> I just did :( I should have read my mail earlier. Well at least we'll
> see if we agree on what needs to be done and how to do it.
> 
My fault. Nothing you could have done about it. I wrote the patches
after the original e-mail exchange and then forgot about it.
Sorry for wasting your time.

Big question remains - want to go with your or my patches ? I'd suggest yours
unless they are not ready, since you know the code and chips better than I do.
Otherwise I can send out mine for review later today.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Jean Delvare]

Hi Guenter,

On Tue, 2 Nov 2010 08:18:16 -0700, Guenter Roeck wrote:
> On Tue, Nov 02, 2010 at 10:29:23AM -0400, Jean Delvare wrote:
> [ ... ]
> > > Reminds me. I have a set of patches for those almost ready for submission.
> > > Hope you didn't do the same work ;).
> > 
> > I just did :( I should have read my mail earlier. Well at least we'll
> > see if we agree on what needs to be done and how to do it.
> > 
> My fault. Nothing you could have done about it. I wrote the patches
> after the original e-mail exchange and then forgot about it.
> Sorry for wasting your time.
> 
> Big question remains - want to go with your or my patches ? I'd suggest yours
> unless they are not ready, since you know the code and chips better than I do.
> Otherwise I can send out mine for review later today.

OK, let's go with mine. I'll post them later today, please review them
if you have time.

Note that I am not specially familiar with the w83792d and w83793
drivers. And I don't have a test device for any of the 3 drivers
(register dumps don't work for that kind of thing.) It might be
difficult to find testers, as not all boards with these chips have the
case open pin wired, and not all cases have an intrusion detection
switch.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC v2] Support of chassis intrusion detection

[Fred .]

Sweet!
Looking forward to 3.2.1. ;)

On Tue, Nov 2, 2010 at 2:21 PM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Fred,
>
> Please don't top-post.
>
> On Tue, 12 Oct 2010 09:15:03 +0200, Fred . wrote:
>> I am sorry tha I do not have the nescesary equipment nor skill set in
>> order to be able to help test
>> or contribute with code.
>>
>> Now since the interface definition is upstreams, I hope that someone
>> may implement the feature
>> in at least one of the drivers.
>
> This is done now: the new w83795 hardware monitoring driver implements
> the standard intrusion detection interface.
>
> I have written user-space code to use that interface. I have two
> patches, one for libsensors, one for sensors, both apply on top of
> lm-sensors SVN, if anyone wants to give them a try. I've attached them.
> They work OK for me, I'll commit them soon unless someone finds and
> reports a problem with them.
>
> Then we will have to convert the remaining drivers. I found 3 drivers
> which need to be converted: adm9240, w83792d and w83793. If there are
> more, please let me know.
>
> --
> Jean Delvare
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors