updates

git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1648 7894878c-1315-0410-8ee3-d5d059ff63e0

doc/developers/new_drivers

@@ -1,5 +1,6 @@
 These are the steps you should follow to write a new driver and
 submit it to us so that it will be applied cleanly to our package.
+See at the bottom for adding new chip support to an existing driver.
 
 Don't be intimidated by the list, it's just here so we don't
 forget anything.
@@ -37,6 +38,7 @@ Steps which apply to only one type of driver are noted.
   Be sure and use 8 column tabs.
   Also, please do not use // comments.
   Also, please do not go past column 80.
+  Also, please use C99 struct initializers {.foo = blat}
   Please do this _before_ you check in your driver.
 
 * Add sysctl definitions to kernel/include/sensors.h (for chip drivers only).
@@ -140,3 +142,33 @@ Checklist for mkpatch support, after the driver is tested and stable:
 
 * Move .o reference in kernel/[chips,busses]/Module.mk
   from first to second section.
+
+
+---------------------------------------------------------------------
+Checklist for _adding_ support for a chip to an _existing_ driver:
+
+* Make the changes to the driver itself.
+
+* Add detection information to prog/detect/sensors-detect.
+
+* Add a strncmp() call for the new prefix in prog/sensors/main.c
+  (chip drivers only).
+
+* Add entries for the new prefix to etc/sensors.conf.eg (chip drivers only).
+
+* Update config help in mkpatch/mkpatch.pl.
+
+* Update config entry in mkpatch/Config.in (chip drivers only)
+
+* Update config entry in mkpatch/mkpatch.pl (bus drivers only)
+
+* Update doc/[chips,busses]/xxx file
+
+* Update doc/chips/SUMMARY file (chip drivers only)
+
+* Update list in README
+
+* Submit the changes as a patch or check them in
+
+* Update entry on 'new drivers' page
+

doc/developers/proc

@@ -34,12 +34,19 @@ There is no facility in the lm_sensors package for drivers
 to output general strings via /proc. This facility may be added
 in the future.
 
+Alarms are direct indications read from the chips. The drivers do NOT make
+comparisons of readings to thresholds. This allows violations
+between readings to be caught and alarmed. The exact definition of
+an alarm (for example, whether a threshold must be met or must be
+exceeded to cause an alarm) is chip-dependent.
+
 Guidelines for new entries:
 	- If there are multiple values, some r/w and some r/o,
 	  put the r/w ones first.
 	- Additional non-standard values should be after the standard values.
 
 
+
 -------------------------------------------------------------------------
 
 /proc entries are as follows:
@@ -66,7 +73,7 @@ beep	  2     Beep/interrupt enable and bitmask.
 		same format as 'alarms' with same bit locations.
 		
 curr[1-n]  3	Current max, min or hysteresis, and input value.
-	       	Floating point values XXX.X or XXX.XX in Amps.
+	       	Floating point values XX.X or XX.XX in Amps.
 		The second value is preferably a hysteresis value,
 		reported as a absolute current, NOT a delta from
 		the max value.