Bug#575810: lmSensors support only returns first subfeartures on each chips

2010-05-02 Thread Marc Dequènes (Duck)

Coin,

I had a partial listing of my sensors via SNMP, compared with the  
output of the 'sensors' command. I applied this patch and it is now  
working perfectly.


Please apply this fix before the Squeeze freeze.

Regards.

--
Marc Dequènes (Duck)


pgp5oBnPDBTnt.pgp
Description: PGP Digital Signature


Bug#575810: lmSensors support only returns first subfeartures on each chips

2010-03-29 Thread ISHIKAWA Mutsumi
Package: libsnmp15
Version: 5.4.2.1~dfsg-5
Severity: Normal
Tags: patch

 Current debian/patches/60_libsensors_api.patch contains needless
subfearture mapping value check. This cause only returns first main
feature related values on each sensor chips.

--- debian/patches/60_libsensors_api.patch~ 2010-03-29 21:10:42.0 
+0900
+++ debian/patches/60_libsensors_api.patch  2010-03-29 21:24:38.0 
+0900
@@ -212,7 +212,7 @@
  int chip_nr = 0;
  int rc = 0;
  unsigned inti = 0;
-@@ -961,18 +953,19 @@ else{
+@@ -961,18 +953,18 @@ else{
  sensor_array[i].current_len = DEFAULT_SENSORS;
  } /* end for */
  
@@ -233,7 +233,6 @@
 -!sensors_get_label(*chip, data-number, label) 
 -!sensors_get_feature(*chip, data-number, val)) {
 +if ((subfeature-flags  SENSORS_MODE_R) 
-+(subfeature-mapping == 0) 
 +(label = sensors_get_label(chip, feature)) 
 +!sensors_get_value(chip, subfeature-number, val)) {
  int type = -1;


 subfearture's type is `struct sensors_subfeature', it is
described in include/sensors/sensors.h:



/* Data about a single chip subfeature:
   name is the string name used to refer to this subfeature (in config files)
   number is the internal subfeature number, used in many functions to refer
 to this subfeature
   type is the subfeature type
   mapping is the number of a main feature this subfeature belongs to
 (for example subfeatures fan1_input, fan1_min, fan1_div and fan1_alarm
  are mapped to main feature fan1)
   flags is a bitfield, its value is a combination of SENSORS_MODE_R (readable),
 SENSORS_MODE_W (writable) and SENSORS_COMPUTE_MAPPING (affected by the
 computation rules of the main feature) */
typedef struct sensors_subfeature {
char *name;
int number;
sensors_subfeature_type type;
int mapping;
unsigned int flags;
} sensors_subfeature;


 Each main feature has individual id's and mapping is indicate the id.
For Example When fan1 (described above) has id = 0, all subfeature of
fan1 (fan1_input, fan1_min, fan1_div and fan1_alarm described above)
have `mapping = 0'. And fan2 on same chips has id = 1, all subfeatures of
fan2 (For example fan2_input, fan1_min and so on) have `mapping = 1'.

 So, subfeature-mapping != 0 is VALID.

 Please drop `subfeature-mapping == 0' check on sensors handling
function (as above patch).


-- 
ISHIKAWA Mutsumi
 ishik...@debian.org, ishik...@hanzubon.jp, ishik...@osdn.jp


60_libsensors_api.patch_fix.diff
Description: Binary data